HPE Zerto встроила многоагентную диагностику в локальный контур disaster recovery

AI-помощник стал частью самого Zerto

HPE Zerto и AWS описали agentic troubleshooting system для инфраструктуры disaster recovery. Она встроена в привычный интерфейс управления и разворачивается как pod внутри локального окружения клиента. Пользователь задаёт вопрос естественным языком, а система сопоставляет его с текущим состоянием защиты, событиями, документацией и доступными действиями.

Задача системы шире поиска по руководству. Она должна помогать разбирать конфигурационные проблемы без немедленного обращения в поддержку, предупреждать о нарушениях здоровья системы и сопровождать mitigation, а в некоторых сценариях — выполнять задачи ради ускорения настройки и освоения функций. При этом официальная публикация не перечисляет полный каталог разрешённых изменений и не говорит, что агент самостоятельно принимает решения о восстановлении после аварии.

Для оператора важна не только финальная формулировка. Интерфейс передаёт ход расследования через Server-Sent Events, поэтому промежуточный прогресс виден в реальном времени. Это уменьшает период, когда сложная диагностика выглядит как зависший чат, но не заменяет проверку результата по данным самой системы восстановления.

Локальный runtime отделён от облачного inference

Agentic layer построен на Strands Agents и работает on-premises внутри ZVM appliance. История сессии хранится локально. Внутренний MCP server оборачивает ZVM API и даёт агентам структурированный доступ к живым данным окружения, а Amazon Bedrock Knowledge Bases используется для получения публичной документации, runbooks и операционных знаний.

Внешняя граница проведена явно: runtime агента остаётся в инфраструктуре клиента, а запросы к foundation model и knowledge base уходят в AWS по HTTPS. Для inference используются Amazon Bedrock и выбранная модель; теги IAM role разделяют запросы арендаторов. До и после inference применяются Amazon Bedrock Guardrails, а CloudWatch, DynamoDB и Lambda обеспечивают лимиты и квоты.

Такая схема не равна полностью автономной air-gapped установке модели. Локальными остаются orchestration, история и доступ к продуктовым API, однако inference требует внешнего соединения. Поэтому при оценке deployment важны точный состав передаваемого контекста, правила редактирования секретов, поведение при потере связи и договорные требования к данным — краткое архитектурное описание не раскрывает эти параметры для каждого клиента.

Оркестратор не разрешает агентам говорить друг с другом напрямую

Центральный Orchestrator отвечает на обычные вопросы сам, а тяжёлые расследования делегирует специализированным sub-agents. ZVM agent разбирает сбои сервисов, сеть и неудачные обновления. VRA agent сосредоточен на проблемах репликации, задержках, связи между площадками и установке Zerto Replication Engine.

Каждый sub-agent получает свежий контекст, отдельный system prompt, собственные инструменты и более сильную модель для reasoning-heavy работы. Назад он возвращает компактный отчёт, а не сырые логи и черновой ход рассуждений. Оркестратор удаляет секреты и лишние журналы перед показом окончательного ответа пользователю.

Связи организованы как hub-and-spoke: sub-agent, обнаруживший проблему другой специализации, сообщает об этом родителю, а не вызывает соседа. HPE объясняет выбор единым местом применения safety rules, линейной трассировкой и защитой от бесконтрольной agent-to-agent recursion, способной исчерпать token budget. Это одновременно упрощает аудит и делает центральный Orchestrator критической точкой качества маршрутизации.

Evaluation проверяет ответ, траекторию, задержку и токены

Команда сначала оценивала крупные модели ради проверки осуществимости, затем сравнивала более быстрые и дешёвые варианты и в итоге выбрала multi-model architecture. Конкретные модели и численные результаты их сравнения AWS не публикует, поэтому из кейса нельзя вывести универсального победителя по цене или качеству.

Regression suite построен на PyTest и Strands Agents Evals SDK. Basic query evaluation проверяет одиночный запрос и ответ; multi-turn evaluation разворачивает разговор с user simulator на базе ActorSimulators; dynamic tests создаются Experiment Generator по заданным критериям, чтобы покрывать заранее не перечисленные сценарии.

Каждый динамический тест оценивается по четырём направлениям: качество ответа, выбор инструментов и траектория, latency и token usage. Это важное разделение: убедительный текст ещё не доказывает, что агент использовал правильный источник или не совершил лишнее действие. Однако публикация не приводит размер тестового набора, пороги прохождения, долю ошибок и независимую проверку этих evaluator-моделей.

Первые production-метрики относятся только к поддерживаемым сценариям

Система выпущена во втором квартале 2026 года. По данным HPE Zerto, её уже приняли и активно используют более 20% клиентов, а количество обращений в поддержку по workflow, поддерживаемым агентской системой, снизилось на 10%. Эти цифры поступают от разработчиков продукта и не сопровождаются абсолютным числом клиентов, периодом сравнения или контрольной группой.

Внутри HPE инженеры также используют troubleshooting capabilities для типовых проблем, а QA automation team подключила систему к расследованию дефектов, найденных во время тестирования. Это показывает переносимость контура между customer self-service и внутренним анализом, но официальный материал не публикует отдельные показатели точности root-cause identification или времени восстановления.

Главный инженерный результат кейса — не обещание безошибочного автономного восстановления, а проверяемое разбиение системы на границы. Локальный MCP даёт типизированный доступ к состоянию продукта, узкие агенты ограничивают контекст, центральный Orchestrator контролирует делегирование, а evaluation измеряет не только текст. Для промышленного применения остаётся проверить собственные аварийные сценарии, полномочия инструментов, отказоустойчивость внешнего inference и качество решений на редких инцидентах.