チーム構造を構築する

概念レベルでは、プラットフォーム エンジニアは開発と運用の間の接着です。 内部開発者プラットフォームを構築するユーザーとして、プラットフォーム エンジニアは、運用を理解する製品マインドセットを持つ開発者です。 開発者として始まったのか、運用チームから始めたのかは、スキル セットよりも重要ではありません。 内部開発者プラットフォームを構築するチームは、開発、IT 運用、K8s 管理者、サイト信頼性エンジニア (SRE)、コードとしてのインフラストラクチャ (IaC) の専門家など、さまざまな背景を持つさまざまなチーム メンバーを取り込むことから強みを得ることができます。

たとえば、ここでの全体的な考え方は、開発チームを顧客と考え、多くの運用チーム、SRE チーム、DevOps チームが、この目標を念頭に置いて機能またはツールを既に構築して提供しています。 実際、これらのチームが開発者に提供する CLI やその他のツールは、多くの場合、プラットフォーム エンジニアリングに向けた最初の成果物です。

また、organization内の既存のアプリケーション チームから適切な開発者を引き付けることで、ツールを開発するためのチームの知識とスキル セットを強化することもできます。 これらの開発者は、投資について考える際に顧客の声を表すのに役立ちます。

特定のorganization構造に関しては、チーム トポロジ モデル (同等に有用な DevOps トポロジ モデルの進化) は、何を行う必要があるかを考えるのに適したアプローチです。 たとえば、プラットフォームの開発者向け側面に焦点を当てた個別のスペシャリストを含む、進化したプラットフォーム チームを選択できます。 ここでは、トピックに関する既存の情報の豊富さを考慮して、これらの詳細については説明しません。

関係なく、このチームは、開発者が主要なターゲット顧客である内部製品として内部開発者プラットフォームを構築することに重点を置いています。 成功するには、次の項目も特定する必要があります。

• より広範なorganization全体で高レベルの目標を優先し、プラットフォームの使用を支持するチーム (通常はエグゼクティブ) のスポンサー。
• 運用、セキュリティ、コンプライアンス、アーキテクチャの関係者は、プラットフォームがガイダンスとニーズに確実に対応できるようにします。
• (実際の役職に関係なく) 製品マネージャーとして行動し、すべての構成員からのニーズを理解し、優先順位を付けるのに役立つユーザー。

問題領域を定義する