Section 6: 運用卓越性 — 📘 基礎編

対象: 実務 1-2 年・GCP 初学者 / SRE / 運用の標準ツールと考え方を初めて学ぶ人。目標: Cloud Observability、SLO、デプロイ戦略、インシデント対応の基本を理解する。

1. Well-Architected の Operational Excellence Pillar

Operational Excellence の 5 つの原則

原則	内容
自動化（Automation）	手作業をなくし、Infrastructure as Code、CI/CD、自動修復を徹底
観測可能性（Observability）	メトリクス・ログ・トレースで「いま何が起きているか」を可視化
継続的改善（Continuous Improvement）	Postmortem、レビュー、定期改善のループ
チームの責任（Ownership）	サービスを誰が運用するか明確化、DevOps / SRE モデル
計画されたリリース	段階的・可逆的なデプロイ、変更管理

なぜ Operational Excellence が重要か

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

DORA メトリクス（4 つの DevOps 指標）

指標	内容
Deployment Frequency	デプロイ頻度（高 = 良い）
Lead Time for Changes	コミット→本番までの時間
Change Failure Rate	変更が障害を起こす割合
MTTR（Mean Time to Restore）	障害からの復旧時間

試験頻出: 「組織の DevOps 成熟度を測る」→ DORA メトリクス。

2. Cloud Observability の 4 大柱

[Cloud Observability] = Stackdriver の後継、統合監視プラットフォーム

メトリクス  ─── Cloud Monitoring
ログ        ─── Cloud Logging
トレース    ─── Cloud Trace（分散トレーシング）
プロファイル ─── Cloud Profiler（CPU/メモリ統計）

加えて:
- Error Reporting    ─── 例外を集約
- Uptime Checks      ─── HTTP/HTTPS/TCP の死活監視
- Managed Service for Prometheus ─── OSS Prometheus 互換
- Cloud Debugger（廃止予定）

Cloud Monitoring の基本

GCP リソースを自動的にメトリクス化。マルチプロジェクト・マルチクラウドにも対応。

機能	内容
Dashboards	カスタムビュー作成
Metrics Explorer	即席でメトリクス可視化
Alerting Policies	しきい値超過で通知
Uptime Checks	外形監視
SLO	信頼性目標の追跡
Notification Channels	Email / Slack / PagerDuty / Webhook

Cloud Logging の基本

全 GCP リソースのログを集約。アプリログも gcloud logging write や Logging Agent で投入可能。

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

概念	内容
Log Buckets	ログの保管先（リージョン指定可、保持期間設定）
Log Sinks	ログを別宛先（BigQuery / Pub/Sub / GCS / 別 Project）に転送
Log-based Metrics	ログを起点にメトリクス化（例: ERROR の数）
Log Router	Sink を中央管理

Cloud Trace の基本

分散トレーシング。マイクロサービス間のレイテンシ可視化。OpenTelemetry 標準対応。

ユーザー → LB → サービス A → サービス B → DB
                  ↓             ↓          ↓
                Span A        Span B    Span DB
                ─────── Trace（連結） ───────

「マイクロサービス全体のボトルネック特定」→ Cloud Trace。

Cloud Profiler の基本

CPU 時間・メモリ・ヒープなどの 継続的プロファイリング。本番環境で常時動かせる軽量プロファイラ。

対応言語: Go、Java、Python、Node.js

「本番でも使えるプロファイリング」→ Cloud Profiler。

Error Reporting の基本

アプリの例外・エラーを 自動集約・グルーピング。スタックトレース、発生回数、影響ユーザー数を表示。

Uptime Checks

外形監視。HTTP/HTTPS/TCP で世界の複数リージョンから到達性チェック。

3. SLI / SLO / SLA / エラーバジェット

用語整理

用語	内容	例
SLI（Service Level Indicator）	信頼性の測定値	過去 28 日の HTTP 200 比率 = 99.95%
SLO（Service Level Objective）	内部の目標値	月次 99.9% を維持
SLA（Service Level Agreement）	顧客との契約値（罰則あり）	99.9% を下回ったら返金
エラーバジェット	1 − SLO の残量	99.9% SLO なら 0.1% = 月 43.2 分

SLI の代表的なタイプ

タイプ	例
Availability	HTTP 200/全体、稼働率
Latency	p99 が 200ms 以下の割合
Error Rate	5xx エラー率
Throughput	RPS、QPS
Saturation	キュー長、CPU 使用率
Quality	データ鮮度、計算精度
Correctness	データの正しさ

