プレイブック

組織全体で、リソースの場所を制限したり、サービスアカウントキーの作成を無効にしたりするなど、予防的なガードレールを強制します。

→組織レベルまたはフォルダレベルで組織ポリシーの制約（例: `constraints/gcp.resourceLocations`、`constraints/iam.disableServiceAccountKeyCreation`）を適用します。

理由: 組織ポリシーは継承され、API レベルで適用されるため、コンプライアンスに違反するアクションが事前に防がれます。これは、事後的な検出と修復よりも効果的です。

リファレンス↗

複数部署、複数環境の組織を構造化し、ポリシーとアクセス制御を効果的に管理します。

→フォルダ階層を設計します。通常は、組織 > 事業部門（フォルダ） > 環境（例: prod, staging）（サブフォルダ） > プロジェクトとなります。

理由: この構造により、詳細なポリシー継承が可能になります。共通のポリシーは事業部門レベルで設定され、環境固有のポリシー（例: `prod` により制限的なもの）は環境レベルで設定されます。

コスト最適化を図りながら、コンプライアンス、セキュリティ分析、および運用のトラブルシューティングのために、すべてのプロジェクトからログを集約します。

→組織レベルの集約型ログシンクを作成します。必要に応じて、ログを複数の宛先にルーティングします: 分析用には BigQuery、長期/低コストのアーカイブ用には Cloud Storage (Coldline/Archive)、SIEM へのリアルタイムストリーミング用には Pub/Sub。

理由: この階層化されたアプローチは、コストと機能の両方を最適化します。BigQuery は強力なクエリ機能を提供し、Cloud Storage は安価なアーカイブを提供します。単一の宛先を使用すると、すべてのユースケースに対して高すぎるか、パフォーマンスが不十分になる可能性があります。

リファレンス↗

BigQuery や Cloud Storage などのマネージドサービスからのデータ漏洩を防ぎ、認証されたネットワークまたは ID からのみアクセスを許可します。

→機密データを含むプロジェクトの周りに VPC Service Controls ペリメーターを作成します。特定の IP 範囲（企業ネットワーク）またはデバイスからのアクセスを許可するようにアクセスレベルを定義します。

理由: VPC Service Controls は、API ベースのサービスを中心に仮想的な境界を作成し、境界外からのアクセスをブロックすることで、盗まれた認証情報や誤設定された IAM ポリシーによるリスクを軽減します。

特定のロールの付与を禁止するなど、プロジェクトオーナーが上書きできないセキュリティガードレールを確立します。

→組織レベルまたはフォルダレベルで IAM 拒否ポリシーを実装します。これらのポリシーは明示的にアクセス許可を拒否し、常に `allow` ポリシーを上書きします。

理由: 拒否ポリシーは、リソース階層の下位レベルでバイパスできない組織全体のセキュリティ制御を強制するための強力な方法を提供し、一貫したセキュリティ体制を確保します。

すべての新規プロジェクトが標準的なベースライン構成（ネットワーキング、IAM、ロギングなど）でプロビジョニングされるようにします。

→Infrastructure as Code（例: Cloud Build を使用した Terraform）を使用して「ランディングゾーン」を作成します。パイプラインを通じてプロジェクトの作成と構成を自動化します。

理由: 自動化により、一貫性が確保され、手動エラーが削減され、プロジェクトのプロビジョニングが高速化されます。これはベストプラクティスをコード化し、ガバナンスを監査可能かつ反復可能にします。

外部システム（GitHub Actions やオンプレミス CI/CD など）が、長期的なサービスアカウントキーを使用せずに GCP リソースにアクセスできるようにします。

→Workload Identity Federation を構成します。外部 IdP（例: GitHub OIDC）を信頼するプロバイダーを作成し、外部 ID を GCP サービスアカウントにマッピングします。属性条件を使用して、特定のレポ/ブランチへのアクセスを制限します。

理由: これにより、主要なセキュリティリスクであるサービスアカウントキーの管理とローテーションの必要がなくなります。短期間有効な ID ベースの認証情報を提供します。

