Друзья, всем привет!
Сегодня погорим о почти бесполезной метрики надёжности: uptime.
Инженеры любят говорить, что соглашение об уровне сервиса (
SLA)= 99.99. Но это число почти ничего не говорит о реальной надёжности системы, потому что uptime не связан с пользовательским опытом и бизнес-результатом. Простой пример: 99.99% доступности = примерно 52 минуты простоя в год.
⚡️Но важны не минуты, а контекст этих минут:
• Это 52 минуты ночью или в пик трафика?
• Сломался критический путь или второстепенная функция?
• Затронуто 1% пользователей или 100%?
Одинаковый uptime может означать радикально разные последствия.
Инженеры по надежности (SRE) вообще почти не используют uptime, потому что это сервисная, а не ориентрованная на пользователя метрика. Она не отвечает на главный для нас вопрос: пользователь смог сделать то, ради чего пришёл?
🔹И кстати, именно поэтому в SRE используются цели уровня обслуживания (SLO) на основе пользовательских операций. Типичные индикаторы уровня обслуживания (SLI):
• Доля успешных запросов (Success Rate)
• Задержка (Latency) — 95-й и 99-й перцентили (p95 / p99)
• Актуальность данных (Freshness)
• Полнота данных (Completeness)
• Корректность данных (Correctness)
Критический путь важнее общего SLA. Он есть в любой системе. Например для маркетплейса этот будет выглядеть так:
Просмотр каталога → Поиск → Карточка товара → Добавление в корзину → Оформление заказа → Оплата
🔹Надёжность всей системы определяется самым слабым звеном на этом пути. Поэтому разумные SLO распределяются не равномерно, а по критичности. Так повелось, потому что стоимость отказа разная. Если упали рекомендации, пользователь всё равно может купить. А вот если упали платежи, то бизнес остановился.🔹Поговорим еще про механизм управления риском (Error Budget).
Главная идея SRE: надежность не максимизируется бесконечно. Она балансируется со скоростью разработки. Например, если SLO = 99.9% успешных запросов, то допустимый бюджет ошибок = 0.1% запросов (примерно 43 минуты недоступности в месяц). Этот бюджет можно осознанно тратить на релизы, эксперименты и инфраструктурные изменения.
🔹Но если бюджет исчерпан, следует использовать заморозку выпуска функций (feature freeze) и делать фокус на надёжности.
⚡️Так все же, почему же идеальный uptime может означать плохой сервис. Классическая проблема – деградация успешности (degraded success).
Вот вам реальный пример, система рассылки уведомлений:
Время безотказной работы API: 99.999%, но 40% сообщений доставляются с задержкой более 1 часа. С точки зрения времени безотказной работ, сервис работает, а с точки зрения пользователя, сервис сломан.
Правильная цель уровня обслуживания здесь выглядит иначе, условно: доставка уведомлений < 5 минут для 99% сообщений. И внезапно оказывается, что реальная доступность системы — 60%.
🔹Как переводить бизнес-риски в SLO
1. Оценить стоимость отказа.
Потери = трафик × конверсия × средний чек заказа × время простоя.После этого разговор про цели уровня обслуживания становится очень конкретным.
2. Найти критические пользовательские сценарии (critical user journeys)
Не все операции равны. Обычно выделяют путь к выручке, активации и удержанию. Именно они получают самые строгие цели уровня обслуживания.
3. Декомпозировать цели по сервисам
Если пользовательский сценарий проходит через 5 сервисов, например аутентификация, каталог, корзина, оформление заказа и оплата, то цель уровня обслуживания системы распределяется по ним через компоновку целей (SLO composition).
И вот это уже инженерная задача — распределение бюджета надёжности (reliability budget allocation).
➡️Что по итогу
Uptime – метрика инфраструктуры. SRE интересует другое, смог ли пользователь выполнить свою задачу? Поэтому реальные SLO строятся вокруг: success rate пользовательских операций, latency, freshness данных, critical user journeys и error budge.
➡️Главный вопрос от SRE бизнесу: сколько денег компания готова терять из-за сбоев? Потому что SLO –не техническая цель, а экономическая договорённость о допустимых потерях 🔥