セクション 6：ソリューションと運用上の卓越性

🎯 学習目標チェックリスト

6.1 Operational Excellence の 5 原則

Well-Architected Framework の 柱 1: Operational Excellence。試験では「運用品質を上げる原則・指標」が問われます。

原則の運用への落とし込み

なぜ Operational Excellence が重要か

• 障害時の MTTR（平均修復時間）を短縮
• 変更の 失敗率 を下げる
• デプロイ頻度 を上げてビジネス価値を素早く届ける
• 過剰なオンコール負担を防ぐ（人間性の維持）

6.2 Observability — メトリクス・ログ・トレース・SLO

ログの種類:
- Audit Logs（管理者活動・データアクセス）
- Platform Logs（GCE、GKE、Cloud Run など）
- User Logs（アプリ独自）
- Network Logs（VPC Flow Logs、Firewall Rules Logs）

SLO: 99.9%（月予算 0.1% = 43.2 分）
Burn Rate 1x:    月末ちょうど予算消化（正常）
Burn Rate 14.4x: 1 時間で月予算の 2% 消費（緊急）

SELECT
  resource.labels.cluster_name,
  COUNT(*) AS error_count
FROM `project.location.LOG_BUCKET._AllLogs`
WHERE severity = 'ERROR'
GROUP BY 1
ORDER BY 2 DESC

from google.cloud import monitoring_v3
from google.cloud.monitoring_v3 import MetricServiceClient

client = MetricServiceClient()
project_name = f"projects/{PROJECT_ID}"

series = monitoring_v3.TimeSeries()
series.metric.type = "custom.googleapis.com/orders_completed"
series.metric.labels["region"] = "asia-northeast1"
series.resource.type = "global"

point = series.points.add()
point.value.int64_value = 42
client.create_time_series(name=project_name, time_series=[series])

Critical Alert =
  (Burn Rate > 14.4 over 5 min) AND (Burn Rate > 14.4 over 1 hour)

6.3 デプロイ・リリース管理

📘 リリース戦略比較

4 つの主要戦略 + Feature Flag / Progressive Delivery を要件で選定。試験頻出は「即時切戻し → Blue-Green」「段階リリース → Canary」。

リリース管理の典型フロー

📘 Feature Flag と Progressive Delivery

コードは本番にあるが、ユーザーへの公開を 動的に on/off する。

Progressive Delivery のフロー

Cloud Deploy の Canary 設計（詳細）

strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true
    canaryDeployment:
      percentages: [5, 25, 50]
      verify: true   # 各段階で verify ステップ実行

GitOps による Continuous Delivery

6.4 本番デプロイ済みソリューションのサポート

📘 インシデント対応の標準フロー

Incident Command System (ICS)

大規模障害時の 役割分担モデル。

Status Page

• 公開: Statuspage、Atlassian、PagerDuty
• 内部: Confluence、Notion、Google Site

📘 Postmortem テンプレート（Blameless）

SRE 文化の中心。個人を責めず、システム・プロセスの改善 に焦点を当てる。

# Postmortem: [障害タイトル]

## 概要
- 発生日時: YYYY-MM-DD HH:MM (JST)
- 復旧日時: YYYY-MM-DD HH:MM (JST)
- 影響期間: XX 分
- 重大度: SEV1 / SEV2 / SEV3

## 影響
- 影響を受けたユーザー数: ...
- 影響を受けた機能: ...
- ビジネス影響: 売上減 / SLA 違反 / 顧客報告件数
- SLO 消費: エラーバジェット XX%

## タイムライン（時系列）
- HH:MM  事象発生（実測）
- HH:MM  アラート発火
- HH:MM  on-call エンジニアが認識
- HH:MM  暫定対応開始（Rollback 実行）
- HH:MM  影響解消を確認
- HH:MM  Status Page 更新（解消）
- HH:MM  事後分析開始

## 検知方法
- 何で気づいたか（アラート種別 / 顧客報告 / 監視ダッシュボード）

## 根本原因（Root Cause）
- Five Whys で 5 段階まで掘り下げた結果
- 直接原因: ...
- システム的要因: ...
- プロセス的要因: ...

## 緩和策（実施したこと）
- 暫定対応 1: ...
- 暫定対応 2: ...

## 教訓（What Went Well / What Went Wrong）
- うまくいったこと
  - アラートが早期に発火した
  - ICS の役割分担が機能した
- うまくいかなかったこと
  - Runbook が古かった
  - 影響範囲の特定に時間がかかった

## アクション項目（再発防止策）
| 内容 | 担当 | 期限 | 優先度 |
|------|------|------|--------|
| Runbook 更新 | @owner | YYYY-MM-DD | P1 |
| 自動ロールバック実装 | @owner | YYYY-MM-DD | P0 |
| Canary 比率見直し | @owner | YYYY-MM-DD | P2 |

