Большинство людей знакомятся с обеспечением надёжности в самый неподходящий момент: в три часа ночи, когда дашборд красный, деплой развёрнут наполовину, а в чате кто-то спрашивает, не откатиться ли. SRE существует, чтобы сделать этот момент скучным. Не за счёт более напряжённой работы во время инцидентов, а за счёт того, чтобы заранее решить, какая доля ненадёжности допустима, — и позволить этому числу управлять релизами, штатом и автоматизацией.
В этом и заключается ключевой сдвиг. Надёжность — это не «100% аптайма»; это продуктовое решение, выраженное числом. Как только это число, с ним можно спорить, его можно тратить и его можно исчерпать. Эта статья о том, как это работает изнутри, где механизм даёт трещины и чего стоит его освоить.
Механизм: SLI, SLO и бюджет между ними
SLI (service level indicator, индикатор уровня сервиса) — это измерение: «доля успешных HTTP-запросов», «доля запросов быстрее 300 мс», «доля сообщений, обработанных за 60 с». SLO (service level objective, цель уровня сервиса) — это целевое значение этого индикатора на заданном окне: «99,9% успешных запросов за 30 дней». Разрыв между 100% и SLO — это бюджет ошибок.
Неочевидная часть: бюджет — это не статистика мониторинга, а счёт для расходования. SLO говорит, какую долю отказов продукт может выдержать; оставшийся бюджет — это то, что инженеры могут потратить на риск: деплои, миграции, эксперименты.
Разбор с реальными числами
Возьмём API с SLO 99,9% на 30 дней. Математика здесь арифметическая, а не статистическая:
- 30 дней = 43 200 минут.
- 0,1% от этого = 43,2 минуты полной недоступности в месяц.
- Или, если считать неуспешные запросы: 10 млн запросов в месяц × 0,001 = 10 000 неуспешных запросов.
Теперь решение. Прошло две недели, бюджет израсходован на 60%, и запланирована рискованная миграция базы данных. Практик не спрашивает «безопасна ли миграция?» — он спрашивает «каков наш оставшийся бюджет и во что обойдётся ошибка?». Если миграция с высокой вероятностью сожжёт оставшиеся 40%, её откладывают или выпускают за фича-флагом с поэтапным развёртыванием, чтобы отказы были локализованы.
Порядок шагов здесь важен. Новички обычно начинают с инструментов: ставят Prometheus, рисуют дашборд, выбирают 99,99%, потому что это звучит профессионально. Рабочий порядок обратный:
- Выберите SLI, который отражает боль пользователя — для оформления заказа «успешный платёж» важнее, чем «CPU ниже 80%».
- Установите SLO исходя из того, что действительно нужно продукту, а не из того, что система достигает сейчас.
- Вычислите бюджет и запишите, на что он предназначен.
- Только после этого выбирайте оповещения — и оповещайте по скорости сжигания бюджета, а не по мгновенным всплескам. Часовой всплеск с 5% отказов при SLO 99,9% тревожен; 2% отказов, держащиеся сутки, хуже и часто остаются незамеченными.
Рутина, дежурства и почему пейджер — это проектный документ
Рутина (toil) — это работа ручная, повторяющаяся, автоматизируемая и линейно растущая вместе с сервисом. Перезапускать зависший воркер каждое утро — рутина. Написать скрипт, который его перезапускает, — и оповещение о том, почему он завис, — уже нет. Команды, которые никогда не измеряют рутину, обнаруживают её только тогда, когда дежурный сгорает.
Качество дежурств тоже измеримо, и это в основном проектная проблема, а не проблема дисциплины. Если одно и то же оповещение срабатывает пять раз в неделю и каждый раз исправление — «игнорировать», оповещение неправильное. Действенное, срочное и привязанное к runbook — вот планка. Всё остальное — в очередь тикетов, а не на пейджер.
У инцидентов своя механика. Роли, которые важны — incident commander (принимает решения, не отлаживает), scribe (хронология), comms lead (общается с заинтересованными сторонами), — существуют для того, чтобы человек с самым глубоким техническим контекстом не отвечал одновременно на вопрос «когда это починят?». Без разделения ролей лучший инженер становится узким местом в первые десять минут.
Безвинный постмортем — это продолжение: хронология, способствующие факторы и задачи с ответственными и сроками. «Безвинный» не значит «без последствий»; это значит, что анализ нацелен на системы и решения, потому что люди, боящиеся наказания, скрывают детали, которые вам нужны.
Где сама схема даёт сбой
Набор инструментов SRE — это модель, а модели отказывают предсказуемым образом.
- SLO установлен по неверному пользовательскому сценарию. Вы измеряете доступность фронтенда, тогда как реальная боль — медленный платёжный провайдер. Симптом: дашборд зелёный, а обращения в поддержку — нет. Исправление: выводите SLI из жалоб и данных поддержки, а не из того, что легко инструментировать.
- Бюджет становится политическим оружием. Одна команда сжигает его на релизах, другой велят его «защищать», и разговор превращается в поиск виноватых. Симптом: обсуждения бюджета появляются в оценке эффективности. Исправление: запишите политику бюджета до первого спора — кто может его тратить, на что и что происходит при нуле.
- Сервис меняет форму, а SLO — нет. Монолит становится десятью сервисами; старое SLO теперь покрывает лишь часть трафика. Симптом: никто не может сказать, к какому SLO относится данное оповещение. Исправление: пересматривайте SLO по расписанию, привязанному к изменениям архитектуры.
- Хаос-эксперименты перестают быть безопасными. День хаоса, который вносит задержку в общую зависимость, может задеть реальный путь клиента. Симптом: радиус поражения эксперимента описан прозой, а не ограничениями. Исправление: ограничивайте эксперименты по охвату, длительности и условию автоматической остановки, и сначала проводите их на стенде или на канареечном экземпляре.
Если уже слишком поздно — бюджет исчерпан, доверие потеряно — восстановление обычно одинаково: заморозить рискованные изменения, заново откалибровать SLO по реальности и перестроить оповещения вокруг скорости сжигания с небольшим числом пейджей.
Пути обучения и их реальная стоимость
| Путь | Время | Стоимость | Что вы получаете |
|---|---|---|---|
| Самостоятельное изучение (книги, доклады, документация) | Месяцы, неравномерно | Низкая | Сильная теория, слабая обратная связь; вы так и не узнаете, выдержал бы ваш дизайн SLO проверку |
| Практика на работе | 1–2 года | Бесплатно, но медленно и дорого из-за инцидентов | Реальные ставки, реальные последствия, никакой безопасной песочницы |
| Структурированный курс | Недели | Умеренная | Последовательный путь и кто-то, проверяющий ваши рассуждения |
Пробел в самостоятельном изучении — не информация, а обратная связь по решениям. На вопрос «какой SLO должен быть у этого сервиса» нет правильного ответа; есть только защитимый, и разницу вы узнаёте, только когда кто-то оспаривает ваши числа.
Кому это подходит — а кому нет
SRE подходит инженерам, которые любят системное мышление и готовы нести ответственность за решения с видимыми последствиями: разработчикам, движущимся к эксплуатации, системным администраторам, движущимся к продуктовому мышлению, тимлидам, которым нужен язык для компромиссов по надёжности. Это не подходит тем, кто ищет чисто инструментальный путь сертификации, или тем, кто хочет полностью избежать дежурств — дисциплина строится вокруг них.
Структурированный маршрут помогает больше всего, когда у вас уже есть некоторый операционный контекст и нужно отточить рассуждения. Site Reliability Engineering (SRE) построен на практике Google SRE и опыте облачно-нативных команд, с персонализированными уроками, которые адаптируются к вашему уровню, — и он проходит через математику бюджета ошибок, шаблоны постмортемов и дизайн SLO для реального сервиса, так что ваши решения проверяются, а не остаются непротестированными.
Начните с одного сервиса, которым вы действительно управляете: выберите единственный SLI, отражающий боль пользователя, вычислите бюджет на 30-дневное окно и запишите, на что вы его потратите. Если вы можете защитить этот абзац перед скептически настроенным коллегой, вы уже мыслите как SRE — а курс будет рядом, когда вам понадобится остальной механизм вокруг этого.
Начать можно здесь: SRE: инженерия надёжности сервисов.