ITSM - IT Service Management / article

Nailing the incident management process

Update: Check out the new Atlassian Incident Management Handbook to see our full process for responding to incidents.

First, let me get something off my chest: front-line support people are the unsung heroes of every business. Every. Business. I truly believe that tech support should be considered a service industry, and customers should be able to leave tips for agents that deliver excellent service. I would happily leave a ten spot to every killer support person who resolved my issues quickly, and with a smile–if only I could.

But I digress. If you’re reading this, you probably manage or serve on a small to mid-sized help desk team. Your hair is probably also literally on fire right now. It really burns. The smell is awful, too. So let’s do something about that!

このシリーズでは、インシデント管理を 2 つのパートに分けて取り扱います。基本原則、高度なヒント、技術的なハウツーなどを紹介し、より優れたインシデント管理プロセスを迅速にかつ容易に採用する支援を目的とします。各パートは以下のとおりです。

  • Part one: Nail the process
  • Part two: Five Expert tips to manage incidents


インシデントは、サービスの質を損なう、または低下させる (または脅かす) あらゆる種類の予期しないイベントです。ビジネスアプリケーションのダウンは、インシデントです。停止はしていないが著しくパフォーマンスが落ちているウェブサーバーもインシデントです。動作が遅いために、生産性に低下させています。さらに悪くなると、完全な障害を引き起こす大きなリスクをもたらします。

A problem is just the not-yet-known root cause behind one or more incidents. In the incidents above where the printer is down and the network is creeping, a misconfigured router could be the underlying problem behind both.

インシデントの処理方法 (および処理しない方法)

ITIL® を使用して、適切なチケット処理の大まかな概要を説明しますが、他の多くの一般的なフレームワークでも、使われる専門用語は少し異なりますが、ほぼ同様のコンセプトで説明できます。

If you are new to ITIL®, no worries. It’s just a flexible set of guidelines you can follow as you build your own process, based on a ton of real world experience. COBIT, TOGAF, or any other major IT framework can get you to a similar place. I recommend familiarizing yourself with the basic concepts in the beginning to give you an early advantage. ("The more you knowwww...")


Even that can seem daunting, I know. But the good news is that you can learn from thousands of other service desk teams' experiences. One of the top mistakes of busy, growing IT organizations is to try to reinvent the wheel and create processes from scratch (without drawing on best practices), or build their own homegrown tools for fielding tickets. The very act of reading this drastically reduces your risk of falling victim to Not Invented Here Syndrome. Nice one.

Anyway, let's get down to it.


インシデントはどこからでも発生します。従業員から報告を受けることもありますし、ネットワークハブの設置ミスと天井の雨漏りが重なった場合には、文字どおり天井タイルから膝の上に落下することだってありえます (自分の経験を話してるわけではありませんよ......*えへん*)。どこから報告を受けたかに関係なく、最初の 2 つのステップはシンプルです。誰かがインシデントを特定した後に、誰かがそれを記録します。セルフサービスヘルプデスク経由ですでに記録されているインシデントを受信した場合、これらの最初の 2 つのステップはすでに完了しています。インシデントについて電話を受けた場合や E メール、テキスト、または伝言で報告を受けた場合は、それをヘルプデスクシステムに適切に記録するのは、サービスデスクチームの仕事です。通常、これらのインシデント記録 (すなわち、チケット) には以下の内容が含まれます。

  • そのインシデントの報告者の名前
  • The date and time the incident is reported
  • インシデントの説明 (何がダウンしている、または適切に動作していないか)
  • 追跡するためにインシデントに割り当てられた一意の識別番号

Not logging incidents yet? Stop reading here, sign up for any basic service desk solution online (may I suggest Jira Service Desk?), and then resume reading. Go ahead. I'll wait.


次の 2 つのステップ、カテゴリー化と優先順位付けは、どちらも重要ですがよく見過ごされます。ここが、私が使用してきた、より「健全な」サービスデスクが他と大きく異なる点です...まあ、それほどではありませんが。

First, you must assign a logical, intuitive category (and subcategory, as needed) to every incident. If you don’t, you are cutting off your ability to later analyze your data and look for trends and patterns, which is a critical part of effective problem management and preventing future incidents. So basically, just don’t forget. And don’t settle for an IT service desk solution that doesn’t allow you to easily customize incident categories.


