Подход SRE обещал более эффективный путь. Возникнув внутри Google и став популярным благодаря поколению платформенных инженеров, SRE предложил компаниям дисциплинированный, ориентированный прежде всего на инженерную практику подход к переходу от хаотичного «тушения пожаров» к предсказуемой и устойчивой эксплуатации систем. Однако спустя годы после массового распространения SRE многие организации обнаружили, что тратят на инструменты SRE больше денег, чем когда-либо, а дежурные инженеры по-прежнему тонут в инцидентах в два часа ночи.

Картина повторяется снова и снова. Названия должностей меняются. Количество дашбордов растёт. Закупаются платформы AIOps с поддержкой ИИ. Бюджеты ошибок определяются в таблице и тут же забываются. А через полгода отчёты о разборе инцидентов выглядят точно так же, как два года назад.

Что идёт не так? После анализа десятков инженерных организаций снова и снова всплывают одни и те же пять ошибок. Причём со временем они начинают усиливать друг друга так, что распутать последствия становится крайне сложно.

Переименовать команду эксплуатации в «SRE», не изменив сам подход к работе, — это организационный эквивалент спортивной полосы на семейном универсале.

1. Культурный провал — отношение к SRE как к переименованию команды, а не как к культурной трансформации

Оргструктура меняется. Система стимулов — нет. А дальше из этого вытекает всё остальное.

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

Настоящий SRE требует принципиально иных отношений между разработкой и эксплуатацией. Он предполагает, что разработчики несут ответственность за показатели надёжности, а SRE-инженеры имеют право замедлять выпуск новых функций, если исчерпан бюджет ошибок. Он требует атмосферы психологической безопасности для проведения безобвинительных пост-мортемов (разборов инцидентов), где инженеры могут честно рассказать, что произошло на самом деле, не опасаясь последствий для карьеры.

Нужны руководители, которые понимают, что расходование 90% бюджета ошибок — это информация для принятия решений, а не признак провала.

Ничего из этого не появляется после изменения оргструктуры. Для этого нужна последовательная и заметная поддержка со стороны руководства, направленная на изменение подхода к обсуждению, измерению и вознаграждению за надёжность по всей инженерной организации, включая продуктовый менеджмент и топ-менеджмент компании. Когда менеджеры продукта никак не отвечают за расходование бюджета ошибок, у них остаётся только один стимул — продолжать выпускать новые фичи.

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

Как это исправить

Культурная трансформация требует не формальной, а реальной поддержки со стороны руководства. Начните с внедрения измеримости надёжности на уровне управления компанией.

• Состояние бюджетов ошибок должно стать постоянной темой на общих инженерных встречах и продуктовых ревью.

• Обучайте работе с SLO и политиками бюджетов ошибок не только инженеров, но и менеджеров продукта.

• Заранее определите путь эскалации при исчерпании бюджета ошибок: кто принимает решение о заморозке разработки новых функций? Здесь не должно быть двусмысленности.

• Проводите безобвинительные разборы инцидентов публично и поощряйте инженеров, которые рано выявляют системные проблемы. Поведение определяется стимулами — меняйте то, что вознаграждается.

2. Ошибки кадровой стратегии — найм по регалиям вместо инженерного мышления и игнорирование способности устранять рутину

Неподходящий SRE-инженер начинает оптимизировать не те вещи и упускает самые важные точки приложения усилий.

Подход к найму в SRE постепенно приобрёл вполне предсказуемую патологию. Рекрутеры копируют описания вакансий из открытой книги Google про SRE, перечисляют все известные человечеству инфраструктурные технологии и затем ищут кандидатов, которые «занимались SRE в FAANG». В результате формируется команда, которая может быть технически очень сильной, но при этом совершенно не соответствовать по своему подходу реальным проблемам надёжности внутри компании.

По-настоящему эффективная работа SRE в своей основе строится на инженерном мышлении в условиях неопределённости. Здесь нужны инженеры, которые умеют строго оценивать риски, объяснять компромиссы SLO нетехническим участникам процесса, выявлять рутинную операционную нагрузку (toil) и создавать надёжную автоматизацию для её устранения, а также сопротивляться организационной инерции, которая со временем превращает любую хорошую SRE-команду обратно в обычную эксплуатацию.

Такие качества невозможно увидеть в резюме, и они почти никогда не проявляются на алгоритмических собеседованиях.

С этим связана ещё одна распространённая ошибка — формирование команды, у которой нет интереса к устранению toil. SRE-команды, нанимающие людей исключительно за навыки реагирования на инциденты, со временем превращаются именно в команды реагирования на инциденты. Причём они становятся очень хороши в устранении аварий, которых можно было вообще избежать.

Если в команде никто не заинтересован в проектной стороне SRE — разработке платформ, создании конвейеров автоматизации, проведении проверок надёжности, — то эта работа просто не выполняется.

Как это исправить

