そうは言っても障害は起きるものです．で，障害が起きて，終息したあとの振り返りとして社内向けにoutage report (障害報告書的な？) のようなものを書くと思うのですが，本記事ではそのときに気をつけていることについて書きたいと思います。
outage reportの目的
そもそもですが，outage reportを書く目的としては以下のような物があるのかなと思っています。
- A: 障害が起きたという事実に関する周知
- 障害についてお客様からお問い合わせが来たりした時に正しい情報を届けられるようにするため
- B: 根本原因の洗い出し
- 再発防止のため
- C: 障害検知フローの確認
- 障害に対する初動までにかかる時間を短くするため
- D: トポロジの形成
- 知見の醸成
- 似たような問題が起きたときに，outage reportに書いてある対処法を逆引き的に利用できるようにするため
outage reportに書いている内容
以下は個人的に (というか所属している組織的に) 書いている内容なので千差万別だとは思いますが，このような感じのことを書いていますというご紹介です．カッコ内のアルファベットは目的の部分に書いたアルファベットと対応しています (Dについては横断的に有効だと思うので省略しています)．
障害のサマリ (A)
- なるべく簡潔に書くように心がけている．多くても3行以内で済むように．
- 外部向けに簡潔に障害内容を伝えられるような内容を心がける
- このサマリだけを読む非技術系のスタッフもいる
障害で発生した症状・お客様から見た問題の詳細 (A)
- 外から見た時の症状について書くようにしている
- 内部のシステム構成などは関係なく，お客さんが実際に対面した (であろう) 問題について書く
- 詳細に書くようにする
機能単位の影響範囲 (A)
- 実際にどの機能が利用不可能になったか，について列挙するようにしている
コンポーネント単位の影響範囲 (B)
障害期間 (A, C)
- 以下の4つについて明記する
- 発生日時
- 問題自体が発生した日時
- 検知日時
- 問題を検知した (初動可能になった) 日時
- お客様影響があった期間
- お客様が当該機能を利用できなかった期間 (from/to)
- 終息日時
- 問題の終息が正しく確認された日時
- 発生日時
- 文字だけだとわかりにくいので，「時系列で追いやすい図」や「グラフ」があると良いと思っている (余裕があれば)
検知フロー (C)
- 以下の3つについて書いている
- いつ検知したのか
- 何によって検知したのか
- 誰が (人・物にかかわらず) 検知したのか
- これによって，検知して初動対応可能になるまでにかかった時間がわかる
- 検知までの時間が長くかかってしまっている場合は，アラートが見落とされているとか，あるいはアラートの仕組みが不足しているとか，なんらか非効率な方法になっているとか，そういった問題を浮き彫りにすることができる
対応タイムライン (B)
- 対応した内容を時系列順に記す
- 「いつ・誰が・何を」という情報が重要
- 「効いた・効かなかった」という情報についても記すべき
原因と解決 (B)
その他反省
- 気づいたことをつらつらと書いてサービス改善につなげる
- 例えば「初動までの時間が長く，alertを上手く検知できていないので改善すべき」みたいな (これは例なのでざっくりしてますが……)
こんなところでしょうか．気づいたら追記するかもわかりません．
outage reportを書くという気持ちを高める
outage reportを書く時ってあまり気持ちがアガるものではないし，障害明けで疲れてたりピリピリしていたり，えてして「なんで俺が書かなきゃならんのだ……」みたいな罰当番的な感じにもなりがちだと思うんですが，実際はそうじゃないですよという雰囲気と仕組みを作ることが重要な気がしています．
例えばoutage reportは関連する人が複数人で書くようにするだとか，あるいはoutage reportを書いた人が評価されるというようにしていくのが良いのではないかと思っている次第です．非常に重要なドキュメントだと思うので．
所属している組織ではscrapboxを使っているので自然と複数人でoutage reportを書く感じになっており，ここらへんは上手くワークしているという感じがしているところです．
今後の課題
これは気をつけている事というよりも抱えている課題なんですが，
- 対応タイムラインを自動的に収集して，あとはコピペするだけにしたい
- outage reportを効果的に社内に周知したい
というのがあって，前者はchat opsに全振りしているような組織だと簡単にできそうで良いな〜と思っているところです (ただそれだけの理由でchat opsに全振りする理由にはならないな……という感じでもある)．なんらかのソリューションが欲しい……
またoutage reportを効果的に社内に通知する方法についてもいい方法を探していて，今の所朝会的なところでoutage reportへのポインタを示すくらいしかできていない状況で，もうちょっとなんかいい方法はないかと探っているという段階です．
なんらか良い方法をご存知の方がいたら教えてもらえると嬉しいです．あと他のみなさんがどういう感じでoutage reportを書いているのかも気になる．
