プレイブック

プラットフォームチームが採用を確保し、開発者の摩擦を減らすための核となる原則を確立する。

→内部プラットフォームを製品として扱う。内部開発者を顧客と見なし、ユーザー調査を実施し、フィードバックを収集し、機能を反復して開発者の認知負荷を軽減する。

理由: この考え方は、インフラ構築から価値提供へと焦点を移し、プラットフォームが開発者の実際の問題を解決し、「シャドウIT」によって回避されないようにする。

すべてのインフラストラクチャとアプリケーションの望ましい状態に対する単一の真実のソースを確立する。

→Gitリポジトリを単一の真実のソースとして使用する。クラスターの状態をGitと比較するために、継続的な調和ループを実行するクラスター内エージェント（ArgoCD、Flux）をデプロイする。

理由: これにより、完全な監査証跡が提供され、容易なロールバックが可能になり、帯域外の変更を自動的に元に戻すことで設定ドリフトを防止する。

リファレンス↗

設定ドリフトを防止し、すべての環境でデプロイされたアーティファクトの一貫性を確保する。

→インフラストラクチャをイミュータブルとして扱う。実行中のリソースを一切変更しない。代わりに、新しいバージョン管理されたアーティファクト（コンテナイメージ、VMイメージ）を作成し、古いものと置き換える。これをリードオンリーのコンテナファイルシステム（`readOnlyRootFilesystem: true`）で強制する。

理由: イミュータビリティは設定ドリフトを排除し、デプロイを予測可能で再現性のあるものにする。「修理するのではなく、置き換える。」

特にマルチクラスター環境や制限されたネットワーク環境において、セキュアなGitOpsデプロイメントモデルを選択する。

→プルベースモデルを実装する。クラスター内で実行されているエージェント（ArgoCD、Flux）がGitからマニフェストをプルする。外部のCIシステムがKubernetes APIにプッシュするプッシュベースモデルは避ける。

理由: プルベースモデルは、Kubernetes APIサーバーを外部に公開したり、CIで複数のクラスターの認証情報を管理したりする必要がないため、よりセキュアである。

経験豊富なチームを過度に制限することなく、開発を加速し、ベストプラクティスを確保する。

→「ゴールデンパス」（または舗装された道）を定義する。これは、一般的なタスク（例：新しいマイクロサービスの作成）のための、事前に設定され、十分にサポートされたテンプレートとワークフローである。

理由: ゴールデンパスは、80%のケースで認知負荷と意思決定の疲労を軽減するが、独自の要件を持つエキスパートチームのために「エスケープハッチ」を許可すべきである。

適切な分離レベルで共有Kubernetesプラットフォームにマルチテナンシーを提供する。

→最も強力な分離のためには、個別のクラスターを使用する。強力な分離と効率のバランスのためには、仮想クラスター（vClusters）を使用する。基本的なソフトマルチテナンシーのためには、RBAC、NetworkPolicies、およびResourceQuotasを使用したネームスペースレベルの分離を使用する。

理由: 選択はセキュリティと「うるさい隣人」のリスクに依存する。仮想クラスターは、完全な物理クラスターのコストなしにコントロールプレーンの分離を提供する。

プラットフォームチームとストリームアラインド（製品）チーム間の主要なインタラクションモードを定義する。

→プラットフォームチームは、主に「X-as-a-Service」モードで運用し、セルフサービスツール、API、ドキュメントを提供するべきである。

理由: 大規模では、プラットフォームチームはすべてのチームと密接なコラボレーションモデルを使用することはできない。サービスとしてのモデルは、スケーリングと開発者の自律性を可能にする。

分散システムのための包括的な可観測性戦略を実装する。

→3つの柱を収集し、関連付ける。Metrics（Prometheus経由の数値時系列データ）、Logs（Fluent Bit経由の構造化イベント）、Traces（OpenTelemetry経由のリクエストフロー）。

