ブレームレス・ポストモーテム（blameless postmortem）とは、インシデントを文書にまとめて振り返るときに、誰がミスをしたかではなく、なぜシステムがそのミスを許してしまったのかを問うやり方です。ITでヒューマンエラーを扱ううえで、私が知る限りいちばん役に立つ習慣です。罰せられないと分かっていて初めて、人はミスをすぐに白状できるからです。残りは地味な話です。そもそもミスが起きる機会を減らすこと、そしてそれでも大きなことが起きたときのために、テスト済みの計画を用意しておくこと。
ニュージーランドにいた頃、Sparkという通信会社のネットワークオペレーションで1年働きました。そこで身に染みた教訓はシンプルです。人はミスをするし、システムは落ちる。しかもこちらの都合などお構いなしのタイミングで。コントロールできる変数はただひとつ、起きたときにどれだけ備えができているか、それだけです。
ミスを白状しやすくする：ブレームレス・ポストモーテム#
一番効く改善は、技術的なものではありません。ミスをした人が罰せられる職場では、ミスは隠されます。そして隠されたミスの修復は、本来より何時間も、ときには何日も遅れます。「壊しました、やったことはこれです」と数分以内に言えるチームは、必ず復旧が速い。その後の対応も同じくらい大事です。症状にパッチを当てて終わりにせず、根本原因まで掘ること。そうしないと、同じミスが別の顔をして戻ってきます。
この「その後の対応」のための仕組みが、ブレームレス・ポストモーテムです。学ぶべきことのあるインシデントが起きたら、誰かがそれを文書にまとめます。何が起きたか、どんな影響があったか、どう直したか。その文書は、関わった全員がその時点で知っていた情報の範囲で善意で動いた、という前提に立ちます。だから「誰のせいか」ではなく「何がそのミスを起こしやすくしていたか」を問います。確認ステップがなかった、ダッシュボードが紛らわしかった、そもそもランブックがなかった、といったことです。「エンジニアが誤って本番でマイグレーションを実行した」は、「デプロイスクリプトが、確認なしで本番にマイグレーションを流せるようになっていた」に変わります。書いたものは他のチームも学べるように共有し、担当者と期限つきのアクションアイテムで締めくくります。そうしないと、誰も動かない文書で終わってしまうからです。詳しくはGoogleのSRE本のポストモーテムの章、Postmortem Culture: Learning from Failureにあり、実例も載っています。
ブレームレス・ポストモーテムのテンプレート#
最初はこのくらいで十分です。実際に書いてもらえる短さに保つのがコツです。
# ポストモーテム: <短いタイトル>
日付: YYYY-MM-DD · 作成者: <名前> · ステータス: 下書き / レビュー済み
## 概要
2〜3文で。何が壊れ、どれくらい続き、どう直したか。
## 影響
誰が、何人、どれくらいの時間影響を受けたか。失われたデータや売上があればそれも。
## タイムライン
タイムゾーンはひとつに統一。
- 14:02 デプロイ開始
- 14:09 最初のアラート発報
- 14:15 ロールバック開始
- 14:21 エラー率が平常に戻る
## 要因
システム、プロセス、ツールのどこがこれを許したか。個人名は書かない。
## うまくいったこと
## うまくいかなかったこと
## アクションアイテム
| 対応 | 担当者 | 期限 |
|------------------------------------------------|--------|------------|
| マイグレーションスクリプトに確認ステップを追加 | <名前> | YYYY-MM-DD |そもそもミスが起きる確率を下げる#
ここでは地味な施策が3つ、仕事の大半をこなしてくれます。まずスキルを錆びさせないこと。エラーは古い知識が大好物なので、定期的なトレーニングは福利厚生ではなくメンテナンスです。次に手順を文書化すること。「ヒューマンエラー」の多くは実は「曖昧さエラー」で、ドキュメントがないから誰かが勘で操作しただけだったりします。そして繰り返し作業の自動化。同じ作業を500回正確にこなすのは人間には無理ですが、コンピュータはまさにそのために作られています。加えて、リスクのある作業にはもう一組の目を。ピアレビューでも、型の決まったセルフチェックでも、世に出る前に恥ずかしい数の問題を拾ってくれます。
大物が来る前に計画を書いておく#
まず正直なリスク評価から始めます。ITインフラのような内部の弱点と、自然災害のような外部の脅威の両方です。リアルタイムの監視は早期警報システムとして必ず入れておく。そのうえで計画を書きます。事業の混乱全般に対しては事業継続計画（BCP）、IT側に特化しては災害復旧計画（DR計画）。災害復旧計画には、システムごとにどれだけ止まっていてよいか、どれだけのデータを失ってよいか（目標復旧時間RTOと目標復旧時点RPO）を書いておきます。
テストしていない計画はただの推測なので、訓練は実施すること。誰がステークホルダーに何を伝えるかも事前に決めておきます。危機のさなかの即興の広報こそ、パニックの発生源ですから。最後に、華のない残りも省略しないこと。地元当局との連絡を保ち、メンテナンスを続け、適切な保険に入っておく。
どれもワクワクしない話ですが、だからこそ機能するのだと思います。障害にうまく対処する会社は運が良いのではなく、すべてが平和なうちに備えていただけです。