В мае 2026 года компания Cleric опубликовала отчет
The State of AI SRE. Отчет объясняет, почему современная эксплуатация требует AI SRE, разбирает подходы к внедрению AI SRE и сравнивает специализированные агентные платформы. В начале отчета авторы отмечают, что интерес к AI SRE быстро растет, при этом руководители задают одни и те же вопросы: стоит ли строить AI SRE платформу самостоятельно или выбрать SaaS решение, когда выбирать AI SRE от вендоров платформ управления инцидентами и как сравнивать и выбирать новые решения от AI SRE стартапов.
В отчете отмечены четыре фактора роста сложности эксплуатации:
- Распределенные системы (Distributed systems). Десятки и сотни слабосвязанных сервисов с отстающей документацией превращают отладку в анализ сложных взаимодействий между зависимостями в условиях неполной информации;
- Рост числа инструментов (Explosion in tooling). Разрозненные инструменты наблюдаемости и инфраструктуры заставляют инженеров постоянно переключать контекст и восстанавливать состояние системы из множества несвязанных источников;
- Агентная разработка (Agentic engineering). AI-инструменты кратно увеличивают объем изменений в Production, а расследование и проверка этих изменений по-прежнему ограничены возможностями людей;
- Непрерывные развертывания в нескольких окружениях (Continuous deployments across multiple environments). Постоянный поток изменений в несколько окружений заставляет инженеров при сбое сопоставлять симптомы с множеством недавних деплоев и изменений конфигурации.
В отчете AI SRE определяют как агентную систему, которая автоматизирует работу по эксплуатации: межсистемное расследование, диагностику и устранение проблем. Большинство решений AI SRE фокусируется на цикле обнаружение, диагностика, устранение (Detect, Diagnose, Remediate). В зависимости от архитектуры AI SRE платформа может:
- проводить триаж и группировать алерты в связное описание инцидента;
- коррелировать телеметрию из разных платформ наблюдаемости;
- запрашивать данные из инфраструктуры, CI/CD и репозиториев кода;
- определять вероятные первопричины с подтверждающими данными;
- рекомендовать шаги по устранению на основе состояния системы;
- выполнять заранее одобренные действия в заданных рамках;
- сохранять институциональную память по инцидентам и расследованиям.
В отчете выделяют три категории AI SRE платформ и отдельно рассматривают собственную разработку платформы.
Платформы управления инцидентами (Incident management platforms):- Сильная сторона: снижают накладные расходы на координацию во время инцидентов;
- Слабая сторона: возможности расследования вторичны по отношению к жизненному циклу инцидента;
- Лучше всего подходят командам, которые улучшают координацию и документирование реагирования на инциденты.
Такие платформы объявляют инциденты, привлекают ответственных, управляют каналами инцидентов, отслеживают статус и фиксируют хронологию. AI-возможности встраиваются поверх этого процесса. Например, Incident.io внедрила AI SRE, который проверяет недавние деплои и изменения кода и предлагает возможные первопричины. Подход особенно ценен, если алерты порождают хаотичные Slack треды, владение сервисами не определено, участники подключаются к инциденту без контекста, а хронологию и постмортемы восстанавливают постфактум.
Платформы наблюдаемости (Observability platforms):- Сильная сторона: мощный анализ логов, метрик и трейсов, уже собранных платформой;
- Слабая сторона: расследование ограничено телеметрией, которую получает платформа;
- Лучше всего подходят командам, чья операционная нагрузка сосредоточена вокруг одной системы наблюдаемости.
Datadog, Dynatrace, New Relic, Elastic и Grafana добавляют агентные возможности, например Bits AI SRE в Datadog. Агент выявляет аномалии, коррелирует сигналы между сервисами, суммирует алерты и находит возможные первопричины. Значительная часть контекста расследования находится за пределами телеметрии, а в крупных организациях сама телеметрия распределена между несколькими платформами (Datadog, Splunk, CloudWatch, Grafana). В таких условиях агент формирует гипотезы по неполной картине и в худшем случае вводит инженеров в заблуждение.
Агентные платформы AI SRE (Agentic AI SRE platforms):- Сильная сторона: расследуют проблемы с использованием множества систем и сигналов;
- Слабая сторона: требуют более глубокой интеграции в Production окружение;
- Лучше всего подходят командам, которые тратят значительное время на расследование проблем.
Cleric, Resolve и Traversal подключаются к тем же инструментам, которыми пользуются инженеры: платформам наблюдаемости, системам развертывания, инфраструктурным инструментам, системам контроля версий и истории инцидентов. Агент формирует гипотезы и собирает доказательства, напрямую запрашивая эти инструменты. Многие такие системы ведут постоянную операционную память и накапливают знания о поведении системы, типах отказов и способах их устранения. Для команд с небольшим числом операционных проблем эффект будет ограниченным.
Собственная разработка AI SRE платформы:- Сильная сторона: максимальная гибкость и контроль над процессом расследования;
- Слабая сторона: агент расследования является лишь одним компонентом рабочей системы, измерение, обучение и понимание окружения требуют глубоких и постоянных инвестиций;
- Лучше всего подходит командам с простыми окружениями, где базовый агент расследования приносит достаточную ценность.
Proof of concept на базе Claude Code или Cursor можно собрать за несколько дней, и для простых проблем он работает хорошо. Основная сложность в том, что агент расследования сам по себе является системой с разомкнутым контуром (Open-loop). В генерации кода есть тесты, в беспилотных автомобилях есть показатель пробега между вмешательствами водителя, а в эксплуатации такого эквивалента нет. Без механизма обратной связи систему нельзя систематически улучшать, ей нельзя доверять и нельзя позволить ей действовать.
Система с замкнутым контуром (Closed-loop) требует пяти возможностей помимо самого агента:
- Измерение и верификация (Measurement and verification). Ground truth в Production редок и запаздывает, поэтому система должна триангулировать множество зашумленных сигналов: повторился ли алерт после исправления, стабилизировались ли нижестоящие сервисы, предпринял ли инженер совсем другое действие;
- Оценка уверенности (Confidence scoring). Точность разбивается по типам проблем. Например, агент прав в 90% случаев для проблем, связанных с деплоями, и только в 50% для сетевых проблем. Это позволяет решать первую категорию с меньшим контролем и эскалировать вторую;
- Операционная память и обучение (Operational memory and learning). Система фиксирует исправления инженеров, удачные подходы к расследованию и операционные предпочтения команды, например «мы всегда откатываем деплой перед отладкой»;
- Понимание окружения (Environment understanding). Топология, конфигурация, базовые значения и организационный контекст постоянно меняются. Например, сервис платежей работает под высокой нагрузкой по пятницам, а задержка движка рекомендаций ожидаемо удваивается во время A/B-тестов;
- Обучение между окружениями (Cross-environment learning). Исчерпание пула подключений выглядит по-разному на PostgreSQL в Kubernetes и на Aurora с PgBouncer, при этом структурный паттерн переносится. Выделить такие паттерны внутренняя команда не сможет из-за недостаточного масштаба.
Эти компоненты образуют маховик (Flywheel): обучение улучшает расследования, измерение доказывает улучшение, оценка уверенности определяет области для действий с меньшим контролем, а каждое расследование генерирует новые данные. Авторы отмечают, что базовый агент расследования является проектом на выходные, а системы измерения, обучения и верификации требуют многолетних платформенных инвестиций. Без них агент выходит на плато, повторяет одни и те же ошибки, теряет доверие инженеров и превращается в неиспользуемый инструмент (Shelfware).
Перед стартом разработки авторы рекомендуют ответить на вопросы:
- Сможете ли вы через 100 расследований определить, какие типы проблем система решает хорошо и какие плохо?
- Учится ли система на исправлениях или каждый раз начинает с нуля?
- Сможете ли вы показать CTO или VP of Engineering, что система реально сокращает время инженеров?
- Кто будет создавать и поддерживать инфраструктуру оценки, чтобы понимать, улучшается система или деградирует?
- Готовы ли вы поддерживать ее как внутреннюю платформу в долгосрочной перспективе?
Сравнение агентных платформ AI SREАвторы сравнивают AI SRE платформы (
Cleric,
Resolve и
Traversal) по семи критериям:
- Базовый подход (Core approach). Каким способом платформа решает задачу понимания происходящего в Production окружении;
- Фокус (What it focuses on). Какой класс проблем платформа решает в первую очередь: ежедневные расследования, рутинные операционные реакции или редкие сложные инциденты;
- Модель автономии (Autonomy model). Где и при каких условиях платформа действует самостоятельно и где передает решение инженеру;
- Обучение (How it learns). Как платформа накапливает знания об окружении и использует их в следующих расследованиях;
- Верификация и обратная связь (Verification and feedback loop). Есть ли у платформы механизм измерения корректности собственных диагнозов, то есть работает ли она с замкнутым или разомкнутым контуром;
- Модель интеграций (Integration surface). С какими системами платформа взаимодействует: наблюдаемость, инфраструктура, код, мессенджеры, история инцидентов;
- Модель развертывания (Deployment model). Изучает ли платформа окружение самостоятельно на уровне продукта или ее настраивают Solutions Engineers под каждого клиента.
Авторы дают следующие рекомендации по выбору:
- Cleric подходит, если инженеры тратят значительное время на расследование проблем эксплуатации (отладка регрессий, поиск причин неожиданного поведения, корреляция сигналов между инструментами), контекст распределен по множеству инструментов, а знания о работе систем хранятся в головах инженеров;
- Resolve подходит, если основные операционные затраты связаны с многократным выполнением одних и тех же шагов по устранению хорошо изученных проблем, команда поддерживает ранбуки и плейбуки, а окружение отличается масштабной инфраструктурой с частыми алертами;
- Traversal подходит, если самые сложные инциденты связаны с каскадными сбоями между множеством сервисов, система крупная и сильно взаимосвязанная, а практики наблюдаемости уже зрелые.
Как устроены AI SRE платформы:
- Traversal строит представление графа зависимостей системы и с помощью причинно-следственного машинного обучения (Causal machine learning) анализирует распространение сигналов. При инциденте платформа выводит наиболее вероятную причинно-следственную цепочку: исходное событие, промежуточные зависимости и путь распространения, с подтверждением телеметрией на каждом шаге. Платформа выполняет только расследование и анализ;
- Resolve работает как слой автоматизации поверх операционного стека и интегрируется с инфраструктурой, инструментами наблюдаемости, облачными API и пайплайнами развертывания. При инциденте платформа с помощью AI выбирает и автоматически выполняет процессы, аналогичные ранбукам: сбор диагностики, проверку инфраструктуры, перезапуск сервисов или перераспределение ресурсов. Процессы автоматизации заранее определяют и поддерживают инженеры;
- Cleric работает как слой расследования поверх Production окружения и итеративно собирает данные, формирует и проверяет гипотезы. Компонент Verification Engine оценивает корректность диагнозов постфактум по сигналам окружения и формирует оценки точности по типам проблем. Компонент Decision Model фиксирует трассы решений инженеров и сопоставляет их с проверенными результатами. По мере роста точности на конкретном типе проблем платформа получает право действовать с меньшим контролем.
ЗаключениеAI SRE является новой и быстро развивающейся категорией. Правильный выбор зависит от того, где сосредоточены основные эксплуатационные боли команд:
- Если главная проблема в координации людей во время инцидентов, стоит начать с платформы управления инцидентами;
- Если расследования проходят внутри одного инструмента наблюдаемости, может хватить встроенных AI-функций;
- При сильной платформенной команде и простом окружении собственная разработка остается обоснованным вариантом;
- Если инженеры тратят много времени на расследования в разрозненных инструментах, восстанавливают контекст, который уже должен существовать, и заново решают уже решенные проблемы, нужна специализированная агентная платформа AI SRE.
Основные инсайты из отчета The State of AI SRE 2026 приведены ниже: