«Диагностика базы данных сократилась с 45 минут до 10»: Cornerstone OnDemand собрала мультиагентную Orion AI на Amazon Bedrock силами трёх человек за полгода

Задача: превратить борьбу с пожарами в автоматизацию

Cornerstone OnDemand — глобальный поставщик решений для готовности персонала, обслуживающий 140 млн пользователей в 186 странах. Его команда Enterprise DataOps работала реактивно и упиралась в четыре повторяющиеся проблемы: расследование производительности базы занимало около 45 минут на инцидент и было размазано по нескольким инструментам и системным представлениям; процессы жизненного цикла базы требовали 10 и более ручных шагов — от установки соединений до рассылки обновлений статуса; отчётность между командой SRE и командой данных шла с задержкой в 15 минут; а избыточные и дублирующиеся алерты создавали шум, в котором тонули действительно важные сигналы.

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

Orion AI: мета-оркестратор и специализированные агенты

Orion AI — мультиагентная система, в которой координирующий агент-мета-оркестратор делегирует работу специализированным дочерним агентам, выстроенным по топологии «хаб и спицы». Инженеры работают с ней через веб-приложение, задавая вопросы и подтверждая действия там же, где и раньше координировали операционную работу, а сами агенты покрывают мониторинг инфраструктуры, диагностику баз данных, операции жизненного цикла баз, клиентскую аналитику и поддержку на основе базы знаний.

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

Измеримые результаты

Диагностика базы данных ускорилась с 45 до 10 минут — на 78%; это крупнейший единичный выигрыш в эффективности у Orion AI на сегодня. Число ручных шагов жизненного цикла сократилось с более чем 10 до одного взаимодействия — на 70%. Задержка отчётности между SRE и командой данных в 15 минут исчезла, уступив место непрерывной кросс-системной видимости в реальном времени. Избыточные алерты уменьшились на 65% по медиане за счёт дедупликации, фильтрации по порогам и кросс-сигнальной корреляции: на каждые 10 прежних алертов до инженеров доходят лишь 3–4, и они адресуются напрямую ответственным командам без промежуточного слоя.

Раньше, чтобы разобрать инцидент, инженеры вручную подключались к пострадавшему экземпляру SQL Server, запрашивали системные представления по цепочкам блокировок и типам ожиданий, сверяли логи, чтобы выделить долго выполняющиеся запросы, и сопоставляли свидетельства в гипотезу о первопричине. Теперь расследование делят три специализированных агента, каждый отвечает за свой этап, а Orion AI ведёт задачу дальше диагностики — до исправления: определяет первопричину, рекомендует решение и создаёт заполненный тикет Jira, назначенный нужному дежурному инженеру. Ручная передача из четырёх шагов сворачивается в одно взаимодействие.

Как это устроено внутри

В основе — несколько примитивов Strands Agents: класс Agent служит строительным блоком и для специалистов, и для мета-оркестратора, инструменты агента — обычные функции Python с декоратором @tool, а BedrockModel оборачивает модель, на которой работает агент. Хабом выступает единственный агент-мета-оркестратор (TaskExecutor), у которого нет доменных инструментов — только маршрутизация (find_relevant_agents, call_agent) и управление потоком (emit_plan_step, emit_confirmation_gate), чтобы он мог рассуждать о запросе шаг за шагом. Спицы — независимые экземпляры Agent, лениво подгружаемые через реестр на декораторах; каждый несёт собственную модель, доменные инструменты и локализованный системный промпт.

Маршрутизация гибридная: около 80% запросов разрешаются через быстрый путь по ключевым словам в памяти менее чем за миллисекунду, а когда ключевых слов не хватает для определения намерения, система откатывается на семантический поиск на базе Amazon Titan Text Embeddings V2. Когда прямая отмена инструмента неуместна, включается цепочка отката на Amazon Bedrock Knowledge Bases — управляемую возможность Retrieval Augmented Generation, которая подтягивает операционную документацию, чтобы ответы опирались на утверждённые процедуры. Всего система использует 13 доменных агентов; три агента по SQL Server показывают, как разделение по домену совпадает со стадиями реального расследования: диагностика (цепочки блокировок, типы ожиданий, долгие запросы и их перевод в бизнес-эффект), анализ блокировок сессий (многошаговое расследование до корневого блокиратора) и диагностика SQL в реальном времени (живые данные о блокировках и сессиях с высокой загрузкой CPU).

Доступ к данным организован двумя способами: Model Context Protocol для инструментов, разделяемых несколькими агентами (например, диагностика SQL в реальном времени через сервер Portal-Tools MCP), и прямые вызовы SDK или REST API для источников без общей MCP-обвязки. Соединения идут по TLS, а учётные данные — токен MCP и авторизация REST API — передаются по запросу, а не встраиваются в код агентов.

Память обеспечивает Amazon Bedrock AgentCore: центральный менеджер читает три уровня параллельно, у каждого свой таймаут и бюджет токенов. Краткосрочная память держит контекст сессии в Amazon DynamoDB со скользящим резюме диалога, которое асинхронно формирует Amazon Nova 2 Lite; долгосрочная даёт кросс-сессионное вспоминание с пространством имён по идентификатору пользователя; третий уровень — эфемерный меж-агентный блокнот, переносящий находки между шагами под-агентов. Менеджер укладывается в жёсткий таймаут 500 миллисекунд при бюджете в 4000 токенов и кэше с вытеснением по давности.

Ограничения, наблюдаемость и переиспользуемые решения

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

Наблюдаемость построена на штатных сервисах AWS: Amazon CloudWatch даёт метрики и структурированные логи по уверенности маршрутизации, задержкам и вызовам агентов, а AWS X-Ray трассирует распределённые вызовы сквозь исполнения агентов. Вычислительный слой развёрнут на Amazon Elastic Container Service: на старте проекта рантайм Amazon Bedrock AgentCore был недоступен, и команда считает прагматичным решением начать с того, что стабильно и доступно сейчас, вернувшись к вопросу по мере взросления управляемых возможностей.

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