Перестройте процесс собеседований для SRE так, чтобы вы могли оценить именно инженерное мышление, а не знание технических мелочей. Добавьте сценарные интервью, где кандидата спрашивают, как он будет принимать решения при конфликте между скоростью разработки и бюджетом ошибок, чем займётся в рамках 20% времени на проектную работу и как станет возражать продуктовой команде, если та систематически ухудшает надёжность системы.

Отдельно оценивайте способность работать с toil: просите кандидатов подробно рассказать о примере рутинной нагрузки, которую они обнаружили и устранили.

Формируйте команду с взаимодополняющими компетенциями: одни инженеры должны иметь глубокий опыт триажа инцидентов, другие — быть мотивированы созданием платформ и инструментов, уменьшающих вероятность возникновения инцидентов.

И, наконец, оплачивайте труд SRE-инженеров на уровне самых сильных разработчиков компании — специфика этой роли этого требует.

3. Ошибки измерения — определить SLO в таблице и затем забыть о них

Бюджет ошибок, который никто не контролирует, — это просто число. А «театр SLO» хуже, чем полное отсутствие SLO.

Компании, прочитавшие книгу про SRE, обычно понимают на интеллектуальном уровне, что SLO и бюджеты ошибок — фундамент всей модели. Поэтому они действительно начинают их внедрять. Инженеров и менеджеров продукта собирают в переговорной, обсуждают, должна ли доступность составлять 99,9% или 99,95%, приходят к цифре, которая всех политически устраивает, а затем фиксируют её на странице в корпоративной wiki, куда больше никто никогда не заходит.

Это и есть «театр SLO», и встречается он удивительно часто. Признаки всегда одинаковые: если спросить технического руководителя, каков текущий уровень расходования бюджета ошибок, он этого не знает. Если спросить, останавливала ли хоть одна команда разработку новых фич из-за исчерпания бюджета ошибок, ответ обычно отрицательный. SLO существуют как документация, но не как часть реальной эксплуатации.

У плохо определённых SLO есть и собственные сценарии отказа. Если доступность измеряется как «время доступности основного балансировщика нагрузки», а не как «доля успешно выполненных запросов с точки зрения пользователя», то вы оптимизируете состояние инфраструктуры, а не пользовательский опыт.

В ситуации, когда балансировщик нагрузки работает, но база данных перегружена и 40% запросов завершаются по тайм-ауту, ваш дашборд SLO продолжит показывать зелёный статус. Это провал системы измерений, замаскированный под успех в обеспечении надёжности.

Как это исправить

SLO работают только тогда, когда становятся обязательной частью эксплуатационных процессов. Для этого необходимы три вещи.

Во-первых, определяйте SLO с точки зрения пользователя: измеряйте то, что реально видят пользователи, а не то, что сообщают инфраструктурные компоненты.

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

В-третьих, разработайте и внедрите политику работы с бюджетами ошибок ещё до запуска SLO. В этой политике должны быть чётко определены ответы на вопросы: что происходит при расходовании 50% бюджета? 90%? 100%? Кто имеет право заморозить выпуск новых релизов?

Без такой политики SLO превращаются в красивую, но бесполезную декларацию намерений.

4. AI/AIOps — поспешное внедрение ИИ-функций для обеспечения надёжности до создания полноценного Observability

Использовать машинное обучение поверх шумной и плохо структурированной телеметрии — один из самых дорогих способов остаться ровно там же, где вы были.

AIOps и инструменты обеспечения надёжности с поддержкой ИИ стали одной из самых быстрорастущих категорий на рынке DevOps-решений. Обещание выглядит крайне заманчиво: ИИ, который автоматически связывает оповещения между собой, предсказывает инциденты до их возникновения и генерирует эксплуатационные инструкции (runbooks) на основе исторических разборов инцидентов. Для SRE-команды, захлёбывающейся от усталости из-за бесконечных алертов, это звучит как спасение.

На практике большинство организаций, внедряющих такие инструменты, к ним не готовы. Более того, без качественной основы для наблюдаемости эти решения начинают активно ухудшать ситуацию.

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

В результате усталость от алертов превращается в путаницу с алертами, усиленную ИИ.

Ключевое условие для эффективного использования ИИ в задачах надёжности — не контракт с поставщиком решений, а чистая, хорошо структурированная и семантически насыщенная телеметрия.

Необходимы структурированные и пригодные для запросов логи, единообразно именованные метрики, связанные с SLO, распределённые трейсы, корректно отражающие прохождение запросов через систему, а также процессы дежурств, которые достаточно хорошо документированы и стандартизированы, чтобы модель могла на них обучаться.

Без этих основ ИИ просто не с чем полноценно работать.

Здесь возникает и другая проблема — проблема компетенций и доверия. Команды, внедряющие ИИ-помощников для реагирования на инциденты до того, как инженеры глубоко разберутся в собственных системах, создают опасную зависимость: инженеры начинают полагаться на диагнозы ИИ вместо того, чтобы развивать способность распознавать паттерны и системную интуицию, которые и делают SRE-инженеров действительно сильными специалистами.

