Большинство инженеров начинают путь с простой задачи - сделать так, чтобы ничего не падало. И в этом нет ничего плохого. Мы ставим мониторинг, настраиваем алерты и радуемся когда всё “зеленое”
Но спустя пару месяцев пользователи начинают жаловаться:
«Поиск выдает результаты через 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