Если коротко, важнее SLO. А теперь по порядку:
👉 SLA (Service Level Agreement) — это договор, обычно с заказчиком. В нём прописано, что обещаем: доступность, время реакции, компенсации. SLA — это про внешнюю сторону бизнеса.
👉 SLO (Service Level Objective) — это цель, которую вы ставите внутри команды. На основе SLI (метрик) определяем, чего хотим достичь: например, 99.95% аптайма или 200 мс P95 latency.
Ключевой момент: SLO формирует реальные ожидания от системы и даёт основу для инженерных решений. SLA — это бумажка, которая пригодится, если всё пошло не так.
Пример:
Вы держите API с 99.9% SLA — значит, по договору можно лежать ~43 минуты в месяц. Но внутри ставите себе SLO в 99.95% — это уже ~22 минуты. Если начали часто превышать SLO — это сигнал: надо искать причину, рефакторить, усиливать мониторинг.
Если не следить за SLO, можно однажды получить «по SLA вы не тянете, платите неустойку».
Почему SLO и SLA часто путают?
Потому что и там, и там — проценты, uptime, цифры. Но:
🔹SLA — для бизнеса
🔹SLO — для инженеров
Так что если вы SRE или DevOps и вас просят «выполнить SLA», а при этом нет ни одного SLO — это красный флаг. Без SLO не видно, как близко вы к провалу, и заранее никак не подстраховаться.
SLO — основа. SLA — фасад.
Без первого второй быстро треснет. Настоящая работа по надёжности начинается с реалистичных, измеримых SLO, а уже потом — SLA на их основе.
Позже расскажу, как правильно ставить SLO, и какие ошибки делают новички. 🔥, кому актуально!