プラットフォームを製品として見るとはどういうことか

一言でいうと

プラットフォームエンジニアリングの目標は、ツールをたくさんそろえることではなく、ストリームアラインドチームの認知負荷(cognitive load)を下げることです。そのため、プラットフォームはプロジェクトではなく製品であり、ユーザーは他の開発チームで、成功メトリクスはデプロイ回数ではなく自発的な採用率です。

なぜ必要なのか

「You build it, you run it」が流行するにつれて、多くの組織が運用の責任を開発チームに押しつけました。意図は良かったのですが、結果はこうなりました。開発者1人が知っておくべきことが爆発的に増えたのです。言語とフレームワーク、ドメインロジック、さらにその上にKubernetes、Helm、Terraform、CIの文法、Secret管理、オブザーバビリティスタック、ネットワークポリシー、コスト最適化までが加わります。

これをTeam Topologiesでは、認知負荷の超過と呼びます。認知負荷には3つの種類があります。

種類	内容	対応
内在的(intrinsic)	言語やデータ構造のような基礎スキル	教育と採用で対応します
外在的(extraneous)	YAMLを8つ順番に書く手順	プラットフォームがなくすべき対象です
学習関連的(germane)	ドメインの問題そのもの	ここに頭を使わせる必要があります

プラットフォームエンジニアリングは、外在的負荷を吸収して、学習関連的負荷に使う余裕を作る仕事です。そのため、「私たちのプラットフォームはうまくいっているか」の答えは、ツールの数ではなく、「開発者がドメインの問題にどれだけ時間を使えているか」です。

どう動くのか

製品としてのプラットフォーム

プラットフォームをプロジェクトとして扱うと、次のように進みます。要件を集めて6か月かけて作り、デプロイし、チームを解散します。製品として扱うと、違ってきます。

ユーザーがいます。 そのユーザーは社内の開発者で、使いたくなければ使いません。
ロードマップがあります。 何をやらないかも決めます。
オンボーディング文書とサポートチャネルがあります。
バージョンと非推奨化のポリシーがあります。 昨日動いていたものが今日壊れると、信頼が失われます。
成功メトリクスがあります。 採用率、最初のデプロイまでにかかった時間、サポートチケット数です。

最も重要な判別式が1つあります。それは強制していないのに人々が使っているかどうかです。社内規定で強制して100%にしたプラットフォームは、採用率ではなく準拠率を測ったことになります。準拠率が高く満足度が低ければ、そのプラットフォームは失敗しつつあるのに、メトリクスがそれを隠します。

Team Topologiesの4つのチームタイプ

CNPAはこの分類を直接問います。

チームタイプ	役割
Stream-aligned	1つの価値の流れ(製品・機能・ユーザージャーニー)に最後まで責任を持ちます。組織の大多数を占めるべきです
Platform	ストリームアラインドチームがセルフサービスで使える内部サービスを提供します
Enabling	他のチームの能力ギャップを一時的に埋めます。常駐せず、去ります
Complicated-subsystem	専門知識が深く必要な部分(ビデオコーデック、決済精算、数学エンジン)を担当します

さらに、インタラクションの方式が3つあります。Collaboration(一時的に密着して一緒に発見する)、X-as-a-Service(境界が明確な利用関係)、Facilitating(教えたら手を引く)です。プラットフォームチームの正常な状態はX-as-a-Serviceです。プラットフォームチームがすべてのストリームチームと常時Collaborationを行っているなら、それはプラットフォームがまだセルフサービスになっていないというサインです。

DevOps・SRE・プラットフォームエンジニアリング

この3つは競合する概念ではなく、焦点が違います。

DevOpsは文化であり、原則です。開発と運用の間の壁をなくそう、という考え方です。チーム名ではありません。「DevOpsチーム」を作ってデプロイを代行し始めたら、なくそうとしていた壁を名前だけ変えて建て直したことになります。
SREは、信頼性をエンジニアリングの問題として扱う具体的な実践です。SLI/SLO、エラーバジェット、トイルの削減、ブレームレスポストモーテムがあります。対象はサービスの信頼性です。
プラットフォームエンジニアリングは、それらの実践をセルフサービス製品としてパッケージ化し、多数のチームがデプロイできるようにする仕事です。対象は開発者体験です。

重なる部分は大きいです。プラットフォームもSLOを持つべきですし(SREの手法)、プラットフォームチームも自分たちのプラットフォームを自ら運用する必要があります(DevOpsの原則)。分かれるのは「誰のために最適化するのか」という点で、SREはエンドユーザーの体験を、プラットフォームエンジニアは社内開発者の体験を最適化します。

現場での姿

筆者の7ノードのホームラボが、この話の縮図です。Cilium 1.20 eBPF CNI、MetalLB L2(10.0.0.200-215)、Harborレジストリ(10.0.0.202)、Gitea(10.0.0.200)、Argo CD(10.0.0.201)、kube-prometheus-stackとGrafana(10.0.0.203)、CloudNativePG、GPU OperatorによるGPU 4枚、KubeVirt、csi-driver-nfsがそろっています。スタックを並べるだけなら、立派なプラットフォームに見えます。

ところが、各コンポーネントを立ち上げる過程で出てきたトラブルの一覧こそが、本当のプラットフォームの価値を示しています。Gateway APIにはCRDのv1.6.1が必要で、v1.2ではコントローラーが起動を拒否しました。KubeVirtはコンポーネントの状態がすべてAllComponentsReadyなのにVMが起動せず、原因はvirt-launcher Podのボリュームマウント漏れでした。containerDiskの経路に欠陥があり、DataVolume(PVC)の経路で回避する必要がありました。

これらの知識はすべて外在的認知負荷です。サービスを作ろうとする開発者が知る理由のないものばかりです。プラットフォームチームの仕事は、これらの落とし穴を一度ずつ踏んでから、その結果を「ゴールデンパス1本」にまとめ、ほかの人が二度と踏まないようにすることです。また、「状態がReady」と「実際に動く」は別の命題だという教訓を同じクラスターで3度目に確認したという記録は、プラットフォームが提供すべきものがインストールではなく検証済みの経路であることも意味しています。

続けて読むこと

次の理論レッスンでは、プラットフォームの成熟度の段階と、内部開発者プラットフォーム(IDP)の構成要素を整理します。その次のモジュールでは、Kubernetes APIをプラットフォームAPIに拡張する方法を、実際のクラスターでCRD・CR・ResourceQuota・RBACを使って自分で作ってみます。