А когда ИИ ошибается — а при достаточном масштабе он неизбежно будет ошибаться — у таких инженеров уже не хватает фундаментального понимания системы, чтобы вовремя заметить ошибку.

Как это исправить

• Прежде чем закупать AIOps-решения, честно оцените текущее состояние своего observability. Может ли ваша команда ответить на вопросы вроде: какова сейчас p99-задержка сервиса оформления заказов? Почему в прошлый четверг в 14:43 резко вырос уровень ошибок?

Если для ответа нужен человек с «историческим знанием» системы, а не обычный дашборд, значит ваша телеметрия ещё не готова к использованию ИИ.

• Сначала сократите объём алертов. Разумным ориентиром можно считать менее пяти действительно значимых вызовов на одного дежурного инженера в неделю. ИИ не способен исправить фундаментально шумную среду оповещений — он может лишь переупаковать этот шум.

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

• Сохраняйте системную интуицию дежурных инженеров. Инструменты ИИ должны усиливать человеческое инженерное мышление, а не подменять процесс его формирования. Даже если ИИ помогает с корреляцией событий, разборы инцидентов должны оставаться процессом, которым руководят люди.

5. Стратегические ошибки — масштабирование SRE быстрее, чем организация способна это переварить, и выгорание команды

Если внедрять SRE во все продуктовые команды до появления единых стандартов, одна хорошая SRE-практика быстро превращается в тридцать несовместимых друг с другом вариантов.

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

Нескольких опытных SRE-инженеров распределяют сразу между десятком продуктовых команд. Каждый встроенный в команду SRE начинает адаптировать практики под локальную культуру конкретного подразделения. Определения SLO начинают расходиться. Форматы эксплуатационных инструкций отличаются друг от друга. Политики маршрутизации алертов противоречат друг другу.

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

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

Именно их начинают бесконечно перебрасывать между дежурствами по системам, которые они едва знают. Времени на проектную работу, ради которой SRE вообще имеет смысл, у них больше не остаётся.

И вскоре так приходит выгорание. Следом — уход сотрудников.

А затем организация, потеряв своих сильнейших SRE-инженеров, делает вывод, что «SRE не масштабируется», вместо того чтобы признать: проблема была в неправильном подходе к масштабированию.

Ситуацию усугубляет и отсутствие инвестиций в саму SRE-команду. Инженеры, которые тратят 100% времени на эксплуатационную работу, не успевают изучать новые технологии, обновлять собственные инженерные модели или создавать общие платформенные решения, которые могли бы многократно увеличить эффективность работы разных команд.

Команда, неспособная инвестировать в собственное развитие, продолжает накапливать технический долг, фактически оставаясь на месте.

Как это исправить

Масштабируйтесь осознанно и постепенно. Прежде чем внедрять SRE в новую команду, определите критерии готовности: есть ли у команды инструментация сервисов? Определён ли SLO? Документированы ли инструкции для дежурств?

Используйте модель взаимодействия с SRE, которая различает полноценное встраивание инженеров в команду, консультационный формат и режим самообслуживания. Не каждой команде нужен выделенный SRE-инженер.

Жёстко защищайте время на проектную работу. Соотношение 50% проектной деятельности и 50% эксплуатационной работы из книги по SRE — не просто предположение, а убедительная рекомендация.

Создавайте общие платформенные решения — конфигурации PagerDuty, инструменты работы с SLO, библиотеки структурированного логирования — которые позволяют масштабировать стандарты надёжности без пропорционального роста штата.

Измеряйте нагрузку дежурств на каждого инженера. Если она превышает устойчивый уровень, рассматривайте это как архитектурную проблему, требующую инвестиций, а не как кадровую проблему, которую можно решить простым наймом дополнительных сотрудников.

Общий знаменатель

Если посмотреть на все пять ошибок вместе, становится заметна общая закономерность: компании воспринимают SRE как техническое решение проблемы, которая в своей основе является организационной и культурной.

Инструменты, дополнительные сотрудники и платформы с ИИ — это лишь усилители. Они усиливают либо ясность и дисциплину грамотно выстроенного SRE-подхода, либо хаос и рутинную операционную нагрузку плохо организованной системы.

Правильно выстроить фундамент — стимулы, измерения, кадровый подход и темп масштабирования — это не «скучная подготовительная работа» перед настоящей работой.

Это и есть настоящая работа.

Именно те команды, которые это понимают, продолжат успешно использовать SRE и через пять лет.

Если после статьи хочется приземлить тему на практику, 10 июня в 20:00 у OTUS пройдёт бесплатный урок «Мониторинг распределенных систем». На нём разберут, зачем мониторинг нужен именно в распределённых системах, как ставить для него нормальные задачи и чем отличаются подходы black-box и white-box. Заодно можно будет познакомиться с преподавателем курса по SRE и задать вопросы. Записаться на урок.

Готовы к обучению на SRE? Пройдите вступительное тестирование и узнаете, есть ли пробелы в знаниях.