AWS обновила Resilience Hub: модульные политики, автоматическое обнаружение зависимостей и генеративный AI для анализа

AWS выпустила новую версию Resilience Hub с моделью приложений на бизнес‑уровне, модульными политиками устойчивости, автоматическим картированием зависимостей через анализ DNS‑логов и генеративным AI для оценки режимов отказа.

AWS представила следующее поколение Resilience Hub, объединив в одном продукте модель приложений, модульные политики устойчивости, автоматическое обнаружение зависимостей через анализ DNS‑логов, генеративный AI‑анализ режимов отказа и сквозную отчётность на уровне организации. Это значимое обновление для команд SRE, потому что обещает стандартизировать оценку резилентности и упростить управление сотнями приложений, снижая риск неожиданных сбоев. Модель приложений пересмотрена в сторону бизнес‑уровня: системы теперь описываются через критические пользовательские пути, связанные с бизнес‑результатами. «Сервисы» в новой модели — это развертываемые единицы, которые включают ресурсы AWS, код и средства наблюдаемости. Resilience Hub автоматически обнаруживает эти компоненты и строит топологию приложения, показывая связи между ресурсами и точки потенциальной уязвимости.

Политики устойчивости перестают быть монолитными: их можно конструировать из модульных требований — SLO, multi‑AZ и multi‑Region DR, требования к восстановлению данных и других блоков — и переиспользовать в разных приложениях. Такой подход позволяет, например, создать шаблон для финансовых приложений с конкретными SLO и целями восстановления, применяемый к множеству сервисов. в результате система выявляет потенциальные режимы отказа и предлагает конкретные рекомендации по смягчению. Отдельно доступна автоматическая оценка зависимостей: анализ DNS‑логов позволяет обнаруживать как используемые AWS‑сервисы, так и внутренние и сторонние конечные точки, включая неожиданные межрегиональные вызовы и критичных третьих‑сторонних поставщиков. Это помогает выявлять скрытые зависимости, которые часто остаются незамеченными при ручной инвентаризации и повышают риск каскадных сбоев.

Для начала работы нужно создать политику в консоли Resilience Hub, настроить первую систему и сервис, запустить оценку режимов отказа и внедрить найденные улучшения. Перед этим требуется настроить IAM invoker role с правами чтения ресурсов; при отсутствии AWS Organizations понадобятся кросс‑аккаунтные роли, либо можно использовать service‑linked roles (SLR) при интеграции с AWS Organizations. Интеграция с AWS Organizations даёт возможность делегированному администратору управлять оценками устойчивости по всем аккаунтам без входа в каждый из них — подробности приведены в User Guide. В целом обновление даёт инженерным командам единую платформу для согласования ожиданий по резилентности, измерения прогресса и документирования соответствия через тестирование, что упрощает масштабирование практик устойчивости на уровне предприятия.