変更要約: Professional Cloud DevOps Engineer 第3章を新規作成（ドメイン3「SRE」: SLI/SLO/SLA・エラーバジェット・ナインとコスト/機会費用、サービスライフサイクル・容量計画＝クォータ/上限/予約/Dynamic Workload Scheduler・オートスケール＝MIG/Cloud Run/GKE・インシデント緩和＝ドレイン/リダイレクト/容量追加/ロールバック）。
3.2サービスライフサイクル・容量計画・インシデント緩和
サービスの計画/デプロイ/保守/廃止のライフサイクル管理、容量計画（クォータ・上限・予約・Dynamic Workload Scheduler）、オートスケーリング（マネージドインスタンスグループ・Cloud Run・GKE）、ユーザーへのインシデント影響の緩和（トラフィックのドレイン/リダイレクト・容量追加・ロールバック）を理解します。
信頼性は運用で守ります。サービスを計画から廃止まで管理し、需要に容量を合わせ、インシデント時はユーザー影響を素早く小さくします。
3.2.1ライフサイクルと容量計画・オートスケール
サービスは 計画→デプロイ→保守→廃止 のライフサイクルで管理します。容量は クォータ/上限 を把握し、確実な確保が要るなら 予約（reservations）や、GPU/TPU など希少リソースのスケジューリングに Dynamic Workload Scheduler を使います。需要変動には オートスケーリング で対応します：VM 群は マネージドインスタンスグループ（MIG）、サーバーレスは Cloud Run、コンテナは GKE（HPA/クラスタオートスケーラ）。「容量の確実な確保＝予約」「VM の自動増減＝MIG」を押さえます。
3.2.2インシデントのユーザー影響を緩和する
インシデント時はまず ユーザー影響の緩和 を優先します（根本原因の特定は並行/事後）。具体的には、不健全な宛先から トラフィックをドレイン/リダイレクト（ロードバランサ/Cloud Service Mesh）し、飽和なら 容量を追加、悪い変更が原因なら ロールバック します。緩和後に恒久対策とポストモーテム（非難しない振り返り）を行います。「まず止血（影響緩和）」「悪い変更が原因＝ロールバック」を結びます。
「要件 → 手段」が頻出。例：「容量を確実に確保」＝予約、「GPU/TPU の確保をスケジュール」＝Dynamic Workload Scheduler、「VM 群を自動増減」＝MIG、「サーバーレスで自動スケール」＝Cloud Run、「不健全な宛先からトラフィックを逃がす」＝ドレイン/リダイレクト、「悪い変更が原因」＝ロールバック。
混同に注意：
①インシデントは根本原因の解明より先にユーザー影響の緩和。
②クォータ/上限（既定の制限）と予約（容量の事前確保）は別。
③オートスケールはMIG（VM）/Cloud Run（サーバーレス）/GKE（コンテナ）を対象で選ぶ。
3.2.3この節のまとめ
- サービスは計画→デプロイ→保守→廃止で管理、容量はクォータ/上限/予約/Dynamic Workload Scheduler
- オートスケール＝MIG(VM)/Cloud Run(サーバーレス)/GKE(コンテナ)
- インシデントはまず影響緩和（ドレイン/リダイレクト・容量追加・ロールバック）、後で恒久対策とポストモーテム
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. VM の集団を需要に応じて自動的に増減させたい。最適なのはどれですか？
Q2. 将来の需要に対して特定マシンタイプの容量を確実に確保したい。最適なのはどれですか？
Q3. 本番でインシデントが発生。SRE として最初に行うべきことはどれですか？
Q4. 悪い変更のデプロイ直後にエラーが急増した。最も適切な緩和策はどれですか？
Q5. GPU/TPU など希少なアクセラレータの容量確保をスケジュールしたい。最適なのはどれですか？