Как отслеживать системные зависимости?

Ответ 1

Я бы сказал, чтобы четко указать, что в вашем архитектурном документе. Для этого есть хорошие инструменты, например Enterprise Architect. Этот инструмент позволяет вам создавать диаграммы с использованием стандарта UML для четкого и визуального описания этих зависимостей.

Ответ 2

Лучший источник информации обычно содержится в файлах Config. Обычно это строки подключения, URL-адреса веб-сервисов и т.д., Что даст хорошее представление о внешних зависимостях.

Другой способ - использовать профилирование, трассировку и применение фильтров, мы можем легко отслеживать любые внешние вызовы. В большинстве случаев зависимость зависит от уровня базы данных, а проверка подключенных серверов и отслеживание их зависимостей может выявить много информации.

Я не уверен, есть ли какой-либо автоматический способ получить эту информацию, особенно если системы находятся на нескольких платформах. Для документирования будет задействовано много ручной работы.

Ответ 3

Это приложение, которое мы производим в Tideway Systems, и для этого используются многие крупные организации. Вы можете использовать этот продукт для поиска своего имущества и использовать возможности моделирования для описания ваших бизнес-приложений (которые обычно состоят из более чем одного программного обеспечения и серверов диапазона).

Похоже, вы имеете право использовать бесплатное Community Edition of Foundation, которое вы можете использовать на 30 серверах - просто download это и проверить. Тогда дайте нам знать, что вы думаете, пожалуйста!

Отказ от ответственности: я запускаю группу разработки Tideway. Продукт очень классный IMO, хотя я сам не написал его непосредственно:)

Ответ 4

Отключите каждую машину один за другим и посмотрите, какие перерывы..; p

Серьезно, однако, нет простого ответа на этот вопрос. С помощью набора систем вы можете создать диаграмму, показывающую основные зависимости, но она не имела бы большого значения, если бы у вас не было представления о том, что такое зависимость. Обычно ваша цель состоит в том, чтобы определить, что вам нужно "пересмотреть" при смене другой системы, а не на какие машины вы можете отключить наугад. Но такая информация требует большого количества деталей и с трудом накапливается в первую очередь.

Все это в конечном итоге заканчивается в ситуации, когда вы находитесь в системе перед автоматизацией. Вы никогда не найдете инструмент автоматизации с термоусадочной пленкой, который поддерживает работу. С другой стороны, с такой большой деталью необходимо что-нибудь, что может позаботиться о половине или даже одной трети рабочей нагрузки.

Ответ 5

Это хороший вопрос. Кажется, мы каждый раз с этим сталкиваемся с этим.

То, что мы пытались сделать за последний год или около того, будет "безжалостным" по двум причинам:

• автоматизация - если вы автоматизируете его и часто устанавливаете/развертываете, то процесс автоматизации, как правило, будет иметь смысл в большинстве случаев (настройки конфигурации и т.д.)

• wiki, wiki, wiki - мы стараемся быть жесткими в обновлении текущей версии команды и проекта wiki.

Любопытно видеть другие ответы.

Ответ 6

Звучит как работа для обнаружения предприятия, которая автоматизирована, насколько это возможно. В зависимости от размера вашей организации и окружающей среды существуют разные решения. Для больших ландшафтов вам понадобится CMDB (база данных управления конфигурациями). Такие продукты, как HP Universal CMDB могут обнаруживать и отслеживать зависимости в крупномасштабных средах.

например. он может обнаруживать отношения между системой SAP и связанными с ней базами данных и узлами, на которых работают распределенные системы, и показывает зависимости. Более важно, чтобы вы могли предупредить вас в случае, если какие-то несанкционированные изменения будут внесены в реальную среду.

Таким образом, ответ зависит от того, что вы считаете "большим".

Ответ 7

Два вида проблем:

a.) для тех, кто хочет знать, как определять зависимости для каждого компонента

b.) для тех, кто хочет отслеживать взаимозависимости и их приоритеты в системе компонентов. (как в, какой компонент сначала устанавливается в тестовую среду и т.д.)

Если у вас есть серия компонентов, для каждой из которых вы знаете зависимости, и вам нужен порядок зависимостей для всего списка компонентов, вы можете найти модуль Perl под названием Algorithm:: Dependency:: Ordered to be некоторой ценности. Существуют и другие связанные модули, которые могут работать с базами данных записей компонентов и т.д. Или даже с простыми файловыми записями. Но предупреждение: у меня были проблемы с тем, чтобы это работало.

