В августе 2026 года компания Dynatrace опубликовала отчет
The State of SRE and Platform Engineering 2026. Отчет подготовлен по результатам опроса 919 руководителей и инженеров в области SRE, Platform Engineering и эксплуатации. Вопросы охватывали применение AI в SRE и Platform Engineering, фактические и ожидаемые эффекты, зрелость SRE практик, работу с SLO, практик тестирования и валидации релизов, болевые точки платформенных команд, оптимизацию ресурсов и встраивание наблюдаемости в жизненный цикл разработки.
В начале отчета авторы предложили модель, в которой SRE и Platform Engineering объединены общим слоем Observability. Оба подхода стали основой современной эксплуатации, поэтому ключевыми задачами становятся масштабирование, интеграция и управление сложностью на фоне быстрого роста AI. В этой модели SRE обеспечивает надежность систем и включает мониторинг, доступность, реагирование на инциденты и SLO. Platform Engineering здесь создает внутренние платформы и инструменты для разработки ПО, что включает CI/CD, развертывание, управление контейнерами, облачную инфраструктуру и управление жизненным циклом приложений. Оба подхода централизуют и стандартизируют инструменты для надежности, безопасности и эффективности. Observability в этой модели формирует общий контекстный слой на их пересечении и объединяет автоматизацию, наблюдаемость для AI, консолидацию инструментов, оптимизацию производительности и планирование мощностей.
Что еще интересного мы отметили в отчете:
- AI используют практически все SRE команды. Только 3% сообщают, что пока не применяют AI в SRE. Самой распространенной AI функцией стала эксплуатация самих AI систем: мониторинг производительности и точности моделей, устойчивости и безопасности данных (58%). Среди сценариев применения AI для задач SRE лидируют автоматическое реагирование на инциденты и устранение их последствий (50%), генерация постинцидентных отчетов (49%), мониторинг комплаенса и отчетность в реальном времени, а также отслеживание будущих регуляторных изменений (48%) и обнаружение аномалий в логах, метриках и трейсах (46%). Далее следуют прогнозирование проблем с надежностью или нарушений SLO, триаж инцидентов и классификация их критичности, анализ первопричин и корреляция событий, интеллектуальное подавление алертов и снижение шума, генерация или рекомендация Runbooks;
- AI используют практически все платформенные команды. Только 2% сообщают, что пока не применяют AI в Platform Engineering. Первое место занимает поддержка разработчиков через AI чат-боты и сервисы (55%). Мониторинг AI инструментов для обеспечения безопасности данных, производительности и точности моделей использует 52%, автоматизацию отчетности по комплаенсу и предиктивную аналитику 49%, генерацию кода для инфраструктуры как кода или CI/CD 46%. Генерацию документации для внутренних инструментов, а также мониторинг и оптимизацию использования внутренней платформы для разработчиков (IDP) применяют по 43%. Рекомендательные системы для шаблонов сервисов и конфигураций, а также интеллектуальное размещение нагрузок и автомасштабирование используют по 42%, автоматическую валидацию или откат развертываний 41%, предиктивную оптимизацию затрат 38%;
- Наблюдаемость является главной точкой входа AI в эксплуатацию. AI/ML-функции в платформах наблюдаемости и AIOps используют или планируют использовать 63% SRE/ITOps команд и 67% платформенных команд. Ассистенты для написания кода, LLM, автономные агенты и кастомные ассистенты на базе GPTs распространены почти так же широко. Собственные ML-модели развивают 32% и 37% команд соответственно;
- Фактический эффект от AI отстает от ожиданий. Рост надежности систем отмечают 55% при ожиданиях 62%, рост продуктивности разработчиков 55% при ожиданиях 58%. Наибольший разрыв касается снижения операционных затрат: 45% фактически при ожидаемых 55%. Сокращение времени обнаружения и устранения инцидентов, снижение ручного труда (Toil), рост принятия и удовлетворенности платформой и ускорение релизных циклов показывают разрыв от 4 до 7 процентных пунктов;
- Зрелость SRE высока, при этом культурные практики надежности отстают. 22% организаций полностью автоматизировали ITOps, SLO и Quality gates для качества и безопасности приложений, еще 42% автоматизировали большую их часть. У 18% многие процессы и SLO хорошо определены и частично автоматизированы, 12% полагаются на ручные усилия, 4% не внедрили ITOps практики формально, 2% не следуют принципам SRE. При этом Blameless postmortems проводят только 30% команд, Progressive delivery используют 36%, Error budgets для решений о релизах 37%;
- SRE практики продолжат активно расширяться в ближайшие 5 лет. Мониторинг AI моделей сегодня используют 67% команд, автоматизировали 47%, через 5 лет его планируют 85%. Автоматизация операционных задач вырастет с 64% до 83%, работа с SLO с 62% до 79%, архитектурные ревью и оценка рисков надежности с 58% до 79%, встраивание SRE в продуктовые команды с 61% до 77%. Самый заметный рост ожидается для Blameless postmortems (с 30% до 53%) и Progressive delivery (с 36% до 61%). Почти все организации получают ожидаемые эффекты от SRE: только 1% не видит результатов, разрыв между наблюдаемыми и ожидаемыми эффектами составляет от 3 до 9 процентных пунктов. Наибольший разрыв касается роста автоматизации и снижения ручного труда (46% и 55%);
- Оценка уровня сервиса опирается на SLI и бизнес-метрики. 53% отслеживают SLI (Service Level Indicators), такие как задержка, доступность и пропускная способность, 52% используют OKR и KPI, 48% применяют метрики DORA, столько же используют AI/ML-инструменты для оценки и прогнозирования производительности сервисов. SLA от провайдеров используют 47%, собственные SLO устанавливают 46%. Обращения клиентов и тикеты поддержки служат источником оценки для 41%, ручные ревью для 39%, простые инструменты мониторинга для 32%, операционные дашборды и алерты для 31%. Только 1% не оценивает уровень сервиса структурированно;
- SLO применяются прежде всего для внешних обязательств, главным препятствием является фрагментация данных. 56% используют SLO для поддержки SLA и обязательств по надежности перед клиентами, 52% для постановки целей надежности, по 50% для валидации качества сервиса при релизах и коммуникации ожиданий со стейкхолдерами, 49% для постинцидентных ревью. Определение Error budgets находится на последнем месте (38%). Среди проблем лидируют слишком большое количество источников данных (49%) и метрик (45%), 35% указывают, что инструмент мониторинга затрудняет определение SLO и отслеживание их истории. Пробелы в знаниях (какие метрики отслеживать, каким должен быть хороший SLO, как его оценивать, с чего начать) отмечают от 10% до 15%;
- Quality gates стандартизированы у большинства, полностью автоматизированная валидация релизов остается редкостью. 54% сделали Quality gates стандартизированными и обязательными, 34% применяют ключевые проверки в большинстве пайплайнов, 10% используют базовые проверки в отдельных пайплайнах. Quality gates применяются для контроля автоматических порогов и валидации метрик производительности, соблюдения SLO на этапах staging и pre-production, проверки интеграции наблюдаемости перед развертыванием, автоматического отката при деградации надежности и блокировки релизов при исчерпании error budget. Интеграционное тестирование применяют 76%, end-to-end тестирование в CI/CD 70%, нагрузочное 57%, модульное 56%, Chaos engineering 40%. Для валидации релизов только 25% опираются на автоматическое тестирование и Systematic quality gates в CI/CD, 61% комбинируют ручные и автоматические проверки, 14% полагаются на ручные проверки;
- Platform Engineering строится вокруг стандартизации и самообслуживания. Доступ к дашбордам наблюдаемости и мониторинга сегодня предоставляют 74% платформенных команд, автоматизировали 58%, через 5 лет планируют 93%. Предоставление инфраструктуры вырастет с 71% до 91%, генерация шаблонов сервисов и Boilerplate кода с 63% до 89%, развертывание приложений через пайплайны с 61% до 88%. Повторяемость развертываний обеспечивают стандартизированные шаблоны CI/CD, автоматические валидации и Rollbacks, инфраструктура как код и Runbooks или политики развертывания. Консистентность развертываний 66% поддерживают через Roadmap и Governance платформы, столько же через версионирование, тестирование и распространение через формальный платформенный пайплайн. У 56% центральная команда поддерживает стандарты при опциональном принятии, у 41% каждая команда решает этот вопрос самостоятельно;
- Интеграция и стандартизация являются главными болевыми точками платформенных команд. 37% сталкиваются со сложностями интеграции с существующими инструментами и системами, 32% с трудностями поддержки стандартизации между командами и окружениями, 31% со сложностью требований безопасности и комплаенса. По 30% указывают на недостаточную автоматизацию и сложность демонстрации бизнес-ценности или ROI, 29% на расхождение приоритетов платформы и потребностей разработчиков. Недостаток прозрачности AI систем, агентов и инструментов, а также ограничения по ресурсам и численности отмечают по 28%. Далее следуют недостаточная документация и поддержка онбординга, отсутствие четкого владения, сложность отладки в Production, низкое принятие платформенных инструментов разработчиками и медленное или ненадежное самообслуживание. Среди эффектов Platform Engineering наибольший разрыв между фактом и ожиданиями касается роста автоматизации и снижения ручного труда (45% и 53%), стабильности развертываний (42% и 49%) и снижения операционной сложности (39% и 46%);
- Стратегии SRE и Platform Engineering сфокусированы на стоимости и снижении ручного труда. Оптимизацию использования облака и AI токенов ставят в приоритет 49% SRE команд и 52% платформенных команд, автоматизацию реагирования на инциденты по 48%, оптимизацию стоимости инфраструктуры 47% и 50%. Снижение ручного труда через AI/ML и автоматизацию является главным направлением для платформенных команд (54%) и важным для SRE (46%). Расширение возможностей наблюдаемости и инженерии надежности платформенные команды выделяют заметно чаще SRE (51% и 44%). Развитие внутренних платформ для разработчиков замыкает список (41% и 44%);
- Безопасность и комплаенс встраиваются в платформу как код. Политики безопасности в виде кода встроили 67% SRE команд и 68% платформенных команд, безопасность интегрирована во все стадии разработки, развертывания и эксплуатации у 64% и 66%, автоматическое сканирование в CI/CD используют 55% и 56%. При этом Ad hoc проверки безопасности сохраняются у 46% и 53%. Требования комплаенса встроены в инфраструктуру и CI/CD у 59% SRE команд и 68% платформенных команд, автоматизированная непрерывная валидация комплаенса между окружениями есть у 58% и 66%. Ручные процессы под управлением команд комплаенса остаются у 46% и 53%;
- Оптимизация ресурсов включает FinOps и Sustainability. Мониторинг, отчетность и планирование энергопотребления или углеродного следа применяют 66% SRE команд и 61% платформенных команд, обучение команд принципам устойчивого проектирования и эксплуатации 64% и 60%. Rightsizing инфраструктуры и устранение недоиспользуемых ресурсов SRE команды применяют заметно чаще (60% и 47%). FinOps практики внедрили по 51%, планирование нагрузок с учетом углеродной интенсивности используют 53% платформенных команд. Отсутствие инициатив по оптимизации отмечают 4% SRE команд и 1% платформенных команд;
- Практики наблюдаемости пока не стали стандартной частью развертываний. 40% платформенных команд встроили наблюдаемость во все развертывания и активно ее поддерживают, 37% включают ее в отдельные сервисы с ограниченным покрытием или консистентностью, 18% находятся на этапе изучения или начала внедрения, у 4% наблюдаемость минимальна или отсутствует в процессах развертывания. В SDLC практики наблюдаемости чаще всего применяют на этапе развертывания, далее следуют тестирование и Staging, разработка, требования и планирование, пост-развертывание и Production.
Основные инсайты из отчета The State of SRE and Platform Engineering 2026 приведены ниже: