デプロイ戦略 完全ガイド: 戻せるものと戻せないもの

• はじめに
• 1. デプロイとリリースを分ける
  • 1-1. 分離のコスト
  • 1-2. 最もよくある失敗
• 2. 戻せる変更と戻せない変更 — 判別チェックリスト
  • 2-1. 三段階の分類
  • 2-2. 実務で誤分類されやすいもの
• 3. 戦略カタログと、それぞれが要求する前提
  • 3-1. ここは意見が割れます
• 4. カナリアが意味を持つための条件
  • 4-1. 対照群は同時並行でなければなりません
  • 4-2. 指標は SLI から導き、数を絞ります
  • 4-3. 規模と期間が代表性を持つこと
  • 4-4. カナリアが売っているのはエラーバジェットです
  • 4-5. カナリアが捕まえられないもの
• 5. スキーマ変更 — デプロイ戦略を最も頻繁に破綻させるもの
  • 5-1. 拡張・移行・縮小
  • 5-2. 一つだけ守るなら
  • 5-3. とくに危険な DDL
  • 5-4. ダウンマイグレーションはたいてい嘘です
• 6. フィーチャーフラグ: ロールバックボタンか、新しい技術的負債か
  • 6-1. フラグの本当の価値
  • 6-2. フラグの本当のコスト
  • 6-3. フラグがロールバックボタンになるために
  • 6-4. ここは意見が割れます
• 7. ロールバックそのものを設計する
  • 7-1. ロールバックは例外手続きではなく通常経路です
  • 7-2. ロールバックとロールフォワード
  • 7-3. ロールバックが誘発する二次障害
  • 7-4. 不可逆の区間を越えた後
• 8. 何を見て中断するか — デプロイゲートと SLO
  • 8-1. 中断基準はデプロイ前に数値で書きます
  • 8-2. 観測遅延が段階の長さの下限です
  • 8-3. ゲートに掛ける指標と掛けない指標
  • 8-4. ゲートが敏感すぎるとき
• 9. デプロイを測る
  • 9-1. 速度と安定性はトレードオフではありません
  • 9-2. 指標を KPI にしたときの歪み
• クイズ: 理解度を確認しましょう
• おわりに
• 参考資料
• 関連記事

はじめに

デプロイ戦略を扱う記事はたいていツールのカタログで終わります。このブログにもすでにそういう記事があります。Feature Flag と Progressive Delivery 完全解剖 はダークローンチ、カナリアロールアウト、フラグ管理ツールを手法ごとに整理していますし、CI/CD と GitOps を扱った記事群はパイプラインの組み方を説明しています。それらを書き直すつもりはありません。

この記事は同じ材料を たった一つの軸で並べ直します。すなわち、この変更はまだ戻せるのか、それともすでに戻せない地点を越えたのか、という軸です。この問いに答えられれば戦略の選択はおおむね自動的に決まります。答えられなければ、どのツールを使っても事故は同じ形で起きます。

したがってこの記事の重心はツールではなく データにあります。無停止デプロイを誇っていたチームが実際に崩れる地点は、ほぼ常にスキーマ変更とデータマイグレーションであり、そこはロールアウトツールがまったく助けてくれない領域だからです。

1. デプロイとリリースを分ける

この二語を同じ意味で使う組織はまだ多くあります。しかし両者を分けられないと、戻す手段が一つしか残りません。

• デプロイ (deployment): 新しいコードが本番環境に存在するようになる出来事です。プロセスは起動しヘルスチェックも通っているが、まだ誰もその経路を通っていないことがあります。
• リリース (release): 実際のユーザートラフィックがそのコード経路を流れ始める出来事です。トラフィック比率、フラグのスイッチ、ルーティング規則が決めます。

二つの出来事をひとまとめにすると、戻す単位も一つだけになります。デプロイ成果物そのものです。問題が起きればパイプラインを回し直して前のイメージを配る必要があり、それはたいてい分単位です。逆に分けておけば、戻す単位はトラフィック比率かフラグの値になり、こちらは秒単位です。

1-1. 分離のコスト

分離はタダではありません。リリースを後ろにずらすということは 新しい経路と古い経路が一つのバイナリの中に同居するということです。コードが増え、テストすべき組み合わせが増え、どの経路が実際に動いているのか分かりにくくなります。このコストは 6 節で改めて扱います。

1-2. 最もよくある失敗

コードは分離したのにスキーマは分離していない場合です。アプリケーションはフラグ一つで戻せますが、すでに実行された ALTER TABLE にはフラグがありません。パイプラインがどれほど精巧でも、可逆性はこの地点で途切れます。

2. 戻せる変更と戻せない変更 — 判別チェックリスト

デプロイ計画を立てる前に、次の五つの問いにまず答えます。答えが曖昧なら、その変更は不可逆側に分類しておくほうが安全です。

Q1. この変更の副作用はプロセスの外に残るか?
    (DB 書き込み、外部 API 呼び出し、メッセージ発行、メール/プッシュ送信、決済)
Q2. 以前のバージョンのコードは、新バージョンが書いたデータをそのまま読めるか?
Q3. 戻すのにかかる時間は、問題を検知するのにかかる時間より短いか?
Q4. 戻すという行為そのものが、新しい状態変化を作るか?
Q5. 外部に契約を公開したか? (公開 API、Webhook ペイロード、イベントスキーマ)
    消費者の数を把握していないなら、その変更はすでに不可逆である。

2-1. 三段階の分類

2-2. 実務で誤分類されやすいもの

• インデックス作成はたいてい条件付き可逆です。削除で戻せますが、作成中に発生したロックと I/O 急増は戻せません。戻せるのは結果であって、その過程ですでに起きた障害ではありません。
• メッセージの発行はほぼ常に不可逆です。コンシューマがすでに受け取っていれば、発行取り消しという概念は存在しません。
• 読み取り専用に見える変更も、キャッシュを汚染すれば不可逆に近づきます。誤った値が長い TTL で入ると、コードを戻してもユーザーはしばらく古い結果を見ます。

可逆性はコードの属性ではなく コードとデータと時間の組み合わせです。同じコード変更でも、まだ誰も書いていなければ可逆であり、百万件書いた後は不可逆です。

3. 戦略カタログと、それぞれが要求する前提

各戦略は「良い/悪い」ではなく それぞれ異なる前提を要求します。前提を満たさないまま使えば、名前だけ立派な危険なデプロイになります。

再作成      [v1 v1 v1] → (全面停止) → [v2 v2 v2]     ロールバック = 再デプロイ、停止が再発
ローリング  [v1 v1 v1] → [v2 v1 v1] → [v2 v2 v1] …   ロールバック = 逆方向、同じ所要時間
ブルーグリーン [blue v1] と [green v2] が併存 → ルーター切替  ロールバック = 切り戻し、秒単位
カナリア    [v1 95%] + [v2 5%] → 比率を上げる         ロールバック = 比率 0、秒単位
シャドー    [v1 100%] + [v2 複製トラフィック、応答は破棄]  ロールバック = ミラーリング停止

