Горящие релизы и ночные дежурства: мой персональный ад

Когда я пришёл на проект, всё было похоже на нескончаемый пожар. В продакшене сыпались алерты один за другим, CI/CD-пайплайны (GitLab и Jenkins) постоянно фейлили, а релизы проходили хаотично — каждый новый билд мог «уложить» сервис. Я пил кофе в три ночи, когда прозвучал очередной звонок на мобильник: «сервис упал — немедленно разбирайся!». MTTR (Mean Time To Recovery) измерялся часами, а “шум от алертов” заглушал любой здравый смысл. Коллеги начали бояться отпусков – постоянно включённый PagerDuty выматывал: начало рабочего дня плавно перетекало в ночной режим. Проще сказать, чем сделать: надёжности — ноль, стресса — зашкаливает. 

Знакомство с SRE: первые SLO и SLI

Ситуация не могла продолжаться. Я вынужден был искать выход и наткнулся на концепцию Site Reliability Engineering (SRE). Это показалось сложным американизмом, но чем дальше – тем понятнее: речь о том, чтобы перестать тушить пожары и системно подходить к надёжности. Первое, что мы сделали – ввели понятия SLO и SLI. Признаться, без гугления я бы запутался. На счастье, в русскоязычных переводах SRE книги нашёл чёткое объяснение: «SLO указывает целевой уровень надёжности сервиса», а «SLI — это индикатор уровня предоставляемого обслуживания». Проще говоря, SLO – это наше обещание (например, 99.9% времени сервис «в железе»), а SLI – метрика, которая показывает реальную работу (доля успешных запросов, задержки и т.п.).

 Мы принялись вместе с продуктовым владельцем определять SLO – тот самый порог надёжности. Например, решили, что 95% HTTP-запросов должны отвечать не дольше 200 мс. Для этого нужно измерять SLI – реальные времена отклика. Важное правило: не надо обещать себе 100%-ю надёжность сразу. Лучше поставить реалистичный SLO (например, 99.9%) и со временем улучшать. (Например, SLO = 99.9% означает, что на каждую тысячу запросов допускается 1 ошибка или медленная операция.) Мы установили ежедневные мониторы, которые собирали SLI из Prometheus. Постепенно увидели, что SLI метрики скачут, и начали снижать SLO до «достижимого», чтобы не валить команду в панику. Процесс настройки SLO/SLO был поначалу чисто воображаемым: записывали значения на доске, обсуждали цифры с бизнесом и командой. Важное правило: последнее слово остаётся за владельцем сервиса – мы лишь консультируем и считаем. 

Наблюдаемость: от «золотых сигналов» к умным алертам

