インシデント対応フローを整備しよう

本記事は SRE Advent Calendar 2022 12日目のエントリーです

インシデント対応、皆さんはどのように行っていますか？
弊社ではインシデント対応の流れとして、大きく分けて3つの対応を行うようにしています。

1. まず Severity Levels(SEVレベル) を判定する
2. SEVレベルに応じた エスカレーションフロー に沿ってステークホルダーに情報連携しつつ、インシデント対応を行う
3. 対応完了後、 ポストモーテム を書く

それぞれの要点を以下にまとめてみます。

1.Severity Levels

• Severity Levelsとは？
  • インシデントの重大度を表すレベル
  • 影響の大きさをレベル別に言語化したもので 「SEV」によるレベル定義を使用して重大度を分類する
  • レベル定義は数値が低いほどより重大な問題として扱う
• Severity Levelsを定義する目的
  • 発生中のインシデントの重大度を明確にする
    • 予め定義しておくことでSEV判定に時間を使わず、サービス復旧に多くの時間を割けるようにする
• 運用
  • インシデント発生時、まず第一にSEV判定を行う
  • SEV判定に迷う場合は上位の重大度として扱って対応を進める
    • SEV-2以上はすべて「重大インシデント」とみなし、他の業務より優先的に対応する

参考

2.エスカレーションフロー

• エスカレーションフローとは？
  • インシデント発生時に想定されるエスカレーション先/対応フローをSEVレベル別に定めたもの
• エスカレーションフローを定義する目的
  • インシデント発生時、情報連携先に迷わないで済むようエスカレーションフローを各チームで事前に整備し、有事の際にスムーズに情報連携できるようにする
    • SEVレベル別に「誰に報告するか?」「まずはじめに何をするか?」「チームでどのように役割分担して動くか?」等が分かるようにする
    • ドキュメントに基づいてチームメンバーが同じ判断基準で迅速な行動ができるようにする
    • 報告用Slackチャンネル、インシデント対応用Web会議室、ステークホルダーの連絡先など、事前に整備しておく
• 運用
  • フローを見ながら、SEVレベルに沿ったエスカレーションと対応を行う

大規模なインデントが実際に起きた時、対応を円滑に進めるには役割分担(Incident Commander, Communication Lead 等)が重要となります。
どんな役割があるんだろう？と思った方は、下記の参考記事を読んでいただき事前にチーム内で認識を合わせておくことをおすすめします。

参考

3.ポストモーテム

具体的な内容は割愛し、要点だけ書いてみます。

• 目的
  • 失敗から学び、改善する為の非難のない振り返り
    • 責任追求の場ではなく、問題の原因を掘り下げ学習し、同じ過ちを起こさないよう成長すること
    • 根本原因の確認と効果的な再発防止策等の検討
  • 影響と損害の評価
  • 事例の収集/共有
• 注意点
  • 非難しない・責任追及の場にしない
    • 誰々が悪いなど、特に個人に対する非難は行わない
    • 非難や責任追及が行われてしまうと、受けた側が防御的になり客観的なデータが出てくることは望めなくなる
  • 原因特定や再発防止は仕組みで考える
    • 問題発生の原因を個人の能力や注意に求めることはしないようにする
    • 個人に原因を求めてしまうと再現性のある再発防止策を導き出すことができない、もしくは困難になってしまう
    • NGワード：しっかり, 注意深く

以上ような流れでインシデント対応を行っています。

実際に運用してみて

このようなフローを定め、運用を回し始めてみましたが
初期段階ではまだ慣れていない為か SEV判定とエスカレーションをせず、内々でインシデント調査/解決に向けて動き始めてしまい、詳細は事後報告。 のような事案がまだ発生していました。
そのような対応に気づく度、口酸っぱくまずはSEV判定して報告しましょう と言い続けていたのですがそれも気が引けたので、改善策としてポストモーテムのテンプレートに以下のような振り返り項目を追加するようにしました。

• 振り返り
  • SEV判定
    • 初動でSEV判定できましたか？
  • エスカレーションフロー
    • 事前に定めたフローに沿ったエスカレーションが出来ましたか？
  • うまくいったこと
    • 簡潔に
  • うまくいかなかったこと
    • 簡潔に

これにより、徐々に改善していった気がします。

余談ですが、現状の弊社の場合インシデント発生頻度はそれほど多くなく（月0-3件？程度）ポストモーテムの共有に関する運用は

• ポストモーテム共有フォルダ(社内からは誰でも参照可能)に置く
• エスカレーションフローで定義されている、インシデント対応用slackチャンネルで共有
• エンジニアの週次会議体で報告

のような内容となっており、インシデント管理ツールの導入は行っていない状況です。

今後、組織が大きくなり発生頻度や共有方法に関して課題感を感じたり、発生頻度に関わらず大きなメリットが感じられた場合は導入を検討していこうと考えています。

まとめ

いかがでしたでしょうか？
事前に定めたフローに沿ったインシデント対応が行われるようになって

• インシデントの重大度に関して、Severity Levelsという共通認識を持てるようになった
• 発生中のインシデントの重大度が明確に判別できるようになった
• SEVレベルに応じたエスカレーションがスムーズに行われるようになった

等のメリットが生まれました。

以上、この記事が皆様の参考になれば幸いです。