agentsclimarketplace
Sign in

Safe release practices

Skill goonobu-dot/dev-skills-library/skills/safe-release-practices

Safe production release practices from Google SRE, Netflix, Microsoft, Meta, and Uber: canary and staged rollouts, roll-back-first incident response, feature flag taxonomy and cleanup discipline, fault injection testing, and blameless postmortems. Use when planning a production deployment or release strategy, adding feature flags, responding to a production incident, or when the user says 本番リリース, カナリア, フィーチャーフラグ, ポストモーテム, 障害報告書. Not for CI pipeline configuration (use ci-cd-hardening) or debugging the failure itself (use systematic-debugging).From its SKILL.md

Install
npx -y skills add goonobu-dot/dev-skills-library --skill safe-release-practices

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

10.8 KB, ~3.7k tokens by cl100k_base, as published. Nobody here has run it

Safe Release Practices

本番への変更は「出す瞬間の安全機構」と「障害を学習に変える仕組み」の両方がなければ安全とは言えない。段階的に出し、悪化したら自動で戻し、起きた障害は個人の懲罰ではなく仕組みの改善に変換する。

鉄則（Iron Law）

  1. 変更は一度に全トラフィックへ出さない。 小さい割合・限定範囲から段階的に広げる。
  2. 異常検知時は「まずロールバック、原因調査は後」を徹底する。 MTTR最小化を原因特定より優先する。ロールバックは「修正」ではなく被害の遮断であり、systematic-debugging の「根本原因を先に特定する」原則はロールバック後の恒久修正フェーズに適用する。
  3. カナリアの良し悪しは人の目視ではなく、事前定義した閾値とメトリクスで自動判定する。
  4. フィーチャーフラグは目的別に分類し、Release Toggleは役目を終えたら独立コミットで確実に除去する。
  5. ポストモーテムは個人ではなく役割で書き、懲罰ではなく再発防止のアクションアイテムを主産物とする。

作業手順

ステップ1: 段階的ロールアウトを設計する

  1. 変更を一度に全体へ出さず、まず小さい単位（1台、1リージョン、1%のトラフィック）に限定して出す。
  2. 地理・時間帯の異なる複数ステージに分けて展開する。トラフィックの日次サイクルや地域特性起因の問題は単一ステージでは検出できない。
  3. カナリア群と対照群（ベースライン）を同一条件で比較できるようにトラフィックを分割する。

ステップ2: 自動判定の仕組みを用意する

  1. エラー率・レイテンシ・CPU等、事前定義したメトリクスをカナリアとベースラインの双方で収集する。
  2. 「悪化」と判定する閾値を事前に決めておく。判定はその場の目視ではなく、統計的な比較で行う。
  3. 判定結果に応じて「自動昇格」「自動失敗（ロールバック）」「人による承認待ち」に分岐させる。
  4. 判定ロジックとメトリクス定義はコードとして管理し、次回のリリースでも再利用する。

ステップ3: 異常発生時に動く

  1. 閾値超過を検知したら、原因調査より先に自動ロールバックを実行する。
  2. ロールバック後に原因調査へ移る。「原因が分かるまでロールバックしない」を避ける。
  3. 監視・可観測性のための新規デプロイ（新しいテレメトリサービス等）も、本番機能追加と同じ厳格さ（段階的ロールアウト・負荷試験）で扱う。「監視のためだから安全」という思い込みを避け、既存のコントロールプレーンへの追加負荷を事前に見積もる。

ステップ4: フィーチャーフラグを分類・運用する

  1. フラグ追加時に目的別へ分類する。
    • Release Toggle: 未完成コードを安全に隠す。短命。リリース後は速やかに除去する。
    • Experiment Toggle: A/Bテスト用。実験終了で除去する。
    • Ops Toggle: 運用者が挙動を制御する。長命、恒久的に残ってよい。
    • Permission Toggle: 特定ユーザー群への機能公開。ライフサイクルは事業判断に従う。
  2. Release ToggleとOps/Permission Toggleを同じ設定ファイル・同じ管理ライフサイクルで扱わない。寿命も削除責任者も異なる。
  3. コードの分岐点を最小限にする。機能内部の全箇所をif分岐で汚染せず、エントリーポイント（ルーティング層）だけで切り替える。
  4. フラグの棚卸しを定期的に行い、役目を終えたフラグを検出・削除する。フラグ除去は独立したコミットとして扱い、他の変更と混ぜない（構造変更と振る舞い変更を分離する原則と同じ理由）。