## 補足（参考リンク）
- 関連 PR: ...
- 関連 Issue: ...
- ログ: ...
- メトリクス: ...

---
※ Blameless（個人を責めない）。システム・プロセスの改善に集中する。

Five Whys の実例

障害: 注文 API が 30 分応答停止
Why 1: DB 接続枯渇
Why 2: 接続プール上限の 100 を超過
Why 3: 旧バージョンが接続を返さないバグ
Why 4: 単体テストはあったが、長時間負荷テストがなかった
Why 5: パイプラインに長時間負荷テストが組込まれていなかった

→ 再発防止策: CD パイプラインに 30 分の長時間負荷テストを追加

Runbook（ランブック）

特定のアラート・障害に対応する 手順書。明確に書かれていれば誰でも対応可能。

[Runbook: Cloud SQL High CPU]
1. CPU メトリクス確認（Cloud Monitoring）
2. 直近 1 時間のスロークエリを `pg_stat_statements` で抽出
3. 該当クエリを開発チームに通知（Slack #db）
4. CPU > 90% が継続するなら一時的にインスタンス昇格
5. アクション完了後 SLO 回復確認

サポートのレベル

6.5 品質管理の評価

📘 コードレビューと Change Management

ITIL Change Management

📘 Continuous Compliance — Policy as Code

代表的な Organization Policy

Assured Workloads（規制業界）

• 規制業界（HIPAA、FedRAMP、IL4、CJIS）向けの コンプラ環境
• リージョン制限、US Person 限定オペレーション等を強制
• 設定が固定され、誤設定リスクを下げる

Continuous Compliance Scanning

6.6 本番信頼性検証 — Chaos / Pentest / Game Day

📘 Chaos Engineering

意図的に障害を注入 し、システムの回復力を検証する手法。Netflix の Chaos Monkey が起源。

Chaos Engineering 4 原則

段階的な導入

代表的なツール

GKE Chaos の代表手法

Game Day の計画

📘 Penetration Testing と Load Testing

Penetration Testing（Pentest）

外部・内部から 攻撃を再現 してセキュリティを検証。

Pentest の流れ

Load Testing（負荷テスト）

ロードテストの種類

GCP 上の負荷テスト構成例

📘 Gemini Cloud Assist for Observability

GCP コンソール内の AI 支援で、運用を強化。

ユーザー: 「Cloud Run service-a が直近 1 時間で 5xx 増加。原因は？」
   ↓
Gemini Cloud Assist:
  - service-a の SLO Burn Rate: 8x（過剰）
  - 関連ログ: Cloud SQL 接続タイムアウト多発
  - 関連メトリクス: Cloud SQL CPU 95%
  - 原因仮説: Cloud SQL のクエリ過負荷
  - 対処提案: クエリ最適化 / インスタンス昇格
  - 関連 Runbook: ...

ユーザー: 「直近 1 時間の error log を要約して」
   ↓
Gemini:
  - 大半は OOMKilled
  - 集中時間帯: 14:30-14:45
  - 影響 Pod: 12 個
  - 修復提案: メモリ Limit を 1Gi → 2Gi

信頼性の重要な考え方

信頼性 vs コスト

99% → 99.9%:   10x コスト
99.9% → 99.99%: 10x コスト
99.99% → 99.999%: 10x コスト

ユーザーが感じる信頼性 を見極め、過剰投資を避ける。

多層防御（Defense in Depth）

Graceful Degradation（縮退運転）

完全に失敗するのではなく 機能を縮退 する設計。

• レコメンドが落ちたら一般人気商品を表示
• DB レプリカが落ちたらキャッシュから読む
• 一部マイクロサービスが落ちても主機能は継続

Failure Domain

「何が同時に壊れるか」を意識した冗長化設計。

📌 章末まとめ — 運用卓越性の翻訳パターン

質問を読む
  ↓
「運用・観測・信頼性」キーワード抽出
  - メトリクス → Cloud Monitoring
  - ログ → Cloud Logging（Sink / Log Analytics）
  - 分散トレース → OpenTelemetry + Cloud Trace
  - 性能ボトルネック → Cloud Profiler
  - 例外集約 → Error Reporting
  - 外形 → Uptime Checks
  - SLO → Cloud Monitoring SLO + Burn Rate Alert
  - デプロイ → Blue-Green / Canary / Feature Flag
  - 承認 → Cloud Deploy Approval
  - GitOps → Config Sync / Argo CD
  - ポリシー → Org Policy / Policy Controller
  - 規制 → Assured Workloads
  - 検証 → Load Test / Chaos / Pentest / Game Day
  - AI 支援 → Gemini Cloud Assist Investigations
  ↓
要件の制約（ノイズ、コンプラ、コスト）を確認
  ↓
最も「症状ベース・SLO 駆動・自動化」志向の選択肢を選ぶ