インシデント対応はシステム運用上避けることのできないものだが、改めて考え直してみると、そのフローについては経験知、暗黙知に頼ってしまっている部分が多いなということに先日気付いた。そこでインシデント対応とは何なのか、どういった原則論に則るべきなのかを客観的に考え直すために、一度主観を廃して、自分が触れてきたリソース上での記述を少し覚え書きとしてまとめてみようと思う。

インシデント対応に関するリソース

インシデント対応を専門として書かれたリソースは案外少ないかも知れない、というのはこの記事を書くにあたり、手元の資料を整理していて感じた。自分がこれまでに触れてきたものとしては、主に以下のものがある。

• ITIL
• Mike Julian (松浦隼人 訳) . 入門 監視. オライリー・ジャパン, 2019, 232p.
• PagerDuty Incident Response Documentation （※リンク先は有志による日本語訳）
• John Allspaw, Jesse Robbins, (角 征典 訳) . ウェブオペレーション : サイト運用管理の実践テクニック. オライリー・ジャパン : オーム社, 2011, 255p.
• Betsy Beyer, Chris Jones, Jennifer Peto, Niall Murphy (Sky株式会社 玉川 竜司 訳) . SRE サイトリライアビリティエンジニアリング. オライリー・ジャパン, 2017, 592p.
• Rob Schnepp, Ron Vidal, Chris Hawley. Incident Management for Operations. "O'Reilly Media, Inc.", 2017, 173p.

自分にとって、特に影響が大きいのはITILかもしれない。ITシステム運用について規格化されたものでは最も知名度があるし、もともと固めの運用に従事していた経験が長いこともあり、v3の頃にCertificateも取得している。

ITILは参考になる一方、厳密に則るとそれなりに運用コストもかかる、「お堅いもの」という印象が否めないのも確かだ。『入門 監視』の中でも、「ほとんどのチームにとっては、このような正式な方法はやりすぎ」として、ITILをそのまま使うのではなく、シンプル化して導入することを促している。僕もそれが現実的な落とし所だと思っている。ITILは残念ながらリソースがオープンなものではないので、そのエッセンスを取り込むなら『入門 監視』を参考にするのがいいかもしれない（余談だが、O'Reilly Online Learningの読み放題のなかでITIL Foundationの日本語訳が読める。これだけで12000円するし、通常販売されているのは物理書籍だけのようなので、ここで電子版を読めるのはちょっとお得）。

PageDuty Incident Response Documentationは、PagerDutyが社内のインシデント対応ドキュメントを縮小して公開しているものにあたる。ITILを除けば、ここに挙げたものの中では最も具体的かつ実践的な内容にまとまっている印象を受ける。

『ウェブオペレーション』『サイトリライアビリティエンジニアリング (SRE book)』はいずれも一部、インシデント対応に言及した章がある。包括的に運用、DevOps、SREに関してまとめた本なので、記述量は他のリソースには劣る。

最後の『Incident Management for Operations (IMO)』だが、これは今回のエントリーを書くにあたって初めて目を通した。SRE bookとPagerDuty Documentationを改めて読んだところ、双方が参考にしているものとして、アメリカの災害対応を標準化したIncident Command Systemや、それに基づいて制定されたNational Incident Management System (NIMS)が挙げられていたのが目にとまった。そこでNIMSについて調べていたところ、『Incident Management for Operations』もまたNIMSを元にしたインシデント対応の方針をまとめたものとなっていたため、あわせて参考とした。少しページ数は少ないO'Reillyだが、丸1冊をインシデントレスポンスに割いているだけあって、記述は非常に詳しい。

以下では、これらのリソースを参照しつつ、最大公約数的にプラクティスをまとめていく。

インシデントとは何か

そもそもの「インシデント」という単語の定義は以下の通りとされている。表現は異なるが、ほぼ同じ意味に取れる。

• 「サービスの計画外の中断、またはサービスの品質の低下」（ITIL）
• 「計画していないサービス停止やパフォーマンス劣化」（PagerDuty）

逆に「何がインシデントではないか」だが、ITILにおいては「インシデント」と「問題」が分離されており、後者はインシデントを引き起こした潜在的な原因である。つまり、症状がインシデント、原因が問題と、別概念として捉えられている。これらの管理プロセスが分けられている意図としては、サービスの中断や劣化という「事象・症状」の復旧は第一に優先するべきであり、その根本的な原因の解決は優先順位的に劣後する、という点がある。SRE bookでも同様に、「止血」や回復を優先せよという記載がある。

また広義のインシデントを分解し、「重大インシデント」と「セキュリティインシデント」という枠を設ける場合がある。重大インシデントは、事業に重大なインパクトをもたらす（ITIL）ものであり、複数のチームの協力（PagerDuty）などが必要となり、セキュリティインシデントは攻撃の遮断といった、通常のインシデントとは別の対策が必要になるなど、いずれも「狭義のインシデント」とは別の管理フローを設けるべきとされる。

オンコール

「call」と言われると日本人としては電話を想像してしまうが、電話に限ることなく、インシデント発生の通知とその受信行為全般を「オンコール」と呼ぶ場合が多い（入門 監視、PagerDuty、SRE book）。

