SRE — Site Reliability Engineering, инженерия надёжности сайтов. Подход придумали в Google в начале 2000-х, когда посадили программистов управлять продакшеном: вместо «стараемся, чтобы не падало» появились измеримые цели надёжности и код, который эти цели защищает. Главный вклад SRE в индустрию — превращение надёжности из пожелания в арифметику: SLI, SLO и бюджет ошибок.
Надёжность переводится в бюджет ошибок
SLI, SLO и бюджет ошибок
Три термина, на которых стоит вся конструкция.
SLI (Service Level Indicator) — что меряем. Не «сервис работает», а конкретная метрика: доля успешных запросов, время ответа 99-го перцентиля, доля свежих данных в выдаче.
SLO (Service Level Objective) — целевое значение SLI. Например: 99,9% запросов за месяц отвечают успешно и быстрее 500 мс.
Бюджет ошибок — допустимая доля неуспешных событий: 100% минус SLO. При цели 99,9% запросов это 0,1% запросов: например, 3000 из 3 млн за выбранное окно. Перевести их в минуты без данных о трафике нельзя. Если же SLI измеряет долю времени доступности, за 30 дней получается 43 200 минут и бюджет 43,2 минуты недоступности. Пока бюджет цел, команда имеет право рисковать: катить релизы, менять инфраструктуру, экспериментировать. Бюджет сгорел — новые фичи замораживаются, и инженерное время уходит на надёжность.
Эта арифметика снимает вечный конфликт «разработка хочет релизить, эксплуатация хочет стабильности». Спор заменяется числом, о котором договорились заранее.
Почему цель — не 100%
Стоимость повышения надёжности зависит от архитектуры, нагрузки и способов восстановления. Если считать доступность по времени за 30 дней, 99% допускает 7,2 часа простоя, 99,9% — около 43 минут, 99,99% — около 4,3 минуты. Ни одно из этих значений не является нормой для всех продуктов: SLO выбирают под пользовательский сценарий, последствия сбоев и цену их предотвращения. Цель 100% не оставляет бюджета ошибок; прежде чем её обещать, нужно оценить, достижима ли она и нужна ли пользователям.
Чем SRE занимается в будни
Дежурства и инциденты — видимая часть: алерт пришёл, надо диагностировать и вернуть сервис. Но зрелость SRE меряется невидимой частью — тем, что происходит после. Постмортем — разбор инцидента с хронологией, причинами и задачами, чтобы этот класс отказов не повторился. Постмортемы пишутся blameless — без поиска виноватых: наказание за честный рассказ гарантирует, что в следующий раз правды не будет.
Вторая постоянная работа — война с toil: ручными повторяющимися операциями. Правило Google — на toil должно уходить меньше 50% времени SRE, остальное — на инженерную работу, которая toil сокращает: автоматизация, инструменты, устранение классов проблем. Перезапустил сервис руками — запиши; перезапускаешь второй раз — напиши автоматику.
SRE и DevOps: философия и реализация
Внутри Google это формулируют так: «class SRE implements DevOps» — SRE реализует интерфейс DevOps. DevOps — набор принципов: одна команда на весь цикл, автоматизация, общая ответственность за прод. SRE — конкретная инженерная дисциплина с числами: вот SLI, вот SLO, вот бюджет, вот правила, что делать при его сгорании. На практике роли пересекаются: DevOps-инженер строит трубу поставки, SRE следит, чтобы то, что по ней едет, не разваливало продакшен. В небольших командах это один и тот же человек.
Мифы, которые мешают
«SRE — это дежурный админ». Дежурство — меньшая часть роли. SRE в первую очередь пишет код: автоматику, инструменты диагностики, защиту от повторения инцидентов.
«Надёжность — забота SRE, остальные пишут фичи». Бюджет ошибок общий. Его тратят релизы всей команды, и фриз при сгорании останавливает всех — поэтому и беречь его выгодно всем.
«Начнём считать SLO, когда вырастем». Ровно наоборот: один честный SLI на главную пользовательскую операцию («оплата проходит успешно») можно завести в любой день, и он сразу заменяет спор «падаем часто или нормально» на цифру.
Частые вопросы
Чем SRE отличается от DevOps-инженера
DevOps — про скорость и автоматизацию поставки, SRE — про измеримую надёжность того, что поставлено. Первый отвечает «как быстро и безопасно доехать до прода», второй — «как прод при этом держит цель 99,9%».
Что такое error budget простыми словами
Разрешённый объём сбоев: 100% минус SLO. При цели 99,9% успешных запросов это 0,1% запросов; при 99,9% доступности по времени за 30 дней — 43,2 минуты. Он превращает надёжность в ресурс, который можно осознанно тратить на риск — или беречь.
Что такое постмортем
Документ после инцидента: что случилось, как чинили, почему стало возможным, какие задачи не дадут повториться. Обязательное свойство — blameless: разбирается система, а не люди.
Какие вопросы задают на собеседовании SRE
Классика: сигналы и коды возврата процессов, диагностика «сервис не отвечает», арифметика SLO, устройство мониторинга. Проверить базу можно на вопросах по DevOps и в скилл-тесте.
С чего начинать путь в SRE
С того же фундамента, что и DevOps: Linux, сети, один язык программирования — плюс привычка всё мерить. Google выложил обе свои книги по SRE бесплатно (ссылки в источниках) — это до сих пор лучший учебник дисциплины.