"Наш SLA — 99.9%". Эту фразу слышит каждый, кто работает с cloud-сервисами. Но когда спрашиваешь "А чем ваш SLA отличается от SLO?", начинается путаница. SLA, SLO, SLI — три аббревиатуры, которые звучат похоже, но означают принципиально разные вещи. Путать их — значит либо обещать клиентам то, что не можете выполнить, либо не измерять то, что должны.
Ниже — каждый термин с реальными примерами, как они связаны между собой, и как использовать их на практике — от стартапа с одним API до enterprise-платформы с десятками микросервисов.
SLI — Service Level Indicator: что вы измеряете
SLI — это конкретная метрика, которую вы собираете. Не абстракция, не цель, а число на дашборде. SLI отвечает на вопрос: "Как мы объективно оцениваем качество этого сервиса?"
Availability SLI: Процент успешных HTTP-запросов. Если из 1,000,000 запросов 999,100 вернули 2xx/3xx, а 900 вернули 5xx — availability SLI = 99.91%. HTTP-мониторинг измеряет это непрерывно.
Latency SLI: Время ответа на определённом перцентиле. p50 = 120ms означает, что 50% запросов обрабатываются быстрее 120ms. p99 = 800ms — 99% быстрее 800ms. Response time tracking даёт эти данные.
Freshness SLI: Как актуальны данные. Если dashboard обновляется раз в секунду, а данные отстают на 30 секунд — freshness SLI = 30s. Критично для realtime-систем.
Correctness SLI: Процент запросов, вернувших правильный ответ. Если поисковый API возвращает релевантные результаты в 98% случаев — correctness SLI = 98%.
Ключевое правило: SLI должен измеряться с точки зрения пользователя, а не сервера. Внутренний CPU usage — это не SLI. "Процент запросов, обработанных быстрее 500ms, измеренный из нескольких регионов" — это SLI.
SLO — Service Level Objective: к чему вы стремитесь
SLO — это целевое значение для вашего SLI. Внутреннее обязательство команды: "Мы стремимся к availability 99.95% за rolling 30 дней". SLO не имеет юридической силы и не предполагает штрафов — это ваш внутренний стандарт качества.
Пример SLO для API: "99.9% HTTP-запросов к /api/v1/* должны возвращать 2xx за менее чем 500ms, измеренное за скользящие 30 дней".
Пример SLO для status page: "Страница статуса должна быть доступна 99.99% времени с response time менее 200ms".
Пример SLO для cron job: "Задача ночного бэкапа должна завершаться успешно в 99.5% запусков, время выполнения не более 2 часов". Мониторинг cron job через heartbeat checks отслеживает выполнение.
Как выбрать правильный SLO
Распространённая ошибка — ставить SLO "как можно выше": 99.999%. Это ловушка. Каждая девятка экспоненциально увеличивает стоимость и сложность. Разница между 99.9% и 99.99% — это разница между "можно деплоить раз в день" и "нужен blue-green deployment с zero-downtime миграциями".
| SLO | Downtime / месяц | Downtime / год | Подходит для |
|---|---|---|---|
| 99.0% | 7.3 часа | 3.65 дня | Staging, internal tools |
| 99.5% | 3.65 часа | 1.83 дня | Non-critical B2B SaaS |
| 99.9% | 43.8 мин | 8.76 часа | Production APIs, SaaS |
| 99.95% | 21.9 мин | 4.38 часа | Payment systems, auth |
| 99.99% | 4.38 мин | 52.6 мин | Infrastructure, DNS, CDN |
Используйте калькулятор uptime для точного расчёта допустимого downtime при разных SLO.
SLA — Service Level Agreement: что вы обещаете
SLA — это контракт. Юридически обязывающий документ, который говорит клиенту: "Мы гарантируем уровень X. Если не выполним — вот компенсация". SLA превращает ваш SLO из внутренней цели во внешнее обязательство с финансовыми последствиями.
Типичная структура SLA:
1. Определение сервиса — что именно покрывается (API, dashboard, все endpoints?).
2. Метрика и порог — "99.9% monthly uptime" (это SLI + SLO внутри SLA).
3. Метод измерения — как считается uptime (по минутам? по запросам? исключается ли maintenance?).
4. Компенсация — service credits при нарушении (обычно 10-30% monthly bill).
5. Исключения — что не считается нарушением (planned maintenance, force majeure, customer-caused issues).
Золотое правило: SLA < SLO < SLI target
Ваш SLA должен быть ниже вашего SLO, а SLO — ниже того, что вы реально достигаете. Если ваш measured uptime — 99.95%, ваш SLO должен быть 99.9%, а SLA — 99.5%. Это даёт вам buffer:
SLI (actual): 99.95% — то, что вы реально достигаете.
SLO (target): 99.9% — ваша внутренняя цель. Нарушение SLO = error budget израсходован, заморозить рискованные изменения.
SLA (promise): 99.5% — то, что вы обещаете клиентам. Нарушение SLA = финансовые компенсации, репутационный ущерб.
Error budget: превращаем reliability в ресурс
Error budget — это концепция из Google SRE, которая меняет разговор о reliability. Вместо "мы должны быть надёжнее" — "у нас есть конкретный бюджет на ненадёжность, и мы решаем, как его тратить".
Если SLO = 99.9% monthly, error budget = 0.1% = 43 минуты downtime в месяц. Эти 43 минуты — ресурс, который вы распределяете:
Деплои: Каждый деплой несёт risk. Если средний деплой вызывает 2 минуты degradation, вы можете деплоить ~20 раз в месяц, оставаясь в бюджете.
Эксперименты: A/B тест, который может сломать 1% запросов на 10 минут = 6 секунд из error budget. Допустимо.
Миграции: Database migration с 5 минутами planned downtime = 11.6% error budget. Планируйте заранее.
Когда бюджет кончается: Замораживайте все неcritical changes. Focusируйтесь только на stability. Автоматизируйте этот процесс через мониторинг burn rate.
Как мониторить SLI/SLO на практике
Теория без инструментов — бесполезна. Вот конкретный setup для мониторинга ваших SLI и отслеживания SLO:
Availability SLI: Настройте HTTP-мониторинг для всех critical endpoints. AtomPing считает uptime автоматически и генерирует SLA-отчёты с daily breakdown.
Latency SLI: Response time monitoring из нескольких регионов. Проверяйте не только среднее, а p95/p99 — именно хвосты распределения влияют на UX.
SSL SLI: SSL-мониторинг с alert на приближающийся expiry. Просроченный сертификат = 100% failure для HTTPS, мгновенный SLO breach.
DNS SLI: DNS-мониторинг для verification что домены резолвятся в правильные IP. DNS failure = полный outage для всех пользователей.
SLA, SLO, SLI — не бюрократия. Это язык, на котором инженеры, product managers, и бизнес могут обсуждать reliability конкретно: с числами, бюджетами, и измеримыми последствиями. Начните с малого — выберите 1-2 SLI для вашего главного сервиса, поставьте реалистичный SLO, и настройте мониторинг, который будет измерять их непрерывно.
FAQ
What is the difference between SLA, SLO, and SLI?
SLI (Service Level Indicator) is the actual metric you measure — for example, uptime percentage or response time. SLO (Service Level Objective) is your internal target for that metric — 'we aim for 99.9% uptime.' SLA (Service Level Agreement) is a contractual commitment to your customers with penalties if you fail — 'we guarantee 99.9% uptime, or we refund 10% of your monthly bill.' SLI is what you measure, SLO is what you target, SLA is what you promise.
Do I need all three: SLA, SLO, and SLI?
You always need SLIs — without measuring, you're flying blind. SLOs are strongly recommended for any production service, even internal ones — they create shared expectations across teams. SLAs are optional and typically used for external customers, enterprise contracts, or public-facing services where downtime has financial impact on customers.
What is an error budget?
An error budget is the amount of downtime your SLO allows. If your SLO is 99.9% monthly uptime, your error budget is 0.1% of the month — about 43 minutes. You can 'spend' this budget on deployments, experiments, or migrations. When the budget runs out, you freeze risky changes and focus on stability. Error budgets turn reliability from a vague goal into a concrete, trackable resource.
What SLO should I set for my service?
Start with what you can actually achieve based on historical data. If your measured uptime over the past 3 months is 99.5%, don't set an SLO of 99.99%. A good starting point: 99.9% for production APIs, 99.5% for internal tools, 99.0% for staging/dev environments. Set your SLO slightly below your actual performance to create a realistic error budget.
How do I monitor SLI metrics?
Uptime monitoring tools like AtomPing measure availability SLIs automatically — uptime percentage, response time, and error rates from multiple regions. For latency SLIs, track p50, p95, and p99 response times. For throughput SLIs, monitor requests per second. The key is measuring from the user's perspective (external monitoring), not just from your servers (internal metrics).
What happens when we violate our SLA?
Typical SLA penalties include service credits (5-30% of monthly bill), extended free service, or in extreme cases, contract termination rights for the customer. The real cost is often reputational — customers lose trust, and competitors use your outage in their marketing. This is why SLOs should be stricter than SLAs — you want to catch problems before they become SLA violations.