• 再作成 (recreate): 前提は計画停止が許されることです。二つのバージョンが決して共存できない場合、たとえば排他ロックが必要な一括マイグレーションでは、この方式のほうがむしろ正直です。欠点はロールバックにも停止が伴うことです。
• ローリング: 前提は 二つのバージョンが同時に生きていても安全だということです。ここにはスキーマの双方向互換、セッション非依存、メッセージ形式の互換がすべて含まれます。この前提を検証せずにローリングを使うことが最も多い事故原因です。
• ブルーグリーン: 前提は本番規模の環境を二組維持する資源と、状態を二環境で共有しても問題ないという確認です。コンピュートは複製しやすい一方、データベースはたいてい共有します。つまりブルーグリーンはアプリケーションのロールバックを秒単位にしますが、スキーマの問題はまったく解決しません。
• カナリア: 前提は観測です。トラフィックを分割でき、分割した二集団の指標を別々に見られる必要があります。詳細は 4 節で扱います。
• シャドー (トラフィックミラーリング): 前提は 新バージョンが副作用を出さないよう隔離できることです。複製トラフィックが実際に決済を起こしたりメールを送ったりすれば、それはシャドーではなく二重処理です。性能とエラー率の検証には優れますが、応答を捨てるため正確性の検証には別途の比較機構が要ります。

3-1. ここは意見が割れます

ブルーグリーンの資源コストとカナリアの運用複雑度のどちらが高いかは、チームごとに結論が異なります。ブルーグリーン支持側は切替が原子的でロールバック手順が単純だと指摘します。カナリア支持側はブルーグリーンが切替の瞬間に 100% を一気に露出させるので実際にはリスクを下げていないと反論します。軸は三つです。インフラコスト、観測の成熟度、トラフィック規模です。一日のリクエストが数千件のサービスで 5% カナリアは統計的に無意味であり、この場合はブルーグリーンが合理的です。

ブランチ戦略にも同じ対立があります。トランクベース開発は統合間隔を縮めてデプロイ単位を小さくしますが、フラグ負債を増やします。長期ブランチはコードベースを綺麗に保ちますが、マージ時点で大きな塊を一度にリリースさせます。どちらが優れているかというより デプロイ単位の大きさとフラグ管理コストを交換する選択です。

4. カナリアが意味を持つための条件

Google SRE Workbook はカナリアを「ある変更をサービスに部分的かつ時間を限定して展開し、それを評価すること」と定義し、残りのサーバー群を対照群 (control) と呼びます。この定義から実務要件が四つそのまま導かれます。

4-1. 対照群は同時並行でなければなりません

Workbook はデプロイ前後を比較する方式を明示的に戒めています。理由は 時間が観測指標を変化させる最大の要因の一つだからです。午前 10 時と午前 11 時ではトラフィックの構成もキャッシュヒット率も違います。したがって比較対象は「昨日の自分」ではなく「今隣で動いている以前のバージョン」でなければなりません。

4-2. 指標は SLI から導き、数を絞ります

Workbook は指標が「サービスの問題を示せる」ものであるべきとし、数はせいぜい十数個程度に留めるよう勧めています。さらに 指標はカナリアしている変更に明確に帰属できなければなりません。全社ダッシュボードのすべてのグラフをゲートにすれば、無関係な指標のノイズでデプロイが止まり続け、結局みなゲートを無視するようになります。

4-3. 規模と期間が代表性を持つこと

カナリアは「全体のデプロイを代表できるだけ十分に大きく、十分に長く」続く必要があります。同時に期間はリリース周期と噛み合わなければなりません。Workbook の表現どおり、毎日リリースするなら一つのカナリアを一週間走らせることはできません。

ここで忘れられがちな算数があります。観測したい問題の発生確率が 0.1% で、カナリア区間に届いたリクエストが 200 件なら、期待発生件数は 0.2 件です。何も起きないのが正常なので、このカナリアは「合格」ではなく 「観測されなかった」と読むべきです。この算数は上記の資料に載っているものではなく、この記事で付け加える解釈です。

4-4. カナリアが売っているのはエラーバジェットです

Workbook の中心的な論拠は単純です。カナリア対象が全体の 5% で、その中のエラー率が 20% なら、全体のエラー率は 1% に留まります。つまりカナリアは バグを消す装置ではなく、バグの露出面積を縮める装置です。この観点ではカナリアの比率と期間は任意に決める値ではなく、許容できるエラーバジェット消費量から逆算すべき値になります。SLI/SLO/エラーバジェットに基づく信頼性エンジニアリング と SLO エラーバジェット計算ツール がこの計算を助けます。

