レジリエンスとデプロイ安全性
概要
物事は壊れます。取るべき姿勢は「すべての障害を防ぐ」ではなく、小さく失敗し、素早く回復し、毎回学習することです。信頼性とは障害がないことではなく、障害が発生したときのブラスト半径を制限し、回復時間を短くすることです。
デプロイ安全性 – すべてのデプロイは元に戻せ、段階的に公開する
- アーティファクトはイミュータブルであり、再ビルドではなくプロモーションされる。 CIで一度だけビルドされた単一のイメージは、そのコンテンツダイジェストで識別され、プレビュー→ステージング→本番と変更されることなく移動します。環境ごとに再ビルドすることは、テストしたことのないものをデプロイすることを意味します。
- タグは可変ポインタであり、ダイジェストが識別子である。 タグは上書きされ、気付かれずに別の場所を指す可能性があります。コンテンツダイジェストはそれができません。各環境は検証したダイジェストを記録し、本番環境は下位環境で検証されたダイジェストのみを実行します。つまり、「テストしたまさにそのもの」という性質は、誰かが覚えておくべき規律ではなく、パイプラインが強制するプロパティになります。
- 本番環境へのデプロイには、人間の判断が必要である。 これは、単独メンテナにとっては、職務分掌ではなく、意図的な一時停止と監査記録を意味します。どちらであるかを明確に述べ、過大評価しないでください。
- 実行中のバージョンはデプロイ時に注入され、イメージに焼き付けられてはならない。 ビルド引数として焼き付けられたバージョンは、リリースを刻印するために再ビルドを強制し、その再ビルドこそがプロモーションが回避しようとしているものです。
- インフラが独自のリポジトリにある場合、展開/収縮（expand/contract）パターンで調整する。 インフラはまず展開（追加的、後方互換）し、アプリケーションは後のデプロイで新しい機能を利用し、そしてインフラは収縮するのは、古い形状に依存する動作中のアーティファクトがなくなった場合のみです。これはスキーマ変更と同じ規律です（
zero-downtime-migrationsを参照）。不変条件：まだ稼働していないインフラ変更を必要とするアプリケーションアーティファクトを決して出荷しないこと。 これを守れば、各リポジトリは独立して元に戻せるようになり、両者の歩調が合わない場合にロールバックを扱いやすくします。 - ロールバックできる場合にのみ、前方へのロールアウトを行う。 リスクのある変更を出荷する前に、ロールバックパスが存在し、テストされています。「どうやってこれを元に戻すのか？」という問いは、インシデント発生時ではなく、計画時に答えられます。
- ロールバックとは、以前に正常だったダイジェストを再デプロイすることである。 そのダイジェストはレジストリにまだ存在し、イミュータブルなので、ロールバックは逆方向へのプロモーションです。決して再ビルドではなく、「当時のまま」の再ビルドでもありません。
- 段階的な公開。 新しいバージョンは徐々にユーザーに届けられます（ヘルスゲート付きロールアウト、サポートされている場合はカナリア）。そのため、悪いリリースが被害を与えるのは一部のユーザーに留まり、全員ではありません。
- スキーマ変更はコードデプロイから切り離され、展開/収縮に従います（
zero-downtime-migrationsを参照）。デプロイは、同時に破壊的なマイグレーションを必要としてはいけません。 - デプロイ準備完了チェックリストが本番環境へのゲートとなる： 可観測性が整っていること、ロールバックが検証されていること、マイグレーションが展開安全であること、SLOが守られていること。
インシデント対応 – 障害は学習へのインプット
- 重要度で分類し、比例した対応を行う。適切な人材を招集するための既知の経路を持つこと。
- すべてのユーザーに影響するインシデントに対して、非難なきポストモーテムを作成する。 タイムラインの記述、原因（システム的なものであり、個人的なものではない）、具体的なアクションアイテムを含みます。問うべきは「このシステムの何がこれを引き起こしたのか」であり、「誰がミスをしたのか」ではありません。
- アクションアイテムは追跡され、忘れられない – それらは将来の検討事項ドキュメント（
recording-decisionsを参照）に流れ込み、実際の作業となります。 - エラーバジェットが優先順位を決める。 信頼性が消費された場合、予算が回復するまで信頼性に関する作業が機能開発よりも優先されます。
クイックリファレンス
| リスクのあるデプロイ前に | 確認すること |
|---|---|
| アーティファクト | CIで一度だけビルドされ、ダイジェストでプロモーションされ、ステージングで検証したものと同じであること |
| ゲート | 本番環境前に記録された人間の判断があること |
| ロールバック | パスが存在し、テストされていること |
| 公開範囲 | 段階的/カナリアであり、一斉ではないこと |
| スキーマ | 展開安全であり、コードデプロイから切り離されていること |
| 可観測性 | 問題が発生しているかどうかを確認できるか |
これを適用するタイミング
ローカル/プレローンチのプロジェクトでもこれらのルールを今すぐ記述し、最初の実際のユーザーが現れた時点で有効にします。プロパティ（一度ビルドし、テストしたものをプロモーションし、本番前に判断し、ロールバック可能であること）は移植可能ですが、メカニズムはそうではありません。コンテナホストではダイジェストによるプロモーションは意味がありますが、静的サイトではほぼ無意味です。また、マネージドプラットフォームはプレビュー環境とインスタントロールバックを無料で提供するかもしれません。プロジェクトのデリバリースキル内でメカニズムを指定してください。プロパティはここに残します。メカニズムのスタック（k8sのプローブ、カナリア、PRごとの環境）：cloud-delivery-aks。
完全な根拠：憲法第XII条、engineering-constitution/references/engineering-constitution.mdに同梱されています。