CSDM とプラットフォームエンジニアリング:チーム間でのサービスアーキテクチャの標準化

[JunshuO]

50のチーム。「サービス」とは何かについて、50通りの定義。

プラットフォームエンジニアリングはインフラストラクチャの問題を解決しました。すべてのチームが同じパイプライン、同じコンテナプラットフォーム、同じ展開ツールを取得します。それが解決できなかったこと、そしてそのすべてを静かに損なっているのは、どのチームもサービスが実際に何であるかについて、依然としてまったく異なる認識を持っているという事実です。そこで CSDM の出番です。

---

誰も全体像を把握できない社内開発者プラットフォーム

プラットフォームエンジニアリングチームはすべてを正しく行いました。彼らは、組織内のすべての開発チームに、一貫したKubernetes環境、管理されたCI/CDパイプライン、共有APIゲートウェイ、一元化されたオブザーバビリティスタックといった、標準化されたインフラストラクチャを提供しました。あらゆる技術的尺度から見て、これは素晴らしい成果でした。

その後、カスケード障害が発生しました。3 つのアプリケーションサービスが同時にダウンしました。運用チームが監視ダッシュボードを開くと、赤い壁が見えました。アラートは、さまざまなチームがまったく異なる方法で定義したサービス名を参照していました (機能別、チームの所有権別、実行しているインフラストラクチャ別)。どのアラートが関連しているのか、どのサービスが障害が発生した共有プラットフォームコンポーネントに依存しているのか、どのビジネス機能が実際に影響を受けているのかをすぐに判断できる人は誰もいませんでした。

インフラストラクチャは標準化されていました。その下にあるサービスアーキテクチャはそうではありませんでした。そして、本番インシデントでは、その区別がすべてを左右します。

✦ ✦ ✦

問題点

プラットフォームエンジニアリングは「方法」を標準化します。しかし、「対象（サービスそのもの）」は誰も標準化しませんでした。

プラットフォームエンジニアリングは、うまくいけば、まさに変革をもたらします。開発チームは、デプロイ パイプラインの再発明をやめ、機能の提供を開始します。インフラストラクチャパターンの一貫性が保たれます。全員が同じ基盤で作業しているため、運用ツールはすっきりと統合されます。生産性の向上は現実的で測定可能です。

しかし、プラットフォームエンジニアリングは、サービスのデリバリーにおける*メカニズム*、すなわち「方法」は標準化します。しかし、デフォルトでは、サービスのデリバリーにおける*モデル*、すなわち「サービスが何であるか」は標準化しません。そして、「サービスとは何か、サービスは何に依存しているのか、サービスがサポートするビジネス機能とどのように関係しているのか」について、50 の開発チームがそれぞれ独自の答えを自由に定義できると、50 の異なる答えが得られます。

大規模なアーキテクチャの断片化にかかるコスト

監視ツールとオブザーバビリティツールは、サービスが一貫して定義されている場合にのみ、関連付けることができます。チーム A が何かを「サービス」と呼び、チーム B が同じタイプのものを「コンポーネント」と呼び、チーム C がそれを親となるグルーピングなしに 4 つのマイクロサービスに分割する場合、オブザーバビリティレイヤーは、何が正常で何が異常であるかについて、一貫した状況説明ができなくなります。

AI 主導の運用ツールはさらに大きな打撃を受けています。サービス関係を推論して根本原因を特定し、障害を予測し、修復を推奨します。彼らに50の一貫性のないサービス定義を与えると、費用のかかる推測しかできません。統一されたサービスモデルを提供することで、オペレーショナルインテリジェンスが可能になります。出力品質の違いは明らかです。

プラットフォームエンジニアリングチームは、実際の問題を解決しました。彼らは関連する問題をそのまま残しただけで、エンタープライズ規模では、管理されていないサービスアーキテクチャは、未対応のままであるほど、時間とともにコストが膨らむ問題です。

説明

プラットフォームエンジニアリングが必要とするアーキテクチャ標準としての CSDM

