Введение
В моей нынешней организации у нас есть много настольных и веб-приложений, которые в какой-то момент подпитываются друг в друга. Рассматривая старые приложения или создавая новые приложения, очень сложно попытаться запомнить, какая система использует другие системы для работы. Я не говорю о зависимостях программного обеспечения, таких как DLL и изображения, я говорю о целых системах, таких как финансовая система, зависящая от системы управления персоналом и т.д.
Мой вопрос
Каков наилучший способ отслеживать, как одна целая система зависит от другой?
Ответ может предложить либо метод выполнения вышеизложенного, либо программный пакет, либо методы документации.
В моем конкретном случае Many означает более 20 веб-приложений и настольных приложений на десятках серверов.
Я бы сказал, чтобы четко указать, что в вашем архитектурном документе. Для этого есть хорошие инструменты, например Enterprise Architect. Этот инструмент позволяет вам создавать диаграммы с использованием стандарта UML для четкого и визуального описания этих зависимостей.
Лучший источник информации обычно содержится в файлах Config. Обычно это строки подключения, URL-адреса веб-сервисов и т.д., Что даст хорошее представление о внешних зависимостях.
Другой способ - использовать профилирование, трассировку и применение фильтров, мы можем легко отслеживать любые внешние вызовы. В большинстве случаев зависимость зависит от уровня базы данных, а проверка подключенных серверов и отслеживание их зависимостей может выявить много информации.
Я не уверен, есть ли какой-либо автоматический способ получить эту информацию, особенно если системы находятся на нескольких платформах. Для документирования будет задействовано много ручной работы.
Это приложение, которое мы производим в Tideway Systems, и для этого используются многие крупные организации. Вы можете использовать этот продукт для поиска своего имущества и использовать возможности моделирования для описания ваших бизнес-приложений (которые обычно состоят из более чем одного программного обеспечения и серверов диапазона).
Похоже, вы имеете право использовать бесплатное Community Edition of Foundation, которое вы можете использовать на 30 серверах - просто download это и проверить. Тогда дайте нам знать, что вы думаете, пожалуйста!
Отказ от ответственности: я запускаю группу разработки Tideway. Продукт очень классный IMO, хотя я сам не написал его непосредственно:)
Отключите каждую машину один за другим и посмотрите, какие перерывы..; p
Серьезно, однако, нет простого ответа на этот вопрос. С помощью набора систем вы можете создать диаграмму, показывающую основные зависимости, но она не имела бы большого значения, если бы у вас не было представления о том, что такое зависимость. Обычно ваша цель состоит в том, чтобы определить, что вам нужно "пересмотреть" при смене другой системы, а не на какие машины вы можете отключить наугад. Но такая информация требует большого количества деталей и с трудом накапливается в первую очередь.
Все это в конечном итоге заканчивается в ситуации, когда вы находитесь в системе перед автоматизацией. Вы никогда не найдете инструмент автоматизации с термоусадочной пленкой, который поддерживает работу. С другой стороны, с такой большой деталью необходимо что-нибудь, что может позаботиться о половине или даже одной трети рабочей нагрузки.
Это хороший вопрос. Кажется, мы каждый раз с этим сталкиваемся с этим.
То, что мы пытались сделать за последний год или около того, будет "безжалостным" по двум причинам:
автоматизация - если вы автоматизируете его и часто устанавливаете/развертываете, то процесс автоматизации, как правило, будет иметь смысл в большинстве случаев (настройки конфигурации и т.д.)
wiki, wiki, wiki - мы стараемся быть жесткими в обновлении текущей версии команды и проекта wiki.
Любопытно видеть другие ответы.
Звучит как работа для обнаружения предприятия, которая автоматизирована, насколько это возможно. В зависимости от размера вашей организации и окружающей среды существуют разные решения. Для больших ландшафтов вам понадобится CMDB (база данных управления конфигурациями). Такие продукты, как HP Universal CMDB могут обнаруживать и отслеживать зависимости в крупномасштабных средах.
например. он может обнаруживать отношения между системой SAP и связанными с ней базами данных и узлами, на которых работают распределенные системы, и показывает зависимости. Более важно, чтобы вы могли предупредить вас в случае, если какие-то несанкционированные изменения будут внесены в реальную среду.
Таким образом, ответ зависит от того, что вы считаете "большим".
Два вида проблем:
a.) для тех, кто хочет знать, как определять зависимости для каждого компонента
b.) для тех, кто хочет отслеживать взаимозависимости и их приоритеты в системе компонентов. (как в, какой компонент сначала устанавливается в тестовую среду и т.д.)
Если у вас есть серия компонентов, для каждой из которых вы знаете зависимости, и вам нужен порядок зависимостей для всего списка компонентов, вы можете найти модуль Perl под названием Algorithm:: Dependency:: Ordered to be некоторой ценности. Существуют и другие связанные модули, которые могут работать с базами данных записей компонентов и т.д. Или даже с простыми файловыми записями. Но предупреждение: у меня были проблемы с тем, чтобы это работало.
В качестве альтернативы инструмент графического отображения может иметь значение.
Это функция группы "Управление конфигурацией". Чтобы начать работу, вам нужно поговорить с "экспертами" в вашей компании и создать карту/график приложений. Используйте graphviz/dot для создания диаграммы, это будет не очень красиво, но это даст вам визуальное представление зависимостей.
Вот пример:
digraph g {
rankdir=LR;
app1->app2->db1;
app1->app3;
}
Надеюсь, что это поможет,
Отображение системных зависимостей - это одно. Настоящие проблемы с окружающей средой, uid, пароли, настройки олицетворения, имена баз данных и другие данные, которые меняются от разработки до qa до uat, являются реальной проблемой.
Кто хранит/запоминает их все?
Разработчик не знает, на каком производственном сервере (ах) его приложение будет находиться. Он только документирует имя своей базы данных разработки, uid's, pwd и описывает его таблицы базы данных, строки привязки и т.д.
Как только он проверяется в репозитории кода и переносится в среду QA, кто хранитель данных, необходимых для обновления этих файлов конфигурации с соответствующими значениями?
Снова при переносе в QA и UAT, кто?
Кто несет ответственность за информирование следующей группы миграции о том, что необходимо изменить?
В моей компании это то, что вызывает у нас большую головную боль. К моменту, когда он будет одобрен внутренним процессом управления изменениями и будет создан запрос миграции для переноса приложения в производственную среду, все, что требуется, - это один параметр конфигурации, который нужно забыть, чтобы разрушить всю реализацию, и это происходит все время, потому что четкие линии ответственности не нарисованы (в моем случае).
Помимо ответственности, я думаю, это центральный репозиторий для этой информации.
т. Система, в которой хранятся все параметры конфигурации для всех проектов/приложений, и на основе вашей "роли" вы можете/не можете видеть фактические значения.
Разработчик заканчивает свою сборку и создает запрос на миграцию в "системе". Лицо QA получает уведомление, что сборка ### готова. Пользователь QA входит в "систему" и получает инструкции по миграции. Теперь они четко знают, что нужно сделать, и они вызывают проверку кода и процесс миграции.
Повторите для UAT и, в конечном итоге, выполните
Когда кто-то строит эту систему миграции, дайте мне знать, потому что это поможет многим людям.
Может быть, я сам его построю... Кто хочет заключить контракт?
Я был знаком с работой, и было предложено в качестве первой задачи, которую я хочу определить, системных зависимостей. Оказывается, то, что имел в виду мой босс, заключалось в том, чтобы поговорить с людьми - таким образом я узнал бы, кто есть кто. Я думал, что мой босс хотел, чтобы я написал компьютерную программу для этого. И так я и сделал.
Мое предположение заключалось в том, что если программа была клиентом другой программы (службы или сервера), то 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 завершилась неудачей. Я все еще не совсем понял это. Очевидно, что ситуацию можно представить ориентированным графом, я просто не разработал детали.