ネットワーク管理（VPC、サブネット、ファイアウォール）を集中化し、個別のチームがそれぞれのプロジェクトリソースを管理できるようにします。

→Shared VPC を実装します。ネットワークリソース用の「ホストプロジェクト」と、アプリケーションワークロード用の「サービスプロジェクト」を作成します。サービスプロジェクトの ID に `roles/compute.networkUser` を付与します。

理由: Shared VPC は、ネットワーク管理とプロジェクト管理を分離し、チームに自律性を提供しながら集中管理とセキュリティを実現します。このユースケースでは、VPC Peering よりもスケーラビリティが高く、より安全です。

GKE クラスターの構成とアプリケーションを、Git リポジトリから宣言的に管理します。

→マニフェストの唯一の真実の情報源として Git リポジトリを使用します。GKE クラスターに Config Sync をインストールし、クラスターの状態をリポジトリの構成と継続的に調整（reconcile）します。

理由: GitOps は、Kubernetes を管理するための監査可能でバージョン管理された自動化された方法を提供します。CI（成果物のビルド）と CD（状態の同期）を分離します。

重大な脆弱性のあるコンテナイメージがデプロイされるのを防ぎます。

→Artifact Registry で自動脆弱性スキャンを有効にします。Cloud Build パイプラインに、Container Analysis API を使用して脆弱性をチェックし、重大な問題が見つかった場合にビルドを失敗させるステップを追加します。

理由: これにより、CI パイプラインに自動品質ゲートが作成され、脆弱な成果物がデプロイ可能な状態に到達するのを防ぎます。セキュリティを「左にシフト」させます。

GKE または Cloud Run に、信頼できる署名されたコンテナイメージのみがデプロイされるように実行時に強制します。

→Binary Authorization を実装します。アテスター（例: 脆弱性スキャン合格、QA 承認用）を作成します。CI パイプラインを構成してアテステーションを作成します。GKE/Cloud Run で、デプロイに特定のアテステーションを要求するポリシーを適用します。

理由: Binary Authorization は、デプロイ時に強力なポリシーベースの強制を提供します。レジストリに入り込んだ場合でも、侵害されたイメージや未承認のイメージのデプロイを防ぎます。

リファレンス↗

API キーやパスワードなどの機密情報を、ログやソースコードに公開せずに Cloud Build の実行中にアクセスします。

→シークレットを Secret Manager に保存します。`cloudbuild.yaml` で `availableSecrets` フィールドを使用して、シークレットを環境変数またはファイルとしてマウントします。

理由: これはネイティブでセキュアな統合です。Cloud Build は認証を処理し、ログからシークレット値を自動的に編集（redact）して、偶発的な公開を防ぎます。

ソフトウェア成果物が信頼できるシステムによって信頼できるソースコードから構築されたことを保証するために、検証可能なソフトウェアサプライチェーンの連鎖を確立します。

→Cloud Build を使用して SLSA 準拠の来歴アテステーションを生成します。これらのアテステーションをイメージとともに Artifact Registry に保存します。デプロイ前に Binary Authorization を使用して来歴を検証します。

理由: SLSA は、ソフトウェアサプライチェーンを強化するためのフレームワークを提供します。このツール群の組み合わせにより、ソースから本番環境まで、エンドツーエンドで検証可能な信頼の連鎖が提供されます。

プライベートな Artifact Registry や Cloud SQL データベースなど、プライベート VPC 内のリソースにアクセスする必要がある CI/CD ジョブを実行します。

→Cloud Build プライベートプールを作成し、プールのネットワークとターゲット VPC の間で VPC ピアリングを構成します。このプールでビルドが実行されるように構成します。

理由: プライベートプールはネットワーク分離を提供し、ビルドがインターネットに公開することなくプライベートネットワーク上のリソースに安全にアクセスできるようにします。

古いコンテナイメージや未使用のコンテナイメージを自動的に削除してストレージコストを管理しつつ、重要なイメージを保持します。

→Artifact Registry のクリーンアップポリシーを構成します。`production` や `latest` のようなタグには `keep` ポリシーを使用します。他のイメージには、経過時間、タグパターン、バージョン数に基づいた `delete` ポリシーを使用します。

