前置き
インシデント管理プロセスとは
インシデント管理プロセス(Incident Management Process)をご存知でしょうか？
インシデント管理プロセスはGoogleのSREチームが行っていた障害対応の方法で、アメリカの消防が緊急対応の方式として確立したインシデントコマンドシステムを元にしています。日本ではGoogle SREチームの書いたオライリーのいわゆるSRE本より広まりました。
この記事で書いていること、書いていないこと
この記事では、Chapter 14 Managing Incidentsに書かれたインシデント管理プロセスについての内容を要約・整理して記述します(SRE本 第14章 インシデント管理の翻訳元の文章です)。
(ちなみに、この記事は私が人へレクチャーするときの資料として使うことを意図しています。原文では見返すときに参照しづらいので、ウェブ上に置きリンクできる形でいつでも参照できる要約を置いておきたかったためです)
この記事にあえて書いていないことがあります。
1つは原文の要素を網羅することです。例えば 計画担当者 については以下では書いていません。原文を網羅しようとすると、もはや原文を読んだほうが早くなるためです。すべての要素をカバーしたい人は記事末尾の原文へのリンクからオリジナルの文章を読むのがいいと思います。
もう1つは自分たちのやり方・改変について書くことです。おおよそ他のSREプロセスと同じく、このインシデント管理プロセスについても導入先の組織に合わせてよく改変されます[1]。ただ、そういった改変を含めてこの記事を書くとSRE本で書かれていることとと自分の組織での改変の境界がわからなくなります。なので、この記事ではあくまでSRE本に書かれている内容をそのまま要約するに留めます[2]。
本題: Google SREのインシデント管理プロセスの要約
インシデント管理プロセスの中心となる概念は以下の2つです。
- 責任の再帰的分離
- 役割の分担
このうち前者がコアとなる概念なのですが、後者を説明してからのほうがわかりやすいため、一旦そちらを先に説明します。
1. 役割の分担
インシデント管理プロセスでは、インシデント対応者へいくつかのロール(役割)を割り当てます。
それが以下の3種類です[3]。
- 指揮官
- 作業担当者
- コミュニケーション担当者
指揮官
インシデントに対する指揮官です。基本的にインシデント対応の最終判断は指揮官が行います。ですので、重要な情報はすべて指揮官に集約し、指揮官への共有なしに重要な意思決定や作業を行うことはNGです。また、後述の作業担当者やコミュニケーション担当者の割り当ても行います。
作業担当者
実際に障害を調査し、原因に当たりが付けばその解決作業も行う人です。
作業担当者が2名以上になった場合、そのうちの1人が他の作業担当者への調査の割り当てや調査結果の集約・分析・解釈、解決作業のアサインなどを行います(詳しくは後述)。
コミュニケーション担当者
障害対応チームとその外部とのやり取りを担当する人です。
多くの開発チームでは、この必要なステークホルダーとのコミュニケーションがあまり適切ではなかったり、もしくは単純に欠落していることが多いです。そこで、コミュニケーション担当者は部長・事業責任者・CEOなどの障害を心配している人や営業チーム・カスタマーサポートなどの顧客対応を行う人達に適切なタイミングで適切な情報のコミュニケーションを行います。
責任の再帰的分離
インシデント管理プロセスでは、前述した役割が再帰的に(ピラミッド状に)分割して移譲されていきます。
例
まず、インシデント発生直後、対応者が1名だけだったとします。
この場合、自動的にこの人は指揮官 兼 作業担当者 兼 コミュニケーション担当者になります。
その後、1名が障害対応へ加わってくれました。
このときに指揮官がその人を作業担当者としてアサインすると、指揮官は作業担当者の任からは離れます。
同様に別の人をコミュニケーション担当者としてアサインした場合、指揮官はコミュニケーションをその人に任せ、自分は全体の把握と指揮に専念し始めます。
この構造は再帰的です。インシデント対応チームが大きくなると作業担当者がよく2名以上になるのですが、その場合は指揮官の下に新たな作業担当者が生えるのではなく、先にいた作業担当者の下に付けられることになります。
ポイント
インシデント管理プロセスがなぜ広く支持されるのか。それは、以下のポイントが非常に強力だからです。
1. レポートラインが明確
この方式では、権限が分離されてできたピラミッド構造がそのまま情報の集約(ボトムアップ方向)と指示の伝達(トップダウン方向)になります。
これにより、誰に伝えたらいいかわからず重要な情報が滞留したり、逆に重要な指示が全員に伝わっていない、などの自体を避けられます。
2. 責任の空白地帯、浮いたボールができない
緊急性が高い一方、混乱もしている緊急対応のシチュエーションでは、誰かがやっていると思っていたという事態が度々起こります。逆に、やっている人がすでにいると知らずに同じ作業を2名以上が行うケースもよくあります。
インシデント管理プロセスではすべての権限はまず指揮官にあり、そこから小分けにしてどんどん移譲していく、というモデルなので、理論上は責任の空白地帯が発生しません。また、行う作業についても必ず上位が把握しているので、同じ箇所を2名以上がやりかけても事前に気づけます。
3. スケールへの耐性
比較的小規模な障害対応ではうまくできていたチームでも、他のチームとの連携が必要になったり、より大規模な障害で普段の数倍の人数での対応が必要となるととたんにうまくできなくなることが多いです。これは慣れていないこともですが、普段行っている体制がスケールに耐えるものでないことも一因です。
インシデント管理プロセスでは、基本的に人数が増えてもフラクタルのようにピラミッドの構造を維持できるため、スケールへの耐性があります。
その他補足
以下は細かいHowについての補足です。
司令所 (war room)
インシデント対応の対応メンバーが集まり、コミュニケーションをする場所です。
slackやchatworkなどのチャットツール、もしくはオフィスの物理的な1室などです。
war roomは障害が発生したときにそこへ行けばとりあえず対応に参加できること、そこへ行けばとりあえず最新の進行状態が把握できることが重要です。一刻を争う近況対応のシチュエーションでは時間を無駄にできないためです。なので、だれもがアクセスしやすく、明確な場所である方で良いです。
インシデント状況ドキュメント
インシデントの状況や時系列を記録したドキュメントです。
Google Docsなど、複数人で同時に編集できるサービスを使うことが勧められています。
以下はその例です[4]。
# 障害のサマリ
# 指令所
# 障害対応メンバー
# 最新状況
# 解決の判断基準
# TODO
# 時系列
このライブインシデント状況ドキュメントは、後から障害対応へ参加するメンバーへの口頭説明を避けられる点、文字記録を取ることで人間の記憶に頼らない証拠を積み上げられる点、ステークホルダーが対応チームへDMを送ることなく、ここを見れば最新状態がわかるようにできる点、などの利点があります。
おまけ: SRE本のインシデント管理プロセスの原文について
SRE本は、実は原文の内容がウェブ上で無料に公開されています。
そのため、インシデント管理プロセスの記述についても以下で誰でも読むことができます。
英語ですが長くなく、Google翻訳して読めば15分ほどで読めます。より詳細な内容に興味がある方はぜひ読んでください。
Discussion