Продакт менеджер и SLI/SLO/SLA

В серии трех коротких статей я хочу рассказать про инструменты Service Level Indicator/Service Level Objective/Service Level Agreement (три разные штуки) и зачем они продакту.

У продукта есть 2 состояния: техническая часть работает, все технические метрики работают, а пользователей нет или они делают не то, что мы от них хотим (продуктовые метрики красные). Это - нормальное состояние всех развивающихся продуктов, идите улучшайте его: копайтесь в аналитике, делайте дискавери, запускайте A/B тесты. Сегодня мы не об этом.

Сегодня я хочу поговорить про другую ситуацию: техническая часть не работает, поэтому... и продукт не работает (даже если пользователи очень хотят).

Можно делать много чего (об этом тоже расскажу), но перед тем как делать, надо сначала измерить. В этот момент ваш технический лид достает 100500 графиков и начинает показывать, что вот тут, значит, трафик, а вот тут датацентры, здесь загрузка CPU - и это все для каждого из 10 сервисов. Неопытный продакт внимательно слушает и пытается разобраться. Технически подкованный продакт достает из широких штанин... SLI.

SLIs (Service Level Indicators) - это две-три главные технические метрики сервиса, которые определяют счастье клиентов этого сервиса. Простое правило проверки: если SLI красная, то клиент должен на вас кричать. Если не кричит - это не SLI, потому что клиенту не больно.

Классический пример: response success rate сервиса API прогноза погоды. Если вы посылаете 100 запросов в секунду (например, из приложения Apple Weather), а в ответ получаете 30% ошибок, то SLI на данном промежутке = 70% и вы начинаете кричать на аккаунт менеджера API прогноза, которому вы, кстати, платите деньги за вызов.

А если, например, внутри сервиса прогноза погоды в одном из датацентров CPU процессоров стало не 20%, а 80%, но при этом API работает штатно, то клиенту все равно. Значит CPU Load - не SLI (хотя и хорошая техническая метрика, на которую будут смотреть программисты).

На картинке выше - поведение реальной SLI (success rate). Как видите, она не всегда равна 100% - с сервисом постоянно что-то происходит, хотя и не так драматично - результаты не падают ниже 97%. Если померить успех на разных временных участках (например, в час), то можно видеть либо красные (все плохо), либо желтые, либо зеленые (все хорошо) промежутки "здоровья" сервиса. Что есть "хорошо", а что "плохо"? Мы поговорим об этом, когда вернемся к SLO.

К сожалению, не все так просто: здоровье сервиса состоит не только из "ответил" или "нет", но еще из, например, "как долго думал перед тем, как ответить"? Почему это важно? Представьте, что вы ищете такси и приложение пытается найти введенный вами адрес уже 10 сек, 20 сек, 30 сек. Не знаю как вы, а я такое приложение закрою, благо, конкуренты по вызову такси есть всегда. Такая эмоциональная реакция означает, что метрика Response Latency очень даже подходит под определение SLI - клиенту явно не все равно.

Как описать данную метрику в виде SLI? Стоит ли взять среднее время ответа сервиса? Или может максимальное? (из 100 запросов выбрать самый медленный и он и будет "метрикой"). Или использовать "страшный" аппарат процентилей? Надо обсудить с командой!

Вместо 100500 метрик вы один раз вместе с командой выделяете 2-4 SLIs, и с этого момента смотрите только на них. Остальные метрики вас просто не волнуют. У меня лично есть дашборда с главными SLI (у моего продукта их 6 - по три на сервис) и глубже я просто не лезу. Если что-то идет не так, команда достает те самые 100500 остальных графиков, чтобы найти причину проблемы.

Научиться понимать, что есть "главные" метрики с непривычки не так просто. Например, какие SLI у сервиса хранения всех сообщений Telegram? А чем они отличаются от SLI сервиса стриминга YouTube? А чем от SLI платежного API? (А они все очень даже отличаются). Если вы читаете не первый мой пост, то знаете, где можно попрактиковаться (правильно, в нашем симуляторе "Технологии для продакта", ссылка в комменте).

Интересны такие "жизненные" темы про реальные инструменты продакта? (и не такие захватывающие дух, как "рост стартапа от 0 до 1000% за 5 дней") Если да, в следующем посте расскажу, что такое SLO и чем она отличается от SLI.