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

https://stackoverflow.com/questions/153445

03-07-2019
|

Вопрос

Введение

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

Мой Вопрос

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

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

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

Решение

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связанные с этим проблемы двух видов:

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

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

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

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

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

Вот такой пример:

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

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

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

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

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

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

Опять же, при переходе на QA и UAT, кто?

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

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

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

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

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

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

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

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

Я был новичком в этой работе, и в качестве первой задачи мне было предложено определить системные зависимости.Оказывается, мой босс имел в виду пойти поговорить с людьми - так я узнал бы, кто есть кто.Я думал, мой босс хотел, чтобы я написал компьютерную программу для этого.Так я и сделал.Мое предположение состояло в том, что если программа является клиентом другой программы (службы или сервера), то netstat -pant и netstat -panu тогда grep для УСТАНОВЛЕННЫХ дал бы вам это.Вы можете идентифицировать службы, выбрав выходные данные для ПРОСЛУШИВАНИЯ.

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow