すべてのデプロイ判断は教訓である：デリバリーシステムに学習ループを構築する
あるチームが新しいバージョンを本番環境にプッシュした。5分後、エラーレートが急上昇した。誰かがロールバックボタンを押した。システムは安定した。全員が安堵の息をつき、次のタスクに移る。
よくある話だろう？問題はロールバックそのものではない。問題はその後に何が起こるかだ。多くのチームはロールバックを物語の終わりとして扱う。しかし実際には、それはもっと価値のある物語の始まりなのだ。
「直したから終わり」で止まってしまうと、次回のデプロイを改善する機会を失う。本当に問うべきは、単に古いバージョンに戻す方法ではない。なぜエラーレートが上がったのか、そして二度と起こらないようにするには何を変えればよいのか、ということだ。
デプロイ判断はなぜデータの宝庫なのか
チームがデプロイ後に判断を下すたびに——プロモート、ロールバック、保留、機能無効化のいずれであっても——データが生まれている。そのデータは、デリバリーシステムが実際にどのように動作しているかを教えてくれる。可観測性のギャップ、テストの盲点、期待と現実のミスマッチを明らかにする。
このデータを無視すれば、手探りで進むことになる。データを取得して分析すれば、時間の経過とともにデリバリー・プロセスを体系的に改善できる。これが学習ループの本質だ。
学習ループとは、すべてのデプロイ判断をデリバリーシステムの具体的な改善につなげるサイクルである。インシデントを火消し作業からフィードバック信号へと変える。ループは3つのステップで構成される：何が起こったかを把握し、なぜ起こったかを理解し、再発防止のために何かを変える。
このサイクルをシンプルなフローチャートで示す：
実際に役立つポストモーテム
学習ループを始める最も直接的な方法は、デプロイのポストモーテムだ。ただし、ポストモーテムは責任追及の場ではない。デプロイ判断の根本原因を理解するための構造化された議論である。
例えば、レイテンシがSLOを超えたため、チームがデプロイを保留したとする。適切なポストモーテムを行えば、レイテンシの急上昇は新しいコードが原因ではなく、ステージング環境で検出されなかったデータベース設定変更が原因だったことが明らかになるかもしれない。これはバグのあるコードリリースとは異なる問題であり、異なる修正が必要だ。
そのポストモーテムから、チームはパイプラインにデータベース設定変更の可観測性シグナルを追加できる。次回は、パイプラインが本番に到達する前に問題をキャッチする。症状を直しただけでなく、システムを直したのだ。
ポストモーテムは長くしたり形式張ったりする必要はない。シンプルなフォーマットで十分だ：何が起こったか、どのような判断が下されたか、根本原因は何か、何を一つ変えるべきか。プロセスに焦点を当て、人を責めないこと。
SLOは固定されたものではない
Service Level Objectives（SLO）を最初に設定したとき、それは最善の推測だった。当時知っていた情報に基づいて、許容できるレイテンシ、エラーレート、可用性を見積もった。しかし、本番の現実は見積もりと異なることがよくある。
SLOが厳しすぎてエラーバジェットが常に枯渇しているなら、問いかけるべきだ：このSLOは現実的か？それとも、ユーザーにとっては実際には問題ないことでチームを罰していないか？逆に、エラーバジェットが全く減らないなら、SLOが緩すぎる可能性がある。そうなると、SLOが危険を知らせないため、チームが慢心する恐れがある。
デプロイ判断にパターンが見られたら、SLOを見直そう。同じ理由で月に3回ロールバックしたなら、それはSLOかデリバリー・プロセスに調整が必要だというサインだ。四半期レビューを待つ必要はない。データが示すときに調整すべきだ。
エラーバジェットは柔軟に
エラーバジェットは固定された数字ではない。チームの実際の経験を反映するためのツールだ。チームがロールバックではなくロールフォワードを頻繁に行うなら、迅速な修正の余地を確保するためにより大きなエラーバジェットが必要かもしれない。デプロイがうまくいかずに機能を無効化し続けるなら、デプロイ前により慎重になるよう、より厳しいエラーバジェットが必要かもしれない。
重要なのは、運用経験に基づいてエラーバジェットを決めることであって、その逆ではない。バジェットが現実と合わなければ、バジェットを変更しよう。
学習をイベントではなく習慣に
学習ループは、定期的なプラクティスになって初めて機能する。スプリントごと、あるいは月に一度、デプロイ判断のデータを確認する定例レビューを予定に入れよう。シンプルな質問を投げかける：
- ロールバックにどのようなパターンが見られるか？
- 同じ理由でデプロイを繰り返し保留していないか？
- 誤った判断を下したとき、欠けていたシグナルは何か？
- 最大の効果をもたらす変更は何か？
そのレビューから、具体的な変更を実行する。新しい可観測性シグナルを追加する。自動化ポリシーを調整する。パイプラインのステップを修正する。変更は大きくなくてもよい。ただ、実際に効果があるものでなければならない。
学習ループのための実践的チェックリスト
明日から学習ループを始めたいなら、最小限のチェックリストを以下に示す：
- デプロイインシデント（ロールバック、保留、無効化）のたびに、1段落のメモを書く：何が起こったか、どのような判断が下されたか、根本原因は何か。
- 月に一度、過去30日間のメモをレビューし、パターンを探す。
- 1つのパターンを選び、パイプライン、ポリシー、または可観測性に1つの変更を加える。
- データが現実と合わない場合は、SLOまたはエラーバジェットを調整する。
- 繰り返す。
これだけだ。派手なツールや専任チームは必要ない。必要なのは、自分のデータを見て、それに基づいて行動する規律だけだ。
デリバリーシステムに完成はない
学習ループは、すべてのデプロイを一方通行のイベントからフィードバックサイクルへと変える。それぞれの判断がシステムについて何かを教えてくれる。それぞれの教訓が、次回のデプロイをより安全に、より速く、より信頼性の高いものにする。
デリバリーシステムは完成品ではない。実際に起こることから学びながら改善されていく、生きたプロセスだ。最も速く改善するチームは、最も多くのツールを持っているチームではない。すべてのデプロイ判断を学ぶ価値のある教訓として扱うチームなのだ。