プラットフォーム エンジニアリングでの効果的なインターフェイスの開発には、カスタムの手動プロセスから、プロビジョニングとサービス要求を合理化する標準化された一貫性のあるソリューションへの移行が含まれます。 この記事では、開発環境の設定とアプリケーションの動作の診断に重点を置いて、インターフェイス開発の段階について説明します。
カスタム プロセス
さまざまな機能とサービスをプロビジョニングするためにさまざまなプロセスのコレクションが存在しますが、インターフェイスの一貫性は考慮されません。 カスタムのカスタマイズされたプロセスは、個人またはチームの即時のニーズに対応し、プロバイダーが自動化された実装スクリプトを使用している場合でも、手動による介入に依存します。
これらのソリューションを要求する方法に関する知識は、個人間で共有されます。 サービスを要求するプロセスには、標準化と一貫性がありません。 プラットフォーム サービスのプロビジョニングと使用には、機能プロバイダーからの深いサポートが必要な場合があります。
中央の要件と標準がない場合、会社がまだ期待を特定して文書化していない場合に、このレベルが適切になります。 これは、初期段階の企業やプラットフォームの取り組みのチームにとって特に効果的です。 これらの環境では、チームはプロセスと機能をニーズに合わせて自由に進化させることができます。これにより、より迅速に提供し、後で必要な場合にのみ標準化の代償を支払うことができます。
開発環境のセットアップ: 個々のエンジニアは、同僚に依頼し、ドキュメントを見つけ、独自の既知のプラクティスに従って、環境を設定するために必要な手順をまとめています。
アプリケーションの動作を診断する: エンジニアは、動作を診断するための独自のツールとプロセスを選択します。 アプリケーションとログにアクセスするための手順を実行する責任があります。
ローカル標準
エンジニアとエンジニアリング チームは、組織内で行うことができる知識共有の量を増やすために、さまざまな機能とサービスの標準を積極的かつ非公式に定義します。 非公式のサポート コミュニティはこれらの基準を中心に立ち上がっていますが、これは個人や個々のチームからのリソースとコミットメントに依存します。
開発環境のセットアップ: 個々のチームが独自のツールとプロセスを定義し、チーム内のエンジニアがこれらのプロセスに従っていることを確認しようとします。 ドキュメントまたはコンテナーを使用している可能性がありますが、ツールとプロセスを文書化する方法の選択はチームによって行われます。
アプリケーションの動作を診断する: 個々のチームは、動作を診断するための独自のプラクティスとプロセスを定義します。 Teams は、デプロイされたリソースにアクセスするために devops/IT チームに依存しています。
プラットフォームと機能をプロビジョニングおよび監視するための一貫性のある標準インターフェイスが存在し、広範なニーズを満たします。 ユーザーは、使用可能な機能を識別でき、必要な機能を要求できます。
ドキュメントとテンプレートの形式で、舗装された道路またはゴールデン パスが提供されます。 これらのリソースは、準拠パターンとテスト済みパターンを使用して、一般的な機能をプロビジョニングおよび管理する方法を定義します。 一部のユーザーは独自にこれらのソリューションを使用することができますが、多くの場合、ソリューションには深いドメインの専門知識が必要であるため、保守担当者からのサポートは依然として不可欠です。
特にチームからのニーズの変化に対応するために、テンプレート/ドキュメントを維持するために中央チームから重要な管理が必要です。
開発環境のセットアップ: 組織全体で必要なツールとプロセスを定義するドキュメントまたはテンプレートを使用して、共通のパスに投資します。 チームはテンプレートを変更するが、一元化されたチームにマージし直すことはできない/できないので、標準から逸脱する可能性があります。
アプリケーションの動作を診断する: デプロイされたリソースにアクセスして診断するために定義された標準的なプラクティス。
セルフサービス ソリューション
ソリューションは、ユーザーに自律性を提供し、保守担当者からのサポートをほとんど必要としないように提供されます。 組織は、ある機能から別の機能へのユーザー エクスペリエンスの検出可能性と移植性を可能にする一貫したインターフェイスを提供するソリューションを奨励し、有効にします。 セルフサービスでは、ソリューションにはチームの認識と実装が必要です。 このエクスペリエンスを向上させるために、ガイド付きの簡素化された内部言語が存在する可能性があります。これにより、ユーザーはプラットフォーム機能をより迅速に導入して統合できます。 これにより、ユーザー中心のセルフサービスで一貫した機能のコレクションが生成されます。
開発環境のセットアップ: エンジニアリング チームは、開発環境を設定するプラットフォームに依存します。 アフォーダンスは、使用可能なリソースを検出するために存在します。 エンジニアリング チームは、すべての対話専用のプラットフォームを採用します。 このプラットフォームは、新しいテンプレートと既存のテンプレートの検出と変更を通じて知識共有を支援し、プラットフォームによって提供される価値を継続的に高めます。
アプリケーションの動作を診断する: 必要に応じてプラットフォームを通じて提供されるリソース/機能を監視するためのツールとサービス。 プラットフォームは、リソース/機能を診断および監視するためのアフォーダンスを提供します。
統合サービス
プラットフォーム機能は、チームが作業を行うために既に使用しているツールとプロセスに透過的に統合されています。 デプロイされたサービスの監視や ID 管理など、一部の機能は自動的にプロビジョニングされます。 ユーザーが提供されるサービスの端に達すると、プラットフォームの機能は構成要素と見なされるため、内部オファリングを離れることなく、自動化されたソリューションを過去に移動し、ニーズに合わせてカスタマイズする機会があります。 これらの構成要素は、より高いレベルのユース ケースを満たすために透明で自動のコンポジションを構築するために使用され、必要に応じてより深いカスタマイズを可能にします。
内部プラットフォーム チームは、組織にとって適切に機能している機能を決定でき、この知識を使用して、プラットフォームをさらに改善するために投資する領域を決定できます。
機能は複数の方法で拡張およびパッケージ化でき、リソースと機能をプロビジョニング、管理、監視するための最大限の柔軟性が提供されます。
開発環境を設定する: プラットフォーム機能は、チームが作業を行うために既に使用しているツールとプロセスに統合されます。 CLI、IDE などを介して使用できます。
アプリケーションの動作を診断する: プラットフォームは、デプロイされたアプリケーションごとに監視機能を自動的に設定します。 プラットフォームは、診断データとデプロイされたアプリケーションを操作するためのアフォーダンスを提供します。