🔖SLA, SLO и SLI простыми словами - часть 1

Большинство инженеров начинают путь с простой задачи - сделать так, чтобы ничего не падало. И в этом нет ничего плохого. Мы ставим мониторинг, настраиваем алерты и радуемся когда всё “зеленое”

Но спустя пару месяцев пользователи начинают жаловаться:

«Поиск выдает результаты через 5 секунд»
«Платежи проходят с задержкой»
«Интерфейс зависает при большом количестве данных»

Метрики — в норме, инфраструктура стабильна, но пользователю от этого не легче. И тут проблема в том, что мы не умеем измерять, насколько хорошо она работает с точки зрения опыта конечного пользователя.

1. От “горит или нет” к пониманию, как горит

Мониторинг обычно отвечает на вопрос: “жив ли сервис”. Но он не отвечает на вопрос: “живёт ли он хорошо”.

Пример: В одном интернет-магазине серверы не перегружены, ошибок 500 нет, но продажи упали на 7%. Оказалось, при переходе к оплате страница грузилась по 6-7 секунд и пользователи просто уходили. С точки зрения мониторинга - всё “зелёное”. С точки зрения бизнеса - потеря денег.

2. Что значит «работает хорошо»?

Чтобы говорить о качестве, нужно зафиксировать, что вообще считается “хорошим”. Для этого инженеры используют три понятия:

- SLA (Service Level Agreement) - "обещание" пользователю. Например: “Сервис доступен 99,9% времени”.
- SLO (Service Level Objective) - цель, к которой стремится команда. Например: “99,95% запросов выполняются за ≤ 200 мс”.
- SLI (Service Level Indicator) — конкретный измеряемый показатель. Например: “latency P99”, “ошибки 5xx”, “успешные транзакции”.

Пример: API биллинга установил SLO: 99,9% запросов быстрее 150 мс. Однажды latency вырос до 400 мс - не авария, но выход за цель. Виноваты оказались обновления сервиса, подгружавшие ненужные связи. После фикса всё вернулось в норму.

3. Бюджет ошибок как кредит доверия

Любая система допускает небольшой процент сбоев. Этот процент - бюджет ошибок. Если SLA 99,9%, то за год допустимо примерно 8 часов простоя.

Бюджет ошибок - это не KPI, а инструмент. Он даёт право на риск. Это возможность для команды использовать бюджет в своих интересах. Бюджет ошибок помогает решать - где стоит рисковать, а где пора стабилизировать.

Примеры: Команда внедряет новый алгоритм рекомендаций. Но есть риск, что новая система снизит продажи или перегрузит сервера запросами. Команда видит, что у них есть в бюджете ошибок время на эксперименты и они решаются катить изменения, чтобы проверить новую фичу. Таким образом вместо того чтобы доводить всё до идеала - они могут просто “освоить бюджет” и им ничего за это не будет. И если всё прошло гладко, то у них еще есть запас на следующие эксперименты.

4. Метрики как язык между инженерами и бизнесом

Инженеры говорят “всё работает”, бизнес говорит “клиенты жалуются”. SLO и SLI помогают перевести одно в другое.

Пример: Руководитель продукта в компании каждое утро открывает дашборд: “Логин”, “Платёж”, “Вывод средств”. Он не лезет в логи, он видит: вчера latency по платежам вышел за SLO. Теперь разговор идёт не о вине, а о влиянии на опыт клиента.

Во второй части мы поговорим о практической стороне вопроса

#observability #slo #sla