理由: 単一の柱だけでは不十分である。それらを関連付けること（例：トレースIDをログに埋め込むこと）は、複雑なマイクロサービスアーキテクチャにおける問題を迅速に診断するために不可欠である。

すべてのKubernetesクラスターでセキュリティポリシーと組織ポリシーを自動的に強制する。

→OPA/GatekeeperまたはKyvernoのようなポリシーエンジンを、検証/変更アドミッションコントローラーとして統合して使用する。ポリシーをGitに保存し、GitOps経由で同期する。

理由: これにより、自動化された予防的なガードレールが提供され、開発者は遅い手動レビューゲートではなく、CI/CDパイプラインで迅速なフィードバックを得ることができる。

チームのスキルセットとポリシーの複雑さに基づいて、Kubernetes用のポリシーエンジンを選択する。

→Kubernetesスタイルの馴染みのあるYAMLで表現できるポリシーにはKyvernoを使用する。より強力な専用言語（Rego）と外部データ統合を必要とする複雑なポリシーにはOPA/Gatekeeperを使用する。

理由: KyvernoはKubernetesの実践者にとって学習曲線が低い。OPA/Regoはより強力だが、新しい言語の学習が必要である。

本番環境にデプロイされるコンテナイメージの整合性と信頼性を確保する。

→Sigstore/Cosignを使用してCIパイプラインでイメージ署名を実装する。ポリシーコントローラー（Kyverno、Gatekeeper）を使用して、Podの作成を許可する前にイメージ署名を検証するアドミッションポリシーを作成する。

理由: これにより、信頼できるCIパイプラインによってビルドされ、改ざんされていないイメージのみがクラスター内で実行され、不正なコード実行が防止される。

リファレンス↗

ゼロトラストアプローチで、クラスター内のすべてのサービス間通信をセキュアにする。

→サービスメッシュ（例：Istio、Linkerd）をデプロイし、メッシュ内のすべてのトラフィックに対して厳格な相互TLS（mTLS）を有効にする。

理由: mTLSは、転送中の暗号化と、クライアントおよびサーバーの両方に対する強力で暗号的に検証可能なIDの両方を提供し、クラスター内でのなりすましや中間者攻撃を防止する。

クラスターで実行されるすべてのワークロードに対してセキュリティのベストプラクティスを強制する。

→組み込みのPod Security Admissionコントローラーを有効にする。ワークロードには`restricted`プロファイルを、プラットフォームコンポーネントには`baseline`プロファイルを強制するようにネームスペースを設定する。

理由: `restricted`プロファイルは、重要なセキュリティ強化（例：非rootユーザーとして実行、すべてのケーパビリティを削除、特権昇格の不許可）を強制し、基盤となるセキュリティ対策である。

リファレンス↗

実行中のコンテナ内の異常なまたは悪意のある動作をOSレベルで検出する。

→FalcoやTetragonなど、eBPFを使用するランタイムセキュリティツールをデプロイする。疑わしいシステムコール、ファイルアクセス、プロセス実行を検出するためのルールを定義する。

理由: 従来のセキュリティツールはコンテナ内のアクティビティに対して盲目である。eBPFはカーネルレベルのイベントに対して深く、低オーバーヘッドの可視性を提供し、他のツールが見逃す脅威の検出を可能にする。

スケーラブルでレジリエントな可観測性データパイプラインを構築する。

→OpenTelemetry（OTel）Collectorを使用する。プロセッサーを連結してデータを変換する（例：PIIを削除するための`attributes`プロセッサー、効率のための`batch`プロセッサー）。OOMを防ぐために、パイプラインの早い段階で`memory_limiter`プロセッサーを使用する。

理由: Collectorは計装とバックエンドを分離し、テレメトリーデータをエクスポートする前に処理、フィルタリング、ルーティングするための柔軟でベンダーニュートラルな方法を提供する。

リファレンス↗