共通サービスデータモデルは、エンタープライズ CMDB 内でテクノロジーサービスをどのように表現し、関連付けるかについての構造化されたフレームワークです。明確なレイヤー (インフラストラクチャ構成アイテム、テクニカルサービス、アプリケーションサービス、ビジネスアプリケーション、ビジネス機能) を定義し、各レイヤーが他のレイヤーにどのように関連しているかを指定します。

プラットフォームエンジニアリングのコンテキストでは、CSDM は開発チームが欠いている共通言語を正確に提供します。社内開発者プラットフォームは、チームにサービスの展開方法を指示します。CSDMは、サービスをどのように表現すべきか、その内容（何であるか、何に依存しているか、どのようなビジネス機能をサポートしているか、誰が責任を負うか）を教えてくれます。

この 2 つが実際にどのように組み合わされるか

プラットフォームエンジニアリングチームは、開発チームが構築する共有インフラストラクチャ機能(コンテナオーケストレーション、APIゲートウェイ、メッセージングインフラストラクチャ、サービスメッシュ)を構築および維持します。CSDM用語では、これらが**テクニカルサービス**にあたります。企業全体で複数のアプリケーションサービスをサポートする再利用可能なプラットフォーム機能。

開発チームがそのプラットフォーム上にビルドして展開するサービスは、**アプリケーションサービス**です。特定のビジネス機能を提供するソフトウェアの運用インスタンス。これらのアプリケーションサービスは、その下のテクニカルサービスに依存し、その上のビジネスアプリケーションと機能をサポートします。

このモデルがプラットフォームエンジニアリングのオンボーディングに組み込まれている場合 (新しいサービスの展開に、適切にタイプ化され、適切に関連付けられたアプリケーションサービスとして CMDB に登録することが含まれる場合)、サービスアーキテクチャを後から手直しする必要がなくなります。これは最初の展開から組み込まれています。すべてのチームは、すでに断片化された状態に新たな解釈を追加するのではなく、共有された一貫したモデルに追加します。

一貫したサービスアーキテクチャで可能になること

実際に機能するオブザーバビリティ : Kubernetes ノードの性能が低下した場合、監視レイヤーは、そのノードのテクニカル サービスに依存しているアプリケーション サービスを即座に追跡し、関連するアラートを 1 つのサービス イベントにグループ化し、リスクにさらされているビジネス機能を特定できます。これは、人間が手動で紐付けを行うことなく可能です。

規模に合わせて機能するガバナンス : アーキテクチャレビュープロセス、変更リスクアセスメント、サービスオーナーシップの説明責任はすべて、サービスを一貫してモデル化することで容易になります。サービスの 50 の異なる定義を管理することはできません。1つであれば管理できます。

推論の根拠となるものを備えたAI : 予測分析、根本原因分析、および自動修復はすべて、正確なサービス関係に依存します。一貫した CSDM に沿ったサービスモデルは、AI の運用出力を技術的に興味深いものから真に役立つものへと変えるものです。

「社内の開発者プラットフォームは、サービスの構築方法を標準化しました。CSDM はサービスとは何かを標準化します。「一貫して展開される」ことと「一貫して理解される」ことは同じものではないからです。」

ソリューション

サービス登録を展開プロセスの一部にする

CSDM をプラットフォームエンジニアリングに統合する最も効果的な方法は、非表示にするのではなく、開発チームがすでに使用しているワークフローに組み込むことで、開発チームが意識しないようにすることです。CMDB でのサービス登録は、コンテナー構成やパイプラインのセットアップと同様に、プラットフォームのオンボーディングプロセスのステップになります。チームは新しいプロセスを採用しません。既存のステップで新しいステップを完了します。

プラットフォームチームは、標準化された CMDB レコード形式、命名規則、関係パターン、所有権フィールドなどのテンプレートを提供し、チームはこれらのテンプレートを一度入力すると、サービスの進化に合わせて維持されます。サービスグラフコネクタとインフラストラクチャディスカバリーツールは、稼働環境と CMDB モデル間の継続的な同期を処理するため、従来、大規模なCMDBの精度維持を困難にしていた手動メンテナンスの負担を軽減します。

