WEB問題集
最近、あるサービスが現在のローリングウィンドウ期間（直近の一定期間）において、エラーバジェット（エラー予算）を超過していることに気づきました。一方、製品チームは新しい機能のリリースを間近に控えています。Site Reliability Engineering (SRE) のプラクティスに従う場合、あなたはどのように行動すべきですか？
正解：B
SRE の基本的な考え方において、エラーバジェットは「信頼性と開発スピードのバランスを保つための客観的な指標」として機能します。
1. エラーバジェットの役割
エラーバジェットを使い果たした（超過した）ということは、そのサービスの信頼性が許容範囲を下回ったことを意味します。この状態での新機能リリースは、さらなる不安定化を招くリスクが非常に高いため、SRE の原則では「リリースの停止（凍結）」が推奨されます。
2. なぜ選択肢 B が正しいのか
-
信頼性の優先: バジェットが尽きた場合、最優先事項は「新機能の追加」ではなく「信頼性の回復」に移ります。
-
ポリシーの遵守: リリースを凍結し、エンジニアのリソースをバグ修正やインフラの改善に充てることが、SRE の標準的なエラーバジェット・ポリシーです。
正解：C, D
ポストモーテムの成功には、Google が提唱する**「Blamelee（非難ゼロ）」**の文化が不可欠です。
1. なぜ C と D が正しいのか
-
リーダーシップの関与（C）: 上級リーダーが参加し、「失敗を責めるのではなく、システムを改善する機会」として認めることで、現場のメンバーは安心して事実を報告できるようになります。リーダー自らが参加することは、その文化が組織にとって重要であるという強力なメッセージになります。
-
ポジティブな動機付け（D）: ポストモーテムの作成は時間と労力がかかる作業です。それを「単なる報告業務」ではなく、組織の知見を高める「価値ある貢献」として称賛（表彰や評価への反映）することで、自発的な協力が得やすくなります。
正解：C
この問題のキーワードは「Constraint Templates（制約テンプレート）」「GKE クラスター全体」「GitHub による自動適用（GitOps）」です。
1. なぜ C が正しいのか
Anthos Config Management (ACM) は、複数の Kubernetes クラスターに対して、一貫した構成やポリシーを GitOps スタイルで適用するためのサービスです。
-
Policy Controller: ACM の一部である Policy Controller を使用すると、まさに問題文にあるような「制約テンプレート（OPA: Open Policy Agent ベース）」を管理し、クラスター全体に強制適用（Enforce）できます。
-
Git 連携: GitHub などのリポジトリを「信頼できる唯一の情報源（Single Source of Truth）」として監視し、変更を自動的にクラスターへ同期する機能が備わっています。
正解：A
この問題のポイントは、**「インシデント管理におけるコミュニケーション」と「キャパシティ（容量）の確保」**の 2 点です。
1. なぜ A が正しいのか
-
コミュニケーション（手順 1）: Google の SRE プラクティスでは、インシデント対応中に独断で行動することは避けるべきとされています。まずチームに「これから何をするか」を共有（Communicate intent）することで、混乱を防ぎます。
-
キャパシティの事前確認（手順 2）: サービスが 70% のキャパシティで動いている場合、1 台を抜くことで残りのノードに負荷が集中し、連鎖的な過負荷（Cascading Failure）を引き起こすリスクがあります。切り離す前に負荷分析を行い、必要なら先にスケールアップしておくのが安全な手順です。
-
安全な切り離し（手順 3）: 十分なキャパシティを確保した上で、異常なノードを切り離します。
正解：C
この問題のポイントは、**「自動化された CI/CD パイプライン」**において、いかに安全かつ Google の推奨する方法で認証（アテステーション）を行うかという点です。
1. なぜ C が正しいのか
-
自動化とセキュリティ: 本格的な CI/CD パイプラインでは、人間（エンジニア）がいちいち署名するのではなく、自動化されたプロセスがアテステーションを作成する必要があります。
-
Cloud KMS の利用: 署名に使用する秘密鍵は、安全なマネージドサービスである Cloud KMS で管理するのが標準です。
-
Workload Identity: これが最大のポイントです。GKE や Cloud Build などのワークロードが Google Cloud API（この場合は Cloud KMS）にアクセスする際、JSON キーなどの静的な認証情報を使わずに、短期間のみ有効なトークンを利用して安全に認証を行う手法として、Google が最も推奨（推奨プラクティス）している方法です。