Как понимать доступность сервиса
Что проверяют
Умеете ли вы превратить «сервис работает» в измеримую величину и договориться о ней. Следом обычно спрашивают, как бы вы считали доступность своего сервиса и сколько простоя допускают «три девятки».
Как отвечать
Доступность это доля времени или доля запросов, в которых сервис корректно отвечает пользователю. Для API практичнее считать по запросам: успешные делить на все, потому что «процесс поднят» и «пользователи получают ответ» это разные вещи.
Три понятия, которые нельзя путать:
- SLI: сама метрика. Например, доля HTTP-запросов, ответивших не 5xx и быстрее 300 мс, измеренная на балансировщике;
- SLO: внутренняя цель по SLI, например 99,9% за скользящие 30 дней;
- SLA: договор с клиентом со штрафами за нарушение. Обычно мягче SLO, чтобы у команды был запас.
Из SLO следует бюджет ошибок: 99,9% за 30 дней это около 43 минут недоступности, 99,99% примерно 4 минуты. Пока бюджет есть, можно выпускать релизы и экспериментировать, когда он кончился, приоритетом становится надёжность.
Как мерить в Python-сервисе: счётчики запросов с меткой статуса и гистограммы задержек через prometheus_client или готовую интеграцию для FastAPI, внешние проверки через Blackbox Exporter, алерты по скорости сжигания бюджета, а не по каждому всплеску. В Kubernetes разведите пробы: livenessProbe проверяет, жив ли процесс, readinessProbe, готов ли он принимать трафик.
Упомяните зависимости: при трёх последовательных зависимостях по 99,9% итог не выше примерно 99,7%. И формулу через время: доступность равна MTBF / (MTBF + MTTR), поэтому быстрое восстановление даёт не меньше, чем редкие сбои.
Где спотыкаются
Считают сервис доступным, раз /health отвечает 200. Эндпоинт жив, а пользователи получают ошибки от базы.
Проверяют базу в liveness-пробе. База моргнула, Kubernetes перезапускает все поды разом, и короткий сбой становится долгим.
Смотрят на среднюю задержку. Среднее прячет хвост, где сидят медленные ответы, поэтому для SLI берут перцентили.