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

https://stackoverflow.com/questions/153445

03-07-2019
|

質問

はじめに

現在の組織では、多くのデスクトップアプリケーションとWebアプリケーションがすべての時点で相互に連携しています。古いアプリケーションの世話をしたり、新しいアプリケーションを作成するとき、どのシステムが動作するために他のシステムに依存しているかを思い出して試すのは非常に困難です。 DLLやイメージなどのソフトウェアの依存関係については話していません。HRシステムなどに依存する財務システムなどのシステム全体について話しているのです。

私の質問

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

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

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

解決

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

他のヒント

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

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

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

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

Foundationの無料Community Editionを使用する資格があるようです。CommunityEditionは最大30台のサーバーで使用できます-ダウンロードしてチェックしてください。その後、あなたがどう思うか教えてください！

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

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

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

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

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

過去1年ほどに私たちがやろうとしたことは、「冷酷な」ことです。 2つの点で：

自動化-自動化してビルド/デプロイを頻繁に行うと、自動化プロセスはほとんどの場合正しくなります（設定など）
wiki、wiki、wiki-私たちはチームとプロジェクトのwikiを最新の状態に保つことに懸命に努めています。

他の応答を見てみたい。

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

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

そのため、答えはあなたが「多く」と考えるものに依存します。

関連する2種類の問題：

a。）各コンポーネントの依存関係を判断する方法を知りたい人向け

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

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

別の方法として、グラフ作成ツールは価値があるかもしれません。

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

例を次に示します。

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

これがお役に立てば幸いです

システム依存関係マッピングは一つのことです。真の環境設定、uid、パスワード、偽装設定、データベース名、および開発からqa、uat、実稼働に変化するその他のデータは、真の課題です。

それらをすべて保存/記憶しているのは誰ですか？

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

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

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

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

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

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

ie。すべてのプロジェクト/アプリケーションのすべての構成設定を保存し、「ロール」に基づいたシステム実際の値が表示される/表示されない。

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

UATを繰り返し、最終的に製品化。

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

たぶん私は自分でそれを構築するでしょう...誰が私に契約したいですか？

私は仕事が初めてであり、最初のタスクとしてシステムの依存関係を特定することが提案されました。私の上司が意味したのは、人々と話をすることでした-そのようにして、私は誰が誰であったかを学びます。私は上司がそれをするためのコンピュータープログラムを書いてほしいと思った。そして、そうしました。プログラムが別のプログラム（サービスまたはサーバー）のクライアントである場合、 netstat -pant および netstat -panu の場合、ESTABLISHEDのgrepを使用すると、それ。 LISTENINGの出力をgrepすることにより、サービスを識別できます。

これは部分的な解決策です。はい、どのアプリケーションがどのアプリケーションと通信するかがわかりますが、他にも依存関係があります。したがって、たとえば、一部のアプリケーションはDNSを使用してサーバーを検索しますが、他のアプリケーションはハードコードされているか、構成ファイルにあります。 TCPまたはUDPを使用するものはすべてIPに依存しています。ほとんどの場所で、IPはARPとイーサネットまたはWiFiに依存しています。別のLAN上のサービスに依存するものは、少なくとも1つのルーターに依存しています。

ロードバランサーまたは何らかのクラスターがある場合、問題はより興味深いものになります。私がロードバランサーから出てくるサービスで、「本当の」ファイアウォールの背後にあるサーバーがダウンした場合、サービスは低下しますが、まだ稼働しています。

サービス（プログラム）はサーバー（ハードウェア）に依存するため、さらに興味深いものになります。サーバーは、電源と空調に依存します。

だから私の思考が制御不能になり、事態はさらに恐ろしく複雑になり、これらの依存関係をすべて取り込むためにドメイン固有言語（DSL）を作成することを考えました。たとえば、server_1、server_3、およびserver_5は電源フェーズ1であると考えました。 server_2、server_4、およびserver_6は電源フェーズ2にあります。Server_1、Server_3、およびserver_5はすべてほぼ同時に失敗します。おそらくフェーズ1が失敗しました。私はまだそれを理解していません。明らかに、状況は有向グラフで表すことができますが、詳細を明らかにしていません。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow