これはWHITEPLUS Advent Calendar 2022の23日目の記事です。

はじめに

こんにちは、WHITEPLUS エンジニアリング部 CX開発Gのhirasushiです。
本日は、ホワイトプラスでのエンジニアによる障害対応体制について紹介いたします。

導入経緯

今までも現在でも、ホワイトプラスでは障害対応専任の部署というものはなく、開発・運用を行っているエンジニアが障害対応も行っています。ただし以前のホワイトプラスでは、障害発生時の標準的な対応方法が決められていない状態でした。アラートなどで障害を検知した後、それに気づいたエンジニアが集まり、それぞれの裁量で対応をした後、報告書を書いて終了...という流れになっていました。
そのため、下記のような問題が発生していました。

情報の流れが整理されていない
- 何が発生し、影響はどのようなものなのか。復旧見込みは立っているのか。などが、インシデント対応しているエンジニア内部に留まっている状態でした。そのため、外部からの情報把握がしにくくなっていました。
障害対応に途中参加しにくい
- 上記の『情報の流れが整理されていない』にも関連しますが、対応がある程度進行した状態のところに後からエンジニアが参加しようとしても、現状がどうなっているか？　分かりづらいため、途中参加がしにくくなっていました
対応エンジニアが一度に複数のことをしないといけない
- インシデント対応にあたっているエンジニアが、調査や修正対応と並行して、他部署からの問い合わせ対応、障害発生報の作成などを行っている状態でした。そのため対応エンジニアには負荷がかかり、また復旧に必要な調査や修正対応に集中しにくくなっていました。

これらの問題を解消するために、障害発生時の標準対応方法を決めたいと思い、障害発生時の標準的な対応方法を決定・導入しました。

導入した対応体制

ホワイトプラスでは、『インシデント指揮官』対応フォーメーションを障害発生時の対応体制として導入しました。
これは

blog.danslimmon.com

こちらの記事に記載されているもので（日本語訳はこちら）、次のようなルールが定められています。

インシデント対応に関わるエンジニアは、何かしらのロールを受け持ち、そのロールの責務を果たす。
- 逆に、ロールを受け持っていないエンジニアは、インシデント対応を行ってはいけない。
ロールには以下のようなものがあるが、これは標準的なものであり、必要に応じて追加/変更することができる。
- インシデント指揮官
  - インシデント対応のトップ
  - 責務: インシデントを解決に向けて動かす
- 主任SME
  - 責務: インシデントの技術的調査/修正を行う
- 外部通信役
  - 責務: 外部（主に他部署メンバー）とのやりとり（チャット、ミーティング等）を行う
- 書記官
  - 責務: インシデントのタイムラインとステータスをチャット上に記載する
インシデント指揮官が最高意思決定権者となり、インシデント対応を解決に向けてファシリテートしていく。

導入のためにやったこと

上記が対応方法のルールとなりますが、これだけで実際の障害対応ができるようになるわけではありませんでした。
導入にあたっては何回か勉強会を開き、

上記の記事を輪読する
記事の中で気になった点や不明な点を話し合う
ステージング環境を使って疑似障害を起こし、ルールに則って障害対応をしてみる

ということをして、エンジニア間で障害対応について共通認識を持てている、障害対応の流れがわかっているような状態をつくりました。
特に疑似障害による障害対応では、実際に各ロールは具体的にどのようなことをすればよいのかを把握することができました。またここでわかったことも、障害対応ルールとして組み込みました。

実際の障害対応の流れ

現在のホワイトプラスでの障害対応は、以下のような流れで実施しています。
なお、ホワイトプラスではエンジニアはほぼフルリモートですので、会話はGoogle Meet、テキストのやりとりはSlackを使っています。

アラートなどで障害発生を検知
検知したエンジニアがチャットボットを使い、調査用と報告用2つのSlackのチャンネルを作成する。
- この対応用のチャットボットを作成し、Slack上でコマンドを実行すれば自動でチャンネルが作成されるようにしました。チャンネルが作成されると、自動でエンジニア全員に通知がいくようにもなっています。
Google Meetで対応用の部屋をつくり、対応可能なエンジニアはそこに集まる。
エンジニアがある程度の人数集まったら、ロールを決定する。
- インシデント指揮官, 主任SME, 外部通信役, 書記官　の順でロールを割り振ります。
- 集まった人数が少ない場合は、一人のメンバーが複数のロールを兼任することもありますが、主任SMEは他のロールと兼任できないルールとしています。
インシデント指揮官が、メンバー全員と『何が起きているのか』『どんな状態になれば解決と言えるか』の認識合わせをします。
インシデント指揮官が主任SMEと調査・対応方針のすり合わせを行います。
主任SMEは調査・対応を開始します。
- アップデートがあれば随時インシデント指揮官と共有します。
外部通信役は報告用のチャンネルに関係者を追加してインシデント発生報を投稿し、今後の窓口が自分であることを宣言します。
- この後関係者とのやりとりは外部通信役が担います。やりとりの内容についてはインシデント指揮官と随時調整します。
書記官は調査用チャンネルにインシデント対応に参加しているエンジニアとそのロールを記載します。
- この後のステータスアップデート（調査の進展、参加メンバーの追加/現象など）も書記官が随時記載していきます。
調査/対応の目処が立ってきたら、インシデント指揮官がどのような状態になったら障害対応体制を解除するかを決め、共有します。
対応が終了したら、外部通信役は報告用のチャンネルでそれを報告し、書記官は報告書を作成します。そしてインシデント指揮官が対応体制を解除します。
後日振り返りを行い、障害対応のやり方や、障害発生の原因について良かったこと/悪かったこと/今後の対応(Next Action)を共有します。

導入前後で変わったこと

この障害対応体制を導入してから、『導入経緯』の中で記載した問題にはうまく対応できるようになりました。
報告用・調査用のチャンネルを作成し、そこに報告やステータスを記載していくようになったため、外部からでも何が起きているのかや今までの経緯が把握できるようになりました。
また、『ロール』を導入したので、途中参加のメンバーでも自分の役割がわかりやすくなり、障害対応に参加しやすくなりました。
さらに、この『ロール』によって主任SMEが調査・対応以外のことを気にせずによくなり、自分の役割に集中できるようになりました。

この障害対応体制は、障害対応に参加するエンジニア全員が把握しておく必要があります。
ホワイトプラスには新しいメンバーも随時加わっているため、障害対応の勉強会を定期的に開催し、全員がこの体制について把握できるようにしています。
また、実際の障害対応が起こった場合、振り返りで『ここはこうしたほうがよかった』などが出てきたら、随時ルールとして反映するようにしています。