全チームが独自パイプラインを構築すると逆効果になる理由
想像してみてください。あなたの組織には5つのストリームアラインドチームがあります。各チームがゼロから独自のCI/CDパイプラインを構築しています。あるチームはJenkinsを選び、別のチームはGitLab CI、さらに別のチームはGitHub Actionsを採用しています。各チームはステージング環境の管理方法、本番環境へのデプロイ方法、APIキーやデータベースパスワードなどのシークレットの保存方法がすべて異なります。
最初は、これが自由に見えます。チームは素早く動けます。自分たちに合ったものを選べます。中央チームを待つ必要はありません。
しかし数ヶ月後、パターンが問題を引き起こし始めます。あるパイプラインでセキュリティ脆弱性が見つかりました。セキュリティチームは修正を適用する標準的な方法がないため、個別に各チームを訪問しなければなりません。開発者が別のチームに異動すると、まったく新しいパイプラインを一から学ぶ必要があります。運用チームは組織全体のアプリケーション健全性を監視しようとしますが、各チームが異なる形式でログを出力しています。
これは自由ではありません。自律性を装った断片化です。
ゼロからすべてを構築する問題
各チームが独立して独自のパイプラインを構築すると、組織は隠れたコストを支払うことになります。そのコストはいくつかの形で現れます。
- セキュリティパッチに時間がかかる。 共有依存関係を更新したり、共通の脆弱性を修正するための単一の場所がありません。
- ナレッジ移行が遅くなる。 チーム間の異動は、ビジネスドメインだけでなく、デプロイワークフローの再学習を意味します。
- 運用の可視性が低下する。 監視、ロギング、アラートがチーム間で一貫しなくなります。
- 監査とコンプライアンスが困難になる。 各チームが独自のプロセスを文書化し、変更が本番環境にどのように移行するかの統一されたビューがありません。
根本原因はチームの能力不足ではありません。根本原因は、各チームが同じインフラストラクチャの問題を何度も解決していることです。彼らはプロダクトではなく、配管作業にエネルギーを費やしています。
プラットフォームチームの実際の役割
プラットフォームチームは、このサイクルを断ち切るために存在します。その主な仕事は、すべてのストリームアラインドチームが使用できる共有機能を構築し、維持することです。これらの機能は、しばしば内部プラットフォームと呼ばれるものを形成します。
プラットフォームには以下が含まれます。
- 標準化されたCI/CDパイプライン
- 開発環境とステージング環境のテンプレート
- デプロイツール
- 集中管理された監視とロギング
- 共有シークレット管理システム
しかし、ここで重要な違いがあります。プラットフォームチームはストリームアラインドチームの作業を行いません。アプリケーションをデプロイしません。リリースのタイミングを決定しません。ビジネス機能を書きません。
プラットフォームチームは基盤を構築します。ストリームアラインドチームはその上に構築します。
ボトルネックの罠
組織がプラットフォームチームを初めて編成するときによくある間違いがあります。プラットフォームチームをすべてをデプロイするチームとして扱うことです。ストリームアラインドチームが新しいバージョンをリリースする必要がある場合、チケットを発行してプラットフォームチームが対応するのを待ちます。
これにより、プラットフォームチームがボトルネックになります。ストリームアラインドチームは列を作り、プラットフォームチームの空き時間を待つことになります。プラットフォームチームを持つ目的はデリバリーを高速化することであり、遅くすることではありません。
正しいモデルはセルフサービスです。プラットフォームチームは、ストリームアラインドチームが自分たちで使用できる機能を提供します。プラットフォームチームはインターフェース、API、テンプレートを定義します。ストリームアラインドチームはパイプラインを実行し、決定を下し、結果に責任を持ちます。
パイプラインで問題が発生した場合、ストリームアラインドチームはプラットフォームチームに報告します。彼らは自分でインフラを修正しません。しかし、デプロイの許可を待つこともありません。
プラットフォームチームの進化
プラットフォームチームは静的であってはなりません。ストリームアラインドチームのニーズは時間とともに変化します。
初期段階では、ビルド、テスト、デプロイを行うシンプルなパイプラインで十分かもしれません。しかし、組織が成長するにつれて、チームはより多くのものを必要とし始めます。あるチームは実際のデータベースを使った統合テストを必要とします。別のチームは本番環境を密にミラーリングしたステージング環境を必要とします。さらに別のチームは変更を段階的にロールアウトするためのカナリアデプロイを必要とします。
プラットフォームチームはこれらのニーズに耳を傾け、それに応じてプラットフォームを進化させなければなりません。これは一度きりの構築ではありません。プラットフォームチームとそれがサービスを提供するチームとの間の継続的な関係です。
また、プラットフォームチームは孤立して作業しません。彼らはしばしばイネーブリングチームと協力して特定の機能をレベルアップします。データベースレプリケーションやネットワークセキュリティなど、プラットフォームの一部に深い専門知識が必要な場合、複雑サブシステムチームと協力することもあります。
正しく機能したときの変化
プラットフォームチームがうまく機能すると、ストリームアラインドチームはバリューストリームに集中できます。彼らはパイプライン用のサーバーの設定方法を心配する必要がありません。本番環境へのアクセスを保護する方法を考える必要がありません。すべてのアプリケーションからのログを集約する方法を考える必要がありません。
これらはすべてプラットフォームによって処理されます。ストリームアラインドチームはコードを書き、パイプラインを実行し、機能を出荷します。プラットフォームが残りを処理します。
これは自律性を奪うことではありません。不要な重複を排除することです。チームは依然としてデプロイの決定を所有します。リリースのタイミングを決定します。ただ、毎回インフラを再発明する必要がなくなるだけです。
プラットフォームチーム開始のためのクイックチェックリスト
プラットフォームチームの編成を検討している場合、初期に確認すべきいくつかのポイントを以下に示します。
- 最大のペインポイントから始める。 初日から完全なプラットフォームを構築しようとしないでください。すべてのチームが苦労している1つの機能（シークレット管理やデプロイテンプレートなど）を選び、それを最初に解決します。
- セルフサービス向けに設計する。 プラットフォームチームが全員が待たなければならないゲートになると、新しいボトルネックが生まれます。すべての機能は、チケットを発行せずにストリームアラインドチームが使用できる必要があります。
- 機能ではなく採用率を測定する。 誰も使わない多くの機能を持つプラットフォームは負債です。実際にプラットフォームを使用しているチームの数を追跡し、他のチームが採用していない理由に耳を傾けます。
- 進化を計画する。 チームが成長するにつれてプラットフォームは変化する必要があります。フィードバックループを構築し、プラットフォームチームが何が機能していて何が不足しているかを把握できるようにします。
まとめ
プラットフォームチームは統制を集中化することではありません。退屈で反復的なインフラ作業を集中化し、ストリームアラインドチームが重要なこと、つまりユーザーに価値を届けることに集中できるようにすることです。正しく機能すれば、プラットフォームチームは他のすべてのチームをより速く、より安全に、より一貫性のあるものにします。間違った方法で行うと、待ち行列がもう一つ増えるだけです。
違いは、基盤を構築するか、ゲートを構築するかです。基盤を構築しましょう。