変更要約: Professional Cloud DevOps Engineer 第3章を新規作成（ドメイン3「SRE」: SLI/SLO/SLA・エラーバジェット・ナインとコスト/機会費用、サービスライフサイクル・容量計画＝クォータ/上限/予約/Dynamic Workload Scheduler・オートスケール＝MIG/Cloud Run/GKE・インシデント緩和＝ドレイン/リダイレクト/容量追加/ロールバック）。
3.1SLI・SLO・SLA とエラーバジェット
サービスの信頼性を測る SLI（可用性・レイテンシ等）、目標の SLO、対外契約の SLA、変更速度と信頼性のバランスを取るエラーバジェット、信頼性のコスト（「ナイン」の数）の考え方を理解します。
SRE（サイト信頼性エンジニアリング）は、信頼性を測れる目標にして、変更速度とのバランスをデータで取ります。出発点は SLI/SLO/SLA とエラーバジェットです。
3.1.1SLI・SLO・SLA
SLI（Service Level Indicator）は信頼性を測る指標（可用性、レイテンシ、エラー率など）です。SLO（Service Level Objective）はその SLI に対する社内の目標値（例：99.9% 可用性）。SLA（Service Level Agreement）は顧客との対外的な契約で、違反時の補償を伴います。一般に SLO は SLA より厳しく 設定し、契約違反の前に内部で気づけるようにします。「測る指標＝SLI」「内部目標＝SLO」「対外契約＝SLA」と結びます。
3.1.2エラーバジェットと信頼性のコスト
エラーバジェット は「100% − SLO」で、許容される不信頼の量です（例：SLO 99.9% ならバジェットは 0.1%）。バジェットが残っていれば積極的に新機能を出し、使い切ったら 変更を抑えて信頼性回復 に充てます。こうして 変更速度と信頼性のバランス をデータで決めます。信頼性を上げるほど（ナイン の数を増やすほど）コストは急増するため、過剰な目標は 機会費用 になります。「速度 vs 信頼性の調停＝エラーバジェット」を押さえます。
「要件 → 手段」が頻出。例：「信頼性を測る指標」＝SLI、「内部の目標値」＝SLO、「顧客との契約」＝SLA、「新機能の出し過ぎと信頼性の調停」＝エラーバジェット、「バジェット枯渇時」＝変更凍結して信頼性回復。SLO は SLA より厳しく設定する。
混同に注意：
①SLO（内部目標）と SLA（対外契約）を取り違えない＝SLO は SLA より厳しく。
②信頼性は100% を目指さない（コストと機会費用が急増）。
③エラーバジェットは罰でなく意思決定の道具（速度の許可証）。
3.1.3この節のまとめ
- SLI＝測る指標、SLO＝内部目標、SLA＝対外契約、SLO は SLA より厳しく
- エラーバジェット＝100%−SLO で速度と信頼性を調停、枯渇時は変更を抑えて回復
- ナインを増やすほどコスト急増＝100% は目指さず機会費用を意識
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 可用性やレイテンシなど、サービスの信頼性を測る指標を何と呼びますか？
Q2. SLI に対する社内の目標値（例：99.9% 可用性）を何と呼びますか？
Q3. 顧客との対外的な契約で、違反時に補償を伴うものを何と呼びますか？
Q4. SLO が 99.9% のとき、許容される不信頼の量（エラーバジェット）はいくらですか？
Q5. エラーバジェットを使い切った場合の SRE 的な対応として最も適切なものはどれですか？