В качестве альтернативы инструмент графического отображения может иметь значение.

Ответ 8

Это функция группы "Управление конфигурацией". Чтобы начать работу, вам нужно поговорить с "экспертами" в вашей компании и создать карту/график приложений. Используйте graphviz/dot для создания диаграммы, это будет не очень красиво, но это даст вам визуальное представление зависимостей.

Вот пример:

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

Надеюсь, что это поможет,

Ответ 9

Отображение системных зависимостей - это одно. Настоящие проблемы с окружающей средой, uid, пароли, настройки олицетворения, имена баз данных и другие данные, которые меняются от разработки до qa до uat, являются реальной проблемой.

Кто хранит/запоминает их все?

Разработчик не знает, на каком производственном сервере (ах) его приложение будет находиться. Он только документирует имя своей базы данных разработки, uid's, pwd и описывает его таблицы базы данных, строки привязки и т.д.

Как только он проверяется в репозитории кода и переносится в среду QA, кто хранитель данных, необходимых для обновления этих файлов конфигурации с соответствующими значениями?

Снова при переносе в QA и UAT, кто?

Кто несет ответственность за информирование следующей группы миграции о том, что необходимо изменить?

В моей компании это то, что вызывает у нас большую головную боль. К моменту, когда он будет одобрен внутренним процессом управления изменениями и будет создан запрос миграции для переноса приложения в производственную среду, все, что требуется, - это один параметр конфигурации, который нужно забыть, чтобы разрушить всю реализацию, и это происходит все время, потому что четкие линии ответственности не нарисованы (в моем случае).

Помимо ответственности, я думаю, это центральный репозиторий для этой информации.

т. Система, в которой хранятся все параметры конфигурации для всех проектов/приложений, и на основе вашей "роли" вы можете/не можете видеть фактические значения.

Разработчик заканчивает свою сборку и создает запрос на миграцию в "системе". Лицо QA получает уведомление, что сборка ### готова. Пользователь QA входит в "систему" ​​и получает инструкции по миграции. Теперь они четко знают, что нужно сделать, и они вызывают проверку кода и процесс миграции.

Повторите для UAT и, в конечном итоге, выполните

Когда кто-то строит эту систему миграции, дайте мне знать, потому что это поможет многим людям.

Может быть, я сам его построю... Кто хочет заключить контракт?

Ответ 10

Я был знаком с работой, и было предложено в качестве первой задачи, которую я хочу определить, системных зависимостей. Оказывается, то, что имел в виду мой босс, заключалось в том, чтобы поговорить с людьми - таким образом я узнал бы, кто есть кто. Я думал, что мой босс хотел, чтобы я написал компьютерную программу для этого. И так я и сделал. Мое предположение заключалось в том, что если программа была клиентом другой программы (службы или сервера), то netstat -pant и netstat -panu, тогда grep для ESTABLISHED даст вам это. Вы можете идентифицировать сервисы путем grepping вывода для LISTENING.

Это лишь частичное решение. Да, это говорит вам, какие приложения говорят с приложениями, но есть и другие зависимости. Так, например, некоторые приложения используют DNS для поиска своих серверов, а другие - жестко закодированные или в файлах конфигурации. Все, что использует TCP или UDP, зависит от IP. В большинстве мест IP зависит от ARP и Ethernet или WiFi. Все, что зависит от службы в другой локальной сети, зависит от хотя бы одного маршрутизатора.

Если у вас есть балансировщик нагрузки или какой-то кластер, проблема становится более интересной. Если я предоставляю услугу, которая выходит из балансировщика нагрузки, и "реальный" сервер за брандмауэром идет вниз, тогда служба деградирует, но все еще работает.

Это становится еще интереснее, потому что службы (программы) зависят от серверов (аппаратных). Серверы, в свою очередь, зависят от мощности и кондиционирования воздуха.

Итак, когда мое мышление вышло из-под контроля, все стало намного сложнее, и я подумал о создании языка, специфичного для домена (DSL), чтобы захватить все эти зависимости. Я думал, что, например, server_1, server_3 и server_5 находятся в фазе питания 1; server_2, server_4 и server_6 находятся на этапе питания 2. Сервер_1, Server_3 и server_5 все сбой примерно в одно и то же время: возможно, фаза 1 завершилась неудачей. Я все еще не совсем понял это. Очевидно, что ситуацию можно представить ориентированным графом, я просто не разработал детали.