ステップ5: 障害への耐性を事前検証する

  1. フェイルオーバーや冗長化の仕組みは「実装しただけ」では信頼しない。実際に発動するかを自動テスト（障害注入テスト）で検証し、CIに組み込んでリリースのたびに実行する。
  2. 想定される障害シナリオごとにPlaybook（対応手順書）を作成する。Playbookのないミティゲーションは未完成とみなす。
  3. Playbook自体を定期的に演習（ゲームデー等）で実際に辿り、古くなっていないか検証する。
  4. カオスエンジニアリングを行う場合は「このコンポーネントが落ちても、システムはこう振る舞うはずだ」という具体的仮説を立ててから障害を注入する。ブラストラジウス制御（対象範囲の限定、即時中断スイッチ）を必ず用意する。

ステップ6: ブレームレス・ポストモーテムを書く

  1. 個人名ではなく役割で記述する（「担当エンジニアが」であり実名を出さない）。
  2. 「その時点で入手可能な情報から見て、関係者は合理的な判断をした」という前提で書く。個人の懲罰を目的としない。
  3. タイムライン・影響範囲・根本原因・再発防止アクションアイテムを分けて記載する。アクションアイテムには担当と期限を必ずつける。
  4. ユーザー影響（データ不整合・古い情報表示等）を明確に切り分けて報告し、データ損失の有無を最優先で確認・開示する。
  5. 再現性が低い・原因不明の障害は、個別事象への固執をやめ、大量データ（ログ・コアダンプ等）を集約した母集団分析で統計的パターンを探すことも検討する。
  6. 組織全体で共有し、他チームが同種の問題を抱えていないか横展開して確認する。

チェックリスト

リリース計画時:

  • 変更は段階的ロールアウト（小さい割合→拡大）で設計されているか
  • カナリア判定は人の目視ではなく事前定義の閾値・メトリクスで自動化されているか
  • 悪化検知時に自動ロールバックする経路があるか
  • 新しいフィーチャーフラグは4分類のどれかに位置づけられているか
  • フェイルオーバー等のミティゲーションに対応する障害注入テストがあるか

インシデント対応時:

  • 原因調査より先にロールバックを実行したか
  • ユーザー影響・データ損失の有無を最優先で確認したか

ポストモーテム作成時:

  • 実名ではなく役割で記述しているか
  • タイムライン・影響範囲・根本原因・アクションアイテムが分けて書かれているか
  • アクションアイテムに担当と期限があるか

定期棚卸し:

  • 役目を終えたRelease Toggleが残っていないか
  • フラグ除去は他の変更と混ぜず独立コミットになっているか
  • Playbookは最新のシステム構成と乖離していないか（演習で確認したか）

アンチパターン集

やりがちな思考現実
「小さい変更だから全トラフィックに一気に出そう」変更の大小と障害インパクトは比例しない。段階的ロールアウトを常に基本形にする
「カナリアの様子を少し見て、大丈夫そうなら昇格しよう」目視確認は見落としと属人化を招く。事前定義の閾値とメトリクスで自動判定する
「原因が分かるまでロールバックは待とう」原因調査を優先すると被害時間が伸びる。まずロールバック、原因調査は後
「監視用の変更だから慎重にしなくていい」監視コンポーネント自体が新たな障害点になり得る。本番機能と同じ厳格さで扱う
「このフラグはもう使っていないはずだから放置でいい」放置されたRelease Toggleは技術的負債と誤動作の温床になる。定期棚卸しで確実に除去する
「フラグ除去も他の修正と一緒にコミットしてしまおう」フラグ除去と機能修正を混ぜると、問題発生時にどちらが原因か切り分けられなくなる
「ポストモーテムで担当者の名前を出して反省を促そう」個人の懲罰化は次回以降の正直な報告を妨げる。役割で書き、仕組みの改善に焦点を当てる
「フェイルオーバーは実装したから大丈夫」実装しただけでは時間とともにリグレッションする。自動テストで実際に発動するか継続的に検証する

出典

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.