運用 / 開発プロセス
壊さずに届け、壊れたら気づく
リリースは「デプロイして終わり」ではない。同じ成果物がどの環境でも同じように動く保証、壊れたときに戻せる仕組み、壊れていることに人間より先に気づく仕組み。テストはその一番外側の防波堤。
読み終わると、これに答えられるようになります
- ?手元では動くのに本番で動かない、を構造的に潰すには何が要るか
- ?アラートが多すぎて誰も見なくなる状態をどう避けるか
- ?E2E テストを増やすほど開発が遅くなるのはなぜか
応用14分
CI/CD — 壊れていることに、人間より先に気づく
自動化そのものが目的ではない。「壊れた変更が本番に届かない」ことと「いつでも戻せる」ことを仕組みで保証する。
CI が落ちたまま3週間放置され、誰も赤信号を見なくなっていた
応用14分
コンテナ — 「手元では動く」を構造的に潰す
仮想マシンとの違いはどこか。イメージが層でできていることが、ビルド時間とデプロイの両方を決める。
latest タグを使い続け、ロールバックしたら別のバージョンが起動した
応用14分
ログと監視 — 誰より先に、壊れていることに気づく
ログは調査のため、メトリクスは検知のため、トレースは特定のため。3つの役割を分けて設計する。
アラートが1日200件届き、本物の障害通知が埋もれて3時間気づかなかった
応用15分
テスト戦略 — どこに何枚の網を張るか
テストは多いほど良いわけではない。壊れやすさ・実行時間・書く手間のバランスをどこで取るか。
E2E テストを増やした結果、CI が40分かかり、落ちても誰も原因を調べなくなった
応用15分
インシデント対応 — 直すのが先か、分かるのが先か
原因が分からないまま戻すのは怖い。その感覚が復旧を遅らせる。止血と原因究明の順序、記録の残し方、そして再発防止に「気をつける」と書かないこと。
原因を突き止めてから直そうとして、復旧が3時間遅れた