Привет, %username%! Попытался разобраться, куда катится Site Reliability Engineering (SRE) за последние лет пять. Ниже накидал мысли по этому поводу. Ссылки на все отчеты вроде не забыл, так что зацени, а потом го в комменты – обсудим вместе.

Что там в отчетах?

Короче, за последние лет пять SRE стала прямо хайповой темой для исследований. Вот самые толковые источники, чтобы быть в теме, что в SRE происходит:

  • Catchpoint — The SRE Report (2020, 2021, 2023, 2024, 2025): Это, наверное, самый жирный отчет прям по SRE. В 2025 опросили больше 300 спецов из разных областей. Говорят, это типа реальное мнение людей из SRE команд, без воды и прикрас.
  • DORA (DevOps Research and Assessment): Каждый год (2020, 2021, 2022, 2023, 2024, 2025) катают отчеты, где уже лет десять меряют, насколько круто DevOps и SRE работают. Смотрят на четыре главные метрики. В 2025 даже целый отчет выпустили про то, как AI влияет на разработку.
  • DevOps Institute — Global SRE Pulse 2022: Это было первое большое исследование, где опросили больше 460 SRE спецов и манагеров из средних и больших компаний. В отчете можно глянуть, как сейчас вообще живёт SRE, какие штуки юзают, как команды себя чувствуют и насколько все заавтоматизировано.
  • Puppet — State of DevOps (2020-2021, 2023): В 2021 отметили десятилетие этих отчетов и выяснили, что у 78% компаний с DevOps дела так себе, где-то на середине. В 2023 больше смотрели на платформенную инженерию.
  • Forrester Research (2020): Выкатили отчет про десять главных трендов в инфраструктуре и сказали, что SRE – это база для стабильной работы всего.
  • Gartner Hype Cycle (2025): Закинули SRE и Platform Engineering на свой график взросления технологий. Ещё упомянули всякие приколы для управления окружениями, чтоб каждый мог сам себе все сделать.
  • ThoughtWorks Technology Radar (постоянно, 2020-2025): Эти ребята вообще всегда следят, как меняются инструменты и практики в SRE, наблюдаемости и чтоб системы были надежными.

Главные изменения в SRE

1. Рост Toil: неожиданный поворот в 2025

Что-то пошло не так: Впервые за пять лет нудной работы (Toil) стало больше. Раньше было 14% времени, а теперь все 20%. Задачи по операционке тоже времени жрут больше – теперь 30% вместо 20%.

Все думали, с AI станет легче. Эксперты из Catchpoint удивились: ждали, что AI уберет рутину, а он наоборот, ее добавил. Может, все дело в том, что AI помогает быстрее делать полезные вещи, а свободное время забивается всякой фигней.

Как было раньше: С 2020 по 2024 нудной работы становилось все меньше. Спасибо автоматизации, IaC, CI/CD и системам, которые сами чинятся. Google советует, чтоб такой работы было не больше половины времени инженера, а у SRE – не больше половины на операционку.

Как бороться с Toil в 2025:

  • Автоматизация через Terraform, Ansible, CI/CD пайплайны.
  • Внедряйте self-healing системы, чтоб все чинилось само.
  • Стандартизируйте все через плейбуки и runbooks.
  • AIOps инструменты – чтобы алерты сами между собой разбирались и мониторили все на будущее.
  • Переходите на self-service порталы вместо тикетов.

2. AI и Machine Learning: уже не просто побаловаться, а без них никуда

Как развивалось:

  • 2020: Только начали пробовать AI в мониторинге и поиске аномалий.
  • 2021-2022: Все больше интересуются, как AI может предсказывать проблемы и автоматом чинить инциденты.
  • 2023-2024: Вовсю внедряют AIOps платформы (Datadog, Splunk, Dynatrace).
  • 2025: GenAI – это революция! 39% спецов говорят, что AI круто генерит код.

Где AI нужен в SRE 2025:

  • Предсказывать инциденты: AI изучает старые данные и говорит, где может рвануть.
  • Автоматически генерить тесты: ML создает тесты, когда код меняется.
  • AI помогает в ChatOps: встраивают LLM в процессы управления инцидентами.
  • Системы, которые сами чинятся: AI находит аномалии и сам все исправляет.
  • Улучшение производительности: AI анализирует, что можно улучшить в SLO.

Важный момент из DORA 2024: второй год подряд получается, что AI делает доставку софта хуже. Короче, AI – не волшебная таблетка, надо аккуратно внедрять и смотреть, что получается.

Что думают про AI: 53% SRE думают, что AI сделает их работу легче, и только 4% боятся, что AI их заменит. При этом 30% решили, что надо учиться AI.

3. Platform Engineering и SRE: теперь вместе навсегда