リスクと影響範囲を最小限に抑えながら、新しいアプリケーションバージョンを本番環境にデプロイする。

→FlaggerやArgo Rolloutsのようなツールを使用して、自動カナリアデプロイメントを実装する。主要なメトリクス（成功率、レイテンシー）を自動的に分析しながら、新しいバージョンにトラフィックを徐々にシフトする。SLO違反時には自動的にロールバックする。

理由: 自動カナリア分析は、実際のプロダクショントラフィックで新しいバージョンを検証し、単純なローリングアップデートよりもはるかに高い安全性を提供する。

即座にロールバックを実行できる能力を持つアプリケーションの新しいバージョンをデプロイする。

→2つの同一の本番環境（「ブルー」と「グリーン」）を維持する。新しいバージョンを非アクティブな（グリーン）環境にデプロイする。検証後、ロードバランサーを切り替えてすべてのトラフィックをグリーンにルーティングする。即座のロールバックのためにブルーをアイドル状態に保つ。

理由: このパターンは、ゼロダウンタイムデプロイメントと可能な限り最速のロールバックを提供するが、通常はインフラリソースが2倍必要となる。

Gitにプレーンテキストの認証情報を保存することなく、GitOpsワークフローでシークレットを宣言的に管理する。

→専用のシークレットオペレーターを使用する。コミットする前にシークレットを暗号化する（Bitnami Sealed Secrets、Mozilla SOPS）か、外部のVaultからシークレットを参照する（External Secrets Operator）。

理由: これにより、機密データがGitから遠ざけられ、シークレットをアプリケーション設定と一緒に宣言的に管理できるため、GitOpsワークフローが維持される。

複数の環境（開発、ステージング、本番）間でアプリケーション設定を重複なく管理する。

→Kustomizeのようなツールをベースとオーバーレイ構造で使用するか、環境固有のvaluesファイルを持つHelmを使用する。通常、プルリクエストを介して、ターゲット環境のオーバーレイ/valuesファイル内のイメージタグまたは設定を更新することで変更を昇格させる。

理由: この「Don't Repeat Yourself」（DRY）アプローチは、環境間の設定ドリフトを防ぎ、違いを明示的かつ監査可能なものにする。

大規模で動的なクラスター群全体で、同じアプリケーションのデプロイメントを管理する。

→クラスタージェネレーターとともにArgoCD ApplicationSetsを使用する。ジェネレーターはラベルに基づいてクラスターを動的に検出し、テンプレートを使用して一致する各クラスターのApplicationリソースを生成する。

理由: これにより、新しいクラスターのアプリケーションブートストラッピングが自動化され、大規模な構成管理が可能になり、数百ものApplicationリソースを手動で作成する必要がなくなる。

リファレンス↗

新しい機能をユーザーにリリースするのを制御しながら、本番環境への継続的デプロイメントを可能にする。

→フィーチャーフラグシステムを統合する。無効化されたフィーチャーフラグの背後で新しいコードを本番環境にデプロイする。特定のユーザーセグメントに対してフラグを有効にすることで機能をリリースし、デプロイメントとリリースを分離する。

理由: これにより、技術的リスク（デプロイメント）とビジネスリスク（リリース）が分離され、高速デプロイメント、A/Bテスト、および「キルスイッチ」機能が可能になる。

新しいコンテナイメージがレジストリにプッシュされ次第、自動的にデプロイする。

→FluxCDのImage Automationコンポーネントを使用する。`ImageRepository`がレジストリをスキャンし、`ImagePolicy`が新しいタグを選択し（例：semverに基づいて）、`ImageUpdateAutomation`がタグの変更をGitリポジトリにコミットし直す。

理由: これにより、CI（イメージプッシュ）からCD（デプロイメント）までのループが閉じられ、CIシステムがクラスターへのアクセスを必要とすることなく、完全に自動化されたGitOpsワークフローが実現する。

