組織レベルでは、プラットフォーム エンジニアリングはリアクティブ カルチャから離れた進化です。 リアクティブ カルチャでは、孤立した開発者がサイロ内にツールを構築します。 その 1 人の開発者が離れると、そのツールの動作に関する知識も失われ、プロセスとダウンタイムが壊れる可能性があります。
より成熟した文化では、ツールは積極的に構築され、プラットフォーム エンジニアリング チームによって維持されます。 開発者には管理された自律性があり、開発者はすぐに新しいプロジェクトを開始できます。
プラットフォーム エンジニアリング チームが成功するためには、組織はエグゼクティブ バイインと適切なスキルを持つ開発者との積極的な文化を持っている必要があります。
プロアクティブカルチャとエグゼクティブバイインは、プラットフォーム エンジニアリング機能モデルの投資機能と一致します。 最高レベルでは、企業のリーダーシップは、イノベーションを促進し、ガバナンス対策を実施しながら、チームの自律性とアカウンタビリティを促進します。
文化の役割
プラットフォーム エンジニアリングの成熟度を持つ組織は、強力なリーダーシップを持っています。 企業内のプラットフォーム エンジニアリングは、継続的な再評価を必要とするバランスを取る行為です。 組織は、現在のリソース使用量を理解し、今後のパスをマップするために、プラットフォーム エンジニアリング チームをサポートする必要があります。
プラットフォーム エンジニアリング導入の初期段階では、製品チームはそれぞれ独自のツール、運用、デプロイ プロセスのセットを持っています。 成熟したプラットフォーム エンジニアリング組織では、一元化されたプラットフォーム エンジニアリングは、リーダーシップと開発者の両方で最適な作業方法と見なされます。 成熟した組織は、製品チームの問題が組織の問題であることを認識しています。
..さまざまなパス、クラウド コスト、インフラストラクチャ コスト、エンジニアリング コスト、さまざまな側面を追いかけているとき、それは組織の問題であり、20,000 人の開発者または組織の 30,000 人の従業員の問題であることが判明しました。 – エンタープライズ ソフトウェア企業のシニア エンジニアリング リーダー
組織の文化は、プラットフォーム エンジニアリングの絶え間ない発見パスをサポートする必要があります。 エグゼクティブは、プラットフォーム エンジニアリング チームがイノベーションを起こすために力を与えるのに重点を置く必要があります。
組織の目標は、経営幹部が最適化される文化へと移行することにあるべきです。
- チームがエッジ ケースに効果的に対処し、イノベーションを推進できるようにします。
- イノベーションと実験を促進するために、チーム内の自律性とアカウンタビリティを促進します。
- 進化するビジネス ニーズとユーザーの要求の中で、継続的な関連性と有効性を確保します。
時間の経過と共に、組織は暫定的な段階から、プラットフォーム エンジニアリングによる文化的変化をサポートするレベルの最適化に移行します。 プラットフォーム エンジニアリングのビジョンを受け入れるために必要な文化的変化を促進するために、各レベルでリーダーシップの役割が進化します。
| [仮] | 運用中 | 拡張性 | 最適化 |
|---|---|---|---|
| データドリブンの意思決定と適応性の文化を推進します。 | コラボレーション、継続的な学習、改善の文化を促進します。 | 共感と成長の文化を促進する。 | イノベーションを促進し、チームが変化と進歩を推進できるようにします。 |
また、組織の動機は、プラットフォーム エンジニアリングの文化的変化をサポートするために、各レベルで進化します。
| [仮] | 運用中 | 拡張性 | 最適化 |
|---|---|---|---|
|
|
|
|
組織構造
プラットフォーム エンジニアは、開発と運用の間の接着です。 特定の組織構造に関しては、 チーム トポロジ モデル は、何を行う必要があるかを考えるのに適したアプローチです。 たとえば、開発者が直面するプラットフォームの側面に焦点を当てた個別のスペシャリストを含む、進化したプラットフォーム チームを選択できます。
成功するには、次の内容を特定します。
- 高レベルの目標の優先順位付けと、より広範な組織全体でのプラットフォームの使用の支持を支援するチーム (通常はエグゼクティブ) のスポンサー。
- プラットフォームがガイダンスとニーズに確実に対応できるように、運用、セキュリティ、コンプライアンス、アーキテクチャの関係者。
- (実際の役職に関係なく) プロダクト マネージャーとして行動し、すべての構成要素のニーズを理解し、優先順位を付けるのに役立つユーザー。
才能のギャップを克服する:プラットフォームエンジニアの要件
プラットフォーム エンジニアは、製品の考え方を持ち、運用も理解する必要があります。 開発者として開始したか、運用チームで始めたのかは、スキル セットほど重要ではありません。 内部開発者プラットフォームを構築するチームは、開発、IT 運用、Kubernetes 管理者、サイト信頼性エンジニア (SRE)、コードとしてのインフラストラクチャ (IaC) の専門家など、さまざまな背景を持つさまざまなチーム メンバーを導入することで強みを得ることができます。
また、組織内の既存のアプリケーション チームから適切な開発者を取り込むことで、ツールを開発するためのチームの知識とスキル セットを強化することもできます。 これらの開発者は、投資について考える際に顧客の声を表すのに役立ちます。
プラットフォーム エンジニアを見つけることは難しい場合があります。
本当に優れたインフラストラクチャとプラットフォーム エンジニアを採用することは非常に困難です。 今日採用している人の多くは、顧客が直接直面するアプリケーションに非常に情熱を持っています。 しかし、インフラエンジニアリングに情熱を持つ大きな視聴者や候補者が技術業界全体に多くいるわけではありません。インフラに関しては、この種の専門知識はまれです。 - 中規模の販売会社のエンジニアリング担当副社長
プラットフォーム エンジニアは、次のことが可能である必要があります。
- 効率性、信頼性、およびセキュリティに重点を置いて、内部開発者製品を構築およびスケーリングします。
- プラットフォーム エンジニアリング製品のアーキテクチャと設計に貢献します。
- コンテナー オーケストレーション (Kubernetes など)、継続的インテグレーションと継続的デプロイ (GitHub Actions、Azure Pipelines など)、監視およびログ ツール (Prometheus、Grafana、Elasticsearch など) を使用して正常に動作します。
- コードとしてのインフラストラクチャと関連するツール (Terraform や Azure Resource Manager など) を使用してテンプレートを構築します。
- 少なくとも 1 つのスクリプト言語 (Python、PowerShell、Bash など) でコードを記述します。
優れたプラットフォーム エンジニアリング チームを構築するには、多様な技術スキルと製品中心のアプローチが組み合わせて必要です。 雇用の課題にもかかわらず、さまざまなバックグラウンドを持つチームを構築することで、効率、信頼性、セキュリティを向上させる内部プラットフォームの向上につながります。 この包括的なアプローチは、組織の即時の技術的ニーズに対応するだけでなく、イノベーションと継続的な改善の文化を促進します。