オンコール担当とは、その名の通り通知を最初に受ける担当者である。オンコール担当は通知を受けことするが、必ずしもそのままインシデントの解決まで担当する者を意味しない。多くのリソースでは、解決においては適切な担当者へエスカレーションすることが求められている。

誰もが、全てを知っているわけではない。 チーム全体で手助けする。 確信がもてない問題をエスカレーションすることは、恥ずべきことではないし学びもある。 私たちのモットーは「エスカレーションをためらわない」（PagerDuty）

オンコール担当がひとりぼっちだということではありません。オンコール担当が知らないことや解決できないことに対しては、エスカレーションパスが必要なのは間違いありません。（入門 監視）

通知手段

オンコールにどのような手段を用いるかについては、リソースにより少し記述が分かれる。受信箱がいっぱいになり、アラート疲れを引き起こしやすいとして『入門 監視』ではメールの使用を避けろとしているが、PagerDutyはメールを「最初の通知」として推奨している。

優先度により、通知先や通知手段は分けておくことが推奨される。即時アクションが必要であればSMS、電話などを利用し、そうではない低優先度のアラートでは人々を目覚めさせてはいけない（PagerDuty）。また高優先度のものについては、誰かが応答するまで繰り返し通知するという手法もある。

ローテーション

オンコールは基本的には忌避されるものであり、心身への負荷が高いため、担当のローテーションが推奨される。

• プライマリ、セカンダリなど常に複数人で待機する（PagerDuty、ウェブオペレーション）
  • 『入門 監視』はオンコールシフト期間が長くなるとして、これを推奨していない。プライマリ担当者がオンコールを受ける責任があるとしている。
• 対応で困った場合はためらわずエスカレーションしてサポートを請う（入門 監視、PagerDuty）
  • 場合により、最初に通知を受け付ける担当と、詳細な対応をする担当を明確に分ける。いわゆるヘルプデスク、サービスデスクの考え方（ITIL、ウェブオペレーション）
• 会社規模が大きければ、タイムゾーンにより時分割を行うFollow-the-Sunを導入する（入門 監視）
• オンコール担当への補償として、担当直後の休暇や、金銭的な手当を検討する（入門 監視）
• ソフトウェアエンジニアもローテーションに入れる（入門 監視）
  • 運用担当への「丸投げ」を避ける意図。

トリアージ

インシデントの通知を受けたあとの最初のステップとして、事象の認識と、優先度や深刻度に応じた分類、トリアージを行う（ITIL、PagerDuty、入門 監視、ICS）。これはビジネス・インパクトの大きな事象を優先的に対応できるようにするため（ITIL）である。深刻なインシデントの場合には、社内外への広い伝達や、複数人での協力体制を敷くなどの相応の対応が必要であり、そういった対応の必要性を迅速に判断するためにトリアージを行う（PagerDuty）。

インシデントの具体的な分類方法については、PagerDutyのドキュメントに端的な例があって参考となる。IMOでもどのようにインシデントを抽象化して分類するか、細かい説明がされている。いずれにおいても判断材料とするべきは症状（影響範囲や停止時間など）とされており、よりインパクトの大きいインシデントでの迅速な対応を可能にすることが求められる。そのため精緻に分類することよりも、早期に分類を判断して行動を開始することを勧めている。

役割分担

先述の通り、インシデントはオンコール担当が必ずしも1人で担当するわけではなく、必要に応じてエスカレーションして複数人で対応する。この際、役割分担を行うことが推奨される。

直感には反することですが、責任分担をはっきりと分けることによって、一人一人が自律的に動けるようになります。これは、同僚の動きを予想しなくてもすむようになるためです。（SRE book）

主な役割としては以下のものがある。

• インシデント指揮者（IC, Incident Commander）。全体の状況把握、指揮・監督、決断、委譲していないその他すべての役割（PagerDuty、入門 監視、SRE book、IMO）
• コミュニケーション調整役（Liaison）。顧客や社内のステークホルダーにインシデントの最新状況を通知する。窓口を限定することで、インシデント解決に取り組む者を集中させる目的もある（PagerDuty、入門 監視、SRE book、IMO）
  • PagerDutyでは、社内向けと社外向けで別の担当を置くことを勧めている。
• 記録係（Scribe）。発生した事象や、インシデント解決のために実行した作業を時系列で記録する（PagerDuty、入門 監視）。
• 実行担当（SME, Subject Matter Expert）。実際にインシデントの解決を担当する。英語の名称通り、ドメインエキスパートを当てる。複数人で作業が重複したりしないよう、解決作業にあたるのはSMEに限定する（PagerDuty、入門監視、SRE book、IMO）。

通常時とインシデント時の役割は一致しない

「指揮者」という性質上、ICをシニアメンバーや上長に割り当てたくなるが、その必要はなく、どの役割に誰を割り当ててもよい（PagerDuty、入門監視、IMO）。そのためにも、なるべく持ち回りでそれぞれの役割を担当したり、平時に障害訓練を実施したりして、すべての役割に慣れておく必要がある（PagerDuty、SRE book）。

