SLI, SLO и бюджет ошибок

Три сокращения и порядок между ними

SLI (service level indicator) - это сам показатель, измеримое число: доля успешных запросов, доля запросов быстрее 300 миллисекунд, доля свежих данных. Главное требование к нему - он должен отражать то, что чувствует пользователь, а не то, что удобно померить.

SLO (service level objective) - цель по этому показателю: «99,9% запросов успешны за скользящие 30 дней». Это внутреннее обещание команды. SLA (service level agreement) - внешнее обещание клиенту, с деньгами за нарушение. Порядок такой: сначала показатель, потом внутренняя цель, и только потом, если нужно, внешнее обещание - причём с запасом. Внутренняя цель всегда строже внешней, иначе нарушение обещания клиенту вы узнаёте от клиента.

// Выбирают цель не по красоте числа, а по цене. Каждая девятка стоит денег: 99% - это 7,2 часа в месяц, 99,9% - 43 минуты, 99,99% - четыре минуты. Разница между последними двумя означает совсем другую архитектуру: запасные мощности в разных площадках дата-центра, автоматическое переключение, отработанные учения. Если бизнесу хватает 99,5%, платить за 99,99% незачем.

SLI

измеримый показатель качества (service level indicator), отражающий опыт пользователя

SLO

внутренняя цель по показателю (service level objective)

SLA

внешнее обещание клиенту (service level agreement) с ответственностью за нарушение

Бюджет ошибок как инструмент

Бюджет ошибок - это то, что осталось от цели: при 99,9% за месяц разрешено 43,2 минуты неуспеха. Считать его надо в потраченном, а не в «сколько раз падали». Посчитал несколько сценариев при цели 99,9%: полный отказ на 10 минут забирает 23,1% бюджета; получасовой сбой с половиной ошибок - 34,7%; четырёхчасовая деградация с 5% ошибок - 27,8%; сутки с одним процентом ошибок - 33,3%.

Обрати внимание на последние два. Медленная тихая деградация, которую никто не считает аварией, съедает бюджета столько же, сколько громкое падение. Именно поэтому бюджет считают по показателю, а не по числу инцидентов.

// Дальше бюджет становится инструментом принятия решений, и в этом весь смысл. Бюджет цел - катим новое, экспериментируем, идём на риск. Бюджет исчерпан - выкатки (установка новой версии на прод) только критичные, команда занимается надёжностью, пока он не восстановится. Это снимает вечный спор «разработка хочет быстрее, эксплуатация хочет стабильнее»: спорить больше не о чем, есть число. И работает это ровно до тех пор, пока правило соблюдают на самом деле.

бюджет ошибок

разрешённая доля неуспеха: разница между 100% и целью

скорость сгорания

как быстро расходуется бюджет; по ней и заводят алерты

Как мерить и на что смотреть

Показатель считают отношением: успешные запросы к общему числу за скользящее окно. Окно берут скользящее, а не календарный месяц, иначе первого числа бюджет волшебно обнуляется и первую неделю можно ронять что угодно.

Алерт вешают не на само значение показателя, а на скорость сгорания бюджета. Логика простая: если бюджет тратится в 14 раз быстрее нормы, то за двое суток он кончится целиком - будим человека сейчас. Если в два раза быстрее нормы, то повод разобраться в рабочее время, а не ночью.

// И два честных ограничения. Первое: не всякий запрос стоит считать. Опросы состояния от мониторинга, повторы клиентов, запросы ботов легко перекашивают картину, и их обычно исключают. Второе: цель должна быть достижимой силами вашего сервиса. Если вы зависите от чужого сервиса с обещанием 99,5%, обещать сверху 99,99% нельзя арифметически.

скользящее окно

последние 30 дней в любой момент, а не календарный месяц

алерт по скорости сгорания

будит, когда бюджет тратится существенно быстрее нормы

Как отвечать: «Зачем нужен бюджет ошибок, если можно просто стремиться к нулю сбоев?»

Потому что ноль сбоев недостижим и, что важнее, не нужен. Бюджет ошибок переводит надёжность из спора в число: при цели 99,9% за месяц разрешено 43,2 минуты неуспеха, и это ресурс, который можно тратить. Я считал, как он сгорает: один полный отказ на десять минут забирает 23% месячного бюджета, а сутки тихой деградации с одним процентом ошибок - 33%, то есть больше. Отсюда два практических следствия. Первое: считать надо по показателю, а не по числу инцидентов, иначе медленная деградация проходит мимо. Второе: бюджет управляет выкатками - пока он цел, команда экспериментирует и катит быстро, а как только исчерпан, выкатки только критичные и все занимаются надёжностью. Это снимает вечный спор между скоростью и стабильностью, потому что спорить больше не о чем, есть число.

Ответ объясняет назначение бюджета, подкрепляет арифметикой сгорания и заканчивается тем, как он меняет работу команды. Последнее и есть смысл всей конструкции.

На чём валятся

• −Обещают 99,99% не понимая, что это четыре минуты в месяц и совсем другая архитектура.
• −Считают надёжность числом инцидентов: тихая деградация съедает бюджет незаметно.
• −Делают внутреннюю цель равной внешнему обещанию и узнают о нарушении от клиента.
• −Берут календарный месяц вместо скользящего окна и обнуляют бюджет первого числа.
• −Обещают сверху больше, чем обещают сервисы, от которых зависят.