operational-excellence

オペレーショナルエクセレンスの評価

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

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

オペレーショナルエクセレンスを評価する対象のワークロードまたは環境を教えてください。以下の情報を共有してください。

• ワークロード名と簡単な説明
• 分析対象のコードパッケージ／ディレクトリ（CI/CD 設定、IaC、アプリケーションコード）
• 既知の運用上の課題（任意。アラート疲れ、デプロイの遅さなど）

ユーザーがすでに詳細を提供している場合、またはコードベース内にいる場合は、質問を省略して調査に進みます。

ステップ 2：CI/CD とデプロイの調査

コードベース内の CI/CD とデプロイに関するすべての設定を分析します。

必ず以下を調査してください。

• パイプライン定義（CodePipeline、GitHub Actions、Jenkins、GitLab CI、CDK Pipelines）
• デプロイ設定（CodeDeploy、ECS デプロイ、Lambda エイリアス、Apollo）
• ビルド設定（buildspec.yml、Makefile、package.json のスクリプト）
• テスト設定（ユニット、統合、E2E テストの構成）
• デプロイ前のゲート（承認ステージ、品質ゲート、セキュリティスキャン）

各パイプライン／デプロイについて、以下を記録してください。

• ファイルパスと行番号
• ステージとその目的
• デプロイ戦略（カナリア、ブルー／グリーン、ローリング、一括）
• ロールバックの仕組み（アラームによる自動実行、手動、なし）
• テストカバレッジのゲート
• アーティファクトの昇格フロー

必ず以下を指摘してください。

• ヘルスチェックによるゲートなしで、本番環境に一括デプロイしている箇所
• ロールバックの仕組みが設定されていない箇所
• パイプラインに自動テストがない箇所
• それ以外は自動化されているパイプライン内の手動ステップ

ステップ 3：可観測性の調査

監視および可観測性に関するすべての設定を分析します。

必ず以下を調査してください。

• CloudWatch アラーム定義（IaC または設定ファイル内）
• ダッシュボード定義（CloudWatch ダッシュボードの JSON、Grafana 設定）
• ログ設定（ロググループ、保持期間、構造化ログライブラリ）
• トレース設定（X-Ray、OpenTelemetry、Jaeger）
• カスタムメトリクスの発行（CloudWatch PutMetricData、StatsD、埋め込みメトリクス）
• 合成カナリア（CloudWatch Synthetics）
• アプリケーションレベルのロギング（構造化ロギング、相関 ID、ログレベル）

各可観測性コンポーネントについて、以下を記録してください。

• 監視対象とその理由
• ファイルパスと行番号
• カバレッジの不足箇所（アラームのないサービス、トレースされていないフロー）

必ず以下を指摘してください。

• CloudWatch アラームがないサービスまたは Lambda 関数
• サービス境界をまたぐ分散トレースがない箇所
• 構造化されていないロギング（JSON なし、相関 ID なし）
• ビジネス上重要な処理にカスタムメトリクスがない箇所
• 正当な理由なくログ保持期間が「無期限」に設定されている箇所
• 重要なユーザージャーニーに合成カナリアがない箇所

ステップ 4：インシデントおよびイベント管理の調査

インシデント対応とイベント管理に関する設定を分析します。

必ず以下を調査してください。

• アラートのルーティング（SNS トピック、PagerDuty／OpsGenie 連携、EventBridge ルール）
• 自動修復（アラームで起動する Lambda 関数、SSM Automation）
• ランブックとプレイブック（SSM ドキュメント、Markdown ランブック、Step Functions）
• エスカレーション設定
• ヘルスチェックの実装（ALB ヘルスチェック、Route 53、カスタムエンドポイント）

---STOP--- チェックポイント：調査完了 — WA フレームワークに基づく評価の準備が整いました

CI/CD パイプライン（{X} 件のパイプライン定義）、可観測性の設定（{Y} 件のアラーム／ダッシュボード／トレース設定）、および分析対象のパッケージ全体にわたるインシデント管理パターンを確認しました。デプロイ戦略、ロールバックの仕組み、監視の不足箇所を記録しました。

これらの調査結果を WA オペレーショナルエクセレンスの柱に関する質問に照らして評価し、リスクレベルを判定してもよろしいですか？

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

ステップ 5：WA フレームワークの質問に基づく評価

各質問について、ステータス、根拠（ファイル：行）、不足箇所、リスクを示してください。

OPS 1 — 優先事項をどのように決定していますか？

• 確認対象：SLO／SLI の定義、ビジネスメトリクスのダッシュボード、ヘルスチェックエンドポイント
• 根拠：アラームのしきい値、ビジネスメトリクスを示すダッシュボードパネル、SLO 目標を記載した README／ドキュメント

OPS 2 — ビジネス成果を支えるために、組織をどのように構成していますか？

• 確認項目：CODEOWNERS ファイル、明確なパッケージ境界、オーナーシップに関するドキュメント
• 証拠：CODEOWNERS、package.json のチームフィールド、README のオーナーシップに関するセクション

OPS 3 — 組織文化はビジネス成果をどのように支えていますか？

