SLA, SLO, SLI и error budget
На прошлом шаге вы научились видеть, что происходит с системой: метрики, логи, дашборды. Остался вопрос, на который графики сами по себе не отвечают: а какая цель? Когда система достаточно здорова? 99% успешных запросов, это хорошо или стыдно? Нужно ли гнаться за 100%? Чтобы про надежность можно было договариваться и спорить по делу, ее переводят в числа. Этим занимаются три похожие аббревиатуры, SLI, SLO, SLA, и идея error budget поверх них. Все это пришло из практики SRE и давно стало общим языком надежности.
Три буквы, SLI, SLO, SLA
Разберем снизу вверх, потому что так понятнее.
SLI (Indicator) – то, что вы реально измеряете. Это метрика с прошлого шага, но не любая, а выбранная так, чтобы отражать счастье пользователя: доля успешных запросов (не 5xx), доля запросов быстрее 300 миллисекунд, доступность сервиса. SLI, это просто число, снятое с системы, например «99,95% запросов за месяц прошли успешно».
SLO (Objective) – цель, которую команда сама себе ставит по этому числу. «Доля успешных запросов должна быть не ниже 99,9% за месяц». Это внутренний ориентир: пока SLI выше SLO, все хорошо, опустился ниже, пора разбираться.
SLA (Agreement) – обещание клиенту, у которого есть последствия. «Гарантируем доступность 99,5%, а если нарушим, вернем часть денег». Это уже договор с деньгами на кону, и потому внешний SLA почти всегда мягче внутреннего SLO: цель ставят строже обещания, чтобы успеть среагировать до того, как нарушение дойдет до клиента.
Связь читается одной строкой: SLI измеряет, SLO задает цель, SLA дает обещание. Путать их любят на собеседованиях, поэтому держите в голове именно эту тройку «измеряю, цель, обещание».
Сколько стоит девятка
Доступность принято считать в «девятках», и за безобидными процентами прячется конкретное время простоя. Вот сколько сервису разрешено лежать при разных целях:
| Доступность | Простой в год | Простой в месяц |
|---|---|---|
| 99% (две девятки) | ~3,65 дня | ~7,2 часа |
| 99,9% (три девятки) | ~8,8 часа | ~43 минуты |
| 99,99% (четыре девятки) | ~52 минуты | ~4,3 минуты |
| 99,999% (пять девяток) | ~5 минут | ~26 секунд |
Из таблицы видно главное: каждая следующая девятка дается куда дороже предыдущей. Подняться с 99% до 99,9%, это серьезная инженерная работа, а прыжок с 99,99% до 99,999% требует резервирования, автоматики и денег, которые большинству проектов не окупятся никогда. Поэтому число девяток выбирают под задачу: блогу хватит двух, платежной системе нужны четыре, и стоят эти варианты совершенно по-разному.
Почему не 100%
Напрашивается мысль: а давайте просто стремиться к 100%. Так вот, не давайте, и это ключевая идея SRE.
Сто процентов недостижимы и не нужны. Стоят они бесконечно дорого, а пользователь разницы все равно не заметит: между 99,99% и 100% стоит его собственный wi-fi, который падает чаще вашего сервиса. Но есть причина серьезнее. Стремление к стопроцентной надежности означает «никогда не рисковать»: не катить новые версии, не экспериментировать, не трогать работающее. А это смерть для продукта, который должен развиваться. Надежность и скорость изменений тянут в разные стороны, и 100% надежности оборачивается нулем новых фич.
Значит, нужна не максимальная надежность, а достаточная. И как только цель перестает быть стопроцентной, появляется кое-что полезное, право на ошибку, выраженное числом.
Error budget, бюджет на ошибки
Если цель 99,9%, то оставшиеся 0,1% это не позор, а разрешенный расход. Это и есть error budget, бюджет ошибок: бюджет равен 100% минус SLO. При цели 99,9% за месяц у вас есть примерно 43 минуты, в которые сервису позволено быть недоступным, и это нормально.
Самое интересное в том, как этот бюджет тратят. Из него оплачиваются риски: каждый деплой, каждый эксперимент, канареечная выкатка из модуля про CI/CD, все понемногу расходует бюджет. И отсюда простое правило жизни команды:
Этим error budget снимает вечный спор между разработчиками, которые хотят быстрее катить фичи, и эксплуатацией, которая хочет стабильности. Вместо споров на эмоциях появляется одно общее число. Бюджет цел, рискуйте на здоровье. Бюджет на нуле, значит, в этом месяце сервис уже исчерпал право падать, релизы тормозят, и силы идут на стабилизацию. И тот же бюджет защищает дежурного из разговоров про три часа ночи: пока команда укладывается в SLO, гнаться за каждой микросекундой и выжигать людей бессмысленно.
Причем здесь DevOps
Вся эта арифметика стоит ровно на прошлом шаге: SLI, это метрика, посчитанная из тех же данных, что собирает Prometheus, а нарушение SLO ловится обычным алертом. Поверх метрик надстраиваются цели, поверх целей бюджет, и из сухих графиков получается язык, на котором бизнес и инженеры договариваются о надежности. Для девопса это повседневная рамка: что считать за SLI, какие SLO держать, сколько бюджета осталось и можно ли сегодня рисковать с выкаткой. А на собеседованиях разница SLA, SLO и SLI и смысл error budget, вопросы настолько стабильные, что их стоит уметь рассказать не задумываясь.
Словарик
| Термин | Что означает |
|---|---|
| SLI | Измеряемый показатель, отражающий счастье пользователя (доля успешных запросов) |
| SLO | Внутренняя цель по SLI (например, ≥ 99,9% за месяц) |
| SLA | Внешнее обещание клиенту с последствиями за нарушение; мягче, чем SLO |
| Девятки | Способ считать доступность: 99,9%, 99,99% и так далее |
| Error budget | Разрешенный расход на ошибки: 100% минус SLO |
| Трата бюджета | Риски, деплои, эксперименты; бюджет исчерпан, релизы замораживают |
| Почему не 100% | Недостижимо, бесконечно дорого и убивает развитие продукта |