復旧後に何が起きるか：インフラ障害をプロセス改善に変える方法
モニタリングダッシュボードが再び緑色に戻った。チームは安堵のため息をつく。インシデントは解決され、サービスは復旧し、ようやく帰宅できる、あるいは通常業務に戻れる。
まさにこの瞬間、多くのチームが最も貴重なものを失っている。それは、障害から得た教訓だ。
すべてが正常に戻ると、自然と先に進みたくなる。プレッシャーは消え、緊急度は過ぎ去り、他にも待っているタスクがある。しかし、何が起きたのかを理解するステップを飛ばせば、次の変更も同じ方法で、同じ時間に、同じストレスを伴って失敗することを保証しているようなものだ。
非難ではなく、ポストモーテムから始める
復旧後に最初に行うべきことはポストモーテムだ。これは誰がミスをしたかを見つけるための会議ではない。実際に何が起きたのかを再構築する構造化されたプロセスである。何が計画され、何が実行され、どこから問題が発生し、復旧がどのように進んだのかを明らかにする。
次のフローチャートは、インシデント解決後の主要なステップをまとめたものです：
タイムラインが必要だ。変更を決定した時点から始める。パイプラインのレビュー結果、適用ステップ、最初のトラブルの兆候、復旧中に行われたすべてのアクションを含める。詳細がまだ新しいうちに書き留めておく。このタイムラインが、パターンを特定するための生の素材となる。
有益なポストモーテムのための最も重要な条件は、非難のない文化である。もし人々がミスを罰せられることを恐れれば、詳細を隠すだろう。チャットログをきれいにし、疑念を省略し、気づいていたが口にしなかった警告サインについて言及しなくなる。非難のないポストモーテムは、誰も責任を問われないという意味ではない。焦点は、障害を許したプロセスにあり、コマンドを実行した人にはない。
2種類の発見事項
タイムラインができ、チームが正直に話せる安全な雰囲気ができたら、通常2つのカテゴリーの問題が見つかる。
最初のカテゴリーは、今回失敗した変更に固有のものだ。Terraformのパラメータが最新のプロバイダバージョンと互換性がなかったのかもしれない。リソースの依存関係が計画時に見えなかったのかもしれない。設定値のタイプミスがあったのかもしれない。これらは直接修正できる一回限りの問題だ。
2番目のカテゴリーはシステム的なものだ。これらは、そもそも障害を可能にしたより深い問題である。パイプラインが適用前に計画チェックを実行しなかった。変更後にその特定のリソースに対するモニタリングがなかった。ユーザーが報告するまで、チームは異常を検出する方法がなかった。復旧計画は存在したが、テストされたことがなかった。これらは、対処されなければ、次の障害が異なる見た目でありながら、まったく同じように感じられる原因となる発見事項だ。
発見事項を具体的な修正に変換する
すべての発見事項は変更に変える必要がある。まずはパイプラインから始める。通常、それが最も早く修正できるからだ。
計画チェックがスキップされたために障害が発生したなら、適用前に計画の検査を必須とする自動ゲートを追加する。モニタリングが異常をキャッチしなかったなら、不足しているメトリクスやアラートを追加する。ロールバック手順が不明確だったなら、テスト済みのロールバックステップを含むようにパイプラインを更新する。これらは、先ほど失敗したのと同じパイプラインにすぐに実装できる技術的な変更だ。
次に、復旧計画自体を更新する。今回のインシデントの経験は、おそらく元の計画のギャップを明らかにしたはずだ。スナップショットからの復元ステップが、データボリュームの増加により予想の2倍の時間がかかったかもしれない。復元後の検証ステップが欠けていたため、誰かが手動で確認するまでサービスが正常であることがわからなかったかもしれない。復旧計画を現実的な時間見積もりで更新し、中間検証ステップを追加し、実際に機能したコマンドを文書化する。
小説ではなく、経験を文書化する
障害後のドキュメントは、誰も読まない形式的なレポートである必要はない。同じような変更に直面したときに、別のエンジニアが手に取れる実用的な記録である必要がある。
書き留める内容：どのような変更が試みられたか、初期の警告サインは何か、どのような復旧手順が取られたか、各ステップにどれだけ時間がかかったか、その後何が修正されたか。短く保つ。1〜2ページで十分だ。チームが見つけられる場所に保存し、誰も開かないフォルダに埋もれさせない。
このドキュメントは、この種の障害を経験したことのない新しいチームメンバーにとって特に価値がある。彼らが同様の状況に遭遇したとき、何に注意し、何をすべきかを示すリファレンスとなる。
再試行のタイミングを決める
すべての修正が完了したら、チームは同じ変更をいつ再試行するかを決める必要がある。急いではいけない。復旧計画が再テストされ、根本原因が完全に理解されていない限り、同じ日に再デプロイしてはならない。
パイプラインの変更が機能することを確認する時間をチームに与える。可能であれば、小さなシミュレーションを実行する。少なくとも1サイクルは修正を浸透させる。目標はスピードではない。目標は、次の試行で同じ失敗を繰り返さないことだ。
復旧後評価のための実践的チェックリスト
次の復旧後セッションのためのクイックリファレンスとして、ここに要点をカバーする短いチェックリストを示す：
- 決定から復旧までの完全なタイムラインを再構築する
- この変更に固有の発見事項を特定する
- 将来の変更に影響を与える可能性のあるシステム的な発見事項を特定する
- パイプラインの修正を実装する（ゲート、モニタリング、ロールバックステップ）
- 復旧計画を現実的な見積もりと検証ステップで更新する
- 将来の参照用に短い実用的なドキュメントを書く
- 修正が検証された後にのみ次の試行を計画する
このステップをスキップすることの本当のコスト
すべてのインフラ障害にはコストがかかる。時間、ストレス、ユーザーの信頼、時には金銭も。そのコストはすでに支払われている。その投資からリターンを得る唯一の方法は、そこから学び、プロセスを改善することだ。
評価をスキップすれば、同じ脆弱なプロセス、同じモニタリングのギャップ、同じ未テストの復旧計画で次の障害に直面することになる。障害は違って見えるだろうが、パターンは同じだ。
時間とともに改善するチームは、決して失敗しないチームではない。彼らは、すべての失敗を、二度と払う必要のない教訓のための授業料として扱うチームなのだ。