Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру.
Много лет назад я сидел под компьютером во время дождя. В субботу. И меня ударила молния.
Не буквально — хотя, если бы было буквально, мне бы сейчас не пришлось писать эту статью. Но энергетически — да. С тех пор я заряжен.
20+ лет в IT: сисадмин, бэкенд-разработчик, руководитель разработки, теперь — SRE.
Ты разработчик или инженер эксплуатации, и тебя дергают на каждую 500-ку. Бизнес требует: «Разберитесь!». А ты не знаешь — это много или мало? И главное — почему именно сейчас?
Если тебя уже задергала куча алертов от сервисов и не знаешь, что делать — ты здесь правильно.
Я раскажу про SLO не в общем, а от себя лично. Не через одну книжку. А через боль и бессонные ночи.
Но предупреждаю, если ты из компании, где SLO уже как офисная кофеварка — тебе тут нечего делать. Эта статья — для тех, кто только начинает. Для тех, кто хочет спать. Для тех, кто не ждёт идеального решения — и готов начать прямо сейчас.
Как становилось больнее
В 2019-2022 году я работал в стартапе. Росли быстро с 30 тыс. до 2 млн клиентов.
Появились несколько приоритетных партнёров. И каждый хотел внимания, потому нужно было каждую пятисотку — чинить немедленно.
У нас стало несколько сотен разных алертов. Которые начали заволакивать сознание как туман. Каждая пятисотка — как крик: «Я умираю!». Мы терпели и работали дальше.
И вот однажды видим, что держится 5% ошибок в API. Это много? Можно до 10% терпеть? Нет? А если станет 3% — то это уже хорошо? Никто не знал. Мы просто терпели. Потому что мы не знали, насколько хорошо работает наш сервис.
Начали искать решение и вышли на SLO.
Волшебные буковки SL{I-O-A}
Кратенько погрузимся в волшебство 3 букв. Неизменные первые две: SL — service level, уровень обслуживания. И вот остальные три:
SLI (Service Level Indicator) — показатель того самого уровня числовой, чтобы можно было на графиках понимать как изменяется он. Например, SLI: доступность API = % успешных запросов с http_status < 500
SLO (Service Level Objective) — целевой уровень показателя SLI, тот уровень ниже которого мы считаем качество обслуживания неудовлетворительным. Например, SLO: SLI доступность API 99.9% или лучше за 28 дней.
SLA (Service Level Agreement) — что будет, если не удержали целевой уровень. То что прописано в договоре оказания услуг клиенту. Например, SLA: доступность API не менее 99.95%
в месяц, каждые 0.1% ниже – штраф 0.005% от абонентской платы
Впервые SLO появилось в книге Google https://sre.google/sre-book/service-level-objectives/
SLO/SLA позволяет нам закрепить договоренности, а SLI их увидеть на данных.
Еще мы дальше будем упоминать бюджет ошибок (Error Budget).
Если твой SLO — 99.95% за 30 дней, то ты понимаешь «Я могу позволить себе 0.05% ошибок за месяц и это 21 минута и 36 секунд. В день 43 секунды.» Если мы за 1 час съели уже 45с, то явно дело плохо. Пользователи уже могут начать замечать ухудшение. И вот тогда — алерт. Не потому что 500-ка в ответе, А потому что пользователь начинает чувствовать боль.
Это не теория. Это переключатель между “каждую пятисотку чинить” и "спокойно работать пока есть запас".
Именно поэтому мы начали с этого. Не с инструментов. Не с дашбордов. С новых понятий.
Потому что без этого — вы не внедряете SLO. Вы внедряете новую систему алертов.
Первый эксперимент
Осознав, что SLO может нам помочь, мы стали искать реализации для подсчета. У нас тогда был платный Datadog как APM — он собирал логи, трейсы и метрики. И в нем уже была встроена возможность добавлять подсчет SLI и SLO.
Мы взяли два критических пути: оформление заказа и показ главной страницы.
И… сработало.
Перестали реагировать на каждую пятисотку. Бизнес перестал требовать «разбор каждой ошибки». Да это не покрыло все, что бы мы хотели, но уже облегчило жизнь.
Это была первая попытка, потому мы не заморачивались с документацией, а просто пробовали и делали.
Потом я ушёл в Ви.Tech и там была иная ситуация.
Что теория говорит нам о внедрении SLO
Надеешься, что уже сотни компаний такое делали и готовое решение должно быть в книжках, а книжек много:
Defining slo: serevice level objective meaning (Google SRE Book, 2017)
Отчет SLO Adoption and Usage in Site Reliability Engineering от Julie McCoy, Nicole Forsgren, 2020
Workshop: The Art of SLOs bu Google - тренинг по базовым основам определения SLI/SLO
Но как дело доходит до реальной практики, оказывается
Что нам вообще требуется, чтобы начать считать SLO
Определить SLI/SLO
Задокументировать SLI/SLO
Реализовать подсчет SLI и мониторинг (настроить алерты по SLO)
Научиться сопровождать
Про первый этап писать тут подробно не буду, так как определить SLI/SLO просто...
На самом деле это не так уж и просто. Даже если у вас есть владельцы продукта, которые описали критические пути пользователя (или хотя бы CJM), вам все равно нужно будет обследовать его технически, чтобы выяснить, что на самом деле делает система и какие компоненты использует в каждом пути. Вот, например, японская компания Merkari рассказывает как они обследовали свои пути пользователей, а вот тут в докладе Т-Банка "Метрики для метрик:
опыт выстраивания SLOs/SLIs для платформы мониторинга” Руслан Боярский рассказал как это делали они.
Второй эксперимент
В Ви.Tech ребята уже сделали первый подход, написали документацию и начали считать SLI/SLO. Дашборды даже уже были некоторые. Но тут не было всего готового как в DataDog.
Но у меня было несколько вопросов: Что это за SLI? Зачем он нужен? Почему он выбран? — существовавшая документация на это не отвечала. Потому я решил эти данные собрать, и пошел за правильной документацией. Тут уже были десятки SLI/SLO и без документации было уже никуда.
Сначала я пошел в Google SRE Workbook, надежда обещала, готовое решение. Нашел там SLO Document Example https://sre.google/workbook/slo-document/. В нем были разделы:
Service Overview – краткое описание сервиса/услуги
SLIs and SLOs – выбранные метрики и цели по ним
Rationale – обоснование выбора SLI/SLO (почему эти)
Error Budget – как считаем, политика реагирования на расход
Clarifications and Caveats – уточнения и ограничения (когда не применяем, расчет в краевых случаях, допущения и исключения)
Попробовали и нам не подошло. Я тогда понял, что они делают упор на сервис (приложение), которых у них много. Сам пример был слишком простым, непонятно было как описывать составные SLI. Решил поискать счастья еще.
Поиски дали плоды в виде Service Level Objective Development Life Cycle от Nobl9 — это увесистый сайт на котором руководство, схемы и есть шаблоны документации.
Вот, например, схема-руководство работы с SLO
На картинке ниже я привел все шаблоны документов, которые по SLODLC предлагается вести для SLO.
Тут я вам напомню, мы еще в самом начале пути и хотим как можно быстрее попробовать и ощутить тот самый эффект от SLO. Потому на этом этапе такой богатый набор документов стал для нас препятствием, замедлил работу. Мы попробовали буквально на нескольких SLI/SLO и наших пользователях, стало ясно, что не то:
Очень много данных надо вносить – бюрократия цветет
Тяжело поддерживать
Наши пользователи плохо понимают, не знают что важно для них
Сделали шаблоны документации SLI/SLO
У нас 2 документа:
Лист обследования системы/услуги
Спецификация SLI/SLO
Лист обследования системы/услуги
Собираем данные о том, что собираемся контролировать с SLI/SLO
Описание кратко — что это и зачем
Владелец и заинтересованные стороны — кто владеет, и кому еще из бизнеса интересна
Бизнес-контекст — какой части бизнеса касается, помогает выделить более приоритетные
Пользователи — кто пользуется, помогает определить критические пути пользователей
Болевые точки — на что жалуются больше всего пользователи
Ожидаемые уровни обслуживания — иногда пользователи уже могут сказать, что для них хорошо, а что плохо
Критические пути пользователей, их приоритеты и ожидания — выясняем какие пути есть, какие из них критические и расставляем по приоритету для бизнеса
Анализ зависимостей и ограничений — от каких сервисов зависит, что за технические ограничения (может не дать добиться нужного уровня
Известные случаи отказов — поможет найти текущие слабые места, которые влияют на удовлетворенность пользователя качеством, а значит это кандидаты в SLI/SLO.
Источники данных и существующие алерты — это поможет в формировании SLI, и в последующем отключении лишних алертов.
Спецификация SLI/SLO
Описание SLI — качество обслуживания чего отражает, как видит это пользователь
Компоненты SLI — технически какие технические параметры подлежат контролю (может быть HTTP метод, или название очереди и т.п.)
SLI/SLO – как считаем, тут пишем формулу. Можно считать долю "плохих минут", а можно долю успешных событий (математика тут разная, углубляться тут не будем)
Источник данных SLI и алертинг — откуда данные для подсчета (часто метрики, но может быть и БД, например, ClickHouse), как настроен алертинг по SLO
Развертывание – где реализация (у нас описания SLI/SLO хранится файлами в git)
Пример части нашего документа спецификации SLI/SLO
Мне очень хочется, чтобы вы тоже могли внедрять SLO быстро, потому наши шаблоны документов выложены тут https://github.com/vseinstrumentiru/slojka/tree/
main/slo-docs-templates. Смотрите, задавайте вопросы, перепиливайте их под себя.
Да, это только еще документ, но какой! Наш анти-стресс-гайд: здесь прописано, что для нас "А-А-А!", а что — "до утра подождёт". Что для нас пожар, а что — просто свечи, которые не трогаем, пока огонь не потушили.
Продолжение следует
Вот такой путь меня довел до SLO и его применения. Конечно это не все — мало лишь документации и понимания, нам нужны были инструменты. У команды уже были наработки, но с ними были сложности, а времени не было. Мы пошли дальше — и нашли несколько инструментов, выбрали один, который почти работал, но требовал доработки. Об этом — во второй части.