エラーバジェットとは

99.9% SLO = 0.1% のエラーが許容範囲
1 ヶ月 = 43,200 分
0.1% = 43.2 分（月 43 分のダウンが許容）

エラーバジェットを使い切ったら 新規機能リリースを止める ことで、運用と機能開発のバランスを取る。

試験頻出: 「エラーバジェット消費中の判断」= 機能リリース停止、信頼性投資に集中。

SLA は SLO の控えめバージョン

通常、SLA は SLO より低めに設定する。

SLA: 99.9%（契約）
SLO: 99.95%（内部目標）← SLA を下回らないバッファ
SLI: 99.97%（実測）

4. アラート戦略の基礎

アラートの 2 つの軸

軸	内容
症状 vs 原因	症状ベース（ユーザー影響）を優先
重大度	Critical / Warning / Info

良いアラートの条件

条件	内容
アクション可能	アラートが鳴ったらやることがある
ユーザー影響を反映	内部の小さい異常ではなく、外部影響に基づく
再現可能	何度発生しても同じ手順で対処できる
ノイズが少ない	誤検知が少ない、抑制機能を活用

アラート疲れ（Alert Fatigue）

過剰アラート → 重要なアラートが見逃される → 障害大型化。

対策:

症状ベース に絞る
SLO + Burn Rate で重要度判定
Snooze / Mute で抑制
連動アラートを グループ化

Notification Channels

種類	用途
Email	低優先
Slack / Teams	共有
PagerDuty / Opsgenie	オンコール
Webhook	カスタム連携
SMS / Voice	緊急時
Mobile App（Cloud Console）	個人

5. デプロイ・リリース管理の基礎

Section 5 のデプロイ戦略をおさらい

戦略	用途
Rolling Update	一般的、順次置換
Blue-Green	即時切戻し可能
Canary	段階リリース、早期検知
Recreate	全停止 → 再起動

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

1. コードレビュー (PR)
2. CI（テスト・ビルド・脆弱性スキャン）
3. Staging デプロイ
4. 受入テスト・回帰テスト
5. Production デプロイ（Canary 5% → 25% → 50% → 100%）
6. 監視・SLO 確認
7. 問題発生 → ロールバック
8. Postmortem（必要時）

Feature Flag

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

ツール	概要
Firebase Remote Config	モバイル/Web 用
App Config（外部）	LaunchDarkly、Split、Unleash

「コード変更なしで機能切替・即時 OFF」→ Feature Flag。

Cloud Deploy の Approval

Production デプロイ前に 承認待ち ステップを挿入できる。コンプラ要件のあるシステムで活用。

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

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

1. 検知   ─── Alert / Uptime Check / 顧客連絡
2. トリアージ ─── 影響範囲、緊急度、担当アサイン
3. 暫定対応 ─── ロールバック、トラフィック切替、リソース増強
4. 復旧   ─── 動作確認、SLO 回復
5. 連絡   ─── Status Page、ステークホルダー通知
6. Postmortem ─── 原因分析、再発防止

Postmortem（事後分析）

必須項目	内容
タイムライン	発生〜復旧の時系列
影響	影響ユーザー数、期間、SLO 消費
根本原因	「なぜなぜ」で 5 段階
対応	暫定 vs 恒久
教訓	何を学んだか
アクション	再発防止策（担当・期限付き）

SRE の鉄則: Blameless Postmortem（人を責めず、システムを直す）

Runbook（ランブック）

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

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

サポートのレベル

レベル	内容	コスト
Basic	コンソール・ドキュメント	無料
Standard	商用、技術サポート	中
Enhanced	24/7、Production Support	中高
Premium	TAM（Technical Account Manager）、優先対応	高

7. 品質管理の評価

コードレビュー

観点	内容
正しさ	バグなし、要件満たす
可読性	他人が読める
テスト	単体・統合テストがある
セキュリティ	入力検証、認証、認可
性能	明らかなボトルネックなし
コンプラ	規制要件遵守

Change Management

変更の 計画・承認・記録 を体系化。

種類	内容
標準変更（Standard）	リスクが低く、手順が標準化されたもの
通常変更（Normal）	CAB（変更諮問委員会）の承認が必要
緊急変更（Emergency）	障害復旧、事後承認

Continuous Compliance

ポリシーを CI/CD・コンフィグから自動チェック。

