Dynatrace 2026: Моніторинг ШІ став основною роботою 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, на який посилається звіт, прогнозує, що 80 відсотків підприємств впроваджать практики SRE до 2028 року, порівняно з 30 відсотками у 2024 році. Це зростання практики у 2,67 раза за чотири роки — агресивно навіть за стандартами дифузії корпоративного програмного забезпечення. Підтримка керівництва вже є: 92 відсотки організацій повідомляють про підтримку ініціатив SRE з боку керівництва, а 89 відсотків організацій, що займаються платформною інженерією, створили внутрішню платформу для розробників, причому 60 відсотків із них повідомляють про широке міжвідомче впровадження.

Тепер про ШІ-складову. 67 відсотків SRE-інженерів називають моніторинг ШІ-моделей своїм головним варіантом використання. 58 відсотків кажуть, що моніторинг продуктивності та точності моделей є вже їхньою найпоширенішою ШІ-можливістю. Половина SRE-інженерів використовує ШІ для автоматизованого реагування на інциденти. 55 відсотків платформних інженерів зосереджені на випуску ШІ-інструментів для розробників — таких як копілоти та чат-боти.

Проблемні точки також кількісно виміряні. 37 відсотків платформних інженерів називають інтеграцію інструментів своїм головним викликом. Лише 40 відсотків впроваджують observability на всіх етапах розгортання. Майже половина SRE-інженерів стверджує, що забагато джерел даних і метрик заважає визначенню корисних SLO. І Dynatrace визнає, що ШІ не виправдовує очікувань щодо скорочення витрат та середнього часу відновлення, хоча загалом відповідає очікуванням щодо надійності та продуктивності. Джерело не розкриває розміру відставання за MTTR у абсолютних хвилинах, що важливо, оскільки це визначає, чи означає «не виправдовує очікувань» незначну різницю чи цілий порядок величини.

Технічна анатомія проблеми

Інженерна проблема, що лежить в основі цих цифр, полягає в тому, що ШІ-навантаження руйнують припущення, на яких будувалася класична observability. Традиційний сервіс має запит, відповідь, гістограму затримки та рівень помилок. Ви можете обгорнути це в OpenTelemetry-спан, визначити SLO на основі p99-затримки та бюджету помилок — і вважати завдання виконаним. Кінцева точка LLM має все це плюс другу поверхню: якість, фактологічну точність і безпеку виводу. Відповідь 200 OK із галюцинованою відповіддю — це тихий збій, який жоден HTTP-рівень зонд не виявить.

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

Проблема SLO — це друга технічна рана. 89 відсотків SRE-інженерів використовують SLO принаймні в деяких командах або системах, що звучить непогано, доки не прочитаєш протилежне: майже половина стверджує, що забагато джерел даних і метрик не дозволяє їм визначати ефективні SLO. Коли ви додаєте метрики якості моделі, метрики вартості токенів, оцінки класифікатора безпеки та показники влучності retrieval-augmentation поверх golden-signal метрик із базового рівня Kubernetes, визначення SLO перетворюється на проблему таксономії, а не математики. Половина SRE-інженерів, яка вже делегує реагування на інциденти ШІ-автоматизації, ускладнює ситуацію, адже агентне виправлення з розмитими SLO — це шлях до автоматичних дій, що спрацьовують на шум.

Чого ми не знаємо з джерела — скільки з цих організацій насправді розгорнули агентне виправлення у виробництво, а не лише в staging. Звіт характеризує команди як такі, що «навмисно надають пріоритет видимості та людському нагляду перед розширенням автоматизації», — це перевіряємий орієнтир: якщо він збережеться, ми повинні побачити, що обсяги автоматичних дій залишаться незмінними або зростатимуть нелінійно відносно обсягів моніторингу протягом наступних дванадцяти місяців. Якщо ні — чекайте на публічний постмортем про вийшовший з-під контролю ремедіатор до середини 2027 року.

Хто ризикує найбільше

Три групи опиняються під загрозою. По-перше, незалежні вендори оцінювання ШІ, які не є Arize. Dynatrace щойно заявила — і підкріпила це чеком — що оцінювання ШІ є функцією observability, а не окремою категорією. Datadog, New Relic, Splunk, Grafana Labs і Chronosphere тепер мусять відповісти, чи будуватимуть вони це самостійно, купуватимуть чи шукатимуть партнерів. Очікуйте щонайменше ще одного придбання вендора оцінювання протягом наступних двох кварталів. Якщо цього не станеться, це сигнал того, що гравці-ветерани вважають, що можуть побудувати рішення швидше, ніж інтегрувати готове.

По-друге, команди платформної інженерії, які сприймають свою IDP як завершений проект, а не як живий продукт. 89 відсотків таких команд мають IDP, але лише 60 відсотків повідомляють про широке впровадження. Цей розрив у 29 пунктів між «побудовано» і «реально використовується» — саме там бюджети скорочують, коли CFO запитує, що платформна команда принесла цього року. У фінтеху та iGaming зокрема, де швидкість випуску є конкурентною перевагою, погано використовувана IDP — дуже помітна стаття витрат.

По-третє, SRE-організації, які купилися на ШІ-для-операцій з обіцянкою скорочення MTTR. Звіт прямо зазначає, що ШІ не виправдовує очікувань як щодо витрат, так і щодо MTTR. Вендори продавали цю ідею; ідея не повністю реалізувалась. Той, чий план штатного розкладу на 2026 рік виправдовувався тим, що «ШІ скоротить тривалість інцидентів на X відсотків», потребує нового обґрунтування, — а джерело не розкриває, яким мав бути X насправді, і саме цю цифру покупці тепер повинні вимагати від своїх вендорів.

Наступні 90 днів для кожної групи: вендори оцінювання ведуть переговори або зміцнюють позиції, платформні команди вимірюють впровадження, а керівники SRE переглядають критерії успіху ШІ-операцій до фіксації річного планування.

План дій для інженерних команд

Якщо ви керуєте надійністю або платформною інженерією — чотири кроки цього кварталу.

Перший: проведіть аудит каталогу SLO, перш ніж додавати до нього будь-які ШІ-метрики якості. Якщо ваші інженери вже кажуть, що метрик забагато для визначення хороших SLO, додавання показників галюцинацій і бюджетів вартості токенів лише погіршить ситуацію. Спочатку скоротіть. Робочий орієнтир: жоден сервіс не повинен мати більше п'яти SLO, і кожен SLO має іменованого власника, який переглядав його за останні 30 днів.

Другий: сприймайте оцінювання ШІ та виробничий моніторинг як один конвеєр, а не два. Незалежно від того, купуєте ви Dynatrace разом із Arize чи ні, архітектурна ставка правильна: ваш eval-харнес у CI повинен випромінювати ті самі сигнали, які споживає ваша виробнича observability, бажано через семантичні конвенції OpenTelemetry. Якщо команда оцінювання та операційна команда дивляться на різні дашборди — ви побудували саме той розрив, який описав Тек.

Третій: встановіть для агентного виправлення явні обмеження радіусу ураження. Половина SRE-інженерів вже делегує реагування на інциденти ШІ. Перш ніж розширювати цей обсяг, визначте, чого ШІ не дозволено торкатися: виробничі бази даних, платіжні рейки, все, що має межі відповідності. Записуйте кожну автоматичну дію в append-only аудит-потік.

Четвертий: вимірюйте впровадження 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 року.