理由: クリーンアップポリシーは、イメージのライフサイクルを管理するための宣言的で自動化された方法を提供し、コスト削減と本番および最近の開発成果物を保持する必要性のバランスを取ります。

開発からステージング、本番へのマルチステージデプロイを、承認と環境ごとの異なる戦略で自動化します。

→Cloud Deploy の配信パイプラインを 1 つ定義し、ターゲットの進行（開発、ステージング、本番）を設定します。本番ターゲットには `requireApproval: true` を構成し、各ターゲットに異なるデプロイ戦略（例: カナリア）を指定します。

理由: Cloud Deploy は、管理され監査可能な継続的デリバリーサービスを提供します。統合された承認とロールバックにより、カナリアやブルー/グリーンデプロイなどのプログレッシブデリバリーパターンを簡素化します。

ユーザーの視点からサービスの信頼性を測定する指標を定義します。

→ユーザーが直面する懸念事項に基づいてサービスレベル指標（SLI）を定義します: 可用性（成功したリクエストの割合）、レイテンシ（しきい値よりも高速なリクエストの割合）、正確性/鮮度（正しく処理されたデータまたは最新のデータの割合）。

理由: SLI は、内部サーバーの健全性ではなく、ユーザーの満足度を測定する必要があります。CPU 使用率などのメトリクスは原因であり、高レイテンシは症状です。SRE は症状の監視と管理に焦点を当てています。

軽微な一時的な問題に対するアラートに悩まされることなく、SLO 違反に早期に気づき、対応できるように通知を受け取ります。

→SLO バーンレート（エラーバジェットが消費されている速度）に基づいてアラートを構成します。マルチウィンドウアラートを使用します: 短いウィンドウで高いバーンレートを検知して緊急ページングを行い、長いウィンドウで低いバーンレートを検知して非緊急チケットを発行します。

理由: バーンレートアラートは予測的です。単一の失敗したリクエストではなく、失敗の「割合」でアラートを出すため、実際の問題を示し、アラート疲れを軽減し、重要なことに集中させます。

リファレンス↗

マイクロサービスアーキテクチャにおけるレイテンシの問題を、リクエストの完全なライフサイクルを理解することで診断します。

→OpenTelemetry SDK でサービスを計測し、Cloud Trace にトレースをエクスポートします。サービスコール間（Pub/Sub などのメッセージキュー経由を含む）でトレースコンテキストが伝播されるようにします。

理由: OpenTelemetry は計測のためのベンダーニュートラルな標準を提供します。Cloud Trace はエンドツーエンドのリクエストフローを可視化し、どのサービスや操作がボトルネックになっているかを簡単に特定できます。

GKE のアプリケーションログが Cloud Logging で正しくパースされ、検索可能で、適切な重大度レベルを持つことを確認します。

→アプリケーションが `stdout`/`stderr` に JSON 形式でログを書き込むように構成します。Google Cloud が期待する値（例: "INFO"、"ERROR"）と一致する `severity` フィールドを含めます。

理由: GKE のデフォルトのロギングエージェントは、stdout からの JSON ログを自動的に取得してパースし、サイドカーやカスタムエージェントを必要とせずに、Cloud Logging で構造化されクエリ可能にします。

サービスの SLO コンプライアンスとエラーバジェットの消費を追跡、視覚化、およびアラートします。

→Cloud Monitoring のサービス監視機能を使用します。サービスを定義し、SLI（例: ロードバランサーからの可用性）を作成し、SLO ターゲットを設定し、バーンレートアラートポリシーを構成します。

理由: このネイティブ機能は、SLO コンプライアンスとエラーバジェットの複雑な計算を自動化し、すぐに使えるダッシュボードを提供し、アラートシステムと統合されます。

メトリクス、トレース、ログをリンクして、問題の根本原因を迅速に特定します。

→トレース ID が構造化ログに含まれていることを確認します。メトリクスグラフのトレースエグゼンプラなどの Cloud Monitoring 機能を使用して、メトリクス異常時に特定のトレースにジャンプし、そのトレースから相関するログにジャンプします。

