インシデントフローを整備して自動化しました

こんにちは。kubopです。

先日、インシデントが発生した際のフローを整備して、一部をSlackBotで自動化しました。
今回は、noteのSREチームとQAチームが協業して行いました。

目的

MTTRを最小化したい

あるインシデントでは、障害検知から対応までの時間が40-50分程度かかっていることがわかりました。
メトリクスや監視による迅速な検知がされているのにも関わらず、実際の対応までにかなり時間がかかっていました。
対応までのフローを固定化し、スムースな橋わたしが出来ると短縮できそうだなと思いました。

ある日の障害対応の時系列をプロセスごとに分離した図

対応者 = 報告者を避けたい

インシデントの調査・対応・切り戻しをしている最中、それ以外の人に状況を伝えるということを同時に行おうとすると更なる2次災害が起きる可能性がありました。

可及的速やかに対応しなければならない時に、実況中継してエンジニア以外の人に状況を説明出来るようにすると1人に責務が集中し、オペレーションミスや判断ミスにつながる恐れがありました。

ジャグリング状態になる

緊急時は役割分担を明確化したい

インシデント発生時、対応者や指揮者はその場にいる人が役割を果たしていました。
また、全員で同じ部分を調査してしまっていたり、役割が重複してしまうことがありました。

実際に行ったこと

インシデントフローを再定義した

現状フローと理想のフローを洗い出した。

現状どのようなフローで動いているのかと、理想的にどのようなフローが実現可能かを洗い出しました。
このフローにより、検知から対応までのフローを迅速に判断することが可能になりました。

また、登場人物を洗い出し、主に「指揮者」と「対応者」がどのように振る舞うべきかを定義しました。

指揮者は、主にインシデントオーナーとして振る舞います。
デバッグ・調査はせずに状況の把握と共有に徹します。
エンジニアや、インシデントの渦中にいる人以外も理解可能なよう、状況説明を一部翻訳しながら全体に周知します。
15分ごとに状況説明をしながら、タイムスタンプを記録します。

15分報

対応者は、インシデントの修正する人として振る舞います。
デバッグ・調査をし、切り戻しやコード修正に当たります。
状況の報告や関係各所への共有は一切考えなくて大丈夫なよう、指揮者は彼らをサポートします。
インシデントが収束した際に、指揮者が記録したタイムスタンプを元に障害報告書を記入してもらいます。

インシデントフローの一部をSlackBotで自動化

おおまかなフロー

障害報告から、Slackのtemporaryなチャンネルの作成、全社員への共有部分はSlackのboltとLambdaを使い自動化しました。
インシデントの名称、招待したいユーザーなどを入力すると自動で上記を全て行ってくれます。
スレッドやチャンネルに情報が散乱するのを防いでくれます。

ワークフロー

temporaryチャンネルに投稿されます。

指揮者・対応者が現在誰が担当しているのかがわかるよう、ボタンを押下して宣言してもらいます。

今後の課題

フローの浸透化

今回定義したフローを全社員が自然と行えるよう浸透化させる必要があります。指揮者とは何か、対応者とは何かがすぐにわかり、誰が担当するかが明確である状態を目指さなければいけません。

タイムキーパー・ステータス変更の自動化

現在は手動で行っているタイムキープ、ステータスの報告は自動的に拡散されるような仕組みを構築したいと考えています。
どうしても実況中継する際に時間の経過を忘れてしまって集中してしまったり、状況の変化に対応しきれないからです。

インシデントの振り返りの仕組み化

ポストモーテムは行っているものの、定期的な振り返りの仕組み、インシデント対応そのものに対する振り返りは行えていません。
毎回フローの振り返りを行い、更なるブラッシュアップをしたいと考えています。