Как менялись отношения:

  • 2020: Platform Engineering как отдельную штуку вообще не выделяли, все было в DevOps.
  • 2021-2022: Начали говорить про Platform Engineering.
  • 2023: Puppet выпустили отчет State of Platform Engineering, и 93% сказали, что это круто.
  • 2024-2025: Platform Engineering и SRE активно работают вместе.

В чем разница и как помогают друг другу:

  • Platform Engineering создает платформы, чтобы разрабам было проще работать: self-service, не надо думать про инфраструктуру, все стандартизировано.
  • SRE следит, чтоб все работало надежно, SLO выполнялись, мониторит продакшн, разруливает инциденты и чтоб всего было в меру – и новых фич, и стабильности.
  • Вместе им хорошо: если платформа сделана правильно, то у SRE меньше Toil, потому что все деплоится по стандарту и куча задач автоматизирована. А SRE, в свою очередь, делает платформы надежнее.

4. FinOps: SRE теперь еще и за бабки отвечает

Как росла важность:

  • 2020: Только начали понимать, что надо следить за расходами в облаке.
  • 2021-2022: FinOps стала отдельной темой.
  • 2023-2024: FinOps активно встраивается в SRE практики.
  • 2025: SRE команды вовсю юзают FinOps, чтобы тратить меньше денег в облаке.

Что SRE должны знать про FinOps:

  • Ответственность за деньги – часть DevOps.
  • Как тратить меньше, но чтоб все работало надежно.
  • Как правильно выделять деньги на облачные ресурсы.
  • Оптимизация производительности за свои деньги.
  • Управление ресурсами.

Catchpoint 2025 говорит, что Capacity Management теперь в приоритете у компаний, наравне с SRE, SLO и автоматизацией починки инцидентов.

5. OpenTelemetry: все стандартизировали наблюдаемость

Как быстро все начали юзать:

  • 2020: Никто толком не знал (~5%).
  • 2021-2022: Уже многие в теме (~20-25% планируют или юзают).
  • 2023-2024: Уже хорошо (~48% юзают).
  • 2025: Практически все (~73% юзают или собираются).

Почему это круто:

  • Стандартизация: один стандарт для всего – как собирать данные, как их отправлять.
  • Не надо зависеть от поставщиков: можно не привязываться к конкретному вендору.
  • ROI: 46% компаний говорят, что ROI больше 20%, а еще 40% – 10-20%.
  • Экономия: 84% компаний, которые стали меньше тратить на observability, говорят, что сэкономили минимум 10%.
  • Зрелость: 81% считают, что OpenTelemetry уже достаточно взрослая штука.

Почему это важно для AI-SRE: OpenTelemetry – это база для AI, потому что он дает одинаковые, понятные данные для анализа.

Но есть и проблемы: сложно внедрить, данных становится слишком много (в 4-5 раз больше), надо интегрировать со старыми системами и следить за расходами.

6. Chaos Engineering: теперь это не просто прикол, а необходимость

Как это стало популярно:

  • 2020: Какая-то странная штука, которую Netflix придумал.
  • 2021: 60% спецов хоть раз пробовали chaos-эксперименты.
  • 2022-2023: Все больше компаний юзают это, чтобы проверять, как системы работают при сбоях.
  • 2024-2025: Chaos Engineering стал важной частью SRE.

Как это работает с SRE:

  • Проверка на отказоустойчивость: специально ломают систему, чтоб найти слабые места.
  • Валидация SLO/SLI: убеждаются, что все работает, даже когда что-то идет не так.
  • Подготовка к инцидентам: тренируются реагировать, чтоб пользователи ничего не заметили.
  • Уменьшение Toil: автоматом проверяют отказоустойчивость через CI/CD.
  • Быстрее чинят: если заранее знают, что может сломаться, то быстрее восстановят.

Популярные инструменты 2025: Qinfinite by Quinnox, Gremlin, Chaos Mesh, LitmusChaos, AWS Fault Injection Simulator.

Важный момент: Chaos Engineering помогает создать атмосферу, где не ищут виноватых, а стараются улучшить систему.

7. SLO и Error Budgets: все становится серьезно

Как взрослели:

  • 2020: Только начали внедрять SLO, но часто не понимали, зачем это.
  • 2021-2022: Стало больше понимания, но 99% SRE не знают, как правильно определить SLO.
  • 2023-2024: SLO стали важны при принятии решений.
  • 2025: SLO помогают решать, что важнее – надежность или новые фичи, появились composite SLO и reliability scoring.

Что нового в SLO:

  • Composite SLOs: объединяют несколько SLO в одну метрику, чтобы видеть картину целиком.
  • Reliability scoring: оценивают надежность системы в цифрах.
  • Мониторинг в реальном времени и алерты: помогают управлять SLO.
  • SLO Development Life Cycle (SLODLC): как правильно внедрять SLO.

