再発防止策を書くのは難しい。
良い再発防止策
良い再発防止策について、順位付けするとしたら、
- その種類の問題について二度と意識することがなくなる解決策
- その種類の問題を開発時に自動的に検知することができる解決策
- その種類の問題が発生しても自動的に復旧することができる解決策
- その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策
と言うのは意識したいと思いつつ、やはり難しい。
再発防止はむずかしい
障害の再発防止策は、
- メカニズム
- ツール
- ルール
- チェックリスト
の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。
まさにこの有名な猫...。
**「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミスを繰り返す最大の原因です。**もちろんミスをして、上司や先輩に注意されたときは「反省」するはずですが、頭の中で反省するだけではなく、ミス再発防止ノートを開き、文字にすることでより冷静に、そしてしっかりと考えられるようになります。
原因については同意だしミス再発防止ノートを書くことがたしかに有効ではありそうだ。IPAには教訓集などというものがありこれはこれで読み応えがある。
「情報処理システム高信頼化教訓集（ITサービス編）」を発行：IPA 独立行政法人 情報処理推進機構
ダイジェスト
だがもう一声。その再発防止ノートや教訓をもっと前向きに書きたい、共有したい。
そこでポストモーテム
インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるドキュメント
早速ですが、皆さんのチームにはインシデント発生時のプロセスが決められていますか？
インシデント管理サービスを提供しているPagerDutyは、「PagerDuty Incident Response」というドキュメントを公開しています。 このドキュメントがすごく良いものだったので、このたび邦訳した物を公開することにしました。
!!! note "ガイドライン"
このページはインシデント発生後5営業日以内に設定されるポストモーテムのミーティングで確認することを目的とします。
最初のステップはインシデント発生の5営業日以内に、共有カレンダーにミーティングを設定することです。
情報が埋まるまでミーティングの設定を待ってはいけませんが、ミーティングまでにページができているようにしてください。
** ポストモーテムのオーナー:** _ここにはあなたの名前が入ります。_
** ミーティングの対象:** _インシデント発生後5営業日以内に、「インシデントポストモーテムミーティング」を共有カレンダーにスケジュールします。ここに日付を入力してください_
** 通話の記録:** _インシデントの通話の記録へのリンクを貼る。_
## オーバービュー
_**短い**1、2文で、インシデントの原因や、タイムライン、および影響などを要約します。
たとえば「8月9日の朝、プライマリデータベースマシンの暴走により1分間のSEV-1が発生しました。この遅延により、0.024%のPagerDutyアラートがSLA違反となりました。」_
## 何が起こったか
_何が起こったかを簡潔に書く_
## 根本原因
_問題を引き起こした全ての条件を書く。問題を悪化させるようなアクションをしても、対応中に犯したミスから学ぶために全て書く。_
## 解決
_何によって問題が解決したか書く。一時的な措置を施した場合は、長期的な対策と共に書く。_
## 影響
_具体的な数字で正確に書く_
| | |
| - | - |
| SEV-1の時間 | ?分 |
| SEV-2の時間 | ?分 |
| SLA違反となった通知 | ??% (?? 中 ??) |
| 破棄された/処理されなかったイベント | ??% (?? 中 ??) _通常は0であるべきだが確認する_ |
| 影響を受けたアカウント | ?? |
| 影響を受けたユーザー数 | ?? |
| 発生したサポートリクエスト | ?? _関連するチケットへのリンク_ |
## 対応者
* _インシデントコマンダーはだれか？_
* _補佐は誰か？_
* _他に誰が関わったか？_
## タイムライン
_重要な時刻を書く。(1) 原因が発生した時刻、 (2) ページされた時刻、 (3) ステータスページが更新された時刻（つまり外部告知された時刻）、(4) 重要なアクションを実行した時刻、(5) SEV2/SEV-1が終わった時刻、(6) タイムスタンプが取得されたツール、ログへのリンク_
| Time (UTC) | Event | Data Link |
| ---------- | ----- | --------- |
## どうだったか？
### うまくいったこと
* _あなたがうまくいったと思ったことや、書きたいことをリストにします。全てを挙げなくても大丈夫です。_
### うまくいかなかったこと
* _あなたがうまくいかなかったと思ったことをリストにします。その目的は、プロセスを改善して全ての点でフォローアップするためです。_
## アクションアイテム
_各アクションアイテムはJIRAチケットの形式で、それぞれのチケットは "sev1_YYYYMMDD" と "sev1" のタグを持ちます。
アクションアイテムは (1) 再発防止のための修正、(2) 問題が再発しても問題が小さくなるような措置、 (3) 内部メールやステータスページの更新などのポストモーテムの残り作業、 (4) インシデント対応プロセスの改善、などです。_
## メッセージ
### 内部メール
_従業員に対するフォローアップです。ポストモーテムミーティングが終わった後すぐに送るべきです。メールにはインシデントの簡単な説明とwikiへのリンクを貼ります_
> 何が起こったか、ポストモーテムへのページがどこにあるかを、簡単に要約します
### 外部告知
_インシデントに関してstatus.pagerduty.comに掲載することです。顧客に何を伝えて、どう謝罪しますか？（謝罪は定型文ではなく真摯に書くべきです）_
> 概要
> 何が起こったか
> これに対して私たちは何をしている
それは学びの機会
いまから我々にできること。それは身の回りで起こった失敗を知って読んでみる、感想を述べてみるということ。
ポストモーテムを書くことは処罰ではなく、会社全体としての学びの機会である。
ポストモーテムの文化を根付かせるのは難しく、継続的な育成と強化が必要になる。そのために以下のような活動を行っている。
今月のポストモーテム
Google＋ポストモーテムグループ
ポストモーテム読書会
不運の輪（トレーニングのようなもの）
ポストモーテムをワークフローに組み込む
ポストモーテムの質を適切に評価する文化
上位のリーダーたちの承認と参加を奨励
まとめ
「会社全体としての学びの機会」というのが大きくポイントだと思う。
大抵の失敗は「その反省文を書くことになった一人だけが原因」なんてことはまず無い。ので、最初から、
- 「次から気をつけます」では的外れ。
- 「複数人でチェックします」でも続かない。
- 全体に公開して継続的に皆でふりかえることができる仕組み。
が必要なのだろうなと感じます。というか失敗は共有してこそだし他チームの失敗にこそ学べたり感謝できたりする。その共通認識があるチームは素敵だな。
以上なにがしかの参考になればさいわいです。