4-5. カナリアが捕まえられないもの

Workbook は限界も明記しています。テスト環境は本番と 100% 同一ではなく、共有された障害ドメインや一部の状態を持つ相互作用は全体規模に達して初めて現れます。コネクションプールの枯渇、キャッシュの殺到、下流依存の飽和は 5% ではおとなしく、100% で爆発します。カナリアの通過は安全性の証明ではなく、明白な失敗の不在です。

5. スキーマ変更 — デプロイ戦略を最も頻繁に破綻させるもの

ここがこの記事の中心です。ローリングでもブルーグリーンでもカナリアでも、前提はすべて「二つのバージョンが同時に生きていても安全」でした。スキーマ変更はその前提を直接壊します。

5-1. 拡張・移行・縮小

Martin Fowler がまとめた Parallel Change パターンがこの問題の標準解です。Fowler は拡張フェーズを「インターフェースを広げて旧版と新版の両方を支えるようにすること」、移行フェーズを「旧版を使っているすべてのクライアントを新版へ移すことであり、これは段階的に行える」と説明します。そしてすべての利用箇所が移った後に初めて、縮小フェーズで旧版を取り除きます。このパターンは Joshua Kerievsky に帰属します。

-- 第1段階 拡張(expand): nullable で追加する。デフォルト値を同時に与えると実装によっては
-- テーブル全体の書き換えと長いロックが発生しうるので、分けておく。
ALTER TABLE orders ADD COLUMN currency_code text;

-- 第2段階 移行(migrate): アプリケーションは両方のカラムに書き、読みはまだ旧カラムから行う。
-- 過去行はバッチで埋める。一度に全部ではなく、キー範囲を区切って再開可能にする。
UPDATE orders SET currency_code = 'KRW'
 WHERE currency_code IS NULL AND id BETWEEN 1 AND 10000;

-- 第3段階 縮小(contract): すべての読みが新カラムへ移ったことを確認したうえで、
-- 数日から数週間後、別のデプロイで取り除く。
ALTER TABLE orders DROP COLUMN currency;

5-2. 一つだけ守るなら

一回のデプロイに二つの段階を入れないことです。拡張と移行を同じデプロイに入れると、ロールバックした際に旧コードが新データに出会います。移行と縮小を同じデプロイに入れると、戻すべきカラムがすでに消えています。各段階の間には最低でも一度の安定化期間が必要で、その長さはロールバックを検討しうる最大の時間と一致すべきです。

5-3. とくに危険な DDL

• NOT NULL 制約の追加: 既存行をすべて検査するため、大きなテーブルでは長時間のロックがかかります。まずアプリケーションから値を埋め、バックフィルを終えてから、最後に制約をかけます。
• カラム名の変更: 原子的に見えて実質は削除と追加です。リネームではなく拡張・移行・縮小で処理します。
• 型の変更: 書き換えが必要な場合が多く、旧コードが新しい型を解釈できなくなった瞬間に不可逆になります。
• インデックス作成: オンライン作成のオプションがあるか、あるとして失敗時に残骸が残るかを確認します。
• 大量バックフィル: バッチサイズ、バッチ間の待機、再開地点、そして停止スイッチが必要です。バックフィルがレプリケーション遅延を生み、読み取りレプリカを落とす事故はよくあります。

5-4. ダウンマイグレーションはたいてい嘘です

多くのマイグレーションツールは down スクリプトを要求しますが、データが削除された後の down はスキーマだけを戻し、データは復元しません。したがって実務で信頼できる巻き戻しは 逆方向マイグレーションではなく、そもそも巻き戻す必要がないよう設計された拡張フェーズです。旧コードが新スキーマの上でそのまま動くなら、コードだけ戻せば済みます。それが拡張フェーズの本当の目的です。