Error Budget Management – это целый рынок: он вырос с $1.2 млрд в 2024 году и, по прогнозам, будет $5.8 млрд к 2033 году. Это значит, что DevOps, SRE и cloud-native технологии становятся все популярнее.

Проблемы с SLO:

  • 51% считают, что observability не очень, особенно там, где мало инструментов.
  • SLO бесполезны, если их не использовать постоянно, потому что системы меняются.
  • Надо думать о пользователях: SLO должны показывать, что пользователи чувствуют, а не только технические метрики.

8. Автоматизация управления инцидентами и AIOps

Как развивалось:

  • 2020: Только начали автоматом делать алерты и тикеты.
  • 2021-2022: Активно развивали runbook automation и self-healing.
  • 2023-2024: Внедрили AIOps, чтобы связывать события и предсказывать проблемы.
  • 2025: AI помогает управлять инцидентами, общаться на обычном языке и автоматом искать причины проблем.

Как выглядит incident management в 2025:

  • Видят все в реальном времени: AI анализирует логи и события и сразу находит закономерности.
  • Алерты на будущее: ML предсказывает, где может случиться инцидент.
  • Автоматически чинят: системы сами исправляют проблемы, без людей.
  • Все общаются в одном месте: все стейкхолдеры сидят в одной системе.
  • Удобные workflows: инструменты для управления инцидентами работают прямо в Slack.

Важный момент: 40% инженеров участвовали в 1-5 инцидентах за последние 30 дней. При этом руководители тоже в деле, не меньше, чем обычные инженеры. 14% сильно стрессуют после инцидентов, потому что им не хватает поддержки.

Как дела с incident management (Global SRE Pulse 2022): больше 70% говорят, что у них хорошо спроектирован процесс управления инцидентами и алерты обрабатываются четко.

Как AI все изменил в 2025:

  • На 56% точнее находят угрозы, чем старые системы.
  • Анализ инцидентов занимает 2.8 минуты вместо 18.5.
  • Автоматизируют 78% действий при обычных инцидентах, раньше было 35%.
  • Ложных срабатываний стало меньше – с 25% до 8%.

9. Надежность vs. скорость: кто победит?

Плохая новость: большинство спецов (больше двух третей) чувствуют, что их заставляют выпускать релизы быстрее, чем это безопасно для надежности.

Почему так происходит:

  • Уходят те, кто создавал SRE: эксперты уходят из компаний, и приоритеты меняются.
  • Бизнес давит: хотят новые фичи и больше денег.
  • Не все понимают одинаково: инженеры и руководители по-разному оценивают надежность – чем выше должность, тем больше уверенности, что все хорошо.

Как было раньше: это старая проблема – что важнее, быстро или безопасно. SRE пытаются это решить с помощью error budgets и SLO. Но в 2025 давление стало слишком сильным.

Что делать:

  • Регулярно проверять и обновлять оценки процессов.
  • Звать внешних экспертов.
  • Улучшать культуру SRE и учить всех в компании, что надежность – это важно.
  • Использовать error budgets, чтобы принимать решения.

10. Структуры SRE-команд и как их организовать

Основные варианты (из книги Establishing SRE Foundations):

  1. You Build It, You Run It: разрабы сами отвечают и за разработку, и за эксплуатацию. Быстро деплоят, но много операционных задач и сложно управлять изменениями.
  2. You Build It, SRE Run It: разрабы пилят код, SRE занимаются операционкой. Может случиться разрыв между командами.
  3. You Build It, You and SRE Run It: все в ответе вместе – SRE управляют операционными задачами, разрабы пишут код, но все вместе смотрят на метрики.

Где команда SRE находится в компании (Global SRE Pulse 2022):

  • 30% — IT operations
  • 22% — отдельная команда
  • 18% — application design & development
  • 18% — IT infrastructure
  • 3% — IT security

Типы команд:

  • Centralized: помогают многим продуктам/сервисам.
  • Dedicated: занимаются конкретными продуктами.
  • Platform-based: строят облачные платформы.
  • Stack-based: отдельные команды для разных стеков приложений/инфраструктуры.

Главное правило Google SRE: максимум 50% времени на операционку, минимум 50% на engineering (улучшения, автоматизация, исправление проблем).

11. Observability: от мониторинга к AI

Как менялось:

  • 2020: Просто мониторили (метрики, логи).
  • 2021-2022: Перешли к observability (метрики + логи + трассировки).
  • 2023-2024: Observability всего стека, смотрят на user experience.
  • 2025: AI сам находит полезную информацию в телеметрии.