ツール	用途
Policy Controller（Anthos / GKE Enterprise）	K8s リソースの Gatekeeper 拡張
Organization Policy	GCP リソースの強制ポリシー
Security Command Center (SCC)	コンプラ違反の検出
Assured Workloads	規制業界向け統制（HIPAA / FedRAMP 等）

8. 信頼性検証 — Load Test / Chaos Engineering / Pentest

Load Test（負荷テスト）

目的	内容
キャパシティ計画	想定負荷で性能を測定
スケール検証	Auto-scaling が動くか
ボトルネック特定	どこが先に詰まるか
SLO 検証	SLO を満たせる範囲を把握

代表ツール: Locust、JMeter、k6、Gatling（Section 5 参照）

Chaos Engineering（カオスエンジニアリング）

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

目的	内容
隠れた脆弱性発見	障害が起きてから直すのではなく事前検証
回復力検証	フェイルオーバー、Auto-healing
チーム訓練	インシデント対応の練習（Game Day）

代表ツール:

Chaos Toolkit（OSS）
Litmus（K8s 向け）
Gremlin（SaaS）
Chaos Monkey（Netflix 発、Spinnaker 統合）

実施例:

ランダム Pod 削除
ネットワーク遅延注入
ノード停止
依存サービスエラー注入

Penetration Testing（侵入テスト・Pentest）

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

種類	内容
ブラックボックス	内部情報なしで攻撃
ホワイトボックス	内部情報を持って攻撃
グレーボックス	一部情報あり

GCP では Pentest は事前申請不要（規約遵守の範囲で実施可能）。ただし禁止行為（DDoS、他テナント影響など）は厳禁。

Game Day

チーム全体で 障害想定演習。Chaos 注入 → 検知 → 対応 → Postmortem を実施。 SRE 文化定着の代表的手法。

9. Cloud Observability の最新機能

Managed Service for Prometheus

OSS Prometheus と互換。GCP マネージドで自動スケール。GKE / Anthos の標準モニタリング。

利点:

PromQL 互換クエリ
自動スケール、ストレージ管理不要
Cloud Monitoring 統合
24 ヶ月の長期保持

Gemini Cloud Assist for Observability

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

機能	内容
Investigations（最新）	障害時の関連リソース・ログ・メトリクスを横断分析、原因仮説生成
Log Analytics + Gemini	自然言語でログを検索（「直近 1 時間の 500 エラーは？」）
Alert Summarization	大量アラートの要約
Runbook 生成	過去対応からランブック自動生成

試験頻出: 「障害時の AI 支援」→ Gemini Cloud Assist Investigations。

10. ベンチマーク（Benchmarking）

性能を 継続的に測定 し、リグレッション検出やキャパシティ計画に使う。

観点	内容
マイクロベンチマーク	関数・API 単位の性能
ロードベンチマーク	システム全体の処理性能
ストレージ性能	IOPS、スループット、レイテンシ
DB ベンチマーク	TPC-C、TPC-H、Sysbench

GCP では Cloud Profiler で本番性能を継続測定可能。

11. まとめ — 運用卓越性の判断フロー

1. 観測可能性の整備
   - メトリクス → Cloud Monitoring
   - ログ → Cloud Logging
   - トレース → Cloud Trace（OpenTelemetry）
   - プロファイル → Cloud Profiler
   - 例外 → Error Reporting
   - 外形 → Uptime Checks
   ↓
2. SLI / SLO / SLA / エラーバジェット を定義
   - SLI 4 種: Availability、Latency、Error Rate、Throughput
   - SLO は内部目標、SLA は契約
   ↓
3. アラート戦略
   - 症状ベース、Burn Rate ベース
   - Notification Channels の使い分け
   - ノイズ削減（snooze、グループ化）
   ↓
4. デプロイ・リリース管理
   - Rolling / Blue-Green / Canary
   - Feature Flag
   - Approval（コンプラ）
   ↓
5. インシデント対応
   - 検知 → 暫定 → 復旧 → Postmortem
   - Runbook 化
   ↓
6. 信頼性検証
   - Load Test（性能）
   - Chaos Engineering（回復力）
   - Pentest（セキュリティ）
   - Game Day（チーム訓練）
   ↓
7. 継続改善
   - DORA メトリクス
   - エラーバジェット運用
   - Continuous Compliance

次のステップ

中堅レベルへ進む方: 02_応用.md で SLO 詳細設計、Multi-burn-rate アラート、Chaos 実践 を学ぶ
試験準備中の方: 03_要点と暗記.md で要点を整理
関連セクション: Section 1（設計）、Section 5（実装管理）