相互の関係を含むITテクノロジースタックをグラフデータベースに文書化するために推奨されるものは何ですか？

500人以上のITスタッフと1,000台以上のサーバーがあり、各サーバーが独自のビジネスアプリケーションを実行している大企業で働いているため、どのITスタッフメンバーがどのサーバーに連絡するかを知る上で、膨大な情報と調整の課題があります。調整の問題は、ITスタックのさまざまな層を担当するさまざまなITスタッフによって複雑になります。たとえば、ハードウェア、仮想化、オペレーティングシステム、アプリケーションサーバー、およびアプリケーション自体を担当するさまざまなチームがあります。

この課題を考慮すると、DevOps内では、IT環境内のさまざまなテクノロジースタックを構成するすべてのコンポーネントを定義および文書化する必要があります。従来、これは適切なCMDBソリューションを使用して達成されていました。

この目的のためにBMC Atriumなどの典型的なCMDBソリューションを調査しましたが、問題はITILフレームワークに従ってIT資産自体を文書化するレベルで停止することですが、文書化には対処しませんITテクノロジースタックの詳細。Puppet、Ansible、Saltなどのツールも調査しましたが、これらのツールは、ソフトウェアの周りの人の調整ではなく、ソフトウェアの展開と構成に重点を置いています。

たとえば、実行可能なソリューションは、これらの概念にとって重要な重要な属性とともに、さまざまな概念を定義します。

• ハードウェア
• 仮想化
• オペレーティングシステム
• アプリケーションサーバー
• 用途

これらの概念は、ソリューションを形成するために、それらの関係の観点から互いに関連付けられます。たとえば、アプリケーションは、オペレーティングシステムなどに依存するアプリケーションサーバーに依存します。このソリューションは、一緒に「金融システム」で定義されます。システムを定義したら、これらのシステムに関連付けられているすべてのメタデータがキャプチャされ、スタック内の各レイヤーの調整が容易になります。つまり、各レイヤーのテクニカルサポートスタッフの調整。

このようなソリューションの目的は、次のようなテクノロジースタックに対してさまざまなクエリを実行することです。

• 誰がどのコンポーネントをサポートしているかを判断するには
• 古くなっているコンポーネント
• どのコンポーネントにパッチを適用する必要があるか

これを念頭に置いて、Neo4Jなどのグラフデータベースで、相互の関係を含むITテクノロジースタックのすべてのコンポーネントを定義するためのオープンソースツールは何ですか？

最初の段落を考えると、あなたが説明している組織は高度にサイロ化された組織であり、DevOps組織が避ける傾向にあるものです。

この課題を考慮すると、DevOps内では、IT環境内のさまざまなテクノロジースタックを構成するすべてのコンポーネントを定義および文書化する必要があります。従来、これは適切なCMDBソリューションを使用して達成されていました。

管理システムが必要なドキュメントであるITIL、あること、あなたはそれがの注意点と任意の開発ドキュメントに戻って取得するなど、DevOpsチームのチームは、通常のコードのように下にある層を定義することでそれを混ぜることができあなたがここに記述しているコード開発のアジャイルな方法論のためにスクラム方法論でよく見られるドキュメンテーションです（反復の終わりに最小限の作業ソリューションを目指した迅速で短い反復）

この回答の残りの免責事項：私はシェフとinspecの詳細を知っているので、ここではそれらを例として取り上げます。しかし、それらは市場に存在する唯一のツールではありません。より良いものはあなたがより快適なものであるので、私はそれらについて議論を開きません。

そのため、質問の残りの部分には少し偏りがあり、個人的には、コードや構成管理システムのコード文書としてインフラストラクチャ以上のものを記述するレイヤー関係を文書化する組織には遭遇しませんでした。（繰り返しますが、これは誰もやらないという意味ではありません。私は聞いたことがないだけです）。
シェフ環境で私の会社から説明するために、アプリケーションのクックブックはその依存関係（tomcat、jboss、nginx / php、およびいくつかの共有データとそのDBスキーマ名のマウントポイントを主に必要とするOS）を宣言し、そのサービスURIを公開します他のアプリケーション設定のためにシェフが消費します。これは、「金融システム」とそのドキュメントを定義するような音で、このアプリケーションクックブックのREADMEにあります。

構成管理システムには通常、中央のレポート場所、データ用の「chef-server」、シェフワールドでのプレゼンテーション用の「管理UI」、ansible worldの2つの名前を付ける「ansible tower」がありますが、通常は、依存関係をグラフ化するよりも全体的な管理対象システム。

とは言っても、chefの場合、chef-serverはCMDBとしても機能し、さまざまなツールで照会できます（HTTP要求からJSONデータを返します）。アプリケーション間の依存関係はさまざまな方法で表現でき、「そのまま」ではありませんメソッドを使用すると、各会社が独自の方法で設定を行うためにシステムでそれらを宣言するため、これを活用してグラフを作成できますが、それはあなたの側にあります。

コードの観点から見たインフラストラクチャでは、インフラストラクチャのニーズはアプリケーションとともに保持されます。ミドルウェアとして必要なもの、どのOS、どのロケール、他のサービスの依存関係、どのサービスを知っているのはアプリケーションです。このアプリケーションの提供）。

私が考えることができる最後のことは、主にCMDBとチケットシステムであるglpiのようなツールだけでドキュメントの依存関係を管理したい場合、アセットとその関係をドキュメント化することを利用して、開いたときに影響を受けるものを伝えることができることですアプリケーションがダウンしているというチケット。ng-inventoryと組み合わせると、システム状態のクエリが可能になり、パッチニーズのクエリを満たすことができますが、これは次のフェーズのように、chef runに統合された検査を実行できるように監査システムタスクです更新/パッチを適用して古いシステムを修正します。