インシデントの解決

解決においては、以下のようなプラクティスが推奨されている。

• リアルタイムに状況をまとめる。
  • タイムスタンプと関係者に関する情報を含める（ITIL）
  • 複数人が並行で編集できるWikiなどを用いる（入門 監視）
  • Slackに状況を書き込んでいく（PagerDuty）
• 迅速な情報共有のための通話と、記録のためのチャットの双方を用いる（PagerDuty）
• ICはSMEの助言のもと、すばやく判断することが求められる（PagerDuty、IMO）
  • 常に状況を観察し、定期的に深刻度の再評価、状況の連絡指示を行うレビュープロセスを設ける（PagerDuty、IMO）
• 優先順位は「出血を止める」、サービスを回復する、根本原因の証拠を保存する、の順である（SRE book）
  • 「出血を止める」という言い方が抽象的でわかりづらいが、『ウェブオペレーション』では、問題が起きているコンポーネントを切り離したりなどして隔離する「封じ込め」というプロセスが最優先とされており、これと同等のものと考えられる。
• パニックに陥らない、解決が困難なら追加支援を求める（PagerDuty、SRE book）

クローズ

インシデントの解決、クローズについてはあまり言及が多くない。

• インシデントの解決 = インシデント発生前の状態へ復旧したかどうか、はICが判断する（PagerDuty、IMO）
• ステークホルダーへ連絡する（PagerDuty、IMO）
• 根本的な解決ではなく、一時的な修正、復元である場合は、インシデント解決後に今後の対応を判断する（IMO）
  • またインシデントが長引く場合には、対応者を交代することがある。その際、ICは次の担当者へ適切に引き継ぎを行うことが求められる（SRE book、IMO）。

ポストモーテムプロセス、事後レビュー

インシデントの解決後、発生事象のフォローアップを行う（all）。このプロセスは、近年ではポストモーテムと呼ばれるドキュメントの作成プロセスとして扱われる（PagerDuty、入門 監視、SRE book）。単に事後レビュー（IMO）と呼んだり、ITILでは先述のとおり「問題管理」という、インシデント管理とは別プロセスとして扱われたりしている。

ポストモーテムプロセスは、発生した問題の理解を促すこと、根本原因を分析してインシデントの再発を防ぐこと、それらを通じて会社全体に学びの機会を提供することを目的としている。

ポストモーテムの記載内容

以下はPagerDutyとSRE bookによる。

• 発生事象のサマリ
• 影響（時間、ユーザー数、SLA違反状況、発生したサポートリクエスト数など、具体的数値で書く）
• 解決した方策、行った対応
• インシデントの根本原因
• タイムライン
• アクションアイテム（インシデント解決、根本原因修正のために行ったすべての対応チケットのリンク）

ポストモーテムレビュー

ポストモーテムは単に記載するだけではなく、レビューを行う。

SRE bookにおいては、下書きの状態でシニアエンジニアが評価し、その後メーリングリストなどで広範な共有を勧めている。

PagerDutyや『入門 監視』においては、同期的なミーティングによるレビューを想定している。参加者は利害関係のあるすべての人（入門 監視）であり、インシデントに関わったエンジニアや対応者、サービスオーナー、影響のあったシステムのマネージャーらが含まれる。

早期に再発防止策を採る必要があるため、レビューをいつまでに行うかあらかじめルール化することも求められる。『ウェブオペレーション』では24時間以内、それが難しければ1週間以内としており、PagerDutyでは最も深刻なSEV-1では3営業日以内、SEV-2では5営業日以内としている。

レビュー観点は以下のような点である。

• インシデントの詳細や原因が十分に分析されているか？（SRE book、PagerDuty）
• 根本原因は十分掘り下げられているか？（SRE book、PagerDuty）
• 今後のアクションプランは適切か？（SRE book、PagerDuty、入門 監視、ウェブオペレーション）

ベストプラクティス

• 誰かを非難することや、ヒューマンエラーに帰結させることを避ける（all）
• 誰が読んでも理解しやすいよう、略語などは使わないか、使う場合は説明を付記する（PagerDuty、IMO）
• 事実を正確に記述し、仮定や不正確な表現を用いない（PagerDuty、ウェブオペレーション）
• 効果的なポストモーテムを書くことは賞賛されるべきである（SRE book）
• 過去の興味深いポストモーテムの読書会などを開き、積極的に学びを広める（SRE book）

Conclusion

いずれも大きな方針としてはそれほどずれていない。オンコールの負荷に留意すること、インシデントの深刻度を適切に見極めること、役割分担を明確にすること、非難のないポストモーテムプロセスで再発を防ぐことなどはいずれのリソースでも言及のある事柄だった。一方で細かな部分では当然ながら差分があり、一部では真逆なことが書かれていたりもする。『入門 監視』がITILをシンプルな形で導入することを勧めていたように、絶対的な正解を求めずに、自分たちの状況に合わせて適切なフローを構築する必要性がある。

また、この分野で規格化されたものはITILぐらいであろうと思っていたが、NIMSを参考としているものがアメリカでは少なくない、というのは新たな発見だった。機会があれば原典にも当たっておきたい。