統制は集中化されています。チーム層ではなく、プラットフォーム層で処理されます。アーキテクチャレビュープロセスでは、新しいサービスが本番環境に移行する前に CSDM モデルに従っていることを検証します。サービス所有権の認定サイクルにより、チームやシステムが変化してもモデルの正確性が維持されます。実行は分散されます。

時間の経過とともに、それが記述する環境を実際に反映したサービスアーキテクチャ、つまり運用チームが信頼でき、AI システムが推論でき、経営層がテクノロジーがビジネスをどのようにサポートしているかの首尾一貫した全体像として読み取ることができるアーキテクチャが浮かび上がります。すべてのチームが独自に正しく行うことを決定したからではなく、プラットフォームがそれを正しく行うことを最も抵抗の少ない道にしたからです。

---

まとめる

プラットフォームは基盤の半分にすぎません

プラットフォームエンジニアリングがフロアを構築しました。すべてのチームが同じインフラストラクチャ上に立ち、同じツールを使用し、同じパイプラインを介して展開します。これは真の成果であり、軽視されるべきではありません。しかし、オペレーショナルインテリジェンス、つまり、数時間ではなく数分で根本原因を見つけ、障害が発生する前に予測し、サービスヘルスの首尾一貫したビューをリーダーに提供できるものには、一貫した基盤以上のものが必要です。その上に構築されたすべてのマップの一貫したマップが必要です。

CSDM はそのマップです。それは後付けや文書化の演習としてではなく、オンボーディングに組み込まれ、ガバナンスによって強制され、自動化によって維持される、プラットフォームエンジニアリングプラクティス自体に統合された要素なのです。地図が正確で床がしっかりしていれば、建物は実際に機能します。

インフラストラクチャを標準化します。次に、その上で実行されるものを標準化します。

---

この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/csdm-and-platform-engineering-standardizing-serv...。

免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。

This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-blog/csdm-and-platform-engineering-standardizing-serv...。

[JunshuO]

50のチーム。「サービス」とは何かについて、50通りの定義。

プラットフォームエンジニアリングはインフラストラクチャの問題を解決しました。すべてのチームが同じパイプライン、同じコンテナプラットフォーム、同じ展開ツールを取得します。それが解決できなかったこと、そしてそのすべてを静かに損なっているのは、どのチームもサービスが実際に何であるかについて、依然としてまったく異なる認識を持っているという事実です。そこで CSDM の出番です。

---

誰も全体像を把握できない社内開発者プラットフォーム

プラットフォームエンジニアリングチームはすべてを正しく行いました。彼らは、組織内のすべての開発チームに、一貫したKubernetes環境、管理されたCI/CDパイプライン、共有APIゲートウェイ、一元化されたオブザーバビリティスタックといった、標準化されたインフラストラクチャを提供しました。あらゆる技術的尺度から見て、これは素晴らしい成果でした。

その後、カスケード障害が発生しました。3 つのアプリケーションサービスが同時にダウンしました。運用チームが監視ダッシュボードを開くと、赤い壁が見えました。アラートは、さまざまなチームがまったく異なる方法で定義したサービス名を参照していました (機能別、チームの所有権別、実行しているインフラストラクチャ別)。どのアラートが関連しているのか、どのサービスが障害が発生した共有プラットフォームコンポーネントに依存しているのか、どのビジネス機能が実際に影響を受けているのかをすぐに判断できる人は誰もいませんでした。

インフラストラクチャは標準化されていました。その下にあるサービスアーキテクチャはそうではありませんでした。そして、本番インシデントでは、その区別がすべてを左右します。

✦ ✦ ✦

問題点

プラットフォームエンジニアリングは「方法」を標準化します。しかし、「対象（サービスそのもの）」は誰も標準化しませんでした。

プラットフォームエンジニアリングは、うまくいけば、まさに変革をもたらします。開発チームは、デプロイ パイプラインの再発明をやめ、機能の提供を開始します。インフラストラクチャパターンの一貫性が保たれます。全員が同じ基盤で作業しているため、運用ツールはすっきりと統合されます。生産性の向上は現実的で測定可能です。

しかし、プラットフォームエンジニアリングは、サービスのデリバリーにおける*メカニズム*、すなわち「方法」は標準化します。しかし、デフォルトでは、サービスのデリバリーにおける*モデル*、すなわち「サービスが何であるか」は標準化しません。そして、「サービスとは何か、サービスは何に依存しているのか、サービスがサポートするビジネス機能とどのように関係しているのか」について、50 の開発チームがそれぞれ独自の答えを自由に定義できると、50 の異なる答えが得られます。

大規模なアーキテクチャの断片化にかかるコスト

監視ツールとオブザーバビリティツールは、サービスが一貫して定義されている場合にのみ、関連付けることができます。チーム A が何かを「サービス」と呼び、チーム B が同じタイプのものを「コンポーネント」と呼び、チーム C がそれを親となるグルーピングなしに 4 つのマイクロサービスに分割する場合、オブザーバビリティレイヤーは、何が正常で何が異常であるかについて、一貫した状況説明ができなくなります。

AI 主導の運用ツールはさらに大きな打撃を受けています。サービス関係を推論して根本原因を特定し、障害を予測し、修復を推奨します。彼らに50の一貫性のないサービス定義を与えると、費用のかかる推測しかできません。統一されたサービスモデルを提供することで、オペレーショナルインテリジェンスが可能になります。出力品質の違いは明らかです。

プラットフォームエンジニアリングチームは、実際の問題を解決しました。彼らは関連する問題をそのまま残しただけで、エンタープライズ規模では、管理されていないサービスアーキテクチャは、未対応のままであるほど、時間とともにコストが膨らむ問題です。

説明

プラットフォームエンジニアリングが必要とするアーキテクチャ標準としての CSDM

共通サービスデータモデルは、エンタープライズ CMDB 内でテクノロジーサービスをどのように表現し、関連付けるかについての構造化されたフレームワークです。明確なレイヤー (インフラストラクチャ構成アイテム、テクニカルサービス、アプリケーションサービス、ビジネスアプリケーション、ビジネス機能) を定義し、各レイヤーが他のレイヤーにどのように関連しているかを指定します。

プラットフォームエンジニアリングのコンテキストでは、CSDM は開発チームが欠いている共通言語を正確に提供します。社内開発者プラットフォームは、チームにサービスの展開方法を指示します。CSDMは、サービスをどのように表現すべきか、その内容（何であるか、何に依存しているか、どのようなビジネス機能をサポートしているか、誰が責任を負うか）を教えてくれます。

この 2 つが実際にどのように組み合わされるか

プラットフォームエンジニアリングチームは、開発チームが構築する共有インフラストラクチャ機能(コンテナオーケストレーション、APIゲートウェイ、メッセージングインフラストラクチャ、サービスメッシュ)を構築および維持します。CSDM用語では、これらが**テクニカルサービス**にあたります。企業全体で複数のアプリケーションサービスをサポートする再利用可能なプラットフォーム機能。

開発チームがそのプラットフォーム上にビルドして展開するサービスは、**アプリケーションサービス**です。特定のビジネス機能を提供するソフトウェアの運用インスタンス。これらのアプリケーションサービスは、その下のテクニカルサービスに依存し、その上のビジネスアプリケーションと機能をサポートします。

このモデルがプラットフォームエンジニアリングのオンボーディングに組み込まれている場合 (新しいサービスの展開に、適切にタイプ化され、適切に関連付けられたアプリケーションサービスとして CMDB に登録することが含まれる場合)、サービスアーキテクチャを後から手直しする必要がなくなります。これは最初の展開から組み込まれています。すべてのチームは、すでに断片化された状態に新たな解釈を追加するのではなく、共有された一貫したモデルに追加します。

