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


12

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

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

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

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

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

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

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

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

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


システム、人員、チームなどに関して組織の規模はどのくらいですか?
030

1
クローズの理由についてより多くの洞察を与えるために、ここにはあまりにも多くの質問があります。その一部はCMDBに関するものであり、他のポイントは監査とコンプライアンスに関するものです。これに対する特効薬はありません。これは実際の環境と使用しているものに大きく依存します。構成マネージャーを使用していますか?周りを見て、ニーズに合ったツールが見つかりませんでしたか?この質問はアドバイスのための投票であり、誰もがその好ましい解決策を持っているので、このサイトには適していないため、既存のツールを見て、一度具体的なことを尋ねてみてください。
テンシバイ

これは奇妙に聞こえるかもしれませんが、より一般的ですがカスタマイズ可能なエンタープライズウェアハウジングソリューションも同様にできますか?
ピーターミュリシキン

編集に感謝し、おめでとう、それは今よりはるかに答えが可能な質問です。グラフデータベースをその下に置く必要はありません(それは必要ではありません)が、正しい答えがあれば、これは省略できると思います。
テンシバイ

@J。Doeエンタープライズウェアハウジングソリューションは機能するかもしれませんが、そのような問題を解決するオープンソースソリューションはありますか。信じられないかもしれませんが、私たちにはたくさんのツールがありますが、どれも実際にこの問題に対処することはできません。サーバー管理側ではBMC ADDMを使用しますが、このツールの主な短所は、アプリケーション中心ではなくサーバー中心です。その結果、1つのサーバーが多数のアプリケーションをホストする場合、サーバーレベルでの関連付けのみが対象となるため、複数のアプリケーション所有者を関連付ける簡単な方法はありません。
グラントダー

回答:


5

最初の段落を考えると、あなたが説明している組織は高度にサイロ化された組織であり、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に統合された検査を実行できるように監査システムタスクです更新/パッチを適用して古いシステムを修正します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.