インシデント重大度1～5の基本

インシデントは、発生するかどうかが問題になるのではありません。いつ発生するかです。システムのクラッシュ、ソフトウェアの障害、ベンダーのサービス停止はいつでも起こり得ます。こうしたインシデントに対する備えは組織の責任であり、インシデントの重大度はその対策に必要な手段の1つです。 

インシデントはビジネスや顧客にさまざまな影響をもたらします。インシデントの重大度は、その影響を分類し、対応方法を決める基準になります。重大度を適切に活用すれば、以下のメリットを実現できます。

• 迅速に対応する
• MTTR (平均修復時間)を短縮する
• 問題が顧客に与える影響について、関係者にできるだけ正確に理解してもらう 

この記事では、インシデントの重大度の概要、活用方法、優先度との違いについて説明します。 

(Splunkソリューションがインシデント管理プロセス全体をどのように支援するのか、こちらをご覧ください)

インシデントの重大度と優先度の違い

重大度と優先度は一見同じように見えます。SEV 1のインシデントが発生した場合、SEV 2よりも優先して対応すべきであることは明らかです。では、重大度と優先度の違いは何でしょうか。 

• 重大度は影響の大きさを基準とします。上記の表に示したように、重大度はユーザーやサービスへの影響の度合いに応じてレベル分けされます。
• 優先度は緊急性を基準とします。優先度は、問題をどのくらいすばやく修正すべきか、どの問題に最初に対処する必要があるかを示します。 

優先度と重大度は、多くの場合、完全に一致します。すべてのユーザーがサービスを利用できなくなるような障害は、優先度が高く、重大度も1です。ただしこれは、技術的な問題とビジネス上の優先順位が一致しているケースです。以下のように、場合によっては優先度と重大度が一致しないこともあります。

• 本番環境に新機能をリリースする場合、優先度は高いかもしれませんが、サービスに問題があるわけではありません。インシデントは発生していないため、重大度は割り当てられません。
• モバイルアプリケーションのUIに恥ずかしいタイプミスがあり、早急に修正する必要がある場合、テクノロジーチームはSEV 5インシデントとして分類するかもしれませんが、優先度は高くなります。 

優先度と重大度が一致しないことがあっても、どちらも状況を伝えるために重要な情報であることは間違いありません。重大度では、問題がいかに深刻であるかを関係者に伝えることができます。優先度では、次に取り組むべき作業を技術担当者に伝えることができます。 

インシデント重大度の定義：ベストプラクティス

インシデントの重大度の考え方はいたってシンプルです。しかし残念ながら、その導入の道のりはシンプルとは言えません。ブログ記事やホワイトペーパーからコピーして今日から実践というわけにはいきません。次のような要素を考慮して、組織に適した定義を考える必要があります。

• ユーザーコミュニティ
• ソフトウェアおよびハードウェアシステム
• ビジネス要件

それでも、以下のベストプラクティスを取り入れれば、重大度の定義(および順守)に役立ちます。

統一が重要

ベストプラクティス：組織全体でレベルと定義を統一する

特に大規模な組織の場合、アプリケーションやソフトウェアスタックごとに異なるインシデント重大度を設定しても問題ないと思うかもしれません。しかし、そもそも重大度を設定することの大きな利点の1つは、インシデントに関する情報を明確に伝えられることです。重大度の設定や定義が複数あると、関係者がインシデントの影響の大きさを正しく理解できず、混乱が生じます。さらに、各アプリケーションを担当するエンジニアや開発者も混乱する可能性があります。 

シンプルに保つ

ベストプラクティス：重大度のレベル数は必要最小限にする。多すぎるのも少なすぎるのも良くない 

レベル数が多すぎると、すぐに混乱を招きます。インシデントの重大度を設定する理由の1つは、インシデントの発生時に重大度を割り当てることで、すばやく対応に取り掛かれるようにするためです。レベル数が多すぎると、その判断が遅れます。逆に少なすぎると、インシデントの違いがわからなくなります。インシデントごとに微妙な(またはそこそこ大きな)違いがあっても、同じカテゴリに入れられてしまうと、真の重大度を適切に把握できなくなります。 

では、実際にはどのようにすればよいでしょうか。まず、関係者を集めて計画を立てます。過去のインシデントを調べ、それぞれのインシデントが、提案したどのレベルに当てはまるかを確認します。その結果を、当時の根本原因分析と照らし合わせます。入念に検討し、必要であればレベル分けを調整します。 

重大度を割り当てるための明確なガイドラインを設定する

ベストプラクティス：重大度をすばやく判断できるようにする

インシデントに適切な重大度をすばやく割り当てることができなければ、重大度を定義した意味がありません。そのため、重大度を簡単かつ正確に割り当てられるようにするためのガイドラインを設定します。インシデントがどの重大度に該当するかを議論するのは時間の無駄です。

まずはレベルを定義してから、ガイドラインの設定に取り組みます。その際は、以下のような測定可能な影響を基準にします。

• 影響を受けるユーザーの割合
• 機能のカテゴリ
• システムへの影響

インシデントの重大度を活用

これまでの説明で、インシデントの重大度とその活用方法を十分にご理解いただけたのではないでしょうか。重大度は情報を共有するための一種のツールです。うまく活用すれば、問題の影響の大きさを正確に伝え、適切なチームにすばやく対応してもらうことができます。また、重大度と優先度はどちらもインシデントに関連しますが、まったく違う概念であることも覚えておきましょう。  

このブログはこちらの英語ブログの翻訳です。