Исследование Dynatrace 2026: мониторинг ИИ стал основной задачей SRE

Две трети инженеров по надёжности сайтов (SRE) называют мониторинг ИИ-моделей своей задачей номер один. Этот единственный показатель — 67 процентов — переосмысляет саму суть SRE в 2026 году: уже не Linux-серверы и поды Kubernetes, а эндпоинты моделей, дрейф и задержка инференса, которые попали в тот же дежурный график, что и платёжный шлюз.

Dynatrace опубликовала эти данные 26 августа 2026 года в отчёте State of SRE and Platform Engineering 2026, совместив их с корпоративным шагом — анонсом намерения приобрести Arize, вендора в области оценки ИИ. Вместе взятые, опрос и M&A-сделка показывают, куда рынок observability направит инженерные бюджеты ближайших трёх лет.

Что произошло

В исследовании приняли участие 919 ИТ-руководителей со всего мира, и, как сообщает Express Computer, его ключевой тезис состоит в том, что ИИ-нагрузки переопределяют требования к командам SRE и платформенной инженерии. Заголовочные цифры стоит рассматривать в совокупности — по отдельности они теряют смысл.

Начнём с уровня внедрения. По данным Gartner, упомянутым в отчёте, к 2028 году 80 процентов предприятий примут практики SRE — против 30 процентов в 2024 году. Это рост в 2,67 раза за четыре года, агрессивный даже по меркам корпоративного программного обеспечения. Поддержка со стороны руководства уже есть: 92 процента организаций сообщают о поддержке SRE-инициатив на уровне топ-менеджмента, а 89 процентов компаний, занимающихся платформенной инженерией, создали внутреннюю платформу для разработчиков (IDP), причём 60 процентов из них отмечают широкое межотдельское внедрение.

Теперь об ИИ-слое. 67 процентов SRE называют мониторинг ИИ-моделей своим главным сценарием использования. 58 процентов говорят, что мониторинг производительности и точности моделей уже стал их наиболее распространённой ИИ-возможностью. Половина SRE применяет ИИ для автоматизированного реагирования на инциденты. 55 процентов платформенных инженеров сосредоточены на создании ИИ-инструментов для разработчиков — копайлотов и чат-ботов.

Болевые точки также выражены в цифрах. 37 процентов платформенных инженеров называют интеграцию инструментов главной проблемой. Лишь 40 процентов встраивают observability на всех этапах развёртывания. Почти половина SRE считает, что слишком много источников данных и метрик мешают формулировать полезные SLO. При этом Dynatrace признаёт, что ИИ не оправдывает ожиданий в части снижения затрат и среднего времени восстановления (MTTR), хотя в целом соответствует ожиданиям по надёжности и производительности. Источник не раскрывает величину отставания MTTR в абсолютных минутах, а это важно: от этого зависит, означает ли «ниже ожиданий» погрешность округления или целый порядок величины.

Техническая анатомия проблемы

Инженерная проблема, скрывающаяся за этими цифрами, состоит в том, что ИИ-нагрузки разрушают допущения, на которых строилась классическая observability. У традиционного сервиса есть запрос, ответ, гистограмма задержки и частота ошибок. Его можно обернуть в спан OpenTelemetry, определить SLO на основе p99-задержки и бюджета ошибок — и считать задачу выполненной. LLM-эндпоинт имеет всё это плюс вторую поверхность: качество, достоверность и безопасность вывода. Ответ 200 OK с галлюцинированным содержимым — это тихий сбой, который не поймает ни один HTTP-зонд.

Именно поэтому 58 процентов SRE называют мониторинг производительности и точности моделей своей наиболее распространённой ИИ-возможностью, и именно поэтому приобретение Arize структурно значимо. Платформы оценки ИИ специализируются на офлайн- и онлайн-оценке: сравнении с эталонными данными, оценке по методу LLM-as-judge, дрейфе эмбеддингов, наборах для регрессии промптов. Платформы observability специализируются на трейсах, метриках, логах и рабочих процессах управления инцидентами. Исторически они существовали в отдельных инструментах, которыми владели разные команды, — именно этот разрыв обозначил Стив Так, директор по продукту Dynatrace: «Команды ИИ-инженеров работали с одним набором инструментов для оценки, а операционные команды мониторили в другом, и этот разрыв больше не является устойчивым по мере того, как ИИ глубже проникает в корпоративное производство».

Проблема SLO — второй технический изъян. 89 процентов SRE применяют SLO хотя бы в части команд или систем, что звучит обнадёживающе, пока не прочитаешь оговорку: почти половина говорит, что слишком много источников данных и метрик не позволяют определить эффективные SLO. Когда поверх «золотых сигналов» из нижележащего слоя Kubernetes добавляются метрики качества модели, метрики стоимости токенов, оценки классификаторов безопасности и показатели точности retrieval-augmentation, определение SLO превращается из математической задачи в таксономическую. То, что половина SRE уже делегирует реагирование на инциденты ИИ-автоматизации, усугубляет положение: агентная ремедиация при размытых SLO — это путь к автоматическим действиям, срабатывающим на шум.