開発者がKubernetesとクラウドインフラストラクチャリソース（例：データベース、メッセージキュー）の両方をセルフサービスでプロビジョニングできる、統一された宣言型APIを提供する。

→Crossplaneを使用する。クラウドプロバイダープラグインをインストールし、開発者向けに高レベルのCompositeResourceDefinitions（XRD）を定義する（例：`kind: PostgresSQLInstance`）。これらをCompositionsを使用して基盤となるクラウド リソースにマッピングする。

理由: これにより、Kubernetesコントロールプレーンが外部リソースを管理するように拡張され、開発者はプラットフォーム定義のパターンに支配されながら、すべてのアプリケーション依存関係に対して馴染みのある`kubectl`とGitOpsワークフローを使用できるようになる。

リファレンス↗

Kubernetesネイティブな方法で、複雑なステートフルアプリケーションのライフサイクル管理（例：インストール、アップグレード、バックアップ、障害回復）を自動化する。

→Kubernetes Operatorを構築する。アプリケーション用のCustom Resource Definition（CRD）を定義し、アプリケーションの状態を管理するための調和ループを実行するカスタムコントローラーを実装する。

理由: Operatorは人間の運用知識をソフトウェアにエンコードし、堅牢な自動化を可能にし、複雑なアプリケーションをファーストクラスのKubernetesリソースとして扱う。

オペレーターが、関連するCustom ResourceがKubernetesから削除される前に、外部リソース（例：クラウドロードバランサー）のクリーンアップを実行できることを確実にする。

→Custom Resourceのメタデータにファイナライザーを追加する。ユーザーがCRを削除すると、CRは`Terminating`状態に入る。オペレーターの調和ロジックがこれを検出し、クリーンアップを実行し、その後ファイナライザーを削除して、K8s APIサーバーが削除を完了できるようにする。

理由: ファイナライザーがないと、オペレーターが外部リソースをクリーンアップする時間がないままCRが削除され、孤立した高価なインフラストラクチャにつながる可能性がある。

宣言型でGitOpsに優しいツールを使用して、Kubernetesクラスター群自体のライフサイクルを管理する。

→Cluster API（CAPI）を使用する。管理クラスターはCAPIコントローラーを実行し、`Cluster`および`Machine`リソースを調和させて、さまざまなクラウドプロバイダー間でワークロードクラスターをプロビジョニングおよび構成する。

理由: CAPIはクラスター管理を宣言型のKubernetesワークフローに変え、クラスター全体の整合性のある自動化されたバージョン管理されたプロビジョニングとアップグレードを可能にする。

リファレンス↗

既存のユーザーを壊したり、「ビッグバン」移行を必要とすることなく、プラットフォームAPI（CRDとして定義）を進化させる。

→CRD定義で複数のバージョン（例：v1beta1、v1）をサポートする。バージョン間の変換を行うコンバージョンウェブフックを実装し、新しいクライアントがv1を使用しながら、古いクライアントが同じ保存オブジェクトに対してv1beta1を使用し続けることを可能にする。

理由: コンバージョンウェブフックは、非破壊的なAPI進化を可能にするネイティブなKubernetesメカニズムであり、安定したプラットフォーム製品にとって重要である。

ツール、ドキュメント、ソフトウェア資産を一元化することで、開発者の認知負荷を軽減し、発見可能性を向上させる。

→CNCF Backstageのようなフレームワークを使用してInternal Developer Portal（IDP）を実装する。そのソフトウェアカタログを充実させ、新しいサービスを足場固めするためのソフトウェアテンプレートを提供し、「docs-as-code」のためにTechDocsを統合する。

理由: IDPは開発者にとって「シングルペインオブグラス」として機能し、プラットフォームの複雑さを抽象化し、オンボーディングと開発を加速するゴールデンパスとセルフサービス機能を提供する。

リファレンス↗

