050 SLA, SLI, SLO и их мониторинг
- Доступность и надежность
- Понимание SLA/SLO/SLI
- Как мониторить доступность (RBSLO)
- Долгие транзакции
- Сложные случаи
Больша́я часть работы SRE строится вокруг измерения фактической надежности сервисов, регистрации и анализа всех произошедших сбоев.
В предыдущей части рассмативались показатели, которые помогают определить наличие отклонений в работе. Такие показатели называются индикаторами уровня сервиса (Service Level Indicators — SLI).
Работа любой SRE команды должна начинаться с изучения аспектов работы сервиса и проектирования SLI. Часто пытаются сэкономить время и силы и вместо проектирования достаточного количества индикаторов просто выбирают что-нибудь из уже имеющихся метрик. Это приводит к ненадежному детектированию сбоев (false positive/false negative), неправильному учету сбоев, неправильному анализу этих сбоев и в результате сервис не становится более надежным.
Для примера попытаемся спроектировать SLI для сервиса такси аналогичного Uber.
Пример проектирования метрик
Начнем с простых RED метрик.
Количество запросов по методам API. У этой метрики есть выраженная сезонность, отклонение от которой должно привлечь наше внимание. Особенно падение этой метрики в ноль.
Количество возвращенных ошибок по каждому API методу. Очевидный учет самодиагностики системы. Количество ошибок в правильно написанной системе должно стемиться к нулю. При этом некорректные запросы пользователей не должны считаться за ошибку — часто их путают и тогда метрика шумит. То есть ночью один хакер, который реверс-инжинирит наше API и делает кривые запросы может легко перебить всю статистику и мы получим ложное сообщение о сбое.
Перцентили (несколько) и среднее ("гистограмма") времени выполнения каждого типа запросов в API. Это должны быть довольно стабильные метрики, если считать только успешные корректные запросы, потому что успешный запрос и запрос завершившийся с ошибкой или составленый некорректно как правило имеют сильно разное время выполнения и считать их вместе в одной метрике приведет к более шумной наблюдаемой картине.
Предположим, что у нас в прогнозировании времени подачи автомобиля и времени поездки учитываются пробки. Но это сложный функционал и он может быть недоступен — это не повод полностью не предоставлять сервис клиентам. Предположим, что мы это учли и наше приложение пытается всегда учитывать пробки на дорогах, но эсли этот функционал сломан, то считает просто по расстоянию, дню недели и времени суток. Тогда мы введем метрику о том, сколько запросов считалось корректно с пробками, а сколько по примерному запасному пути. Всплеск в этой метрики, скажет нам о проблемах в системе учета пробок.