Источник не сообщает, сколько из этих организаций реально внедрили агентную ремедиацию в production, а не только в staging. Отчёт характеризует команды как «намеренно расставляющих приоритет в пользу видимости и человеческого контроля перед расширением автоматизации» — это проверяемое утверждение: если оно верно, объёмы автоматизированных действий должны оставаться стабильными или расти медленнее объёмов мониторинга в течение следующих двенадцати месяцев. Если нет — ждите публичного постмортема о неуправляемом ремедиаторе к середине 2027 года.

Кто пострадает

Под угрозой оказываются три группы. Первая — самостоятельные вендоры оценки ИИ, не являющиеся Arize. Dynatrace только что заявила с чековой книжкой в руках, что оценка ИИ — это функция observability, а не самостоятельная категория. Datadog, New Relic, Splunk, Grafana Labs и Chronosphere теперь обязаны ответить: строить, покупать или партнёриться. Ожидайте как минимум ещё одного поглощения вендора оценки ИИ в течение двух следующих кварталов. Если этого не произойдёт — значит, игроки рынка считают, что смогут создать такое решение быстрее, чем интегрировать готовое.

Вторая группа — команды платформенной инженерии, рассматривающие свою IDP как веху поставки, а не живой продукт. 89 процентов таких команд имеют IDP, но лишь 60 процентов сообщают о широком внедрении. Этот разрыв в 29 процентных пунктов между «создали» и «реально используют» — то место, где бюджеты урезают, когда финансовый директор спрашивает, что принесла платформенная команда за год. В финтехе и iGaming, где скорость выпуска является конкурентным рвом, невостребованная IDP — очень заметная строка расходов.

Третья группа — SRE-организации, которые поверили в ИИ для операций на основе обещания снизить MTTR. Отчёт прямо указывает, что ИИ не оправдывает ожиданий ни по стоимости, ни по MTTR. Вендоры продавали этот тезис; он так и не реализовался в полной мере. Тем, чей план по найму на 2026 год был обоснован тем, что «ИИ сократит продолжительность инцидентов на X процентов», нужно новое обоснование — а источник не раскрывает, каким именно был X, хотя покупатели должны требовать эту цифру у своих вендоров.

Ближайшие 90 дней для каждой группы: вендоры оценки ведут переговоры или укрепляют позиции, платформенные команды инструментируют внедрение, а руководители SRE пересматривают критерии успеха ИИ-операций до фиксации годовых планов.

План действий для инженерных команд

Если вы отвечаете за надёжность или платформенную инженерию, в этом квартале стоит сделать четыре шага.

Первый: проведите аудит каталога SLO, прежде чем добавлять в него метрики качества ИИ. Если инженеры уже говорят, что метрик слишком много для формулирования хороших SLO, добавление показателей галлюцинаций и бюджетов стоимости токенов только усугубит ситуацию. Сначала — сокращение. Рабочий ориентир: ни один сервис не владеет более чем пятью SLO, и у каждого SLO есть именной владелец, который просматривал его в течение последних 30 дней.

Второй: рассматривайте оценку ИИ и производственный мониторинг как единый пайплайн, а не два отдельных. Независимо от того, покупаете ли вы Dynatrace-плюс-Arize, архитектурная ставка верна: ваш eval-инструментарий в CI должен генерировать те же сигналы, которые потребляет ваша производственная observability — в идеале через семантические конвенции OpenTelemetry. Если команда оценки и операционная команда смотрят на разные дашборды, вы воспроизвели именно тот разрыв, о котором говорил Так.

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

Четвёртый: измеряйте внедрение IDP еженедельно, а не ежеквартально. Если ваша внутренняя платформа находится в том самом 29-процентном разрыве между «внедрена» и «широко используется», исправление — это работа над опытом разработчиков, а не добавление функций. Инструментируйте саму платформу той же телеметрией, которую вы требуете от прикладных команд.

Ключевые выводы

• 67 процентов SRE ставят мониторинг ИИ-моделей на первое место среди сценариев использования, что фактически переопределяет описание должности SRE: теперь оно строится вокруг поведения моделей, а не только инфраструктуры.
• Прогноз Gartner — 80 процентов внедрения SRE к 2028 году против 30 процентов в 2024 году — означает рост практики в 2,67 раза за четыре года, и рынок инструментов консолидируется в соответствии с этим.
• Намерение Dynatrace приобрести Arize — это ставка на то, что оценка ИИ войдёт в observability как функция, а не как самостоятельная категория. Следите за ответными M&A-сделками со стороны Datadog, Splunk или Grafana в течение двух кварталов.
• По данным отчёта, ИИ не оправдывает ожиданий по MTTR и стоимости, однако источник не квантифицирует отставание — а именно эту цифру каждый покупатель должен требовать у своего вендора до планирования на 2027 год.
• Главный скрытый риск — агентная ремедиация, работающая на размытых SLO. Если команды не сократят метрики и не ограничат радиус поражения автоматизации сейчас, к середине 2027 года стоит ожидать публичного инцидента, вызванного автоматизированным ремедиатором.