reliability-improvement-plan

信頼性改善計画

ステップ 1：コンテキストの収集

ユーザーに次のように尋ねます。

信頼性を評価したいワークロードを教えてください。以下の情報を共有してください。

• ワークロード名と、分析対象のコードパッケージ／ディレクトリ
• 可用性目標（99.9%、99.95%、99.99% など）
• 復旧目標（定義されている場合は RTO と RPO）
• 過去のインシデント（任意。最近の停止やニアミス）

コンテキストがすでに提供されている場合、または IaC を含むコードベースを扱っている場合は、そのまま進めてください。

ステップ 2：フォールトトレランスの調査

インフラを分析し、単一障害点を特定します。

必ず次の項目を確認してください。

• コンピューティングのデプロイ（AZ の分散、インスタンス数、ASG の設定）
• データベースの設定（Multi-AZ、リードレプリカ、クラスターのトポロジー）
• キャッシュの設定（クラスター�ード、レプリカ数、フェイルオーバー）
• ロードバランサーの設定（クロスゾーン、ヘルスチェック、ターゲットグループ）
• NAT Gateway の配置（単一か AZ ごとか）
• DNS の設定（Route 53 のヘルスチェック、フェイルオーバールーティング）
• キューとメッセージングの設定（DLQ、再試行ポリシー）
• ストレージの冗長性（S3 レプリケーション、EBS スナップショット、EFS）

各コンポーネントについて、次の項目を記録してください。

• ファイルパスと行番号
• 現在の冗長性レベル（単一 AZ、マルチ AZ、マルチリージョン）
• 障害の影響範囲
• フェイルオーバーの仕組み（自動、手動、なし）

次の項目は必ず高リスクとして指摘してください。

• 本番ワークロードでの単一 AZ データベースのデプロイ
• 自動スケーリングなしのコンピューティング（インスタンス数が固定）
• 負荷分散されたターゲットのヘルスチェックがない
• 複数の AZ にサービスを提供する単一の NAT Gateway
• レプリケーションされていないステートフルサービス
• 非同期呼び出し（Lambda、SQS、EventBridge）に DLQ がない
• 外部サービスの呼び出しにサーキットブレーカーまたはタイムアウトがない

ステップ 3：復旧能力の調査

バックアップと復旧の設定を分析します。

必ず次の項目を確認してください。

• AWS Backup のプランとルール
• RDS の自動バックアップ設定（保持期間、PITR）
• S3 のバージョニングとレプリケーションルール
• DynamoDB の PITR とバックアップ設定
• EBS スナップショットの設定
• クロスリージョンレプリケーションルール
• 災害復旧の設定（パイロットライト、ウォームスタンバイリソース）

各ステートフルリソースについて、次の項目を記録してください。

• バックアップの頻度と保持期間
• 復旧ポイントの能力（RPO）
• 復旧時間の見積もり（RTO）
• 復旧がテストされているか（DR ランブック、FIS 実験を確認）

次の項目は必ず高リスクとして指摘してください。

• バックアップが設定されていないステートフルリソース
• 本番データのバックアップ保持期間が 7 日未満
• 重要なデータのクロスリージョンバックアップがない
• 復旧テストの証拠がない（FIS 実験も DR ランブックもない）

ステップ 4：スケーリングとキャパシティの調査

スケーリングとキャパシティの設定を分析します。

必ず次の項目を確認してください。

• Auto Scaling Group の設定（最小、最大、希望数、スケーリングポリシー）
• ECS サービスのスケーリング（ターゲット追跡、ステップスケーリング）
• Lambda の同時実行数設定（予約済み、プロビジョニング済み）
• DynamoDB のキャパシティモード（オンデマンドかプロビジョニング済みか、自動スケーリング）
• SQS／Kinesis のスループット設定
• API Gateway のスロットリング設定
• サービスクォータの使用状況とアラーム

次の項目は必ず高リスクとして指摘してください。

• 自動スケーリングポリシーのないコンピューティング
• min = max の ASG（スケーリングの余裕がない）
• サービスクォータのアラームがない
• 重要な関数に予約済み同時実行数が設定されていない Lambda
• 過負荷時に負荷遮断またはスロットリングを行わない

ステップ 5：レジリエンスパターンの検出

アプリケーションコードを分析し、レジリエンスパターンを検出します。

必ず以下を確認してください：

