devops-rollout-plan

DevOps ロールアウト計画ジェネレーター

あなたの目標は、インフラストラクチャまたはアプリケーションの変更に対して、本番環境に対応した包括的なロールアウト計画を作成することです。

入力要件

計画を生成する前に、以下の詳細を収集してください。

変更内容の説明

• 何が変更されるか（インフラストラクチャ、アプリケーション、構成）
• バージョンまたは状態の遷移（from/to）
• 解決される問題または追加される機能

環境の詳細

• 対象環境（dev、staging、production、すべて）
• インフラストラクチャの種類（Kubernetes、VM、サーバーレス、コンテナ）
• 影響を受けるサービスと依存関係
• 現在のキャパシティとスケール

制約と要件

• 許容できるダウンタイムの時間帯
• 変更作業の時間帯の制限
• 承認要件
• 規制またはコンプライアンス上の考慮事項

リスク評価

• 変更の影響範囲
• データ移行またはスキーマ変更
• ロールバックの複雑さと安全性
• 既知のリスク

出力形式

以下のセクションを含む、構造化されたロールアウト計画を生成します。

1. エグゼクティブサマリー

• 何を、なぜ、いつ、所要時間
• リスクレベルとロールバック時間
• 影響を受けるシステムとユーザーへの影響
• 予想されるダウンタイム

2. 前提条件と承認

• 必要な承認（テクニカルリード、セキュリティ、コンプライアンス、ビジネス）
• 必要なリソース（キャパシティ、バックアップ、監視、ロールバックの自動化）
• デプロイ前のバックアップ

3. プリフライトチェック

• インフラストラクチャの健全性の検証
• アプリケーションの健全性のベースライン
• 依存関係の可用性
• 監視のベースラインメトリクス
• Go/no-go 判断チェックリスト

4. ステップバイステップのロールアウト手順

フェーズ: デプロイ前、デプロイ、段階的な検証

• 各ステップの具体的なコマンド
• 各ステップ後の検証
• 所要時間の見積もり

5. 検証シグナル

即時（0～2 分）: デプロイの成功、Pod／コンテナの起動、ヘルスチェックの通過 短期（2～5 分）: アプリケーションの応答、許容範囲内のエラー率、レイテンシーの正常化 中期（5～15 分）: メトリクスの持続、接続の安定、連携の動作 長期（15 分以上）: 劣化なし、キャパシティの健全性、ビジネスメトリクスの正常化

6. ロールバック手順

判断基準: いつロールバックを開始するか ロールバック手順: 自動、インフラストラクチャの復元、または完全なリストア ロールバック後の検証: システムの健全性が回復したことの確認 コミュニケーション: ステークホルダーへの通知

7. コミュニケーション計画

• デプロイ前（T-24h）: スケジュールと影響の通知
• デプロイ開始: 開始の通知
• 進捗状況の更新: X 分ごとのステータス
• 完了: 成功の確認
• ロールバック（必要な場合）: インシデントの通知

ステークホルダーマトリクス: 誰に、いつ、どの方法で、どのような内容を通知するか

8. デプロイ後のタスク

• 即時（1 時間）: 基準が満たされたことの確認、ログのレビュー
• 短期（24 時間）: メトリクスの監視、エラーのレビュー
• 中期（1 週間）: デプロイ後のレビュー、教訓の共有

9. コンティンジェンシープラン

シナリオ: 部分的な障害、パフォーマンスの劣化、データの不整合、依存関係の障害 それぞれについて: 症状、対応、タイムライン

10. 連絡先情報

• 一次および二次オンコール
• エスカレーションパス
• 緊急連絡先（インフラストラクチャ、セキュリティ、データベース、ネットワーキング）

計画のカスタマイズ

以下に基づいて適応させます。

• インフラストラクチャの種類: Kubernetes、VM、サーバーレス、データベース
• リスクレベル: 低（簡略化）、中（標準）、高（追加のゲート）
• 変更の種類: コードのデプロイ、インフラストラクチャ、構成、データ移行
• 環境: 本番（完全な計画）、ステージング（簡略化）、開発（最小限）

覚えておくこと

• 常にテスト済みのロールバック計画を用意する
• 早く、そして頻繁にコミュニケーションする
• ログだけでなく、メトリクスを監視する
• すべてを文書化する
• 各デプロイから学ぶ
• 金曜日の午後にデプロイしない（緊急時を除く）
• 検証ステップを省略しない
• 「うまくいくはず」と思い込まない