dependencies - システムの依存関係を追跡する方法は?

Question

序章

私の現在の組織では、多くのデスクトップアプリケーションと Web アプリケーションがすべて、ある時点で相互にフィードしています。古いアプリケーションを管理したり、新しいアプリケーションを作成したりするとき、どのシステムが他のシステムに依存しているかを覚えようとするのは非常に困難です。DLL やイメージなどのソフトウェアの依存関係について話しているのではなく、HR システムに依存する財務システムなどのシステム全体について話しているのです。

私の質問

あるシステム全体が別のシステムにどのように依存しているかを追跡する最良の方法はどれですか?

_{答えは、上記を実行する方法、ソフトウェアパッケージ、またはドキュメントテクニックのいずれかを示唆している可能性があります。}

_{私の特定のケースでは、「多数」とは、20 を超える Web およびデスクトップアプリケーションが 12 のサーバーを超えることを意味します。}

score 6 · Accepted Answer

アーキテクチャ設計ドキュメントでそれを明確に述べてください。Enterprise Architectなど、これに適したツールがいくつかあります。このツールを使用すると、UML 標準を使用してこれらの依存関係を明確かつ視覚的に説明する図を作成できます。

score 4 · Accepted Answer

これは、 Tideway Systemsで作成する種類のアプリケーションであり、多くの大規模な組織がこの目的のために使用しています。この製品を使用して不動産を発見し、モデリング機能を使用してビジネスアプリ（通常は複数のソフトウェアとスパンサーバーで構成されます）を記述できます。

最大30台のサーバーで使用できるFoundationの無料のCommunityEditionを使用する資格があるようです。ダウンロードしてチェックアウトするだけです。それでは、ご意見をお聞かせください。

免責事項：私はTidewayで開発グループを運営しています。この製品は非常にクールなIMOですが、私自身は直接書いていません:)

score 4 · Accepted Answer

各マシンの電源を 1 つずつオフにして、何が壊れているかを確認します.. ;p

真剣に、この質問に対する簡単な答えはありません。システムのコレクションを使用して、基本的な依存関係を示す図を作成できますが、依存関係が何であるかを理解していなければ、あまり意味がありません。通常、あなたの目標は、別のシステムを変更するときに何を「再検証」する必要があるかを判断することであり、どのマシンをランダムにオフにできるかではありません。しかし、そのような情報は膨大な量の詳細を必要とし、そもそも蓄積するのが困難です。

これらすべてが最終的に、システムが自動化よりも進んでいる状況になります。追いつくシュリンクラップされた自動化ツールを見つけることはできません。一方、非常に詳細な作業が必要なため、ワークロードの半分または 3 分の 1 を処理できるものはすべて価値があります。

score 4 · Accepted Answer

通常、最良の情報源は構成ファイルにあります。これには通常、接続文字列、Web サービスの URL などが含まれており、外部の依存関係を把握するのに役立ちます。

もう 1 つの手法は、プロファイリングまたはトレースを使用してフィルターを適用することです。外部呼び出しを簡単に追跡できます。ほとんどの場合、依存関係はデータベースレイヤーにあり、リンクサーバーをチェックしてその依存関係を追跡すると、多くの情報が明らかになります。

特にシステムが複数のプラットフォーム上にある場合、この情報を自動的に取得する方法があるかどうかはわかりません。そのすべてを文書化するには、多くの手作業が必要になります。

score 2 · Accepted Answer

これは良い質問です。私たちは毎回これに苦労しているようです。

この 1 年かそこらで私たちがやろうとしてきたことは、次の 2 つの点で「無慈悲」であることです。

自動化 -- 自動化して頻繁にビルド/デプロイする場合、自動化プロセスはほとんどの場合 (構成設定など) を正しく行う傾向があります。
wiki、wiki、wiki -- 私たちは、チームとプロジェクトの wiki を最新の状態に保つことに熱心に取り組んでいます。

