In my job, I use a number of collaboration tools. From email and instant messaging to browser-based collaboration platforms, they help me get information, generate information, and share information. My ambition is that the vast majority of questions any of my colleagues may have about the peculiarities of our customer-facing systems. Our documentation systems are open – at least to reading – by default. This way, anyone can look up information on any system.
For many technicians, a critical incident will trigger something akin to an adrenaline response. With experience, this will give you focus and clarity of thought as the incident unfolds. However, the response can only be sustained for a limited amount of time, and once it is over, you will likely experience some tangible aftereffects.
Last week, we discussed urgency, impact and priority, as these things pertain to incidents in ITIL. As I mentioned, critical and high priority incidents are mercifully rare. When they do, inevitably, occur, it is imperative that we respond appropriately, and immediately.
It is part of the nature of IT service and support that you will, from time to time, be called upon to handle a high priority, high urgency incident. In most production systems these are mercifully rare, but it is still important that you understand how to identify them.