Надёжность обсуждают без цифр
«Система вроде работала нормально» — единственный доступный аргумент. Продукт считает, что сбоев мало, поддержка видит очередь обращений, и договориться не получается.
SRE и надёжность
Надёжность в цифрах и договорённостях вместо «вроде работало»
Выбираем ключевые сценарии, задаём для них целевые показатели и считаем бюджет ошибок. Выстраиваем дежурства, разборы инцидентов без поиска виноватых и учения перед сезонными пиками.
Или сразу: +7 (962) 368-39-51 Telegram
3–5
ключевых сценариев вместо сотни метрик
28 дней
скользящее окно расчёта SLO
error budget
общий язык у продукта и эксплуатации
blameless
разбор причин, а не поиск виноватых
Как надёжность теряется в спорах
Разногласия между продуктом и эксплуатацией возникают не из-за разных целей, а из-за отсутствия общей метрики.
Релизов боятся и поэтому их откладывают
Чтобы не сломать продакшен, изменения копятся неделями. Крупный релиз повышает вероятность сбоя, сбой подтверждает страх — круг замыкается.
Пожары тушат, но не разбирают
Инцидент закрывают восстановлением сервиса, после чего все возвращаются к текущим задачам. Через месяц та же авария повторяется, потому что причины не разобраны и меры не назначены.
Дежурство держится на одном человеке
Звонят всегда одному инженеру, ротации и компенсации нет. Он выгорает и уходит, а вместе с ним уходит и знание системы.
Непонятно, когда можно рискнуть
Нет правила, определяющего, допустимо ли сегодня выпускать рискованное изменение. Решения принимаются настроением, а не остатком бюджета ошибок.
Сезонный пик застаёт врасплох
Распродажа, отчётный период или рекламная кампания дают нагрузку в пять раз выше обычной. Ёмкость планируется по средним значениям без нагрузочных испытаний.
Что входит в SRE-практику
Начинаем с измерений и договорённостей: без согласованных целевых показателей остальные процессы превращаются в формальность.
SLI, SLO и бюджет ошибок
Переводим разговор о надёжности в измеримые величины по сценариям, которые важны пользователю, а не по внутренним техническим метрикам.
- Выбор 3–5 ключевых сценариев: вход, поиск, оформление заказа, оплата, выгрузка
- Определение SLI на основе реального трафика и расчёт SLO на скользящем окне 28 дней
- Бюджет ошибок как договорённость: сколько недоступности мы допускаем в месяц
- Дашборд остатка бюджета и отчёт для продукта и руководства
Дежурства и работа с инцидентами
Строим процесс, при котором дежурство посильно для команды, а инцидент разбирается один раз, а не повторяется каждый месяц.
- Ротация дежурств, эскалация и понятные критерии привлечения второго инженера
- Матрица severity: что будит ночью, что ждёт утра, кто принимает решение
- Регламент коммуникации со стейкхолдерами во время инцидента
- Blameless postmortem: таймлайн, способствующие факторы и план действий с владельцами
Учения и проверка отказоустойчивости
Проверяем, что система действительно переживает отказ компонента, а не только выглядит отказоустойчивой в схеме на доске.
- Нагрузочное тестирование ключевых сценариев (k6, Vegeta) перед сезонными пиками
- Проверка деградации: отключение внешнего сервиса, узла, реплики, брокера очередей
- Тестирование отката релиза и восстановления из резервной копии на реальных данных
- Разбор результатов и корректировка целевых показателей по факту
Ёмкость и производительность
Считаем, сколько система выдержит и за счёт чего растёт: по профилю нагрузки, а не по среднему числу запросов в секунду.
- Профилирование медленных сценариев: запросы, SQL, внешние вызовы, фоновые задачи
- Оптимизация очередей, кэша и индексов там, где это даёт измеримый эффект
- Прогноз ёмкости на сезонные пики и планирование ресурсов заранее
- Регулярный обзор стоимости инфраструктуры вместе с ростом нагрузки
Как мы внедряем SRE
Практика приживается, когда она опирается на существующие данные. Первые шаги совместимы с текущим уровнем мониторинга.
-
01 1–2 недели
Базовые измерения
Собираем статистику по доступности и сбоям за последние месяцы, разбираем историю инцидентов, определяем, какие сценарии действительно критичны для бизнеса.
-
02 1 неделя
Согласование SLO
Формулируем целевые показатели вместе с продуктом и эксплуатацией, договариваемся о бюджете ошибок и о том, что происходит при его исчерпании.
-
03 2–4 недели
Процессы дежурств и разборов
Вводим ротацию, эскалацию и severity-матрицу, шаблон postmortem и правило разбирать каждый инцидент, влияющий на пользователей.
-
04 постоянно
Учения и регулярный цикл
Проводим нагрузочные испытания и учения по отказам, разбираем результаты, пересматриваем пороги и цели. Дальше цикл повторяется ежеквартально.
Как выбрать SLO, который не сожжёт команду
Самая частая ошибка — назначить «доступность 99,99%» по умолчанию. Такой показатель означает не более 4,3 минуты недоступности в месяц и требует резервирования на всех уровнях, включая внешние зависимости, которыми вы не управляете, и постоянного дежурства. Если цель не подкреплена бюджетом и процессами, она становится источником конфликтов, а не ориентиром.
Мы начинаем с реально достигнутого уровня, измеренного по фактическому трафику. Затем выбираем цель чуть выше текущей — например, при фактических 99,5% ставим 99,7% на квартал — и смотрим, что нужно изменить в архитектуре и процессах, чтобы её удерживать. SLO считается на скользящем окне (обычно 28 дней) по успешным запросам ключевых сценариев, а не по времени работы серверов: пользователю не важно, что процесс был запущен, если заказ не оформлялся.
Бюджет ошибок как инструмент переговоров
Бюджет ошибок — это допустимый объём недоступности, вытекающий из SLO. Он превращает спор «можно ли выпускать рискованное изменение» в арифметику. Формула проста: если целевой показатель 99,9% на 28 дней, бюджет составляет около 40 минут недоступности за период, и он расходуется как на аварии, так и на плановые работы.
Дальше работает политика, согласованная заранее. Пока бюджет не израсходован, команда может выпускать изменения в обычном режиме и экспериментировать. Когда израсходована половина, релизы требуют более внимательного контроля и обязательного плана отката. Когда бюджет исчерпан, новые функциональные изменения приостанавливаются, и команда занимается надёжностью: устраняет причины, пересматривает ёмкость, автоматизирует восстановление. Главное в этой схеме — то, что решение принимается по данным, а не под давлением, и что у продукта и эксплуатации появляется общая метрика.
Разбор инцидента без поиска виноватых
Цель postmortem — не найти виновного, а понять, почему система позволила ошибке привести к сбою. Если разбор превращается в поиск ответственного, инженеры начинают скрывать детали, и следующая авария происходит по тем же причинам с меньшей информацией.
Мы проводим разбор по фиксированному шаблону: хронология событий с точным временем обнаружения и реакции, влияние на пользователей и бизнес, способствующие факторы — технические, организационные и человеческие, — и что сработало хорошо. Итог разбора — план действий с конкретными владельцами и сроками, а не абстрактное «быть внимательнее». Отдельно проверяем время обнаружения: если о проблеме узнали от клиента, первая задача — не исправление, а алерт, который сообщит о ней автоматически.
Частые вопросы
DevOps — это подход к организации работы: одна команда отвечает и за разработку, и за эксплуатацию, а изменения доставляются автоматизированно. SRE — конкретная инженерная практика внутри этого подхода, которая вводит измеримые цели надёжности, бюджет ошибок, дежурства и разборы инцидентов. Проще говоря, DevOps отвечает на вопрос «как мы выпускаем изменения», а SRE — на вопрос «насколько надёжно работает то, что мы выпустили, и как это измерить».
Отдельная команда — нет, а практики — да. В небольшой компании роли распределяются между существующими инженерами: целевые показатели надёжности согласуются один раз, дежурство ведётся по ротации, а разбор инцидентов занимает час и заканчивается списком задач с владельцами. Дорого стоит не введение практик, а их отсутствие: повторяющиеся аварии и выгорание единственного человека, к которому звонят в любое время.
Первое — зафиксировать факт и посчитать, сколько бюджета израсходовано, чтобы разговор шёл о числах. Второе — разобрать причины в формате postmortem и отделить системные проблемы от разовых. Третье — приостановить рискованные изменения и направить усилия на надёжность: устранение единых точек отказа, автоматизацию восстановления, алерты на симптомы. После стабилизации цель можно скорректировать, если она оказалась недостижимой при текущей архитектуре и бюджете.
Минимум дважды в год и обязательно перед известными пиками: сезонными распродажами, отчётными периодами, крупными рекламными кампаниями. Отдельно раз в квартал полезно проверять деградацию: отключать реплику, внешний сервис или брокер очередей и смотреть, как ведёт себя система и что показывают алерты. Такие учения дешевле реальной аварии и обычно выявляют неожиданные зависимости — например, отсутствие таймаутов на вызове внешнего API.
DevOps: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Сколько недоступности в месяц вы готовы считать нормой?
Если ответа нет — начнём с измерений и согласуем целевые показатели надёжности для ваших сценариев.