Карта зависимостей сервисов

Что это за сервис

Каталог сервисов с картой зависимостей для дежурных, платформенной команды и архитекторов. У каждого сервиса есть владелец, уровень критичности и список тех, от кого он зависит и кто зависит от него. По карте видно, что ещё пострадает, если сервис деградирует.

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

Что он делает

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

Нюансы и особенности

Готовые каталоги есть. Backstage, OpsLevel, Cortex и карты сервисов в Datadog или Grafana решают ту же задачу и умеют строить граф по трассировкам. Если компания уже ведёт каталог в одном из них, отдельная карта не нужна. Приложение на Filament оправдано, когда сервисов десятки, а не сотни, нужен простой каталог с владельцами рядом с другими внутренними инструментами и нет ресурса поддерживать Backstage.
Ручная карта устаревает. Зависимости подтягивают из данных трассировки, конфигураций шлюза или реестра сервисов. Ручной ввод допустим для внешних систем, но с датой последней проверки.
Уровень критичности обязателен. Сервис без уровня нельзя сохранить; плоский список без уровней не отвечает на вопрос, что чинить первым.
Без владельца — черновик. Сервис без владельца остаётся в статусе черновика и попадает в еженедельную сводку; повысить его уровень до назначения владельца нельзя.
Циклы ищут явно. Циклические зависимости не видны на глаз в большом графе. Фоновая проверка ищет циклы и выводит их списком предупреждений.
Каскадные предупреждения — ваше правило. Когда критичный сервис деградирует, зависимые получают значок предупреждения. Логика каскада — понятный запрос, который команда может прочитать и изменить.
Выведенные из эксплуатации сервисы не удаляют. Их переводят в архив, чтобы история инцидентов и зависимости прошлых периодов оставались понятными.

Как сгенерировать через ИИ-агентов

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат перед следующим шагом.

1. Данные и модели

Создай модели и миграции для каталога сервисов: Team (название,
ротация дежурства), Service (название, команда-владелец, уровень
критичности 1–3, статус: черновик, активен, в архиве; текущее состояние,
источник данных, дата последней синхронизации), Dependency (сервис,
от которого зависят, зависимый сервис, тип связи, источник, дата
последнего подтверждения). Пара сервисов в зависимости уникальна.
Добавь фабрики с реалистичным графом.

2. Каталог и карточка сервиса

Сгенерируй Filament-ресурс для Service. В таблице покажи уровень,
команду, статус, число входящих и исходящих зависимостей и дату
синхронизации; фильтры по уровню, команде и «Без владельца». В карточке
выведи обе стороны зависимостей через relation managers. Уровень
обязателен, без команды сервис сохраняется только как черновик.

3. Радиус поражения и циклы

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

Проверьте радиус поражения на демо-графе с циклом: обход должен завершиться и не повторять сервисы.

4. Синхронизация

Сделай синхронизацию по расписанию из реестра сервисов или API-шлюза
через HTTP API: новые сервисы создаются черновиками, связи обновляют
дату подтверждения, исчезнувшие связи помечаются к проверке, а не
удаляются. Когда критичный сервис переходит в состояние «деградация»,
помечай все зависимые сервисы предупреждением.

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

5. Роли и сводка

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