6. フィーチャーフラグ: ロールバックボタンか、新しい技術的負債か

6-1. フラグの本当の価値

フラグの価値は 戻すのにかかる時間をパイプラインの速度から切り離すことです。パイプラインが 12 分ならロールバックも 12 分ですが、フラグなら数秒です。検知時間が 3 分の組織では、この差が障害時間を 4 分の 1 に縮めます。

6-2. フラグの本当のコスト

フラグ一つはコード経路を二つにします。理論上 n 個のフラグは 2 の n 乗個の組み合わせを作り、実際にテストされる組み合わせはごく一部です。独立だと信じていた三つのフラグが、特定の組み合わせでだけ壊れるバグはここから生まれます。

リリースフラグ  生成時に削除チケットと期限を同時に作る      寿命: 数日から2週間
実験フラグ      実験の終了日がそのまま期限                  寿命: 実験期間
運用フラグ      キルスイッチ。長期生存を認め文書化する      寿命: 無期限
権限フラグ      実はフラグではなくプロダクト機能である      寿命: 恒久

6-3. フラグがロールバックボタンになるために

• オフ側の経路が実際に実行されている必要があります。一か月誰も通っていない旧経路はすでに腐っている可能性が高いです。カナリアやステージングで定期的に両方を通します。
• フラグはコード経路だけを戻します。オンの間に新形式で保存されたデータは、フラグを切っても残ります。つまりフラグを入れた瞬間、その機能は 2 節の基準で条件付き可逆になります。
• フラグ評価の失敗時の既定値を決めておきます。フラグサービスが応答しないときに安全側へ倒れなければ、フラグ自体が新しい単一障害点になります。

6-4. ここは意見が割れます

フラグがリスクを減らすのか増やすのかは、正直に係争中の主題です。減らす側はロールバック時間と露出面積を根拠にします。増やす側は、残されたフラグが恒久的な分岐となりコードの理解を妨げること、そして「いつでも切れる」という感覚が検証を緩めることを挙げます。実務的にこの論争の軸は フラグ削除を強制する手続きが存在するかどうかです。手続きがあれば前者が、なければ後者が正しい組織になります。

7. ロールバックそのものを設計する

7-1. ロールバックは例外手続きではなく通常経路です

一度も実行したことのないロールバックは計画ではなく願望です。実際に機能している組織は、リリースリハーサルでロールバックを最低一度は実行し、以前の成果物がレジストリに残っているか、ロールバック命令の権限を誰が持つか、設定変更がコードと一緒に戻るかを毎回確認します。

[ロールバック判断チェックリスト — デプロイ開始前に埋めておく]
1. 検知: どの指標が何分以内にこの失敗を示すか?
2. 閾値: その指標がどの値なら中断か? (デプロイ前に数値で確定)
3. 実行: ロールバック命令は何で、誰が権限を持つか? 所要時間は?
4. データ: このデプロイがすでに書いたデータはどうなるか?
5. 不可逆: 戻せない部分の補償手続きは何か?
6. 通知: 誰に知らせるか? (社内、顧客、外部 API 消費者)

7-2. ロールバックとロールフォワード

戻すことが常に正解ではありません。判断基準は二つです。以前のバージョンが確実に正常だったか、そしてロールバックがデータの観点で安全かです。どちらかでも怪しければ、修正版を素早く前へ押し出すロールフォワードのほうが安全です。ただしロールフォワードは「速く直せる」という楽観に依存するので、障害中は時間の上限を決め、その中で解決しなければロールバックへ切り替える規則が必要です。

7-3. ロールバックが誘発する二次障害

戻す行為そのものが障害を作ることがあります。Google SRE Book は連鎖障害を「正のフィードバックの結果として時間とともに拡大する障害」と定義します。ロールバック直後はキャッシュが空になり、コネクションが張り直され、失敗していたリクエストが一斉に再試行されます。まさにそのフィードバックです。