理由: オブザーバビリティの三本柱（メトリクス、ログ、トレース）間をシームレスに切り替える能力は、平均解決時間（MTTR）を短縮するための鍵です。

ユーザー登録や支払い失敗など、ログデータでのみ利用可能なアプリケーション固有のイベントに対して、カスタムメトリクスとアラートを作成します。

→Cloud Logging で、ログベースのメトリクスを作成します。関連するログエントリと一致するフィルターを定義し、メトリクスタイプ（カウンターまたはディストリビューション）を構成します。このカスタムメトリクスをダッシュボードとアラートポリシーで使用します。

理由: ログベースのメトリクスにより、非構造化または半構造化されたログデータを構造化された時系列データに変換でき、アプリケーションコードを変更せずにビジネスレベルの KPI を簡単に監視およびアラートできます。

データベースに負荷をかけずに、遅いクエリなどのデータベースパフォーマンスの問題を診断します。

→Cloud SQL インスタンスで Cloud SQL Insights と Query Insights を有効にします。ダッシュボードを使用して、高負荷クエリを特定し、実行計画を分析し、パフォーマンス傾向を確認します。

理由: Query Insights は、軽量でエージェントレスなクエリパフォーマンス監視を提供します。従来のプロファイリングツールのオーバーヘッドなしに、DBA や開発者が非効率なクエリを特定するのに役立ちます。

重要なユーザー体験や API の可用性を外部の視点からプロアクティブに監視します。

→単純な HTTP/TCP チェックには Cloud Monitoring の稼働時間チェックを使用します。複数ステップのユーザーフロー（例: ログイン、カートに追加、チェックアウト）には、管理環境でカスタムスクリプト（例: Puppeteer）を実行する合成モニターを使用します。

理由: 合成監視は、実際のユーザー操作をシミュレートし、ユーザーが問題に気づく前に問題を検出できます。これは、外側から内側へスタック全体をテストします。

サービスの信頼性の必要性と、新機能リリースの必要性のバランスを取ります。

→サービスレベル目標（SLO）（例: 99.9% の可用性）を定義します。残りの 0.1% がエラーバジェットです。バジェットがほとんど残っている場合は機能をリリースします。バジェットが枯渇した場合は、機能リリースを停止し、信頼性向上に焦点を当てます。

理由: エラーバジェットは、リスクの意思決定を行うためのデータ駆動型フレームワークを提供し、エンジニアリング、製品、ビジネスチームを共通の目標に合わせます。

心理的安全性の文化を育みながら、インシデントから学び、再発を防ぎます。

→インシデント発生後は、非難をしない事後分析を実施します。個人への責任追及ではなく、システム要因、プロセスギャップ、ツール障害に焦点を当てて調査します。結果は、実行可能な改善項目のリストであるべきです。

理由: 非難をしない文化は、正直でオープンなコミュニケーションを促進し、インシデントの根本原因をより正確に理解し、より効果的な予防措置につながります。

混乱や重複する労力を避け、大規模なインシデントへの対応を効果的に調整します。

→インシデントコマンドシステム（ICS）を実装し、明確に定義された役割を設定します: インシデントコマンダー（全体調整）、オペレーションリード（技術調査/修正）、コミュニケーションリード（ステークホルダーへの更新）。

理由: ICS は、インシデント対応のための標準化されたスケーラブルな構造を提供し、明確な指揮系統とコミュニケーションを確保します。これは、複雑な問題を迅速に解決するために不可欠です。

ソフトウェアデリバリー組織のパフォーマンスを測定します。

→DORA の主要な 4 つの指標を追跡します: デプロイ頻度（どれくらいの頻度か）、変更のリードタイム（コミットからデプロイまでどれくらい速いか）、変更失敗率（デプロイの何パーセントが失敗を引き起こすか）、サービス復元時間（MTTR）。

理由: これら 4 つの指標は、開発速度と運用の安定性の両方をバランス良く捉え、高性能な組織と相関があることが証明されています。

SRE チームが手動の反復的な運用タスク（トイル）に多くの時間を費やしすぎており、エンジニアリングプロジェクトに時間が割けていません。