• リトライ設定（SDK クライアント、独自のリトライロジック）
• タイムアウト設定（HTTP クライアント、データベース接続、Lambda のタイムアウト）
• サーキットブレーカーの実装
• フォールバックロジックとグレースフルデグラデーションのパターン
• 冪等性の処理（冪等性キー、重複排除）
• ヘルスチェックエンドポイントの実装
• コネクションプーリングの設定

外部連携ごとに、以下を記録してください：

• 設定済みのタイムアウト（または未設定）
• リトライポリシー（指数バックオフ、最大試行回数、ジッター）
• サーキットブレーカー（あり／なし）
• 失敗時のフォールバック動作

必ず以下を HIGH RISK として警告してください：

• タイムアウトのない外部サービス呼び出し
• SDK クライアントにリトライロジックがない
• イベント駆動型の処理に冪等性がない
• 実際の機能を検証しないヘルスチェック（表面的なチェック）
• Lambda のタイムアウトが API Gateway のタイムアウト以上（呼び出し元は必ずタイムアウトします）

ステップ 6：変更管理の検出

デプロイの安全性に関する設定を分析します。

必ず以下を確認してください：

• デプロイ戦略（カナリア、ブルー／グリーン、ローリング、一括）
• デプロイ時のヘルスチェックによるゲート
• 自動ロールバックの設定（アラームベース）
• データベースの移行戦略（後方互換性、ブルー／グリーンスキーマ）
• フィーチャーフラグの使用状況

必ず以下を HIGH RISK として警告してください：

• 本番環境への一括デプロイ
• ヘルスチェック失敗時の自動ロールバックがない
• 後方互換性のないデータベース移行
• 本番環境のトポロジーを反映した本番前環境がない

---STOP--- チェックポイント：検出が完了しました。評価の前に、調査結果を提示してください。

ワークロードの信頼性について、以下のことが分かりました：

• アーキテクチャ：{コンポーネントと依存関係の概要}
• 単一障害点：{これまでに特定した数}
• 復旧能力：{バックアップ／DR の状況の概要}

信頼性の全評価に進みますか？それとも、対象範囲を調整しますか？

ユーザーが明示的に確認するまで、この時点より先に進まないでください。

ステップ 7：WA フレームワークの質問に照らして評価

各質問について、ステータス、根拠（ファイル：行）、ギャップ、リスクを提示してください。

REL 1 — サービスのクォータと制約をどのように管理していますか？

• 根拠：クォータのアラーム、SDK のリトライ設定、スロットリング処理のコード

REL 2 — ネットワークトポロジーをどのように計画していますか？

• 根拠：サブネットの定義、AZ の分散、NAT の冗長性

REL 3 — システムは需要の変化にどのように適応しますか？

• 根拠：ASG の設定、スケーリングポリシー、Lambda の同時実行数、DynamoDB のキャパシティモード

REL 4 — 分散システムで障害を防ぐために、インタラクションをどのように設計していますか？

• 根拠：リトライロジック、タイムアウト設定、SQS による疎結合化、冪等性トークン

REL 5 — 障害を緩和または耐えられるように、インタラクションをどのように設計していますか？

• 根拠：サーキットブレーカーのコード、フォールバック経路、バルクヘッドパターン、負荷制限

REL 6 — ワークロードのリソースをどのように監視していますか？

• 根拠：ヘルスチェックエンドポイント、アラームの定義、複合アラーム、ダッシュボードの設定

REL 7 — 需要の変化に適応できるよう、ワークロードをどのように設計していますか？

• 根拠：スケーリングポリシーのメトリクス、スケジュールされたスケーリング、予測スケーリングの設定

REL 8 — 変更をどのように実施していますか？

• 根拠：デプロイ設定、ヘルスチェックによるゲート、ロールバックをトリガーするアラーム

REL 9 — データをどのようにバックアップしていますか？

• 根拠：AWS Backup のプラン、PITR の設定、レプリケーションルール、スナップショットの設定

REL 10 — ワークロードを保護するために、障害分離をどのように活用していますか？

• 根拠：AZ の分散、セルベースのパターン、シャッフルシャーディング、分離境界

REL 11 — コンポーネント障害に耐えられるよう、ワークロードをどのように設計していますか？

• 根拠：マルチ AZ の設定、フェイルオーバーポリシー、ステートレス設計、ヘルスベースのルーティング

REL 12 — 信頼性をどのようにテストしていますか？

• 根拠：FIS の実験、障害注入コード、ゲームデーの手順書、DR テストスクリプト

REL 13 — 災害復旧（DR）はどのように計画していますか？

• 証拠：クロスリージョンのリソース、DR の自動化、バックアップからの復元手順、RTO/RPO のドキュメント

