こんにちは。@nari_ex です。
今回は、インシデントマネジメントのプラクティスの一つである重大度(Severity)を紹介します。
重大度とは?
重大度とは、イベントがシステムやビジネスに与える影響の深刻さを評価・分類する指標です。主に対応の優先度を判断するために使われ、インシデントレスポンスにおけるトリアージに役立ちます。インシデントマネジメントの実務では欠かせない概念です。
このプラクティスは、医療分野におけるトリアージのプラクティス(START法)によって定義されるトリアージ・タッグに類似したものです。
トリアージタッグは、傷病者の緊急度と治療優先度を示す色付きタグ(札)を付与することで、迅速かつ適切に傷病者の緊急度・優先度を分類するためのプラクティスです。とりわけ多数傷病者(Mass Casualty Incident, MCI)が発生した際に利用されます。一般的なタグの色と対応内容は以下の通りです。
| 色 | カテゴリ名 | 意味・対応内容 |
|---|---|---|
| 黒 | 死亡/救命不能(Expectant) | すでに死亡しているか、極めて重篤で救命の見込みがない |
| 赤 | 緊急(Immediate) | 今すぐ処置が必要。放置すれば生命の危険がある |
| 黄 | 準緊急(Delayed) | 重症だがしばらくは安定しており、処置を後回しにできる |
| 緑 | 軽症(Minimal) | 自力歩行可能な軽症者。処置の優先度は最も低い |
色の種類と意味をチーム全体で共通認識しておくことで、患者の現在のステータスと必要な対応内容が瞬時に理解できるようになります。結果として、タグに基づいて複数人が能動的に対応できるようになります。
システムインシデントの現場でも、このプラクティスを用いることによってインシデント対応をより効率的に行うことができます。
重大度の具体的なメリット
軽微なインシデントはごく少数のメンバーで対処可能ですが、深刻なインシデントはロールの異なるメンバーが複数人で協力して対応する必要があります。つまり、インシデントの深刻さ(重大度)によって対応の仕方が変わります。
重大度を定義して運用するメリットは、組織全体に対して対応内容や判断軸を瞬時にスイッチできることです。代表的な効果は以下の4点です。
1. 優先順位
複数のインシデントが生じた場合に、重大度ははどのインシデントを優先すべきなのかを決める指標として利用できます。
また、当該インシデント対応の緊急性(ex. 翌営業日の営業時間帯に対応すればよいのか、休日深夜でも対応しなければいけないのか)を判断する際にも役立ちます。
2. 人的リソースの割当
重大度を定義することは、インシデント対応に過剰な人員アサインを防いだり、迅速に重要なリソースを割り当てることに役立ちます。対応メンバーをスケールイン・スケールアウトさせる際の調整弁として重大度は効果的です。
通常、重大度の高いインシデントでは、カスタマーサポート、セールス、PdM、経営層、テクニカルエキスパート、あるいは部門横断チームの関与など、より重要なリソースの割り当てが必要になります。重大度の低いインシデントでは、リソースを絞って対応することで、ほかメンバーはより優先度の高い問題に集中することができます。
3. コミュニケーションとエスカレーション
重大度は、組織内のコミュニケーションに共通言語を提供し、明確な期待を確立するのに役立ちます。利害関係者が重大度レベルを理解すれば、それに応じて対応とエスカレーションのプロセスを調整することができます。
4. 継続的な改善
重大度は、インシデント発生後の分析と継続的な改善の取り組みに貢献します。インシデントを重大度に基づいて分類することで、パターンを分析し、改善のための領域を特定することができます。
データドリブンなアプローチは、SREカルチャー醸成に必要な最終ステップするステップにもマッチしたものであり、繰り返し発生する重大度の高いインシデントを特定し、根本原因を特定し、将来の停止による影響を軽減するための予防措置を実施するのに役立ちます。
重大度の定義例
重大度の定義は、組織内で共通認識を持てるか、具体的なアクションが紐づくかが重要なポイントです。
重大度レベルを示すラベルは、海外の事例や伝統的なインシデントマネジメントツールではP0〜P4, SEV1〜SEV5を利用する例が多いです。ここ数年で登場したツールについては、英単語を用いて表現するケースが増えてきている印象です。
以下に示すのは重大度の定義の例です。文章で定義する例もありますが、Topotalではより理解を促進させるために表形式でカテゴリごとに明記するフォーマットを推奨しています。
| レベル | 定義(影響度) | 緊急度 | オンコール | コミュニケーション |
|---|---|---|---|---|
| CRITICAL(P0) | 全体または大多数の顧客に対して重要機能が停止、深刻な体験劣化が生じている | 即時対応が必要(24h365d、即着手) | 対応可能なすべての関係者にページング | 経営幹部に通知。全顧客向けの公開コミュニケーションを検討 |
| HIGH(P1) | 大多数の顧客に対して明確に不便を感じさせる劣化が生じている | 迅速な対応が必要(24h365d、15分以内着手) | 該当エンジニアチームにページング | 関連エンジニアチームのリーダーに通知。 影響を受けた顧客へのコミュニケーションを検討 |
| WARNING(P2) | 一部の顧客に対して顧客体験の軽度な劣化が生じている | 営業時間帯に他の業務よりも優先して対応 | 営業時間内のみページング | 関連エンジニアチームのマネージャーに通知。 重要顧客のみ対応検討 |
| INFO(P3) | 顧客体験に目立った劣化がないか、非常に軽微な影響が生じている | 通常業務と並行して勤務時間内に対応 | ページング不要 | 関連エンジニアチームのマネージャーに通知。顧客向け通知は不要 |
また、重大度はポストモーテム作成基準としても役立ちます。たとえば「CRITICAlとHIGHは必須、WARNINGは任意、INFOは不要」と定義しておくことで、ポストモーテムを作成すべきかどうかを迷わずに判断することができます。
コラム: Waroom標準の重大度について
Topotalが提供するWaroomでは、インシデントレスポンスに不慣れなメンバーにも直感的に伝わりやすいように数値表現は避け、CRITICAL〜INFOという単語を用いて定義しています。これらのラベルは、日本語でのカスタマイズも可能です。
また、重大度レベルは4段階にしています。5段階は複雑かつ高度なので広くおすすめはしづらい、3段階は評価が大味になりやすく使いづらいという理由から、4段階の重大度をデフォルトで提供しています。
UNKNOWN レベル
Waroomでは重大度が判別できないときに一時的に利用するレベル UNKNOWNも用意しています。これはインシデント起票時の入力負担を減らす意図があります。 先ほどWaroomの定義は4段階と説明しましたが、厳密には4+1のレベル定義を提供しています。
インシデントレスポンスの初動を自動化した先では、重大度を定義することは、ともすると重要なメンバーを強制的に動員するスイッチを押すこと(またはあえて押さないこと)を意味します。インシデント起票時にこのような社内インパクトの大きい判断に躊躇して時間を浪費するケースは、慣れていないメンバーであればあるほど顕著になります。また、熟練のエンジニアでも単に即時判断できないケースはあります。
上記のケースにおいて、重篤度判断を保留にしたことを示すラベル UNKNOWN は有効です。
このように、Waroomでは組織が中長期的な改善を行うために、さまざまなメンバーが気軽かつ迅速にインシデント起票できる環境づくりを心がけています。
まとめ
インシデントマネジメントにおける重大度(Severity)に関する知見を共有しました。
システムインシデントに関するプラクティスは医療の現場から学びを得て応用しているケースが多く、重大度の定義はその代表的な例の一つです。
重大度の定義は、とにかく実践的かどうかが重要だと考えています。インシデントが起こる前に組織内で共通認識を構築することは、効率的なインシデントレスポンスを行う第一歩です。
また、定義したあとはフィードバックを集めながら定期的な見直しを行うことも重要です。サービス特性や求められるサービスレベルにあわせて定義をブラッシュアップする必要があります。
今回例示した重大度定義の考え方や定義のフレームワークがインシデントマネジメント改善に役立てば幸いです。
勉強会を行います

インシデントの属人化と生成AIについての勉強会を行います!
オンラインイベントのためお気軽にご参加頂けると幸いです
生成 AIは “Incident Buddy” になり得るのか? - connpass
最後に
TopotalはSREを軸にしたスタートアップです。
本記事で紹介した Waroom やSREの支援やにご興味がありましたら気軽にお問い合わせください。
また、SRE as a Serviceをともに提供するSite Reliability EngineerやWaroomを開発するバックエンドエンジニア(Ruby on Rails)を募集しています。SREのプラクティスを用いて世の中の開発・運用の現場を一緒に変革していきましょう。
もし気になる方はカジュアル面談のお申し込みをお願いします!
