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

Question

Введение

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

Мой вопрос

Какой самый лучший способ отследить, как одна целая система зависит от другой?

_{В ответе может быть предложен либо способ выполнения вышеизложенного, либо пакет программного обеспечения, либо методы документирования.}

_{В моем конкретном случае Многие означают более 20 веб-приложений и приложений для настольных компьютеров на более чем дюжине серверов.}

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

Вот пример:

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

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

Answer 7

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

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

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

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

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

Answer 8

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

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

Таким образом, ответ зависит от того, что вы считаете «многими».

Answer 9

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

Это только частичное решение. Да, он говорит вам, какие приложения говорят с какими приложениями, но есть и другие зависимости. Так, например, некоторые приложения используют 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 завершилась неудачно. Я до сих пор не совсем понял это. Очевидно, что ситуацию можно представить ориентированным графом, я просто не проработал детали.

Answer 10

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

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

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

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

Опять при миграции на QA и UAT, кто?

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

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

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

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

Разработчик заканчивает сборку и создает запрос на миграцию в «системе». Сотрудник QA получает уведомление о том, что сборка ### готова. Сотрудник QA входит в систему и получает инструкции по миграции. Теперь они четко знают, что нужно сделать, и запускают процесс проверки кода и миграции.

Повторите для UAT и в конечном итоге Prod.

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

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