入門監視やSRE本に学ぶ障害対応フォーメーション

システム障害が起こったときにどういう体制で望むか、エンジニア個人が障害に直面した時にどのような役割を受け持つのが良いのか。組織によって色々なパターンはあるでしょう。しかし、幸いにも「入門 監視」やSRE本に書かれている4つの役割分担が浸透しているので、それをベースに考えるのがファーストステップとしては良いのではないでしょうか。

ただ、小さな組織では障害時に4人もすぐに揃わない場合もあるでしょうし、そもそも4人もスタッフがいない、と言う場合もあるでしょう。そういった場合にもどうすればいいのか考えていきます。

役割分担の基本

「入門 監視」には以下の4つの役割定義があります。SRE本にもほぼ同様の分類がありますが、そこでは「書記」ではなく「計画担当者 (Planning)」という少し別の役割が書かれています。ここでは「入門 監視」の方に準ずることとします。

  • 現場指揮官 (IC, Incident Commander)
  • 実施担当者 (SME, Subject Matter Expert)
  • コミュニケーション調整役 (Communication Liaison)
  • 書記役 (Scribe)

ちなみに、この役割定義は、インシデント・コマンド・システム*1に由来するとSRE本には書かれています。

まず、一般的な定義を記します。

現場指揮官 (IC, Incident Commander)

現場を指揮する人。インシデントコマンダー、名前がかっこよくてテンションが上がるので良い。調査及び対応の指揮・監督をし、対応方針を決断する人。決める人なので手は動かさないのが望ましい。テックリードやSRE的な人に担当してもらうのが良く、システムに明るくないマネージャーがやってしまうのはアンチパターン。

実施担当者 (SME, Subject matter Expert)

実際に障害対応作業を行う役割。

コミュニケーション調整役 (Communication Liaison)

ステークホルダーに状況の共有をおこなう役割。チーム外からのコミュニケーションを一手に引き受け、割り込みからチームを守る。ここにマネージャーを充てるのはセオリーの一つ。

書記役 (Scribe)

障害対応の状況を記録する役割。

実運用

理想的には前項の4人以上が揃えば良いのですが、現実として組織にそんなに人がいない、また、深夜に障害を察知した最初の一人がまずは全部やらざるを得ないことなどもあり、実運用上は縮退運転もあり得ます。この時、役割の優先度としては以下のようになるでしょう。

現場指揮官 → コミュニケーション調整役 → 実施担当者 → 書記役

役割を立てる優先順位と兼務は上の順でやっていくことになりますが、以下のように枝分かれしていくことになります。

  • 対応ライン: 現場指揮官 → 実施担当者
  • コミュニケーションライン: コミュニケーション調整役 → 書記役

役割は状況に応じてフレキシブルにアサインし、障害対応中のアサイン変更もありえます。ではそれぞれどのような動きをしていくのか。

現場指揮官

まずはコマンダーがいないと始まらない。システムに詳しいテックリードやSREが望ましい。捕まらないときは、いる中で一番詳しい人が担当する。基本的には手を動かさないが、実施担当者が不足している場合には、手を動かすこともあります。

現場指揮官ひとりだけで、コミュニケーション調整役を含めた他の人が捕まらない場合は、関係者を広く呼び出します。この時、簡単に関係者を呼べる広報の仕組みを予め用意しておくと良い。例えば、全員のスマホなりページャーを鳴らす仕組みだったり、チャットツールに障害時にしか使わないチャンネルを用意しておいて、そこはエンジニアやマネージャーは全ての通知を受け取るようにしておくなどの方法があります。

ちなみに、障害時に新規にチャットチャンネルを作るよりも、障害時にしか使わない対応チャンネルを用意しておくのが、後から来た人が迷わなくて良いと思っています。ただ、そこで発言する人はあくまで対応チーム内に留め、それよりチーム外との連絡は別チャンネルでコミュニケーション役が引き受けるのが混線がなくて良いでしょう。例えば #incident というチャンネルで障害対応を進め、 #general で社内連絡をするなど。

現場指揮官は、コミュニケーション調整役が捕まらない場合は、頑張ってその役割も兼ねることになります。

事実上、指揮者は委譲していない全ての役割を受け持ちます。

SRE本にも上記の記載があります(id:mactkgさんに教えてもらいました)。がんばりましょう。Hashicorp社の「インシデント指揮官トレーニングの手引き」*2も参考になります。

コミュニケーション調整役

開発に関わるマネージャー、具体的には開発ディレクターやPMが担当するのが良い。ステークホルダーに情報を共有する役割を担う。例えば以下のようなこと。

  • 社内の情報共有用のチャンネルでチーム外へ状況を逐次共有する
  • 社外に向けて、ステータスページやSNS、ブログなどを更新する
  • 重要顧客に個別に連絡をする

チーム外からのコミュニケーションを一手に引き受ける役割であり、割り込みからチームを守ることも期待される。なので、ここにマネージャーを充てるのがセオリーとなります。

適宜、情報整理や対応ラインとの橋渡しをおこなったり、書記役担当から情報を得たりする。対応チームの支援も行う。実施する部屋を取ったり、食べ物の補給など。

書記役が不在の場合、それを兼務します。

実施担当者

当然だがチームのエンジニアが担当する。何かをオペレーションを実施するときは、声出しを心がける。これは、他の人と作業がかぶらないようにするためと、書記役に伝えて記録してもらうため。ちなみに、障害対応はオンラインにせよオフラインにせよ「会議室」に集い、声を掛け合いながら対応するのが良い。

なので、障害対応に際しては、オンラインの場合は最初にWeb会議室を作って入る、もしくは入るURLを決めておく。

書記役

チームのエンジニアが担当できると良い。人が足りない場合はマネージャーにやってもらったり、他チームの人にヘルプに入ってもらうこともできる。

まずは記録を取るドキュメントを作成しチームにURLを共有する。リアルタイム編集できるGoogle Docsなどが好ましい。これも障害当初の大事なTODOの一つ。

対応チームは全員がこれを見ながら対応に当たり、状況や作業ログを追記していく。何が起こっているのかわからない場合は書記役がちゃんと「聞く」のが大事。書き漏らさないようにする。なので、わからないときに率先して聞く役であるとも言えます。

主の書記役は他のことをやらず、記録を取ることに集中する。交代しながらできるのが良い。また、ドキュメントの更新自体は、別に書記役以外がおこなっても構わないし、書記役に任せっきりにしないほうが良い。全員が見ているのだから。

このドキュメントがしっかり作れると、レポートの作成や振り返り時に非常に役に立ちます。

まとめ

役割分担は重要です。障害時に血を止めることに集中しすぎてしまい、体外連絡が疎かになることや、対応の中心メンバー以外が逆に手持ち無沙汰になってしまうことなどはよく起こります。多くの人が身に覚えがあるでしょう。私もあります。

しかし、ここで書かれたような役割分担のパターンを各自が頭に入れておくと、障害対応に加わったメンバーが「じゃあ自分はこの役割をやろう」と自主的に動けるようにもなるでしょう。