一貫したサービスアーキテクチャで可能になること

実際に機能するオブザーバビリティ : Kubernetes ノードの性能が低下した場合、監視レイヤーは、そのノードのテクニカル サービスに依存しているアプリケーション サービスを即座に追跡し、関連するアラートを 1 つのサービス イベントにグループ化し、リスクにさらされているビジネス機能を特定できます。これは、人間が手動で紐付けを行うことなく可能です。

規模に合わせて機能するガバナンス : アーキテクチャレビュープロセス、変更リスクアセスメント、サービスオーナーシップの説明責任はすべて、サービスを一貫してモデル化することで容易になります。サービスの 50 の異なる定義を管理することはできません。1つであれば管理できます。

推論の根拠となるものを備えたAI : 予測分析、根本原因分析、および自動修復はすべて、正確なサービス関係に依存します。一貫した CSDM に沿ったサービスモデルは、AI の運用出力を技術的に興味深いものから真に役立つものへと変えるものです。

「社内の開発者プラットフォームは、サービスの構築方法を標準化しました。CSDM はサービスとは何かを標準化します。「一貫して展開される」ことと「一貫して理解される」ことは同じものではないからです。」

ソリューション

サービス登録を展開プロセスの一部にする

CSDM をプラットフォームエンジニアリングに統合する最も効果的な方法は、非表示にするのではなく、開発チームがすでに使用しているワークフローに組み込むことで、開発チームが意識しないようにすることです。CMDB でのサービス登録は、コンテナー構成やパイプラインのセットアップと同様に、プラットフォームのオンボーディングプロセスのステップになります。チームは新しいプロセスを採用しません。既存のステップで新しいステップを完了します。

プラットフォームチームは、標準化された CMDB レコード形式、命名規則、関係パターン、所有権フィールドなどのテンプレートを提供し、チームはこれらのテンプレートを一度入力すると、サービスの進化に合わせて維持されます。サービスグラフコネクタとインフラストラクチャディスカバリーツールは、稼働環境と CMDB モデル間の継続的な同期を処理するため、従来、大規模なCMDBの精度維持を困難にしていた手動メンテナンスの負担を軽減します。

統制は集中化されています。チーム層ではなく、プラットフォーム層で処理されます。アーキテクチャレビュープロセスでは、新しいサービスが本番環境に移行する前に CSDM モデルに従っていることを検証します。サービス所有権の認定サイクルにより、チームやシステムが変化してもモデルの正確性が維持されます。実行は分散されます。

時間の経過とともに、それが記述する環境を実際に反映したサービスアーキテクチャ、つまり運用チームが信頼でき、AI システムが推論でき、経営層がテクノロジーがビジネスをどのようにサポートしているかの首尾一貫した全体像として読み取ることができるアーキテクチャが浮かび上がります。すべてのチームが独自に正しく行うことを決定したからではなく、プラットフォームがそれを正しく行うことを最も抵抗の少ない道にしたからです。

---

まとめる

プラットフォームは基盤の半分にすぎません

プラットフォームエンジニアリングがフロアを構築しました。すべてのチームが同じインフラストラクチャ上に立ち、同じツールを使用し、同じパイプラインを介して展開します。これは真の成果であり、軽視されるべきではありません。しかし、オペレーショナルインテリジェンス、つまり、数時間ではなく数分で根本原因を見つけ、障害が発生する前に予測し、サービスヘルスの首尾一貫したビューをリーダーに提供できるものには、一貫した基盤以上のものが必要です。その上に構築されたすべてのマップの一貫したマップが必要です。

CSDM はそのマップです。それは後付けや文書化の演習としてではなく、オンボーディングに組み込まれ、ガバナンスによって強制され、自動化によって維持される、プラットフォームエンジニアリングプラクティス自体に統合された要素なのです。地図が正確で床がしっかりしていれば、建物は実際に機能します。

インフラストラクチャを標準化します。次に、その上で実行されるものを標準化します。