こんにちは！
インフラの奥村です。

最近チームで行っている取り組みとして「SRE本読書会」を行っております。
内容としては

O'Reilly Japan - SRE サイトリライアビリティエンジニアリングを各メンバーが事前に読む
各メンバーが感想、議論したいことを共有する
議論する
アクションを生み出す

です。

今回はそんな中から生まれた「障害対応テンプレート」について執筆致します。「実際に使ってみた」の章は松谷（まっちゃん）が執筆しております。

本題
- 作る
- 使う
まとめ

本題

作る

障害対応テンプレートとは？

障害が発生した際に、「残しておくべき情報」や、「本来こういう流れで対応した方良い」というのを、テンプレート化したものになります。
後述しますが、私の部署ではアトラシアンのConfluenceで台紙を作成し、それをテンプレートとしています。

障害と言っていますが、システムに発生した「正常の動作ではない動作」が発生した時に記述するようなテンプレートになっています。

また、対応後に振り返りを行い、経験や対応を展開するための項目もあります。

ツール

私の部署では以下の2つを使っています。

アトラシアンのConfluence
Slack

プレーンなテキストを誰もが編集でき、かつ共同編集できるソフトウェアが望ましいです。（Google docsなど）
対応が分散された場合に一つの資料にそれぞれで書き込める状態が望ましいでしょう。
私の部署ではアトラシアンのConfluenceを利用しています。

Slackに関しては、普段はコミュニケーションツールとして利用しています。
アラートを担当者に知らせるのもSlackで行っています。
Slack Botに「障害対応テンプレート」で文言を登録し、テンプレートのURLをレスポンスするようにしています。

障害対応テンプレートの内容

対応準備チェックリスト
- 障害対応フローチャートの確認済みか？
- 担当割り振りは決まっているか？
時系列の記録
- タイムライン
  - 何時に何が発生したか(n..)
- 会話ログ
現象
- 何でこの現象が発生した事を知ったか？
- 動作
  - 期待される動作がどういったものか？
  - 実際にはどう動作しているか？
暫定対応
- 暫定対応仮説
- 暫定対応方法
- 暫定対応結果
調査
- 調査項目(n)
  - 調査担当
  - 調査過程
    - 打ったコマンドやその時のメトリックなど
  - 調査結果
原因
- 仮説(n)
  - 仮説検証（再現）
  - 検証結果
恒久対応
- 案(n)
- 採用された恒久対応
  - 採用された理由
やらなかったこと
所感
振り返り
- KPT
- 他のチームでも活かせそうなことはないか？

補足

暫定対応が明確な場合は「暫定対応仮説」を飛ばして記述してよい事を記載している
調査の調査項目、原因の仮説、恒久対応の案は複数挙げれるようになっています。( nの部分 )

何故作った？

システム部門のインシデントを管理する仕組みは既にありました。
既にあったインシデント管理に加えて、対応を行ったときのより詳細な記録を残す場所として作成しようという事になりました。

また、もともとあったインシデント管理のシステムではステータスの管理はできるものの、共同編集をすることができず、内容のレビューをリアルタイムで行うのに手間がありました。
その課題は解決されました。

それに加えて、障害対応時の心情に対する効果も期待しています。

SRE本にも書いていますが、障害が発生したら人は多少なりとも冷静さを失うものです。（冷静な人もいるかもしれませんが！）

冷静じゃない時にいち早く問題を解決しようと思い、記録された仮説なしに対応を行おうとする事があります。
実際に自分自身も同じ考えで同じ対応を過去にしていました。
ですが、その対応によってさらに問題が起こる事もあります。

というような内容で議論している内に、「『一度冷静になって、対応の時は冷静な判断を下せるようになる』というのは無理だから、判断は形式化されたものに任せよう」となりました。
その一つが「ほしい情報が一覧化されているテンプレート」でした。
（これとは別に、障害対応時のフローチャートなんかもあります。）

せっかく作るのであれば、SRE本に書いてあるポストモーテムの内容も取り入れようということで、振り返りなどの項目が追加されました。

インプット

テンプレートを作成するにあたってインプットとしたのは以下です。

O'Reilly Japan - SRE サイトリライアビリティエンジニアリング
- 12章
- 13章
- 14章
- 15章
経験

今後どうしていくか

私のチームで扱っているシステムの障害が発生した場合にはこちらのテンプレートを用いて記録するようにしています。

また、ポストモーテム（障害対応記録など）は「非難を避け、建設的であり続けること」が重要だと言っています。

非難を取り除けば、報告しやすく、報告の頻度が上がり、活かせる情報が増えていきます。

という考えの元、Slackに「カジュアルポストモーテム」チャンネルを作成し、ポストモーテムを共有してカジュアルに話し合う場所を設けました。
この場所で、フィードバックなどが発生したらなお良いですね。

今後は部署内の利用者を増やしていき、障害から学んだ事をより多くのメンバーに知ってもらうようにしていきたいです。

使う

ではここからはまっちゃんの方で書かせていただきます！
自分からは実際に奥村が作成した「障害対応テンプレート」について実際に使う機会があったので使ってみてどうだったのかを書いていきます。

インシデントに対するチームの認識

チームとしてインシデントの対応記録・ポストモーテムを残そうという話はふりかえりからメンバーから出てくるようになり、最近残すようになりました。
スクラムチームとしてインシデントにどういう体制で取り組むかという話も上がりました。
現在の体制は下記の通りです。

インシデント発覚
- 自分がインシデント見つける
- チームメンバが見つけチームのインシデントチャンネル経由or口頭で共有をもらう
規模の判断
- 自分が発覚したインシデント内容に基づき影響度を判断する
チームにインシデントを共有
インシデント取り組み体制を共有
- 規模が小さい
  - 少人数で取り組む
- 規模が大きい
  - 全員で集まる
  - 認識合わせ
  - 役割分担
  - 対応方法の検討
インシデントの対応に着手

対応後は共有するべき箇所に共有を行い、インシデントの対応記録・ポストモーテムを完成させます。
必要に応じて取り組み後のふりかえりを行います。

問題点

しばらく運用していたものの、下記の疑問点が自分の中でありました。

何をインシデントの対応記録・ポストモーテムに残せば良いのか
どこまでインシデントの対応記録・ポストモーテムに残せば良いのか

他チームの内容を参考したものの、ものによっては項目が無かったり、次に活かせない対応記録になってしまいました。
その中でテンプレートを作ってくれた話があったのでさっそく使うことにしてみました。

調査〜暫定対応までテンプレートを使ってみた

インシデントや障害のレベルにもよると思いますが、基本的には発生したものは急いで対応を行い正常動作に戻します。
奥村の章にも書いていますが、冷静さに欠け急いで対応を行なうところに目を向けてしまった場合、本来解決するべき現象、原因、対応が整理できなくなり時間がかかることも過去にあります。

テンプレートに沿って進めることで原因について追求することができ、暫定対応までスムーズに物事が進めたと思います。
またこのテンプレートは現象、暫定対応、調査、原因、その仮説が残せるようになっており、結果だけでなく、その過程も記録することができました。
自分たちが運用していたものは結果だけを残していた事が多かったので、この過程を残せるのは非常に大きいと思っています。