他の回答を見て興味があります。

score 1 · Accepted Answer

これは「構成管理」グループの機能です。開始するには、会社の「専門家」と話をして、アプリケーションのマップ/グラフを作成する必要があります。graphviz/dot を使用して図を生成します。見栄えはよくありませんが、依存関係を視覚的に表現できます。

以下に例を示します。

digraph g {
 rankdir=LR;
 app1->app2->db1;
 app1->app3;
}

お役に立てれば、

score 1 · Accepted Answer

次の 2 種類の問題が関係しています。

a.) 各コンポーネントの依存関係を決定する方法を知りたい人向け

b.) コンポーネントのシステムにおける相互依存関係とその優先順位を追跡したい人向け。(どのコンポーネントが最初にテスト環境にインストールされるかなど...)

一連のコンポーネントがあり、それぞれの依存関係がわかっている場合、コンポーネントのリスト全体の依存関係の順序が必要な場合は、Algorithm::Dependency::Ordered という名前の Perl モジュールが価値のあるものになることがあります。 . コンポーネントなどのデータベースレコードや、単純なファイルレコードを操作できる関連モジュールが他にもあります。ただし、警告: これを機能させるのに問題がありました。

あるいは、グラフ作成ツールが役立つ場合があります。

score 1 · Accepted Answer

可能な限り自動化されたエンタープライズディスカバリーの仕事のように思えます。組織の規模と環境に応じて、さまざまなソリューションがあります。とにかく大きなランドスケープの場合は、CMDB (構成管理データベース) が必要です。HP Universal CMDBなどの製品は、大規模な環境で依存関係を検出して追跡できます。

たとえば、SAP システムとそれに関連するデータベース、および分散システムが実行されているホストとの関係を検出し、依存関係を表示できます。さらに重要なのは、実際の環境に対して不正な変更が行われた場合に警告できることです。

したがって、答えは、何を「多い」と見なすかによって異なります。

score 0 · Accepted Answer

システム依存関係のマッピングは1つのことです。真の環境設定、uid、パスワード、なりすまし設定、データベース名、および開発からqa、uat、本番へと変化するその他のデータは、真の課題です。

誰がそれらすべてを保存/記憶しますか？

開発者は、自分のアプリケーションがどの本番サーバーに常駐するかを知りません。彼は、開発データベースの名前、uid、pwdのみを文書化し、データベーステーブル、conn文字列などについて説明しています。

コードリポジトリにチェックインし、QA環境に移行したら、これらの構成ファイルを適切な値で更新するために必要なデータの管理者は誰ですか？

再びQAとUATに移行したとき、誰ですか？

次の移行グループに何を変更する必要があるかを通知するのは誰の責任ですか？

私の会社では、これが私たちに最も頭痛の種を引き起こしているものです。内部の変更管理プロセスによって承認され、アプリケーションを本番環境に移行するための移行要求が作成されるまでに、必要なのは1つの構成設定だけで、実装全体を台無しにすることを忘れてしまいます。明確な責任の線は引かれていません（私の意見では）。

責任を超えて、私はこの情報の中央リポジトリだと思います。

すなわち。すべてのプロジェクト/アプリケーションのすべての構成設定を保存し、「役割」に基づいて実際の値を表示/表示できないシステム。

開発者はビルドを終了し、「システム」に移行リクエストを作成します。QA担当者は、ビルド###の準備ができたという通知を受け取ります。QA担当者は「システム」にログインし、移行手順を取得します。今、彼らは何をする必要があるかを明確に理解しており、コードチェックアウトと移行プロセスに取り組んでいます。

UATと最終的には製品について繰り返します。

誰かがこの移行システムを構築するとき、それは多くの人々を助けるので、私に知らせてください。

多分私はそれを自分で作るでしょう...誰が私と契約したいですか？

dependencies - システムの依存関係を追跡する方法は?

10 に答える 10

Related

Reference