• 確認項目：テストカバレッジ、PR テンプレート、コントリビューションガイド、コードレビュー設定
• 証拠：テストディレクトリ、.github/PULL_REQUEST_TEMPLATE、CONTRIBUTING.md

OPS 4 — 可観測性をどのように実装していますか？

• 確認項目：相関 ID を含む構造化ログ、分散トレーシング、カスタムメトリクス、ダッシュボード
• 証拠：ロガー設定、X-Ray/OTEL SDK の使用、PutMetricData の呼び出し、ダッシュボード JSON

OPS 5 — 欠陥を減らし、修正を容易にし、本番環境へのデプロイの流れを改善するにはどうすればよいですか？

• 確認項目：自動テスト（ユニット、統合、E2E）、リンティング、セキュリティスキャン、段階的なデプロイ
• 証拠：テストファイル、ESLint/prettier の設定、SAST ツールの設定、パイプラインのステージ定義

OPS 6 — デプロイのリスクをどのように軽減していますか？

• 確認項目：カナリア／ブルーグリーンデプロイ、フィーチャーフラグ、自動ロールバック、デプロイアラーム
• 証拠：CodeDeploy のデプロイ設定、フィーチャーフラグ SDK のインポート、ロールバックアラーム ARN

OPS 7 — ワークロードをサポートする準備ができていることを、どのように確認していますか？

• 確認項目：既知の障害モードに関するランブック、デプロイ前チェックリスト、負荷テスト、運用準備レビュー
• 証拠：SSM ドキュメント、ランブックの Markdown ファイル、負荷テストスクリプト、準備状況の設定

OPS 8 — ワークロードの健全性をどのように把握していますか？

• 確認項目：複合アラーム、健全性ダッシュボード、依存関係の健全性追跡、SLI モニタリング
• 証拠：CompositeAlarm コンストラクト、ダッシュボード定義、ヘルスチェックエンドポイント

OPS 9 — 運用の健全性をどのように把握していますか？

• 確認項目：DORA メトリクスの追跡、デプロイ成功率のモニタリング、パイプライン健全性ダッシュボード
• 証拠：パイプラインメトリクス、デプロイ監視アラーム、運用ダッシュボード

OPS 10 — ワークロードと運用のイベントをどのように管理していますか？

• 確認項目：運用イベント向けの EventBridge ルール、自動修復 Lambda、エスカレーション設定
• 証拠：EventBridge ルール定義、修復用 Lambda コード、SNS トピックのサブスクリプション

Step 6: リスク評価

各検出事項を、影響度 × 発生可能性で評価します。

影響度：軽微（不便だが、手動での回避策がある）｜中程度（検出の遅れ、復旧時間の延長）｜重大（停止を検出できない、ロールバックできない、データ損失）

発生可能性：低（まれな条件が必要）｜中（通常の運用下で発生する可能性がある）｜高（次のインシデントまたはデプロイ時に発生する可能性が高い）

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

Step 7: 評価を作成する

# Operational Excellence Assessment: {Workload Name}

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

## Maturity Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| CI/CD & Deployment | {score} | {strength} | {gap} |
| Observability | {score} | {strength} | {gap} |
| Incident Management | {score} | {strength} | {gap} |
| Change Management | {score} | {strength} | {gap} |
| Continuous Improvement | {score} | {strength} | {gap} |

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

## Medium Risk Findings
{Same format, condensed}

## Low Risk Findings
{Summary table: ID | Domain | Title | Recommendation}

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Impact | Effort |
|---------|--------|--------|--------|
{Add alarms, fix log retention, enable rollback}

### Foundation (1-4 weeks)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Add tracing, implement canary deployments, create runbooks}

### Strategic (1-3 months)
| Finding | Action | Impact | Effort | Dependencies |
|---------|--------|--------|--------|--------------|
{Chaos engineering, self-healing automation, DORA metrics tracking}

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

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

評価を提示した後、次の内容を提案します。

次の対応をご希望ですか？

• CI/CD、可観測性、またはインシデント対応を詳しく調査する
• 特定されたギャップを補う CloudWatch アラームとダッシュボードの IaC を生成する
• 特定の障害モード向けのランブックを作成する
• 繰り返し発生する問題に対する自己修復型アーキテクチャを設計する
• 相関 ID を含む構造化ログを実装する

キャリブレーションの指針

• CI/CD パイプライン、自動ロールバック、CloudWatch アラーム、構造化ログを備えたワークロードは成熟しています。高度な改善（カオスエンジニアリング、SLO ベースのアラート、運用レビュー）に重点を置いてください。
• すべての指摘にはコード上の根拠が必要です。既存の実装を確認せずに「監視を導入すべき」といった一般論を述べないでください。
• コードから判断できないこと（例：オンコール体制の質、インシデントレビューのプロセス）は「判断不能」とし、判断に必要な情報を説明してください。
• ギャップを列挙する前に、既存の運用上の強みを明示的に評価してください。
• アーキテクチャの移行中にあるワークロードについては、新しいアーキテクチャによって生じる運用上の要件に焦点を当ててください。