所有権、依存関係、運用ステータスを含む、組織内のすべてのソフトウェアの単一で信頼できるインベントリを提供する。

→Gitリポジトリ内の`catalog-info.yaml`ファイルを通じてソフトウェアカタログ（例：Backstage Software Catalog）を実装する。これにより、サービス、ライブラリ、APIなどの中心的な検索可能なレジストリが作成される。

理由: カタログは、発見可能性（「どのようなサービスが存在するか？」）と所有権（「このサービスについて誰に話せばよいか？」）の問題を解決し、マイクロサービスアーキテクチャのスケーリングにとって重要である。

開発者が組織の標準に準拠した新しい本番対応サービスを数分で作成できるようにする。

→Backstage Software Templatesのようなスキャフォールディングツールを使用する。標準的なプロジェクト構造、CI/CDパイプライン構成、可観測性ダッシュボード、および`catalog-info.yaml`を含む新しいGitリポジトリを生成するテンプレートを定義する。

理由: テンプレートはベストプラクティスをコード化し、開発者に「舗装された道」を提供することで、初回コミットまでの時間を劇的に短縮し、新しいサービスがセキュリティ、可観測性、コンプライアンスを組み込んだ状態で作成されることを保証する。

技術ドキュメントが最新で、バージョン管理され、それが記述するソフトウェアと同じ場所に配置されていることを保証する。

→「docs-as-code」アプローチを採用する。ドキュメントをサービスのGitリポジトリ内のMarkdownファイルに保存する。Backstage TechDocsのようなツールを使用して、このドキュメントをIDPで自動的にビルドおよびレンダリングする。

理由: このモデルはドキュメントをコードのように扱い、プルリクエストでレビューでき、それが記述する機能と一緒にバージョン管理されるため、古くなったドキュメントや時代遅れのドキュメントを防ぐ。

プラットフォームの有効性と、それがソフトウェアデリバリーパフォーマンスに与える影響を測定する。

→4つのDORAメトリクスを追跡する。デプロイ頻度（速度）、変更のリードタイム（速度）、変更失敗率（安定性）、サービス復元時間（MTTR、安定性）。

理由: DORAメトリクスは、組織のパフォーマンスと相関することが証明されている業界標準の結果志向の指標である。これらは速度と安定性の両方のバランスの取れた視点を提供する。

リファレンス↗

共有Kubernetesプラットフォームを使用するチームに、正確で詳細なコスト可視性を提供する。

→OpenCostやKubecostのようなFinOpsツールをデプロイする。ワークロードの実際の時間経過によるリソース消費に基づいてコストを割り当てる。共有クラスターコスト（例：システムコンポーネント、ノードオーバーヘッド）を比例配分する。

理由: 正確なチャージバック/ショーバックは説明責任を促し、チームがリソース使用量を最適化するように奨励する。それがなければ、共有プラットフォームのコストは不透明で管理が難しい。

プラットフォームが実際に価値を提供し、開発チームによって使用されているかどうかを測定する。

→主要なプラットフォーム機能、特にゴールデンパステンプレートと共有CI/CDパイプラインの採用率を追跡する。開発者満足度調査（NPS形式）で補完する。

理由: オプションの意見が反映されたプラットフォーム機能の高い採用率は、プラットフォームが実際の問題を解決しているという強いシグナルである。採用率が低い場合は、開発者のニーズとのミスマッチを示唆する。

プラットフォームの現状を評価し、改善のためのロードマップを作成する。

→プラットフォーム成熟度モデルを使用して、セルフサービス、可観測性、セキュリティ、信頼性、ガバナンスなどの複数の側面で機能を評価する。アドホック/手動から完全に自動化され最適化されたレベルまで定義する。

理由: 成熟度モデルは、自己評価のための構造化されたフレームワークを提供し、弱点の特定を助け、プラットフォームの進化に向けた戦略的ビジョンについてチームを連携させる。