SLA, SLO, SLI

Три слова, которые путают зря

Эти три термина постоянно смешивают, и смешение дорого обходится, потому что прячет, кто за что отвечает. Зафиксируем:

• SLI — Service Level Indicator (индикатор). Число, которое ты реально измеряешь. «Доля HTTP-запросов, вернувших 2xx/3xx менее чем за 300 мс.» Это отношение хороших событий к валидным, посчитанное по реальному трафику. SLI — это факт.
• SLO — Service Level Objective (цель). Цель, к которой ты держишь этот SLI внутри. «99,9% запросов успешны под 300 мс, измерено за 28 дней.» Это цель, которую ты ставишь себе сам. SLO — это решение.
• SLA — Service Level Agreement (соглашение). Контракт с клиентом о том, что будет, если ты промахнёшься — обычно возврат денег или сервисный кредит. «Если месячная доступность упадёт ниже 99,5%, ты получаешь 10% месячной платы назад.» SLA — это обещание с деньгами.

Зависимость идёт в одну сторону: ты измеряешь SLI, целишься в SLO и обещаешь SLA. Без хорошего SLI твой SLO — фикция, а SLA — иск, ждущий своего часа. У команды из вступления было всё три — просто они построили их на индикаторе («TCP подключился»), который не имел отношения к опыту пользователя («оформление сработало»).

Девятки и чего стоит каждая

Когда стейкхолдер требует «пять девяток» — ты понимаешь, на что соглашаешься и в какую сумму это выльется? Доступность обычно выражают в «девятках» — проценте времени, что сервис поднят за некое окно. Арифметика девяток неинтуитивна, потому что каждая лишняя девятка режет допустимый простой в 10×, и абсолютные числа быстро становятся крошечными:

доступность     простой/год     простой/месяц    простой/день
99%    (две 9)     ~3,65 суток      ~7,2 часа       ~14,4 мин
99,9%  (три 9)     ~8,76 часа       ~43 мин         ~1,44 мин
99,99% (четыре 9)  ~52,6 мин        ~4,3 мин        ~8,6 с
99,999%(пять 9)    ~5,26 мин        ~26 с           ~0,86 с

Читай колонку «месяц» медленно — это окно, которое использует большинство SLO. При трёх девятках ты можешь лежать ~43 минуты в месяц — один плохой деплой и откат влезают сюда. При четырёх девятках у тебя ~4,3 минуты — один человек, которому пришёл алерт, который залогинился и среагировал, уже это пробивает, так что четыре девятки фактически требуют автоматического failover. При пяти девятках (~26 секунд в месяц) человека в петле нет вообще; ты платишь за полностью автоматическое обнаружение и восстановление, мульти-региональное резервирование и инженерную организацию, чтобы всё это вести. Каждая девятка — примерно на порядок больше денег и операционной зрелости, чем предыдущая — поэтому «мы хотим пять девяток» от команды, которая деплоит вручную в пятницу под вечер, — это разговор о бюджете, а не об инженерии.

Почему SLO ниже SLA

Надёжная команда никогда не ставит внутренний SLO равным подписанному SLA. Она намеренно ставит SLO жёстче SLA — обещаешь клиенту 99,5%, целишься в 99,9%. Зазор — это буфер: если пробил внутреннюю цель 99,9%, срабатывает алерт, и у тебя есть запас среагировать до того, как пробьёшь контракт 99,5% и будешь должен возвраты. SLO — это пожарный датчик; SLA — горящее здание. Будь они равны, ты бы впервые узнал о беде, когда деньги уже ушли.

Есть и тоньше причина: SLA — юридический и коммерческий артефакт, часто оговариваемый консервативно и медленный к изменениям. SLO — инженерная ручка, которую крутишь по мере того, как узнаёшь, что достижимо и что пользователям реально нужно. Раздельность позволяет инженерии затягивать или ослаблять цель без перезаключения контракта.

Бюджет ошибок: разрешение тратить надёжность

Самая полезная идея во всей этой области — обратная сторона SLO. Если твой SLO — 99,9% успешных запросов, то 0,1% разрешено отказывать — эти 0,1% и есть твой бюджет ошибок (error budget). За окно в 28 дней при, скажем, 100 миллионах запросов это 100 000 запросов, которые ты можешь «потратить» на отказ, прежде чем пробьёшь цель.

Это переформулирует надёжность с «никогда не падать» (невозможно и неверная цель) на «оставаться в бюджете». А бюджет — это ресурс, который можно тратить, что растворяет классическую драку между продуктом (катить фичи) и SRE (держать стабильность). Практика SRE в Google это конкретизирует: если бюджет остался — катишь; если бюджет исчерпан — политика замораживает рискованные запуски, и команда тратит усилия на надёжность, пока бюджет не пополнится. Спорит число. Команда, безупречная весь месяц, имеет бюджет, чтобы спалить его на рискованную миграцию; команда, у которой только что был инцидент, в долгу по бюджету и должна притормозить. Важно: тратить бюджет — нормально и ожидаемо — вечно неистраченный бюджет ошибок часто значит, что ты переинвестировал в надёжность, которую пользователи не просили и которую можно было пустить на фичи.