Когда инфраструктура твоей компании обслуживает сотни заказов в минуту, работает в десятках стран и опирается на сотни микросервисов, ты начинаешь видеть систему не только как код, но и как живой организм. Местами он предсказуемый, местами капризный, а иногда даже способен на сюрпризы — особенно в пятницу вечером.
В Dodo Engineering мы давно научились масштабировать бизнес, выстраивать процессы разработки и доставки обновлений, держать систему в тонусе и балансировать нагрузку между сервисами. Наша система Dodo IS просто не может позволить себе капризы: она работает круглосуточно в двух облаках, более чем в 25 странах и практически всех часовых поясах. С ростом бизнеса мы столкнулись с новым вопросом: «а как вообще понять, что всё действительно работает хорошо, а не просто «не горит» прямо сейчас?»
Так в нашу инженерную саванну пришел SLO'н — огромное, немного неповоротливое, но очень умное существо. Он способен навести порядок в хаосе метрик, алёртов и человеческих нервов, отличить реальную проблему от мнимой, а шум в логах — от сигнала тревоги.
А ещё SLO'н — очень непростой. Он требует внимания, точных чисел и ясных целей, поэтому поначалу мы его боялись, а кто-то даже пытался его прогнать. Но потом мы поняли: если его приручить, он не только защитит нас от ночных звонков, но и научит бизнес говорить на языке надёжности.
Эта статья — история о том, как мы приручали своего SLO'на: от первых экспериментов с нагрузочным тестированием и «бюджетом ошибок» до построения культуры надёжности, где инженеры и бизнес наконец начали говорить на одном языке.
До нашей эры
Нагрузка, ошибки и первые шаги
Первым делом мы занялись нагрузочным тестированием. Так мы смогли понять реальные границы устойчивости системы. Простой пример: сервис обрабатывает 2000 запросов в минуту. Мы рассчитали Error Budget — допустимое количество ошибок — и впервые получили инструмент, который помогает не реагировать на инциденты, а предупреждать их.
Вдохновлялись мы книгами по SRE и лекцией Данилы Морданова. Они и помогли нам осознать: надёжность — это не «чтобы не падало», а чтобы предсказуемо работало.
Настройка алёртов: меньше шума, больше смысла
Далее пришло время умных алёртов. Мы внедрили алёртинг с понятием Burn Rate — скоростью «сгорания» Error Budget. Система состояла из двух частей: одна отслеживала резкие всплески за последние 5 минут, а другая более долгосрочные тренды. Так мы избавились от ложных срабатываний из-за мелких флуктуаций.
Формула алёрта строилась на основе Error Budget: чем выше Burn Rate, тем быстрее расходовался бюджет и тем чувствительнее становилось оповещение. Но реальность быстро напомнила, что теория ≠ практика: объёмы трафика различаются между облаками на порядки, сам трафик неоднороден в течении суток — ночью его практически нет, а вечерами приходят «пики».
Нам пришлось настраивать чувствительность алёртов в зависимости от времени, адаптируя под интервалы: когда сервис реально используется и когда нагрузка минимальна. Это снизило шум и повысило доверие к системе уведомлений — теперь, если алёрт приходит, значит, действительно что-то происходит.
Как мы группировали сервисы
Мы начали различать критичные и вспомогательные сервисы. Первые — это всё, что связано с созданием заказов: мобильное приложение, сайт, API. Вторые — внутренние процессы, отчёты, интеграции.
Оказалось, что одинаковые метрики и алёрты для всех — плохая идея. Там, где трафика мало, метрики теряют смысл. Поэтому мы группировали сервисы по уровню критичности, чтобы управлять надёжностью более гранулярно. У каждого сервиса была своя конфигурация для настройки параметров для наблюдаемых эндпойнтов.
Метрики, графики и «девятки»
Следующий шаг — построение инструмента для отслеживания надёжности во времени. Мы начали измерять успешные запросы в «девятках» (99%, 99.9% и т. д.) и строить графики динамики SLI.
Но вскоре стало ясно: высокий SLI — не гарантия хорошего опыта. Если сервис отвечает медленно, пользователю всё равно плохо. Поэтому мы добавили вторую метрику и начали считать APDEX — показатель, который оценивает удовлетворённость скоростью работы от 0 до 1.
Такая методика оказалась понятна всем — и разработчикам, и бизнесу. Хотя сразу «прочувствовать» отчёты смогли не все. Так мы сделали первый шаг к общей культуре разговора о надёжности не только в инженерных терминах.
Надёжность — не только про инженеров
В какой-то момент мы поняли: чтобы приручить SLO'на окончательно, нужно, чтобы всё племя участвовало. Не только разработчики, но и бизнес.
Мы начали проводить воркшопы, где показывали дашборды, обсуждали алёрты и объясняли, как ошибки влияют на реальных пользователей. Цветовые статусы помогли мгновенно считывать обстановку: зелёный — спим спокойно, жёлтый — насторожились, красный — пора бить в бубен.
Это изменило культуру: разговор о надёжности перестал быть «делом инженеров» и стал общей ответственностью. Подробности этого периода вы сможете найти в докладе Сергея Бухарова «SLO: как не надо».
Казалось, мы наконец-то научились держать руку на пульсе: сервисы стали стабильнее, инциденты реже — всё под контролем. Но, как это часто бывает, со временем проявились и слабые стороны.
Во-первых, обновления данных приходили раз в неделю. На таком диапазоне ошибки было искать сложно. Да и вспоминать, что в это время происходило, в какой день и где именно — а потом ещё и сопоставлять это всё — практически нереально.
Во-вторых, настройка этой красоты оказалась довольно трудоёмкой. Конфиги множились, а каждый новый сервис требовал ручной настройки.
В-третьих, не было единой метрики, которая показывала бы состояние всей системы за определённый период. Можно было смотреть на отдельные сервисы, но ответить на простой вопрос «как у нас дела за прошлую неделю?» — было достаточно проблематично без ручных подсчётов.
Наконец вовлечённость начала снижаться. Поначалу все активно следили за графиками, обсуждали отклонения, искали причины, но вскоре метрики стали стали чем-то вроде декоративной статистики. Они просто существовали ради того, чтобы существовать. Система работала на энтузиазме, без целей, без бейзлайнов — по принципу «чем зеленее, тем лучше».
Стало понятно, что мы дошли до потолка старой системы. Она помогала наблюдать, но не помогала понимать. С этого момента началась новая глава, где мы пересмотрели сам подход к SLO и сделали акцент не на измерениях, а на их смысле.
Наша эра
Нам захотелось большего — чтобы стабильность превратилась из технического показателя в общую точку внимания для разработчиков, продактов и менеджеров. Мы также хотели превратить SLO из набора графиков в инструмент принятия решений. С этого момента началась наша следующая глава — «Наша эра», где мы научились не просто измерять надёжность, а управлять ею, держать в целевом диапазоне.
Новая модель
Пришла пора эволюционировать. Для начала мы выбрали модель сбора данных и формирования из них показателей. Исходные данные:
Наша система располагается в двух облаках.
Метрики нужно собирать для каждого сервиса и компонента.
Метрики должны показывать как внутреннее состояние сервиса, так и его доступность снаружи.
В качестве базовых метрик мы выбрали стандартные Success Rate и Response Time, которые снимаются непосредственно с самих сервисов. Почти все наши сервисы отправляют свои метрики через OTEL-стек, что позволяет нам собирать и анализировать данные в одном месте и одинаковыми инструментами. В конечном итоге все логи у нас попадают и хранятся в Azure Data Explorer (Kusto).
Также нам было необходимо наблюдать за нашими сервисами снаружи. Для этого мы выбрали метрику Availability. Она очень похожа на Success Rate, только основана на данных не c самого сервиса, а снимается с ингресса, который стоит перед этим сервисом.
Ключевое отличие этой метрики: она показывает 5ХХ ошибки, даже когда сервис не смог ответить (например, из-за перегрузки), и запрос был прерван по таймауту. Для конечного пользователя это всё равно ведь означает, что система недоступна.
Кумулятивная метрика – Reliability
Теперь у нас есть все необходимые исходные метрики. Пришло время определяться с общим показателем надёжности системы. Мы назвали его соответствующим образом — Reliability.
Но как его посчитать? Мы проанализировали подобные «ритуалы» в других крупных IT-племенах и выработали для себя такую методику:
Интервал стабильности
Для начала мы выбрали интервал времени такой продолжительности, чтобы показатели работы сервисов внутри него были для нас статистически значимыми. Это должен быть не длинный интервал, где состояние системы, скорее, будет размытым и не покажет нам аномалии. При этом интервал должен быть достаточным, чтобы определить наличие проблемы, сравнивая его с другими интервалами.
Мы проанализировали наш трафик к критичным сервисам системы в разные периоды времени и интенсивности запросов и выбрали таким интервалом 2 минуты. Этого времени достаточно для накопления данных, которые можно считать показательными.
Пороговые разрешения
Как я уже говорил ранее, наши сервисы живут в двух облаках: Microsoft Azure и Yandex Cloud. Они достаточно разные. Например, в первом за обработку потока событий отвечает служба Event Hubs, а в Яндексе – Kafka. Это значит, что они предоставляют разные гарантии доступности, и, соответственно, могут давать различные показатели по производительности и надёжности. Да и наш трафик в Yandex Cloud почти в 10 раз выше. Стало быть и параметры отслеживания у них могут быть разными.
А ещё у каждого роута API могут быть собственные целевые показатели. Они зависят от того, где эти роуты применяются. Для каждого роута (+ HTTP-метод) + облако мы считаем, что наша эталонная «двухминутка» зелёная (т.е. укладывается в наши целевые ожидания) если:
для Success Rate соотношение успешных запросов, где код ответа != 5хх к общему количеству запросов выше или равно заданному значению для этого роута. В этом показателе мы следим за всеми роутами в сервисе. Если для какого-то из них трешхолд не задан, мы будем считать его как 0.95.
для Response Time по заданному квантилю запросы уложились в определённое пороговое значение в миллисекундах. Мы также добавили роутам свойство критичности, потому что не все из них будут суперважными, даже в сервисах критического пути (например, healthcheck’и).
При этом мы хотели, чтобы можно было смотреть и за «неважными» роутами, но так, чтобы они не попадали в итоговый расчёт и не влияли на итоговый показатель надёжности. Это может быть полезно, например, для какого-то тестового роута.Availability рассчитывается аналогично Success Rate. Только у неё другой источник данных и нет разбивки по роутам — считаем сразу на весь сервис. Пороговое значение Availability принимаем равным 0.95.
Поскольку параметров много, а управлять ими хочется просто, мы решили создать инструмент, с которым приручить SLO'на будет проще. Назвали мы его SLO Watсher.
В этом инструменте мы настраиваем параметры исходя из следующих правил:
Success Rate – доля успешных запросов к общему количеству запросов за 2 минуты, чтобы интервал считался «зелёным», значения от 0 до 1;
Response Time основывается на двух параметрах: квантиль и пороговое значение. При заданном квантиле в 0.95 и трешхолде в 50 миллисекунд «двухминутка» у роута будет зелёной, если 95% запросов за это время уложились с ответом в 50 мс;
для Availability по сервису — нашего показателя доступности снаружи — мы выбрали 95-й квантиль, т.е. 95% всех запросов в сервис вне зависимости от роута должны возвращать успешный ответ.
Считаем цифры
Теперь складываем весь пазл воедино. Выглядит наша схема так:
В общем виде мы считаем, что наша система прожила свою успешную «двухминутку» в зелёных оттенках, если все квадратики по всем метрикам в каждом сервисе каждого роута+метода в обоих облаках — тоже зелёные. Математически выражаясь: конъюнкция всех трёх метрик.
Reliability = ErrorRate & ResponseTime & Availability
Чтобы подсчитать какой-то из показателей на дистанции времени, достаточно посчитать соотношение «зелёных» квадратиков к их общему количеству за это время. Считать можно как каждую метрику в отдельности хоть для каждого роута (например, Success Rate за неделю), так и общий показатель по всей системе — всё по одним правилам.
«Зачем так жёстко? — спросите вы — Если хотя бы один сервис или даже роут API нарушит заданные показатели, весь интервал будет считаться провальным?» «Да! Так и есть» — отвечу я.
Мы рассматривали и альтернативный подход к этому упражнению. Показатель Reliability можно считать как соотношение количества всех «зелёных» квадратиков пространства по всем метрикам к общему их количеству — соотношение площади зелёного пространства к общей площади. Но у этого подхода мы нашли несколько минусов:
Влияние метрик будет неравномерным, так как количество учитываемых в расчётах роутов в каждой из метрик может отличаться. Где-то мы учитываем только критичные, где-то все, а где-то и вовсе без разбивки.
Влияние сервисов также будет неравномерным: сервис с более «упитанным» API будет перетягивать одеяло на себя.
Легко потерять отдельно взятую аномалию в отдельно взятом сервисе, так как влияние каждого квадратика на общую картину достаточно мало.
Поэтому мы решили, что пойдём по более строгому пути. Зато так мы сможем увидеть проблемы в любом месте системы.
Информацию по каждому квадратику, а также необходимый контекст расчётов мы складываем в хранилище. А чтобы было проще рассчитать показатели на длинных дистанциях (например, год), мы вычисляем дневные агрегаты по каждому сервису в каждом облаке.
Рисуем рисунки
Мы научились собирать данные. Теперь нужно заставить их приносить пользу. А как быть уверенным в том, что они действительно полезны? Конечно же, спросить тех, кто будет ими пользоваться. Да-да, это те самые CustDev-исследования (Customer Development). И пусть их в основном применяют при разработке продуктовых фич, мы применяем тот же подход и при разработке внутренних инструментов.
Мы побеседовали с нашим СТО, нашими Engineering-менеджерами, техлидами и разработчиками — постарались охватить максимальную аудиторию, включающую разные роли и разные уровни технического менеджмента. Для этих сегментов аудитории мы создали свои дашборды, которые отвечают их запросам и позволяют быстро оценить ситуацию.
SLO Overview
Основная верхнеуровневая доска с показателями надёжности системы за различные периоды времени: месяц, квартал, 2 недели. На ней можно увидеть и значение итоговой метрики Reliability, и влияние каждой отдельной метрики.
Здесь мы отслеживаем влияние каждой из трех наших метрик на систему.
Success Rate отвечает на, казалось бы, простой вопрос: сколько запросов завершились успешно? На практике именно она помогает понять, насколько система выполняет свои обязательства перед пользователями. Если Success Rate падает, значит часть функций перестала приносить пользу — пользовательский опыт страдает.
Для нас Success Rate стал своеобразным «барометром доверия» к системе. Чем выше этот показатель, тем реже пользователю приходится сталкиваться с неприятным «что-то пошло не так».
Response Time показывает, как быстро всё работает. Даже корректный сервис может вызывать раздражение, если отвечает с задержкой. Поэтому Response Time — это не просто измерение скорости, а отражение воспринимаемой отзывчивости системы.
Быстрая реакция формирует ощущение надёжности, а стабильная скорость отклика помогает командам выявлять деградации производительности задолго до того, как пользователи начнут жаловаться. Этот параметр мы обязательно определяем для важных роутов сервисов критического пути, а для всех остальных — там, где необходимо следить за скоростью отдачи ответа.
Availability — самая «человеческая» из всех метрик. Пользователю-то всё равно, сколько микросервисов крутится внутри и какие у них показатели. Ему важно, доступна ли система прямо сейчас.
Availability показывает, насколько сервис виден «снаружи»: можно ли к нему достучаться, отвечает ли он, не прерываются ли соединения. Это наш внешний контур доверия, индикатор того, насколько система жива в глазах пользователя. Даже если внутренние компоненты работают идеально, но внешний уровень недоступен, то для клиента система мертва.
Для отслеживания каждого отдельного сервиса на SLI мы добавили рейтинг сервисов. В нём собираются топ-10 сервисов с самыми низкими показателями за прошедший период времени. Он позволяет нам быстро оценить ситуацию и решить, стоит ли корректировать поведение сервисов.
Например, если мы посмотрим на график справа, то сможем сделать следующие выводы:
Основная метрика, которая оказывает существенное влияние на стабильность у большинства сервисов, — Response Time. Это сигнал, чтобы проанализировать поведение сервисов и выявить причины: возможно, были какие-то изменения в сервисе, а может мы слишком оптимистично выставили целевые параметры.
У некоторых сервисов Response Time не задан. Это нормально, потому что не все сервисы критичные. На них значительно влияет Success Rate. Если он низкий, значит сервис работает нестабильно.
Unit/Team Board
Для наших Engineering-менеджеров и лидов команд мы разработали отдельную доску — Unit/Team Board. По ней можно быстро узнать о состоянии сервисов, посмотреть на динамику по дням и узнать показатели каждого из сервисов. Смотреть можно на динамику показателей как всего юнита, так и каждой отдельной команды.
Service Board / Investigation
Самая подробная скрижаль — доска с детальной информацией по сервису для техлидов команд и разработчиков. С её помощью можно оценить состояние сервиса в целом и его отдельно взятых компонентов, влияние отдельных метрик и «облаков».
На этой доске мы создали дополнительные инструменты для анализа. Так мы быстрее находим места в сервисе, на которые стоит обратить внимание. Видим, где команде нужно быстро вмешаться в жизнь сервиса.
Например, хитмап. Он позволяет отрисовать те самые зелёные и красные квадратики по каждой метрике. С его помощью можно узнать, какая из них больше влияет на Reliability и на что нам обратить внимание в первую очередь.
Другой пример — борды, которые вы видите ниже. Это инструменты для оценки каждого показателя в сервисе. На них можно рассмотреть каждый роут под микроскопом и найти самое узкое место, которое нужно оптимизировать.
Также мы поставили себе цель связать все наши данные воедино, чтобы можно было пройти от самых верхнеуровневых до наиболее конкретных показателей стабильности отдельного сервиса или его роутов. Для этого мы добавили связи между досками, которые в несколько кликов позволяют опуститься до уровня источника проблем.
В итоге у нас получился инструмент, который может быстро и наглядно показать, насколько стабильно работает система в целом и её отдельные части. А ещё он сигнализирует о тех местах, которые требуют нашего внимания.
Настоящее время
Мы научились просто и прозрачно считать наши SLI и даже красиво рисовать метрики в различных срезах. Но мало научиться выводить эти данные — нужно, чтобы владельцы сервисов реагировали на их изменения.
Мы решили внедрить отслеживание показателей и реагирование на их изменения в регулярные процессы команд. Для начала мы подключили периодические уведомления. Поэкспериментировав с разными интервалами и форматами, мы пришли к еженедельным уведомлениям о тех ситуациях, которые действительно заслуживают внимания.
Чтобы не превращать получение уведомлений в карго-культ, мы оставили в алёртах только то, во что действительно нужно погрузиться и что поможет задетектить проблему. Все дополнительные подробности и инструментарий можно найти в Grafana.
На эти уведомления может подписаться как команда, так и отдельный человек. Им может быть лид команды или Engineering-менеджер юнита.
Команды, отвечающие за критичные сервисы, встроили просмотр досок с метриками SLO в свой ежедневный моцион. В случае «покраснения» метрик они оперативно назначают ответственных за починку.
Регулярная инспекция показателей стала частью процесса и ответственности лидов команд, которые следят за здоровьем свои сервисов, и Engineering-менеджеров, которые отвечают за доставку качественного продукта пользователям. На регулярных встречах они анализируют ситуацию и корректируют планы команд, если это необходимо для быстрой реакции на изменение поведения системы.
По метрикам посещаемости в Grafana мы можем отслеживать, насколько регулярно команды пользуются этими дашбордами. Так по мере необходимости можно корректировать процессы в командах.
Когда система начала показывать первые данные, стало понятно: графики — это не просто красивые линии или столбики, а прямые указания на то, где нам стоит поработать руками. Если сервис стабильно «краснеет» по одной из метрик, это не всегда повод для паники, но всегда – сигнал к исследованию.
В большинстве случаев причина оказывается вполне земной: где-то в коде заложен неоптимальный алгоритм, где-то запрос делает лишние обращения к базе, а где-то нагрузка выросла быстрее, чем ожидалось. В таких ситуациях мы идём классическим путём инженера: ищем, оптимизируем, тестируем, убеждаемся, что сервис стал работать быстрее и надёжнее. Например, в нашем сервисе, отвечающем за управление сменой, с конца августа появился большой «фон» ошибок:
Благодаря дашбордам удалось быстро определить проблемные роуты и команда нашла ошибки в коде. Как видно из изображения выше, команда пофиксила сначала один эндпойнт и продолжила исследование второго. В результаты оба кейса были исправлены, а сервис вышел на свои целевые показатели.
Иногда проблема не в сервисе, а в ожиданиях от него: целевые показатели оказываются слишком оптимистичными, особенно если задавались «по ощущению», а не по реальной статистике. Тут важно время от времени сверять цифры с реальностью: смотреть на дашборды, анализировать данные по периодам и понимать, действительно ли выбранные SLO отражают нормальную, а не идеальную картину работы.
Нужно понимать, что корректировка таких значений — не шаг назад, а наоборот, шаг к осознанности. Лучше иметь реалистичные цели, по которым можно стабильно отслеживать качество, чем гнаться за недостижимыми «пятью девятками».
Так, например, случилось с сервисом меню. На несколько роутов выставили слишком оптимистичные цели по времени ответа. Тогда мы получили заметную просадку в метриках, но затем скорректировали параметры Response Time и вновь увидели реалистичные результаты.
Снижение показателей может быть вызвано и внешними причинами, на которые мы не можем повлиять: это могут быть инциденты в дата-центрах, ложные срабатывания WAF или проблемы у магистральных провайдеров. В этом случае мы уже разрабатываем более комплексные решения по предотвращению подобных ситуаций.
В итоге мы пришли к простому, но важному выводу: корректировка показателей — это не про уступки, а про баланс. Где-то стоит подкрутить код, а где-то ожидания. Главное, чтобы система не превратилась в гонку за зелёными квадратиками, а оставалась инструментом для улучшения реальной надёжности и пользовательского опыта.
Мы запустили систему в начале года. Как и полагается любому новому зверю в экосистеме микросервисов, первые месяцы ушли на приручение: уточнение параметров, шлифовку конфигураций и настройку алёртинга под реальные сценарии.
К началу лета в систему были подключены все юниты и команды: в общей сложности порядка тридцати инженерных команд и несколько продуктовых направлений. Постепенно SLO Watcher перестал быть внутренним экспериментом и превратился в рабочий инструмент, которым разработчики и менеджеры действительно пользуются каждый день.
Следующие месяцы показали, что мы вышли на устойчивую орбиту. Динамика метрик стала стабильной, Reliability перестал скакать как кардиограмма под нагрузкой, а визуализации в Grafana превратились из «пожарных щитов» в панели управления.
Команды начали видеть закономерности, понимать влияние изменений в коде на показатели. Но главное – появились данные, на которые можно опираться в принятии решений. Теперь разговоры про надёжность стали предметными, а не эмоциональными. Пожалуй, это один из лучших индикаторов успеха.
Мы прошли путь от хаотичного сбора данных к осознанному управлению надёжностью. Мы перестали просто «измерять ради измерений» — теперь наши метрики работают на нас. То есть сейчас и начинается то, ради чего все задумывалось: осмысленное проектирование, измерение и улучшение сервисов, которое объединяет инженеров, менеджеров и продактов вокруг одной цели.
Вместо заключения
Эта история началась с простого желания понять, насколько стабильно работает наша система. Заканчиваем мы её с универсальным инструментом для отслеживания состояния системы. Он считает метрики, помогает принимать решения, подсвечивает слабые места и делает жизнь многих микросервисов немного спокойнее.
Чему нас научила эта история? Тому, что внутренний инструмент — это тоже продукт. К его разработке нужно подходить так, будто мы пишем приложение для пользователей.
Хорошая инженерия — же это не только про код, но и про проектирование, архитектуру и понимание потребностей пользователей. Когда уделяешь внимание этим вещам, инструмент перестает быть «внутренней утилитой для своих» и становится надёжным помощником для всей компании.
В нашем случае так и случилось: продукт стал не просто системой наблюдения, а общим языком между командами, продактами и инфраструктурой. Теперь, когда кто-то спрашивает «как у нас дела с надежностью?», мы не роемся в бесконечном числе вкладок в браузере, а смотрим на один показатель и точно знаем, где всё хорошо, а где стоит вмешаться.
Так что приручая своего SLO'на, начинайте не с кода, а с понимания, для кого и зачем вы это делаете. Тогда вы сможете приручить не только SLO'на, но и других диковинных зверей, которые обитают в вашем племени микросервисов.
Спасибо, что дочитали статью! О том, как мы развиваем IT в Додо, читайте в Telegram-канале Dodo Engineering. Там мы рассказываем о жизни нашей команды, культуре и последних разработках.