→最も時間のかかるトイルを特定し、定量化します。これらのタスクを優先順位付けして自動化します（例: 手動スケーリングの代わりにオートスケーリングを実装する、一般的なアラートの自動修復）。トイルをエンジニア時間の 50% 未満に制限します。

理由: トイルは生産性と士気を低下させます。自動化を通じてこれを体系的に削減することで、エンジニアは長期的な信頼性向上に取り組む時間を確保できます。

共有インフラストラクチャにおいて、クラウドコストを異なるチーム、サービス、または環境に正確に帰属させます。

→一貫したラベリング/タグ付け戦略を実装します。これらのラベルを使用して Cloud Billing レポートをフィルタリングします。GKE の場合、GKE コスト配分を有効にして、名前空間またはワークロード別にコストを分割します。

理由: 正確なコスト配分は可視性を提供し、説明責任を促進します。自身の支出を見ることができるチームは、それを最適化する権限を与えられます。

多様なワークロード（安定した、中断可能な、開発/テスト）に対するコンピューティングコストを最適化します。

→ワークロードと料金モデルを一致させます。安定した 24 時間年中無休のワークロードには、コミット利用割引（CUDs）を使用します。フォールトトレラントで中断可能なジョブ（例: バッチ処理）には、スポット VM を使用します。開発/テスト環境は営業時間外にシャットダウンするようにスケジュールします。

理由: コンピューティング料金に対する画一的なアプローチは非効率です。適切なツールを適切な用途に使用することで、パフォーマンスに影響を与えることなく大幅な節約（70% 以上）につながります。

GKE のコストとパフォーマンスを最適化するために、Pod が適切な量の CPU とメモリを要求していることを確認します。

→Vertical Pod Autoscaler（VPA）を `recommendation` モードでデプロイします。その提案を分析して、Pod のリソース `requests` を調整します。確信が持てたら、`auto` モードに切り替えて継続的なライトサイジングを行います。

理由: Pod の過剰なプロビジョニングは費用を無駄にし、プロビジョニング不足はパフォーマンスの問題（スロットリング、OOMKilled）を引き起こします。VPA は実際の使用データを使用して正確なサイジング推奨を行い、効率と安定性の両方を向上させます。

Cloud Run サービスのコールドスタートによって引き起こされるレイテンシを削減します。

→`min-instances` の値を設定して、複数のインスタンスをウォーム状態に保ちます。さらに、コンテナイメージ（より小さなベースイメージ、少ないレイヤー）とアプリケーションの起動コード（遅延初期化）を最適化します。

理由: `min-instances` はコールドスタートを削減する最も直接的な方法ですが、コストがかかります。これとコンテナおよびコードの最適化を組み合わせることで、パフォーマンスとコストのバランスの取れたアプローチが提供されます。

変動するクエリパターンを持つ大規模な BigQuery 分析ワークロードのコストを最適化します。

→オンデマンド料金から BigQuery エディション（スロット）に切り替えます。予測可能な負荷のためにベースラインのスロットコミットメントを購入し、ピーク時にはオートスケーリングを有効にします。さらに、パーティション分割/クラスタ化されたテーブルを使用し、`SELECT *` を避けることでクエリを最適化します。

理由: 一貫したワークロードの場合、スロットベースの料金はオンデマンドよりも費用対効果が高くなります。オートスケーリングは、コストを制御しながらバーストに対する柔軟性を提供します。クエリとテーブルの最適化は、処理されるデータ量を削減し、直接コストを削減します。

グローバルに分散されたアプリケーションの高額なネットワークエグレスコストを削減します。

→Cloud CDN を使用して、ユーザーに近いエッジで静的コンテンツをキャッシュします。動的トラフィックの場合は、適切なネットワークサービスティア（パフォーマンス重視の場合は Premium、コスト削減重視の場合は Standard）を選択します。クロスリージョントラフィックを最小限に抑えるために、データをリージョン内で処理します。

理由: エグレスは主要なコスト要因です。CDN はオリジンからのトラフィックをオフロードし、直接エグレスを削減します。ネットワークティアと思慮深いリージョンデータ処理の使用により、コストを大幅に削減できます。