インベントリとリレーションシップ追跡を使用して検出を改善し、無駄を排除する

organizationが増えるにつれて、追跡に必要なものの量も増えます。 コード、API、コンテナー、仮想マシン (VM)、メッセージング トピック、チーム メンバーシップ、プロジェクトの所有権などを追跡することが必要になる場合があります。 スケーリングするにつれて、一方のチームが他のチームについて知らないため、重複する作業を頻繁に見つけることは珍しくありません。 チーム間を移動したり、新しい人が入社したり、他のユーザーが退職したりすると、プロジェクトが孤立する可能性があります。 管理されていない場合、既に存在するものを簡単に発見できないために、技術的なスプロールや無駄につながる可能性があります。 これは一般的な課題です。 たとえば、次の引用符を考えてみましょう。

コンテナーまたは [VM] インスタンスが 1 トン実行されています。 古い VM を削除できますか? 誰も知らない。 古いものをクリーンし、適切なタグを使用する方法を考え出して、何ができるか、ライフサイクルが何であるかを通知できる所有者またはチームを把握する必要があります。... 何が起こるかわからないため、特定の VM をシャットダウンできるかどうかを知りません。 - 大規模な物流会社の DevOps エンジニア、Martin

調整されたインベントリを使用して追跡、セキュリティ、再利用を改善する

必要なものの一部は、内部の顧客がわかりやすい方法で視覚化できるエコシステムで作成または構築したすべての "もの" を追跡するのに役立つインベントリです。

インベントリを使用すると、セキュリティが向上し、再利用が促進され、一般的に検出が容易になります。 たとえば、Azure デプロイ環境では、コードとしてのインフラストラクチャ (IaC) を通じて作成された複雑なインフラストラクチャを、開発と運用の両方で理解できるレベルの抽象 環境 として記述および追跡します。 同様に、 Azure API Center には、開発者が API を検出して使用する方法が用意されています。 GitHub Packages や Azure Artifacts (または承認済みパッケージや SDK のその他のインベントリ) などのパッケージ レジストリにより、サプライ チェーンのセキュリティが向上します。 これらの各ツールには、廃棄物の管理、追跡、およびクリーンに役立つインベントリが用意されています。

これらのインベントリを作成または適用する方法を評価する場合、重要な決定の 1 つは、それらのコンテンツがどれだけ広く表示されるかを決定することです。 ここには正しい答えや間違った答えはありません。 一部の企業では、"誰もが準備中の食品を見ることができるが、少数の人しか調理できない" オープンキッチンアプローチを採用しています。オープン キッチンを使用すると、開発者はソフトウェア資産を完全に可視化できますが、自分が担当する資産のみを変更できます。 逆に、規制対象の企業は、プロジェクト名の可視性も機密性が高いと見なされる、より厳格なルールを持つ場合があります。

リレーションシップを使用して検出と追跡を改善する

持っているものを追跡するのに役立つ 1 つ以上のインベントリ システムを用意することは、プラットフォームのエンジニアリング プラクティスと技術的なスプロールの回避にとって重要です。 最初は、一連のフラット インベントリ リストで十分な場合があります。 ただし、開始する必要はありませんが、複数のインベントリ間で異なる資産間のリレーションシップを追加することで、検出可能性を向上させることもできます。 必要な可視性のレベルに関係なく、集約ポイントを一元化することで、チームは利用可能なすべての資産をすばやく検索して検出できます。 これにより、再利用が促進され、冗長性が低下し、ガバナンスに対する一貫したアプローチが確立されます。

API 定義と、 インターフェイスを実装するデプロイされたアプリケーション コードの間の関係を考えてみましょう。 このコードはリポジトリに格納され、チームによって管理され、その使用に関するドキュメントが提供されます。 開発、テスト、運用、さらには一時的なサンドボックス環境が作成されます。 クラウド ネイティブシナリオでは、環境が共有 Kubernetes クラスターにデプロイされる場合があります。 API を構築する開発チームとその内部コンシューマーは、これらの各ことに関する情報を取得できる必要がありますが、リソースの関係は明らかではありません。

まず、Wiki ページのように単純なものを使用して、それぞれの関連性を追跡できます。 しかし、ドキュメントの時間が短縮され、検索と解析の両方が困難になる場合があります。 理想的には、リレーションシップ グラフ を持つシステムを使用して、インベントリ内でこれらのリレーションシップを走査するユーザー インターフェイスを活用できます。 検出可能性を本当に向上させるには、複数の種類のインベントリまたはグラフに格納されている物を関連付ける必要があります。 インベントリを直接使用する必要はありませんが、API カタログ システム内の情報に関連付けることができるようにしたい場合があります。

デジタル ストアの類推を使用するには、カタログ内の項目 (テンプレート) を結果の在庫コンテンツに関連付けるのも役立ちます。 たとえば、いずれかのテンプレートで安全でない構成が作成されている場合は、テンプレートを作成したすべてのリソースをすばやく見つけて修正する必要があります。 開始する適切なアプリケーション テンプレートも、基本的にこのカタログ内のスターター キット バンドルであり、他の種類のカタログ 項目 (IaC テンプレートなど) と結び付けられます。 これらの関連付けを追跡すると、インフラストラクチャがまだプロビジョニングされていない場合でも、不適切な IaC テンプレートを参照するアプリケーションを事前に見つけることができます。

この概念的で高度な開発者プラットフォーム グラフの簡略化されたバリエーションは、現在、いくつかのツールキットと製品で見つけることができますが、呼び出される内容は異なります。 たとえば、オープンソースのポータル ツールキット Backstage.io では、これをソフトウェア カタログと呼びますが、他の製品では異なる用語が使用されています。 ただし、これらの製品とツールキットのほとんどは、より広範な機能セットを使用していることを前提としており、インベントリの内容をそれらの中で複製する必要があります。 この重複は、カタログ データベースの内容がユーザー固有ではなく、古くなる可能性があり、実際のソース システムのユーザー承認メカニズムによって制御されていないことを意味します。 ただし、オープン キッチンのアプローチに従っている場合は、organizationで問題なく動作する可能性があります。

役立つ概念の詳細については、こちらを参照してください。

プラットフォーム エンジニアリングの取り組みを開始する