[Время на прочтение поста: ~5 мин.]

Представьте: понедельник, вечер, релиз. Вы смотрите, как билд катится на прод — и тут всё ломается.

Сайт недоступен. Клиенты негодуют. Продакт в панике.

Окей, откатили.

Но на следующий день — снова баг. Ещё откат. Команда сильно устала. Релизов уже никто не хочет.

Ты думаешь: - Да как так-то? - У нас же 99.9% аптайма!

Спойлер: 99.9% — это катастрофа. Это 8 часов простоя в год.

И что самое неприятное: • Вы не понимаете, когда это критическая проблема, а когда, просто баг. • Вы не знаете, сколько ещё можно совершать ошибки, пока бизнес не начнёт тонуть. • И вы вообще не представляете, сколько денег сжигаете, когда падаете.

Давайте разбираться!

🚨 Почему 99.9% — это катастрофа? • 99.9% — 43 мин. простоя в мес. или 8 ч 45 мин/год. • 99.95% — 22 мин. простоя в мес. или 4 ч 22 мин/год. • 99.99% — 4 мин. простоя в мес. или 52 мин/год.

3 буквы, которые помогут исправить ситуацию!

SLI — Как узнать, что сервис вообще работает? Service Level Indicator — это показатель здоровья вашей системы.

Пример: • Среднее время отклика API — 320 мс. • Процент успешных запросов — 98.9%. • Доступность сервиса за месяц — 99.94%.

Это как градусник для вашего сервиса. Ты видишь: температура 38.5 — плохо, 36.6 — нормально.

Но есть одна проблема: ⚠️ Если вы не знаете, какая температура нормальная — показания бесполезны.

Именно поэтому нужен следующий уровень.

SLO — На что мы готовы закрыть глаза? Вот тут начинается самое интересное.

Service Level Objective — это цель, которую ты ставишь для своего сервиса.

По сути, это договор с самим собой:

Мы готовы мириться с 4 часами простоя в год. Всё, что больше — недопустимо. Пример: • Аптайм не ниже 99.95% в месяц. • Время загрузки страницы — до 2 сек для 95% пользователей. • Не больше 0.5% запросов с ошибками в день.

Вот что происходит, когда компании ошибаются с SLO: Netflix — $9 млн убытков за сутки простоя (2019)

Amazon — $34 млн за несколько часов простоя (Prime Day, 2021)

Stripe — $1.5 млн за 4 часа падения (2022)

SLA — Что мы обещаем клиенту? Теперь самое важное.

Service Level Agreement — это юридическое обещание клиенту. Если вы его нарушите — заплатите. Буквально.

Пример: • Если аптайм упадет ниже 99.9% — вернем деньги. • Если время отклика превысит 500 мс — дадим скидку. • Если проблема не решится за 1 час — продлим подписку.

Вот где ловушка: 👉 Если ваше SLO = SLA — вы гарантированно будете терять деньги. 👉 Каждая ошибка = прямые убытки.

Поэтому умные компании делают так: • SLO: 99.95% (внутренний стандарт). • SLA: 99.9% (обещание клиенту).

Этот зазор и есть ваша защита.

💸 Error Budget — Сколько ошибок мы можем себе позволить? Лимит на ошибки.

Если вы пообещали 99.95% аптайма, у вас есть 4 часа простоя в год.

Как работает: • Пока бюджет цел — команда двигает фичи и быстро релизит. • Если бюджет сгорел — фокус на стабильности, но разработка не останавливается. • Это позволяет балансировать между скоростью разработки и надёжностью сервиса.

Как правильно использовать SLO в реальной жизни? Вот несколько реальных подходов: 1. SLO для CI/CD Shopify поставили SLO на скорость деплоя: • Билд не дольше 1 мин. • Тесты не дольше 5 мин.

Скорость релизов увеличилась на 40%, а количество откатов уменьшилось.

2. SLO для пользовательского опыта Netflix ставит SLO не на весь сервис, а на конкретные user journey: • Время начала стрима • Время переключения между сериями Удержание пользователей выросло на 17%.

3. SLO как защита от микроменеджмента Google внедрили Error Budget на всё: • Если бюджет цел — разрабатывают фичи. • Если бюджет сгорел — чинят стабильность.

Страх релизов исчез, а скорость разработки выросла на 32%.

Итак, запомните: 👉 SLI — градусник. 👉 SLO — договор с самим собой о том, что считается нормой. 👉 SLA — юридическое обещание клиенту. 👉 Error Budget — страховка для инноваций и экспериментов.

В следующем посте я расскажу, как ставить SLO, чтобы балансировать между стабильностью и скоростью разработки.