Следующим шагом стала настройка мониторинга (observability). Прежде мы мониторили наощупь, решив напоследок убить всю инфраструктуру инструментами, но толку не было: метрик много, алертов ещё больше. Чтобы найти смысл, я вспомнил про «четыре золотых сигнала» SRE (latency, traffic, errors, saturation). Как пишет Google SRE, дашборды должны содержать «задержки, трафик, ошибки и нагрузку» (saturation). Мы взяли за основу эти сигналы: через Prometheus начали собирать задержки запросов, частоту обращений, процент ошибок и загрузку ресурсов (CPU/RAM). Grafana помогла увидеть временные ряды, а в ELK стек (Elasticsearch/Logstash/Kibanaпоехали логи для разбора деталей.

 Но метрик стало столько, что появился новый вызов – «сигнал против шума». Когда приходит сто оповещений в минуту, теряется смысл. В духе SRE мы решили как можно больше автоматизировать и исключить тривиальные алерты. Как пишут в SRE-руководстве Google: «эффективные системы оповещений имеют хорошее соотношение сигнал/шум». Мы выдвинули принцип: каждое правило оповещения должно быть максимально простым и надежным. Например, вместо бессмысленной тревоги по выросшему порогу (которая повторяется десятками по нескольку раз в день) мы перешли к комбинированным условиям («срабатывает только при 3 ошибках подряд»). Сфокусировались на явных симптомах, а не на «шуме»: если система начинает отвечать с HTTP 500, это — настоящий сигнал, а не те же 404 от ботов. Как итог, количество ложных тревог упало в разы, и команды начали быстрее реагировать на реальные проблемы.

Постмортемы без обвинений: учимся на ошибках

Наши инциденты стали учителями, а не поводом отстреливать ответственных. Мы ввели формат blameless postmortem — разбор без обвинений. То, чему нас учили, чётко отражено одной фразой из SRE-практик: «Каждый инцидент — это возможность улучшить систему, а не повод найти виноватого». На первой встрече постмортема мы исключили «аудиторию виноватых»: вместо упрёков спрашивали «как и почему так могло случиться? Чего нам не хватило?». Например, вместо «Кто сломал базу?» теперь звучало «Почему автоматизация позволила это сделать? Чего не хватило – проверки, документации, мониторинга?». Ошибки стали рассматривать как сбой процесса, а не человека.

 Такой подход действительно работает: команда перестала бояться оперативных разборов, и инциденты начали эффективно исправляться. Мы писали не «страшилки» в Jira, а конкретные action items: например, «добавить проверку в пайплайн», «настроить алерт по загрузке подрантов», «улучшить документацию запуска контейнера». После каждого postmortem в план попадала хотя бы одна улучшалка. Спасибо культурам SRE, которые говорят: «Blameless culture делает системы более надёжными, а инженеров — более уверенными». И правда: когда люди не боятся признаваться в ошибках, они начинают активнее придумывать улучшения.

Бюджет ошибок и релизы: когда катим, а когда ждём

Впитав SLI/SLO, мы получили мощный инструмент для диалога с бизнесом: Error Budget. Проще говоря, это «запас надёжности»: величина, на сколько мы можем «слить» SLO, прежде чем остановиться и исправлять проблему. В цифрах: если SLO = 99.9%, то error budget = 0.1%. Например, при миллионе запросов в месяц это всего 1000 неуспешных операций. Когда мы видим, что за месяц «сожжено» уже 90% бюджета ошибок, у нас «горит красный свет» для новых функций. Мы объявили такую политику: «Если сервис в норме — релизы идёт по расписанию. Если бюджет ошибок исчерпан, все фичи на паузе, фокус на надёжности». Это прописано, например, в примере политики SRE: при превышении error budget «останавливаются все изменения (кроме критичных хотфикс-ов), пока сервис не вернётся в SLO».

 Для бизнеса это аргумент «из кости»: мы договорились, что если «белые пятна» в стабильности не исчерпаны — можно катить. Но если показатели пошли вразнос — нужно «спуститься с газу» и разобраться. В живописном виде мы показывали диаграмму: SLO план-центр (горизонтальная линия), реальные значения SLI (линия с выбросами), и область error budget (расстояние между SLO и 100%). Когда видят красный — бизнес понимает, что пора остановить потоки фич и срочно исправлять. Так мы превратили неуловимый «запрос на стабильность» в конкретную политику с понятными цифрами.

Надёжность в бэклоге: стабилизация как фича

Надёжность перестала быть «вечным долгом». Мы встроили её в процесс разработки: теперь у нас есть зависимости от надежности в бэклоге. В планах появились задачи вроде «проработать отказоустойчивость», «автоматизировать развёртывание», «добавить мониторинг X». Никто не летал в воздухе — всё официально оценивалось планировщиками. Например, мы:

• Автоматизировали CI/CD. Перевели все задачи билда в GitLab CI/CD и Jenkins Pipelines, чтобы минимизировать ручной ввод. Каждый новый сервис теперь разворачивается несколькими кликами благодаря заранее настроенным скриптам.

• Инфраструктура как код. Написали Terraform-манифесты и Ansible-плейбуки для развёртывания кластеров. Одно нажатие кнопки — и готов новый майнинг-пул Docker/Kubernetes. Это сильно снизило риск «рутинных» проблем при расширении мощностей.

• Контейнеризация и оркестрация. Перевели приложения в Docker и настроили Kubernetes. Появились автоскейлинг и «канареечные» релизы, так что новый код теперь выкатывается постепенно, а не сразу на всех пользователей.

• Наблюдаемость по умолчанию. При каждой задаче по новой фиче мы сразу добавляли Prometheus-метрики и дашборды в Grafana. Логи всех сервисов ушли в центральный ELK, чтобы любой инцидент можно было быстро отследить.

• Процессы и культура. Составили runbook’и для критичных сервисов и регламент выполнения OnCall. Установили, что на каждое инцидентное событие заводится карточка в бэклоге с конкретным планом «как предотвратить».

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

Итоги: спокойнее и умнее

Спустя год изменений ситуация выглядит иначе. Мы по-прежнему используем Docker/Kubernetes, Terraform/Ansible, GitLab CI, Prometheus/Grafana/ELK и прочие инструменты, но на эти штуки уже не смотрим «как на панацею». Мы не убегаем от ошибок – мы их анализируем. MTTR упал в разы: теперь от сигнала «сервис не отвечает» до первого отклика инженера проходит не 40 минут, а считанные минуты, благодаря чётким процедурами и готовым шаблонам действий. Алёрт-шум снизился (ведь остались только важные тревоги, а не сотня спам-сообщений). Стабильность возросла – пользователи перестали видеть внезапные «упадания» сервиса в вечер выходного дня.

 Главный вывод: меньше стресса, больше смысла. Мы превратили бессистемное тушение пожаров в упорядоченный процесс. “Насколько устояли SLO” стало мерилом прогресса; “сколько ошибок съели” – показателем риска; “сколько осталось тишины в PagerDuty” – косвенным доказательством успеха. Как говорят SRE’шники, «мы выбрали уровень надёжности, который можем себе позволить, и добились его, работая в режиме error budget».

 Вместо вечного «всё упало – бегите чинить!» теперь каждый знает свою роль: мы можем спокойно принимать новые решения (например, менять инфраструктуру или выкатывать фичи), когда error budget позволяет; и выкладывать руки (делать стабилизацию) когда нет. В итоге команда стала уверенней, процессы — прогнозируемее, а работа — умнее. И это главное: мы работаем спокойнее и умнее – именно этого добивались, познакомившись с SRE-подходом.

Источники и материалы: в этой истории использованы идеи Google SRE (например, о SLO/SLI, «четырёх золотых сигналах», сигнал/шум, blameless culture, error budget и надёжностном бэклоге) и наш собственный опыт их применения.