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

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

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

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

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

похоже, вы имеете право использовать бесплатную версию сообщества Foundation, которую вы можете использовать на серверах до 30-просто скачать его и проверить его. Тогда дайте нам знать, что вы думаете, пожалуйста!

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

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

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

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

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

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

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

2. wiki, wiki, wiki -- мы стараемся быть жесткими в сохранении команды и проекта wiki современный.

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

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

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

поэтому ответ зависит от того, что вы считаете "много".

два вида проблем, связанных:

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

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

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

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

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

вот пример:

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

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

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

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

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

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

снова при миграции в QA и UAT, кто?

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

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

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

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

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

повторите для UAT и в конечном счете prod.

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

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

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

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

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

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

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