• 再試行は 常にランダム化した指数バックオフで予約します。SRE Book の明示的な推奨です。
• 再試行予算を置きます。書籍の例はプロセスあたり毎分 60 回です。
• 階層が重なると再試行は掛け算になります。三階層がそれぞれ 4 回再試行すれば、ユーザーの一動作が 64 回の試行になります。
• 再試行可能なエラーと恒久的なエラーをコードで区別し、恒久エラーは決して再試行しません。
• 無制限にキューへ積むより早めに拒否するほうが安全です。ロードシェディングと優雅な劣化がその手段です。

再試行を安全にするには冪等性が要ります。RFC 9110 は冪等を「同一のリクエストを複数回送ったときのサーバー上の意図された効果が、一度送った場合と同じであること」と定義し、GET、HEAD、PUT、DELETE、OPTIONS、TRACE を冪等に分類します。POST は冪等ではありません。設計の詳細は 冪等性とリトライ: 信頼できる API と リトライ累積確率 計算ツール を参照してください。

7-4. 不可逆の区間を越えた後

戻せない地点をすでに越えているなら、残るのは補償だけです。誤送信された通知への訂正告知、誤って計算された値を直す訂正バッチ、外部消費者への変更案内がそれにあたります。重要なのは この手続きを事故の後に発明しないことです。2 節で不可逆と分類された項目は、デプロイ計画書に補償手続きを併記すべきです。

8. 何を見て中断するか — デプロイゲートと SLO

8-1. 中断基準はデプロイ前に数値で書きます

デプロイ中にダッシュボードを見ながら「この程度なら大丈夫そうだ」と判断するのは、事後的な正当化になりがちです。数値と観測時間を先に書いておけば、判断は議論ではなく確認に変わります。

# 例 — デプロイゲートを宣言的に書いておく形
canary:
  steps: [1, 5, 25, 50, 100] # トラフィック比率
  interval: 15m # 各段階の観測時間、指標の遅延より長く
  analysis:
    - metric: request_error_rate # SLI から導いた指標
      compare_to: baseline # 同時並行の対照群であり、過去の時点ではない
      fail_if: canary > baseline * 1.2
    - metric: latency_p99
      fail_if: canary > baseline * 1.3
  on_failure: rollback # 自動中断のうえ人に通知

8-2. 観測遅延が段階の長さの下限です

指標パイプラインが 5 分遅れているなら、3 分のカナリア段階は何も見ないまま通過します。各段階の観測時間は、指標の遅延に最低一回の集計周期を足した値より長くなければなりません。この計算を省いた自動昇格パイプラインは、一気に 100% まで上がってからアラートを鳴らします。

8-3. ゲートに掛ける指標と掛けない指標

• 掛けるべきもの: ユーザー視点の SLI です。リクエストエラー率、レイテンシの上位分位、中核となる転換フローの成功率です。
• 参考に留めるもの: CPU やメモリなどの資源指標です。変更との因果が弱く、ノイズが大きいためです。
• 掛けてはならないもの: 変更との帰属関係がない指標です。先に引用した Workbook の帰属要件がこの話です。
• エラーバジェットの消費率: 中断判断には絶対値より消費速度のほうが有用です。

8-4. ゲートが敏感すぎるとき

偽陽性が頻発すると、人はゲートを無視するか迂回します。ゲートを導入した後は 中断のうち実際に欠陥だった割合を併せて記録してください。その割合が低いときは、閾値ではなく指標の選択が誤っている場合が多いです。

9. デプロイを測る

DORA は四つの中核指標を次のように定義しています。

• デプロイ頻度: 一定期間のデプロイ回数、またはデプロイ間の時間です。
• 変更のリードタイム: 変更がバージョン管理にコミットされてから本番にデプロイされるまでの時間です。
• 失敗したデプロイの復旧時間: 即時の介入を要するデプロイ失敗から復旧するまでの時間です。
• 変更失敗率: デプロイ後に即時の介入を要したデプロイの割合です。
• 手戻り率: 本番障害によって発生した計画外デプロイの割合です。

9-1. 速度と安定性はトレードオフではありません

DORA はこの点を明確に述べています。研究の結果、速度と安定性はトレードオフではなく、多くのチームではむしろ両指標が相関するというものです。DORA の表現をそのまま借りれば、長期的に見た本当のトレードオフは 「より良いソフトウェアをより速く」と「より悪いソフトウェアをより遅く」の間にあります。

この結果がこの記事の主題と交わる地点は明快です。頻繁にデプロイするチームが安定しているのは、デプロイ単位が小さいからであり、小さい単位はそのまま戻しやすい単位だからです。可逆性は速度の代償ではなく、速度の前提です。

9-2. 指標を KPI にしたときの歪み

デプロイ頻度を目標にすれば、意味のないデプロイを分割して数字を作れます。変更失敗率を目標にすれば、失敗を失敗として記録しない誘因が生まれます。四つの指標は 一緒に見たときだけ意味を持ち、個別の指標を成果目標に据えた瞬間に歪みます。この警告は上記資料の文ではなく、この記事で付け加える実務上の注意です。

クイズ: 理解度を確認しましょう

おわりに

デプロイ戦略を選ぶことはツールを選ぶことではありません。この変更がまだ戻せる状態かを判別し、戻せない部分を可能な限り後ろへ倒し、それでも残る不可逆区間について補償手続きを先に書いておくことです。

この記事の内容を一文に縮めるとこうなります。可逆性はデプロイパイプラインではなくデータモデルで決まります。拡張・移行・縮小を守るチームはどのデプロイツールを使っても安全であり、それを飛ばしたチームはどのツールを使っても同じ場所で転びます。

参考資料

• Canarying Releases — Google SRE Workbook — カナリアの定義、同時並行の対照群という要件、指標の選定と数の制限、規模と期間の代表性、5% カナリアでエラー率 20% なら全体 1% になる計算、そしてカナリアが捕まえられない限界を引用しました。2026-08-15 確認。
• DORA metrics: the four keys — DORA — デプロイ頻度、変更のリードタイム、失敗したデプロイの復旧時間、変更失敗率、手戻り率の定義と、「速度と安定性はトレードオフではない」という結論を引用しました。2026-08-15 確認。
• Parallel Change — Martin Fowler — 拡張、移行、縮小の三段階の定義と Joshua Kerievsky への帰属を引用しました。2026-08-15 確認。
• Addressing Cascading Failures — Google SRE Book — 連鎖障害の定義、ランダム化した指数バックオフ、毎分 60 回という再試行予算の例、階層ごとの再試行が掛け算になる計算、ロードシェディングを引用しました。2026-08-15 確認。
• RFC 9110 — HTTP Semantics — 9.2.2 節の冪等の定義、冪等メソッドの一覧、POST が冪等でないことを引用しました。2026-08-15 確認。
• 2 節の三段階の可逆性分類、4-3 の標本数の算数、7-1 のロールバック判断チェックリスト、9-2 の KPI 歪みの警告は、上記資料にそのまま載っているものではなく、この記事で整理した手順と解釈です。

関連記事

• このブログの関連記事: Feature Flag と Progressive Delivery 完全解剖
• このブログの関連記事: SLI/SLO/エラーバジェットに基づく信頼性エンジニアリング
• このブログの関連記事: Strangler Fig パターン完全ガイド
• このブログの関連記事: 冪等性とリトライ: 信頼できる API
• 関連ツール: SLO エラーバジェット計算ツール
• 関連ツール: リトライ累積確率 計算ツール

完全ガイドシリーズ

• 前の記事: コードレビュー完全ガイド: レビューをプロセスとして設計する
• 次の記事: リファクタリング完全ガイド: 振る舞いを保ったまま構造を変える手順