SLI, SLO, SLA, или почему «доставим за 30 минут» — это три разных разговора

Вы открыли пиццерию. Пицца вкусная, курьеры быстрые, приложение работает. На сайте красуется обещание «доставим за 30 минут». Но как понять, насколько хорошо пиццерия с этим справляется?

SLI (Service Level Indicator) — показатель, которым измеряют качество сервиса. Например, доля заказов, доставленных не позднее чем через 30 минут после оформления. За прошлую неделю таких оказалось 94%. Это наш SLI. Никаких обещаний, просто измерили, как работает доставка.

SLO (Service Level Objective) — целевое значение показателя, которого команда хочет достичь. Пиццерия ставит цель: не менее 95% заказов должны приезжать за 30 минут. Теперь понятно, что результат в 94% за прошлую неделю до цели немного не дотянул.

SLA (Service Level Agreement) — соглашение с клиентом о том, какой уровень сервиса ему гарантируют и что произойдёт, если обязательство нарушат. Например, пиццерия обязуется доставлять не менее 90% заказов за 30 минут в течение месяца. Если условие не выполнено, клиентам положена компенсация согласно соглашению.

Получается, что SLI — это фактические 94% доставок вовремя, SLO — внутренняя цель в 95%, а SLA — обязательство перед клиентами обеспечить 90% с оговорёнными последствиями нарушения.

SLO обычно выше SLA, потому что обещать клиентам ровно тот результат, которого команда едва достигает, довольно рискованно. Лучше иметь запас. При этом SLA есть не у каждого сервиса, а SLO вполне может существовать без него.

У SLO есть ещё одно интересное понятие — error budget, или бюджет ошибок. Если цель — 95% доставок вовремя за месяц, то оставшиеся 5% можно потратить на опоздания, не нарушив внутреннюю цель. На тысячу заказов это 50 опозданий. После пятидесятого команда уже не укладывается в SLO, даже если остальные пиццы курьеры доставят телепортацией.

В IT всё то же самое, только вместо пиццы — доступность API, время ответа сервера или доля успешных запросов.

Хотя пицца, конечно, понятнее 🍕

#ks_буковки #ks_разработка