Step 8: リスク評価

各指摘事項について、影響度 × 発生可能性を用いて評価します。

影響度：軽微（短時間の性能低下、自動復旧） | 中程度（一部のユーザーに長時間の停止、手動対応が必要） | 深刻（全面停止、データ損失、RTO 内に復旧できない）

発生可能性：低（複数の障害が同時に発生する必要がある） | 中（単一のコンポーネント障害で発生する可能性がある） | 高（通常の運用イベントで発生する可能性があり、冗長性がない）

影響度	発生可能性	リスクレベル
深刻	高	重大
深刻	中	高
深刻	低	高
中程度	高	高
中程度	中	中
中程度	低	中
軽微	高	中
軽微	中	低
軽微	低	低

---STOP--- チェックポイント：評価が完了しました — 改善計画を作成する前に、指摘事項を確認してください。

評価の概要：

• 重大な指摘事項：{count}
• 高リスクの指摘事項：{count}
• 中・低リスクの指摘事項：{count}

改善計画の全体を作成しましょうか。それとも、先に特定の指摘事項について話し合いますか？

ユーザーが明示的に確認するまで、この時点より先に進まないでください。

Step 9: 計画を作成する

# Reliability Improvement Plan: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Availability Target**: {target}
- **Packages Analyzed**: {list}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Reliability Maturity**: {1-5} — {one-line justification}

## Reliability Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Fault Tolerance | {score} | {strength} | {gap} |
| Recovery & Backup | {score} | {strength} | {gap} |
| Scaling & Capacity | {score} | {strength} | {gap} |
| Resilience Patterns | {score} | {strength} | {gap} |
| Change Management | {score} | {strength} | {gap} |
| Testing & Validation | {score} | {strength} | {gap} |

## Single Points of Failure
| Component | Evidence | Failure Impact | Current Mitigation | Risk Level |
|-----------|----------|---------------|-------------------|------------|
| {component} | {file:line} | {impact} | {mitigation or "None"} | {Critical/High/Medium/Low} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), impact assessment, recommendation, effort, AWS services}

## Medium and Low Risk Findings
{Condensed format}

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Impact | Effort |
|---------|--------|--------|--------|
{Enable Multi-AZ, add health checks, configure DLQs, add timeouts}

### Foundation (1-4 weeks)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Auto-scaling, circuit breakers, backup configs, deployment safety}

### Strategic (1-3 months)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Multi-region DR, chaos engineering, cell-based architecture}

## Testing Plan
| Test | Validates | Frequency | AWS Service | Evidence Exists |
|------|-----------|-----------|-------------|-----------------|
| AZ failover | Compute survives AZ loss | Monthly | FIS | {Yes/No} |
| Database failover | RDS failover < 60s | Quarterly | FIS | {Yes/No} |
| Load test | Handles 2x peak | Before releases | Load Testing | {Yes/No} |
| Backup restore | RPO met, data recoverable | Monthly | AWS Backup | {Yes/No} |
| Deployment rollback | Bad deploy reverted < 5 min | Every deploy | CodeDeploy | {Yes/No} |

## Next Steps
{Top 5 concrete reliability actions the team should take this week}

Step 10: フォローアップを提案する

計画を提示した後、次の内容を提案します。

次のことをご希望ですか？

• 特定のコンポーネント向けにマルチ AZ アーキテクチャを設計する
• カオスエンジニアリング向けの FIS 実験テンプレートを生成する
• サービスの依存関係にサーキットブレーカーパターンを実装する
• ステートフルリソース向けのバックアップおよび DR の IaC を作成する
• 自動ロールバックを備えたデプロイの安全設定を設計する

評価の指針

• マルチ AZ、自動スケーリング、ヘルスチェック、自動ロールバック、バックアップを備えたワークロードは成熟しています。高度なテスト（カオスエンジニアリング、DR 訓練、ゲームデー）に重点を置いてください。
• すべての指摘事項には、必ずコード上の証拠が必要です。IaC を確認せずに「マルチ AZ がない」と指摘しないでください。
• データパイプラインでは、コンピューティングの可用性よりデータの耐久性を優先してください。メッセージの損失は処理の遅延より深刻です。
• 可用性目標に応じて期待値を調整してください。99.9% でマルチリージョンは不要ですが、99.99% では必要です。
• コードからは確認できない運用面（例：DR 訓練が実際に実施されているか）については、「判断できません」も妥当な回答です。
• ギャップを列挙する前に、既存の信頼性パターンを明確に示してください。