Second, every incident must be prioritized. To prioritize an incident, start by assessing its impact on the business. Consider both the number of people that will be impacted, as well as the potential financial, security, and compliance implications of the incident to determine how much pain the incident is causing and how urgent a resolution is to the business.

Then, address all open incidents in order of prioritization. Most organizations set clear service agreements around each level of priority, so customers know how quickly to expect a response and resolution. I highly recommend that practice.




これを病院が新しい患者に行うトリアージ機能として考えてみてください。サービスデスクの従業員は、考えられる問題について迅速な仮説を打ち立てることにより、修正するか、適切な手順に従うか、適切なリソースを集めるかのいずれかに着手できます。ナレッジベースと診断マニュアルは、このステップにおいても有効なツールです。1 次レベルのサービスデスクエージェントが、自身の初期診断に基づいて利用可能なナレッジとツールを使用してインシデントを解決できた場合は、ここで解決済みとなります。そうでない場合は、エスカレーションします。

Incident escalation

エスカレーションは悪い意味に聞こえますが、そうではありません。最前線のサポートチームは、最も一般的なインシデントの多くをエスカレーションせずに解決できるはずです。しかし、解決できない問題の場合、目指すべき目標は 2 次または 3 次レベル (より技術的な) のサポートが即座に対応に取りかかり、迅速にインシデントを解決できるよう、適切な情報を収集して記録することです。


ITIL® は、これを独自の 1 ステップと見なしています。実際には、インシデントのライフサイクル全体を通じて発生します。最前線のサポート担当者は、情報の収集時にすでにある程度調査しており、診断に成功し、エスカレーションする必要なくインシデントの解決すら終わっているかもしれません。その場合は、次の数ステップ、解決と復旧、およびインシデントのクローズに直接進みます。それ以外の場合、レベル 2 と 3 サポートにエスカレーションすると調査と診断が行われます。または、解決を支援するために外部リソースまたは他の部門のメンバーに参加してもらいます。

Resolution and recovery

最終的に、そして理想的には設定されたサービスレベルアグリーメント (SLA) で定めた時間内に、診断を行い、インシデントの解決に必要なステップを実行します。一部の修正 (バグのパッチなど) は、適切な解決策が特定された後も、テストおよびデプロイメントが必要な場合があるため、復旧は単に運用が完全に元どおりになるまでにかかる時間を意味します。


その後、インシデントはサービスデスクに戻され (エスカレーションされた場合)、クローズされます。品質を維持してスムーズなプロセスを確保するため、インシデントのクローズは、サービスデスクの従業員のみに許可されています。インシデントオーナーはインシデントの報告者に解決が満足のいくものであったことを確認する必要があり、確認できたらインシデントをクローズできます。


The process may seem unnecessarily formal, particularly if you only have a few service desk analysts. Regardless of your team structure, though, the incident lifecycle is still the same. Let’s say you only have one service desk analyst, so there is no level three support. But incidents that surpass the knowledge of your service desk analyst have to go somewhere, whether it’s to your chief engineer or an outside consultant or even you, right? Voila! You do indeed have level two or level three support–it’s just you, or your engineer.

My point? Even though ITIL can seem to be all about semantics, don’t get caught up in them. Look for easy ways to adapt your organizational hierarchy and process workflows to fit with an easy IT service management framework like I outlined above. By doing so, you will deliver far better customer service, and deliver much more value back to the business. Plus, your hair will stop burning much faster (bonus points!).

And finally, a few reminders: Log every incident. Give it a unique number. And capture important details (like date, time, and description) in a central help desk system like Jira Service Desk. If you have a large internal or external audience to communicate incident updates to, consider a status page for incident communication. Assign every incident a category (and subcategory, as needed). Give every incident a priority level, and every priority level an SLA. Whenever possible, enable your front line support team with knowledge base articles and incident diagnostic scripts to help them resolve incidents quickly. Make sure the service desk always retains control of incident progress, routing, and status. Don’t just capture incident data. Analyze it! Look for trends, patterns, and potential underlying problems that can reduce incident volume and mitigate risk. Coming up in part two, I'll walk through some expert tips for even better incident handling. See you on the next page!


Nick Wright



Jira Service Desk logo