Как определить свои SLI и SLO?

Давайте еще раз расскажу, что такое SLO, SLI и error budget, чтобы это навечно отложилось в голове

Допустим, ты владелец кофейни.

SLI (Service Level Indicator) — это что мы меряем.

Это просто число с датчика.

В кофейне это:

  • Температура кофе в градусах.
  • Количество клиентов в очереди.
  • Время приготовления твоего ванильного рафа в секундах.

В IT это:

  • Скорость ответа сайта (скажем, 200 мс).
  • Количество ошибок "500 Internal Server Error" (скажем, 0,01% от всех запросов).
  • Доступность сервиса (скажем, 99,9%).

Короче, SLI — это просто показания счётчиков.

SLO (Service Level Objective) — это цель, к которой мы стремимся

Это наше обещание клиенту (или себе).

Это граница, которая разделяет "что для продукта хорошо и что плохо". Например, "98% операций создания ВМ завершаются за 60 секунд или быстрее" - это хорошо. Если за месяц у нас за 60 секунд создавалось 34% ВМ, а все остальные создавались дольше - это повод принять какие-то меры.

В кофейне: "Мы гарантируем, что температура кофе будет не ниже 62 градусов в 99% случаев" или "Мы гарантируем, что 99,95% заказов тыквенного латте мы приготовим за 53 секунды".

SLO - это не "идеал", это минимально приемлемый для клиента уровень качества. Если кофе холоднее 62 градусов, то клиент ругается. Если тыквенный латте готовится три минуты - клиент идет в соседнюю кофейню и к нам больше не придет.

Вот мы и подобрались к главному...

Error Budget (Бюджет ошибок) — это твоё право на ошибки

Внимание, сейчас будет магия.

Error Budget = 100% - SLO

Если наше SLO по доступности = 99,9%, то наш Error Budget = 0,1%.
В месяце 30 дней * 24 часа * 60 минут = 43200 минут.
Наш Error Budget = 0,1% от 43200 минут = 43 минуты простоя в месяц.

Что это значит?

Эти 43 минуты в месяц - это лимит продукта на всё "творчество". Это лимит на все риски, которые несет продукт, выкатывая сырые и кривые фичи не тестируя их, ломая архитектуру и требуя "запустить всё побыстрее к конференции".

Пока есть Error Budget (остались минуты простоя) - можно выкатывать новые фичи, проводить рискованные обновления, SRE тебя не остановят. Ломай, твори! У тебя есть на это бюджет.

Как только Error Budget потрачен (сервис уже пролежал 43 минуты за месяц) - ВСЁ, стоп-кран. SRE говорят: "Никаких новых фич до восстановления бюджета, работаем над надежностью, правим баги".

Теперь вся команда занимается только одним - латанием дыр и улучшением надежности, чтобы вернуть доверие клиентов и не вылететь в трубу.

Вернемся к теме главы

1. Определяем сервис

Первый шаг - определить сервис, который будем измерять. Биллинг, Service Controller, главную страницу портала и т.п.

Определяем индикаторы уровня обслуживания (SLI)

Определяем SLI, которые наиболее релевантны для сервиса, которые лучше всего показывают качество работы сервиса. Не нужно окучивать ВСЕ продуктовые функции, в этом никакого смысла нет.

SLI это конкретные, поддающиеся количественной оценке, измеримые метрики, которые помогают оценить производительность сервиса. Обкладываем сервис метриками, рисуем дашборды, измеряем, повторяем... и в итоге мы точно понимаем, какие показатели являются показателями того, что "в продукте все хорошо". То, что мы наизмеряли - это и есть SLI. Не забываем про временнОе окно.

Определяем цели уровня обслуживания (SLO)

После того как мы определили свои SLI, нам нужно определить SLO для каждого из них.

SLO - это конкретные и реально достижимые цели, которых мы стремимся достичь для каждого SLI.

Это значение должно формироваться не только исходя из технических критериев и текущей ситуации. SLO обычно устанавливаются, учитывая нормальное поведение выбранных метрик и на основе ожиданий клиентов, стандартов и т.п. То есть, это должны быть реальные, достижимые и не фантастические значения (например, "100% доступность" - это фантастика, "99,9% ВМ создаются быстрее 15 секунд" - тоже.).

Прописываем процедуру действий на случай истощения Error Budget

Этот пункт должен быть, это основа основ: важно заранее продумать, что мы будем делать в случае истощения Error Budget, согласовать эти договоренности со всеми и заыиксировать их в виде документа, например:

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

Что делать, если SLI просел ниже SLO? Читать главу "Что делать при нарушении SLO?".

Отслеживаем выполнение установленных нами SLO

Набираем статистику, анализируем.

Определяем области для улучшения

После того, как мы насобирали разные данные о работе нашего продукта настало время подумать. Если продукт не соответствует требованиям SLO, необходимо определить основную причину проблемы и предпринять шаги по повышению производительности.

Можно постоянно находить, что мы можем улучшить в продукте и, следовательно, периодически ужесточать SLO. Когда станем более зрелыми, можно считать MTTR.

Оцениваем результаты внедрения SLI и SLO

Оцениваем, корректируем.

Это не разовое действие, это процесс, цель - ужесточать SLO, тем самым делать наш сервис все надежнее, устойчивее и лучше.

Важно. Очень важно: SLO должно быть жестче, чем SLA!!!

Что за "временнОе окно"?

SLO и SLI можно подсчитывать за разные периоды. Можно использовать календарное окно ("январь") или плавающее окно ("две недели").

Плюс календарного окна: легче планировать задачи и управлять временем - "за этот месяц я достиг SLO, все хорошо", или "SLO не достиг, нужно переделать архитектуру/переписать фичу/исправить вон ту багу".

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

Короткие периоды хороши для быстрого понимания ситуации. Если не достигнут SLO за прошлую неделю, останавливаешь выкатку новых фич на прод (новая фича = падению прода :)) и приоритизируешь исправление багов на следующую и исправляешь ситуацию.

Более долгие периоды хороши для стратегического планирования. Если у тебя три крупных проекта, оценка показателей за квартал/полгода позволят правильно расставить приоритеты.

Google рекомендует начинать с четырехнедельного плавающего окна.

Советы по выбору SLO:

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

Хорошо построенные SLO - полезный фактор воздействия на команды.

Плохо продуманные SLO, могут привести к пустой трате рабочего времени.

Композитные, составные SLO

Сложные системы состоят из множества компонентов. У нас может быть SLO для каждого компонента, но как рассчитать SLO для всей системы в целом?

Например, если у нас есть 4 реплики микросервиса, как именно это повышает надежность всей системы?

Или если система может функционировать только при условии работы всех её зависимостей, как нам рассчитать надежность такой системы?

Читайте в главе Reliability Block Diagrams :)