Что важно в 2025:

  • Slow is the new down: 53% компаний согласны, что плохая производительность – это так же плохо, как если бы все упало.
  • Много инструментов – это нормально: большинство компаний используют 2-10 инструментов для мониторинга/observability, и это не проблема, если они приносят пользу.
  • Разные данные: 81% компаний используют 2+ типа телеметрии, 43% – 4+ типа.
  • Что в приоритете: логи (65%), метрики (56%), события и трассировки.

Как все поменялось: раньше observability была нужна, чтобы люди могли понять терабайты данных. Сейчас, с AI, главное, чтобы машина могла быстро найти нужную информацию.

12. Обучение и развитие

Учиться надо: технические тренинги очень важны, чтобы освоить новые технологии, включая AI. Но каждая пятая компания на это забивает.

Как учатся (Catchpoint 2025):

  • Онлайн-платформы (55%).
  • Очное обучение (45%).
  • Конференции (41%).

Странно: все говорят, что учиться важно, но времени нет. Руководители учатся меньше других и, наверное, думают, что им это не нужно.

Важно для карьеры: DevOps Institute говорит, что SRE – это хороший способ продвинуться в IT, если прокачивать нужные навыки.

Выводы и что будет дальше

Главное из анализа

  1. Странности 2025: несмотря на AI и автоматизацию, Toil впервые вырос за пять лет, и AI пока не оправдывает надежд. Значит, дело не только в технологиях, но и в культуре и правильном подходе.
  2. SRE взрослеет: SRE стала серьезной штукой – 62% компаний в той или иной степени используют SRE (19% во всей компании, 55% в отдельных командах, 23% пробуют). SLO, error budgets и chaos engineering – это уже не ново, а стандарт.
  3. Все работают вместе: SRE, Platform Engineering, DevOps, DevSecOps и FinOps – это не конкуренты, а друзья, которые помогают друг другу. Компании, которые это понимают, получают больше выгоды.
  4. AI – это помощник, а не замена: AI помогает инженерам, а не заменяет их. AI должен быть частью культуры и процессов.
  5. Культура важнее: Puppet 2021 показал, что 78% компаний застряли на середине пути в DevOps/SRE, потому что думают только о технологиях, а не о культуре. Надо менять культуру, а не просто внедрять новые инструменты.
  6. Надежность под угрозой: все хотят быстро, но забывают про надежность. Надо этим управлять с помощью error budgets, SLO и объяснять всем, что надежность – это важно.

Что ждет нас после 2025

  • AI будет еще круче: AI будет лучше предсказывать проблемы, автоматом искать причины и чинить системы. Но важно помнить, что надо измерять, как AI влияет на производительность.
  • Platform Engineering станет важнее: платформы будут строить по строгим правилам, чтобы разрабам было удобнее. Internal Developer Platforms (IDP) станут стандартом для больших компаний.
  • Больше контроля: будут следить за тем, чтобы все было безопасно и надежно. Regulation as code станет важной темой.
  • Инструменты станут проще: все инструменты DevOps/SRE объединят в одну платформу, чтобы было проще управлять.
  • Экология: будут думать о том, как технологии влияют на экологию, и стараться делать все более зеленым.
  • eBPF: будут больше использовать eBPF, чтобы видеть, что происходит внутри системы, без лишних инструментов.
  • Kubernetes: Kubernetes останется главной системой для управления приложениями.
  • Zero Trust: безопасность станет еще важнее, и будут использовать принципы Zero Trust.

Что посоветовать компаниям

  1. Считайте Toil: регулярно проверяйте, сколько времени уходит на рутину, и выделяйте время на автоматизацию.
  2. Observability – это важно: переходите от простого мониторинга к полноценной observability с OpenTelemetry.
  3. SLO – это культура: SLO должны быть не просто цифрами, а частью процесса принятия решений.
  4. Пробуйте Chaos Engineering: начните с маленьких экспериментов в staging и постепенно переходите к production.
  5. Культура и люди: учите людей, создавайте атмосферу, где не боятся ошибаться, и поддерживайте друг друга.
  6. Не перегибайте с централизацией: выберите подходящую структуру SRE-команды, чтобы централизация помогала, а не мешала.
  7. Думайте, зачем вам AI: внедряйте AI, только если понимаете, какие проблемы он решает, и измеряйте результат.

SRE продолжает развиваться и становится все важнее для компаний. Чтобы добиться успеха в SRE, нужно уметь соблюдать баланс – между технологиями и культурой, между новым и стабильным, между скоростью и надежностью. Компании, которые это понимают, будут готовы к будущему.

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат, а так же подписывайся на канал.

О способах отблагодарить автора можно почитать на странице “Донаты”.