運用 / 開発プロセス

壊さずに届け、壊れたら気づく

リリースは「デプロイして終わり」ではない。同じ成果物がどの環境でも同じように動く保証、壊れたときに戻せる仕組み、壊れていることに人間より先に気づく仕組み。テストはその一番外側の防波堤。

読み終わると、これに答えられるようになります

自動化そのものが目的ではない。「壊れた変更が本番に届かない」ことと「いつでも戻せる」ことを仕組みで保証する。

CI が落ちたまま3週間放置され、誰も赤信号を見なくなっていた

仮想マシンとの違いはどこか。イメージが層でできていることが、ビルド時間とデプロイの両方を決める。

latest タグを使い続け、ロールバックしたら別のバージョンが起動した

ログは調査のため、メトリクスは検知のため、トレースは特定のため。3つの役割を分けて設計する。

アラートが1日200件届き、本物の障害通知が埋もれて3時間気づかなかった

テストは多いほど良いわけではない。壊れやすさ・実行時間・書く手間のバランスをどこで取るか。

E2E テストを増やした結果、CI が40分かかり、落ちても誰も原因を調べなくなった

原因が分からないまま戻すのは怖い。その感覚が復旧を遅らせる。止血と原因究明の順序、記録の残し方、そして再発防止に「気をつける」と書かないこと。

原因を突き止めてから直そうとして、復旧が3時間遅れた

誤ってコミットしたアクセスキーを次のコミットで消した。半年後にリポジトリを公開した数時間後、そのキーで高額なサーバーが大量に立ち上がった。漏れた鍵に効くのは削除ではなく、無効化。

消したはずのアクセスキーが Git の履歴に残っていて、リポジトリを公開した数時間後に悪用された

使われていないフラグの名前を再利用したら、デプロイに失敗していた1台だけが3年前のコードを動かした。フラグはデプロイと公開を分ける道具で、分けたぶんだけ本番の状態の数が増える。

使われていないフラグの名前を再利用したら、1台だけが3年前の機能を動かし、誤った価格の注文が2時間続いた

毎日バックアップを取っていた。3年間、一度も失敗していなかった。いざ戻そうとしたら、復旧に11時間かかると分かった。

毎日のバックアップは3年間成功していた。戻す段になって、11時間かかると分かった

検証環境のつもりで流したバッチが、本番の顧客にメールを送った。設定が欠けたとき、安全側に倒れるか危険側に倒れるかで結果が変わる。

検証環境で流したバッチが、本番のメール配信サービスを叩いて顧客に届いた

夜間の請求バッチが 3,200 件目で止まった。朝、担当者が最初から流し直した。最初の 3,200 人に、請求が 2 回届いた。バッチは必ず途中で止まる。だから、どこからでも流し直せる形にしておく。

夜間の請求バッチが 3,200 件目で止まり、朝に最初から流し直したため、3,200 人に請求が 2 回届いた

アラームは 1 日 80 件鳴っていた。当番は見なくなり、決済の 5% が失敗していた 2 時間に誰も気づかなかった。鳴らすべきは「何かがおかしい」ではなく、「利用者との約束を、このままだと守れない」とき。

アラームが 1 日 80 件鳴り続けて当番が見なくなり、決済の 5% が失敗していた 2 時間に誰も気づかなかった