Чеклист зрелости культуры SRE в компании¶

Можно купить дорогие инструменты мониторинга и нанять талантливых инженеров за 500000 рублей в секунду, но без правильной культуры это все равно, что построить гоночный болид Формулы-1 и посадить за руль водителя, который боится скорости. Культура SRE это система ценностей, практик и ожиданий, которые делают надежность приоритетом для каждого в компании, от стажера до CEO.

Этот чеклист поможет вам, даже если вы не инженер, оценить, на каком этапе находится ваша организация.

Уровень 0: реактивный хаос¶

"Пожары" - это норма.

Инциденты: реагирование на сбои происходит в панике. Поиск виновного - стандартная процедура после падения сервиса.
Планирование: нет понятия error budget и нет SLO. Надежность не обсуждается при планировании новых функций. Девиз: "Выкатываем как можно быстрее, кто и как будет поддерживать - потом разберемся".
Дежурства: дежурство - каторга и наказание. Нет четких процедур эскалации, а оповещения приходят бессистемно, часто среди ночи, по неважным поводам.
Автоматизация: большинство действий выполняется вручную. Повторяющиеся операции (развертывание, перезапуск) отнимают львиную долю времени инженеров.
Измерения: решение о надежности принимается на основе ощущений ("все вроде работает") или жалоб пользователей в поддержку. Нет ключевых метрик. Если надежность никак не измеряется, если значения до и после никак не сравнить, то процесс улучшения надежности никак не управляется.

Что делать? Начать с основ: внедрить написание постмортемов без поиска вины и определить хотя бы один ключевой SLO для главного продукта.

Уровень 1: начальный¶

Появились процессы, но они фрагментарны.

Инциденты: проводятся регулярные разборы полетов с фокусом на системные причины, а не на личности. Ведутся записи (постмортемы / база знаний).
Планирование: команды разработки знают, что такое SLO для их сервиса, но воспринимают его как досадное ограничение. Надежность начинает учитываться в оценках сроков.
Дежурства: существует график дежурств. Появляются runbook'и для решения частых проблем. Некоторые оповещения автоматически фильтруются.
Автоматизация: автоматизированы самые болезненные и рутинные задачи (например, развертывание в тестовое окружение). Команда начинает ценить время, сэкономленное автоматизацией.
Измерения: определены SLO и SLI для основных сервисов. Есть дашборды, но ими пользуются в основном SRE, а не разработчики или менеджеры продукта.

Что делать? Стандартизировать процессы. Сделать постмортемы и работу с SLO обязательной практикой для всех команд, запускающих новый функционал. Внедрить практику error budget.

Уровень 2: управляемый¶

Практики SRE стали стандартом работы инженерных команд.

Инциденты: постмортемы публичны и доступны всей компании. Выводы из них систематически превращаются в задачи (баги, фичи, улучшения инструментов). Существует классификация инцидентов по серьезности (Severity).
Планирование: Error budget используется, как реальный инструмент принятия решений. Если бюджет израсходован, команда фокусируется на улучшении надежности, а не на выпуске новых функций. Продукт-менеджеры говорят на языке SLO.
Дежурства: это почетная обязанность и часть карьерного роста. Runbook'и полны и актуальны. Существует практика искусственных инцидентов для тренировки новичков. Оповещения четко ранжированы и приходят адресно.
Автоматизация: автоматизировано большинство операционных задач. Команды разрабатывают сервисы с учетом возможности автоматического восстановления (self-healing). SRE тратят менее 50% времени на ручную операционную работу.
Измерения: SLO/SLI мониторятся в реальном времени и понятны всем заинтересованным сторонам. На их основе строятся долгосрочные планы по надежности (Reliability Roadmap).

Что делать? Горизонтальное масштабирование культуры. Делиться успехами с другими отделами. Активно вовлекать нетехнические команды в обсуждение надежности.

Уровень 3: надежность как преимущество¶

Надежность - часть компании и ее конкурентное преимущество.

Инциденты: в компании проводит упреждающие Game Days - плановые учения, где имитируются сбои, чтобы проверить и улучшить реакции и системы. Культура извлечения уроков распространяется за пределы инженерных команд.
Планирование: надежность является одним из ключевых факторов при принятии стратегических бизнес-решений (выход на новый рынок, запуск крупной акции). Error Budget Policy формализована и поддерживается руководством.
Дежурства: система надежна настолько, что дежурства становятся спокойными. Инженеры используют это время для проактивных улучшений и изучения системы. Психическое здоровье и work-life баланс дежурных в приоритете.
Автоматизация: cистемы обладают высокой степенью самоисцеления. Автоматизация предсказывает и предотвращает проблемы (с помощью ML и AIOps). Инженеры создают платформы, а не скрипты.
Измерения и культура: метрики надежности (SLO) публично показываются всем в компании и даже, в какой-то форме, клиентам, как доказательство качества сервиса. Надежность - часть бренда.

Как пользоваться этим чеклистом¶

Соберите фокус-группу из представителей разных ролей (разработчики, SRE, менеджеры продукта, руководители). Пройдите чеклист анонимно и обсудите расхождения в оценках. Это само по себе будет откровением, узнаете много нового :)
Не пытайтесь прыгнуть с "Уровня 0" на "Уровень 3". Выберите 1-2 пункта из текущего уровня, которые дадут максимальный эффект, и сфокусируйтесь на них в следующем квартале.
Улучшение культуры это тоже метрика. Определите, как вы поймете, что продвинулись (например: "Увеличить % пост-мортемов с выполненными action items до 80%" или "Снизить количество ночных оповещений на одного дежурного на 50%").
Рассказывайте о победах! Но только о реальных победах, не нужно рассказывать только ради того, чтобы рассказывать. Когда благодаря постмортему было предотвращено повторение крупного сбоя - это история успеха. Когда error budget спас команду от выгорания - это история успеха.

Культура SRE это не галочка, которую можно поставить и забыть. Это постоянно развивающийся организм, это процесс. Даже компании на "Уровне 3" постоянно экспериментируют и улучшают свои практики.

Итоговый вопрос должен звучать не "Достигли ли мы идеала и 99,999?", а "Стали ли мы сегодня надежнее, чем вчера, и понимаем ли мы, почему?". Если ответ "да" - все идет в правильном направлении.