Привет, Хабр! Я Руслан Боярский, SRE-инженер в Т-Банке, где мы строим и поддерживаем Sage — внутреннюю платформу наблюдаемости для 7 000+ инженеров. У нас собираются миллионы метрик в секунду, работают десятки тысяч алертов, и на нас завязаны решения о стабильности критически важных сервисов.
В какой-то момент мы задались вопросом: насколько на самом деле надежна наша платформа? У нас были SLA, но не было уверенности, что они отражают реальные ожидания пользователей.
В статье по мотивам моего доклада на DevOpsConf 2025 — наш путь от гипотез и «галлюцинаций» до рабочих SLO: как мы с помощью глубинных интервью с клиентами перестали гадать о надежности и начали измерять ее по-настоящему.
Как все началось: от SLA по умолчанию к вопросам о реальной надежности
Наша observability-платформа формирует фундамент наблюдаемости в Т-Банке. Нагрузка на платформу за семь лет выросла многократно, а с ней — доверие пользователей и их ожидания в вопросе надежности.
В начале пути у нас уже есть SLA с клиентом и механизмы отслеживания. С ростом нагрузки и появлением новых функций возникли вопросы:
Какая надежность у нас сейчас?
Как нам измерить надежность и правильно ли мы ее измеряем сейчас?
Какие ожидания у наших пользователей по надежности от нас?
Вопросы стали отправной точкой — с этого момента начался этап Discovery. Нас ожидали проработка требований, общение с клиентами и проектирование SLO.
Выбор точки входа: почему начали с подсистемы метрик
Sage — огромная система: логи, трейсы, метрики. Это слон, которого надо есть по кускам. Поэтому мы решили пойти по пути, когда выбираем одну подсистему, получаем опыт и потом масштабируем его на остальные подсистемы.
Выбор пал на подсистему метрик. Она популярна у наших пользователей: многие SRE-команды в компании строят свои алертинги, дашборды и работу на основе метрик, хранящихся в Sage.
Дальше нужно было собрать контекст: архитектура, процессы и функциональность. Информацию мы искали в команде, которая отвечает за подсистему метрик. Это небольшая кросс-функциональная команда: нет отдельного QA, но есть разработчики, продакты и SRE-партнер, помогающий надежностью и инфраструктурой.
Важно: команда работает по принципу you build it — you run it.
Работая с командой, мы сразу фиксируем ключевую функциональность подсистемы:
Запись временных рядов метрик в наше коммунальное хранилище.
Поиск и процессинг по метрикам из этого хранилища.
Архитектура подсистемы метрик: пайплайн записи и поиска
Чтобы понимать, с чем работаем, показываю high-level схемы.
В центре — Metrics Collector, наше решение. Оно поддерживает два формата сбора телеметрии: OpenMetrics и Remote Write. Каждая метрика попадает в коллектор, который дублирует ее в два хранилища: краткосрочное (STS, short term storage) и долгосрочное (LTS, long term storage).
Mage — поисковый движок, который предоставляет клиентам синтаксис MageQL. Каждый поисковый запрос, который проходит через наш поисковый движок, тоже обращается к двум хранилищам: долгосрочному и краткосрочному в зависимости от выбранного интервала. Если окно запроса до 30 дней — идем в краткосрочное хранилище, если больше — в долгосрочное.
На весь Sage внутри Т-Банка:
18 млн точек (сэмплов) в секунду на запись в базу;
~150 000 таргетов, чьи метрики собираются по Remote Write и OpenMetrics;
~1 800 RPS поисковых запросов.
Контекст собрали. Дальше нужно было понять, какие услуги подсистема реально предоставляет клиентам и чего конкретно клиенты от нас ждут.
Как определили услуги: от гипотез к клиентским потребностям
Сначала договоримся о терминах.
Услуга — это набор действий, которые закрывают потребность клиента. Чтобы понять, что является услугой, достаточно задать два вопроса:
Зачем ко мне приходит клиент?
Какую потребность он закрывает, когда приходит?
Ответив на них, понимаем, что такое услуга.
Важный момент: во всех моих рассуждениях фигурирует клиент, он же пользователь. Понять его ожидания и поговорить с ним помогают продакты — к ним мы и пошли с запросом: «Нужна ваша помощь, чтобы пообщаться с клиентами и узнать их ожидания по надежности».
Вместе с продактами получили список наших пользователей. Большая часть — технари: SRE и разработчики. Важный момент — мы сами тоже пользователи нашей системы. Еще есть сервисы, для которых Sage выступает бэкендом, — с ними тоже надо взаимодействовать.
Глубинные интервью с клиентами: как проверяли свои гипотезы
На этапе глубинного интервью мы сформулировали список услуг, как сами их видим, и гипотезы об ожиданиях клиентов в вопросе надежности.
Важный момент: все это — наши галлюцинации. Пока мы не проверили гипотезы на пользователях и не поняли, как они интерпретируют наши предположения, верить им нельзя. Задача интервью — как раз проверить.
Несколько гипотез, которые у нас появились:
У нас есть одна услуга — «загрузка метрик». Пользователи не знают, по какому конкретному каналу идут их метрики.
Наличие дыр в метриках неприемлемо: если есть дыры — клиенты рвут волосы.
Клиенты часто пользуются метриками за год.
Все три не подтвердились. Но подробнее об этом — ниже, сначала — о том, как мы проводили интервью.
Подготовка к любому интервью начинается со скрипта — на языке продактов это документ со списком вопросов и планом интервью. Параллельно собираем список респондентов.
Несколько важных моментов про сам процесс:
Лучше, если на интервью будет присутствовать технарь. В нашем случае я был тем самым переводчиком между инженером или пользователем со стороны клиента и продактом, который будет собирать из услышанного отчет.
Первые интервью — репетиция и отладка скрипта. Их мы проводим внутри своей команды, с коллегами. Идея простая: в исходном скрипте всегда есть косяки — неудачные формулировки, дублирующиеся вопросы. Лучше выловить их на своих, чем испортить первое интервью с реальным клиентом.
На интервью важно слушать. Закрываем лишние ноутбуки, чатики и все остальное. Этот час — про нашего клиента: слушать, задавать вопросы, получать информацию.
План интервью:
Попросить разрешения включить запись — после интервью нужен артефакт, к которому можно вернуться, если что-то было понято неправильно.
Использовать открытые вопросы и провоцировать респондента рассказывать о реальном опыте, а не о гипотетическом будущем.
Задать в конце несколько финальных вопросов.
В нашем случае открытые вопросы звучали так:
«Расскажи, когда тебя в последний раз подвел Sage во время сбоя». Дальше начинается рассказ, и мы цепляемся за детали.
«Расскажи про последний крупный инцидент. А Sage как тебе в нем помог? А чего не хватило?»
«Расскажи, когда у тебя не было метрик за последние пять минут? Как ты вышел из ситуации?»
На последнем вопросе иногда выяснялось: «О, слушай, там коллеги быстро сделали обходное решение, нас в целом все устроило. Это было разовое событие». Это тоже ценный инсайт.
В моем случае выстрелили два вопроса:
«Как ты считаешь, с кем еще мне было бы полезно поговорить?» Так мы получили дополнительные релевантные контакты — людей, для которых наша надежность важна.
«Есть ли что-то, что я забыл спросить, но чем ты хотел бы поделиться?» Я же человек — обязательно что-нибудь забуду.
Результаты интервью: три группы услуг и неожиданная терпимость к дырам
Подводя итоги исследования, мы получили три группы услуг:
запись метрик;
глобальный поиск;
администрирование подсистемы.
Помните гипотезу, что пользователи знают только про одну услугу — «запись метрик»? Мы ошиблись. Пользователи отлично понимают, по какому именно каналу в Sage поступают их метрики. Поэтому группа «Запись метрик» распалась на две отдельные услуги: загрузка данных по Remote Write и скрейпинг таргетов по OpenMetrics.
Группа «Администрирование» для клиентов менее важна, а значит, в будущем можем давать на нее более низкие гарантии, чем на запись метрик и глобальный поиск.
Важный момент: всю работу в фазе Discovery нужно фиксировать как требования. В нашем случае мы завели документ, в котором рядом с каждой услугой есть ее описание, чтобы любой человек, зайдя в документ, понял, что мы имеем в виду.
Примеры:
Загрузка данных по Remote Write — «пользователь системы может записать метрики в систему, используя протокол Remote Write».
Поиск по историческим данным — «пользователь системы может делать поиск по данным из долгосрочного хранилища».
В целом текущее положение клиентов устраивает. Но некоторые гипотезы мы уверенно опровергли, например ту самую «дыры в метриках неприемлемы». Клиенты спокойно сказали: «Если во время инцидента у нас будут дыры в метриках на минуту — переживем, главное, чтобы они совсем не пропали».
Еще один артефакт: уровень надежности — Tier. Мы поняли, что одну и ту же услугу можно предоставлять с разными гарантиями.
Уровень надежности — это как раз про гарантии. Есть клиенты, которых устраивает дефолтная конфигурация коммунального хранилища. А есть клиенты с другими требованиями: например, по умолчанию мы храним метрики с интервалом 30 секунд, но кому-то нужен интервал в секунду — под них мы можем адаптировать услугу и давать другие гарантии.
Graceful degradation — состояние системы, когда она может ограничить нагрузку, фильтруя часть телеметрии. Наши коллеги прямо сказали: «Мы понимаем, что у вас коммунальное хранилище и бывают ситуации, когда базу шатает. Мы готовы к тому, что можем потерять часть метрик, но, если вы нам явно скажете, какие именно метрики можно потерять и предложите их временно отключить, мы пойдем навстречу».
От услуг к SLO: как формулировали цели надежности
Разобрались со списком услуг, сформировали ожидания по надежности. Теперь — этап проектирования SLO. Чтобы двигаться дальше, нужно проговорить ключевые слова SRE-мира: SLI, SLO, SLA, бюджет ошибок или плохих минут.
Плохая минута лежит в основе всех остальных измерений. Почему минута? Потому что в разговорах с клиентами мы всегда общались именно в минутах: «Sage простаивал пять минут, нам было некомфортно», «У нас было отставание метрик на две минуты», «У нас стреляли фолсовые алерты». Все общение с внешним миром — в минутах.
Плохая минута — клиент не смог воспользоваться услугой в рамках этой минуты.
Хорошая минута — обратная ситуация: услуга была предоставлена, работала стабильно, клиент ею воспользовался.
SLI (Service Level Indicator) — индикатор, отражающий рабочее состояние компонента услуги в настоящий момент. Можно строить на логах, метриках: задача — просто показать, в каком состоянии компонент сейчас.
SLO (Service Level Objective) — тот трешхолд, по которому мы понимаем: индикатор его пробил — клиент не удовлетворен, пошли плохие минуты. На одну услугу SLO может быть несколько.
Визуализируем на примере. Есть API, есть запросы по нему. SLO формулируем так: «Пользователь доволен, если доля успешных ответов за 1 минуту ≥ 98%». На графике появляется красная линия — трешхолд.
Сверху накладываем SLI — «процент успешных запросов за 1 минуту».
Случился сбой, SLI провалился ниже трешхолда.
Все время, проведенное ниже трешхолда, — те самые плохие минуты. На нашем примере получается 14 минут простоя: пользователи не смогли воспользоваться услугой.
А точно ли мы считаем надежность? Справедливый вопрос: мы же обещали говорить про надежность, а теперь появились какие-то минуты.
В первую очередь нас интересует доступность услуги — те самые девятки, которые везде используются (иногда их называют uptime). Доступность можно интерпретировать двояко:
про прошлое — «услуга была доступна 99% времени»;
про будущее — «услуга будет доступна с вероятностью 99%».
SLA — это соглашение. Критерии и правила соглашения мы определяем в том числе с бизнесом. В нашем случае соглашение состоит из двух условий:
SLA мы заключаем по доступности услуги.
Указываем, на каком интервале считаем эту доступность.
Для наших услуг мы выбрали окно 30 дней. Интересный момент про интерпретацию. SLA «две девятки» может пониматься двояко:
со стороны клиента — клиент может пользоваться услугой 99% времени от окна (иначе санкции или альтернативы);
со стороны нас — услуга может быть недоступна в течение 1% от окна. Это время, которое мы можем тратить на работы, улучшения, развитие продукта.
SLO для Remote Write: доступность, латентность и лаг метрик
Мы собрали всю команду, которая участвует в развитии подсистемы метрик: разработчиков, SRE-партнеров, продактов, тех, кто участвовал в интервью. Теперь наша задача — совместно продумать для каждой услуги ее SLO.
Алгоритм такой встречи:
Смотрим схему пайплайна записи.
Выявляем критические узлы.
Смотрим, как их отказ влияет на клиентов.
Строим путь данных / путь запроса.
Формулируем SLO.
У нас ушло три-четыре итерации, чтобы получить финальные спецификации SLO по услугам. Разберем на примере загрузки по Remote Write.
Metrics Writers (как правило, vmagent) по протоколу Remote Write передают телеметрию в нашу систему. Метрики прилетают через балансер, попадают в Metrics-коллектор, который сохраняет их в VictoriaMetrics — в краткосрочное и долгосрочное хранилища.
При этом у нас есть отложенная запись через Kafka — фоновый процесс, который нужен, чтобы сглаживать всплески нагрузки у клиентов. Если клиентский поток превышает лимит прямой записи, Metrics-коллектор складывает часть метрик в Kafka, а потом в фоне вычитывает и записывает в базу.
Мы сформулировали два вида влияния:
1. Дропы метрик. На стороне клиента метрики обычно отправляет vmagent — у него есть своя очередь. Если мы начинаем медленно отвечать или возвращать ошибки, очередь на стороне vmagent растет, а при переполнении новые метрики в нее уже не попадают — дропаются. Когда Sage восстановится, у пользователя на дашбордах за это время будут пробелы — телеметрии просто нет.
2. Отставание метрик (lag). Клиент успел записать в нас метрики, они дошли до коллектора, но тот по какой-то причине не смог сохранить их в базу. Когда база восстановится, лаг откачается из Kafka и клиент увидит свои метрики без пробелов, просто с задержкой.
Для клиента критичны и потеря метрик, и отставание по ним: во время инцидента он теряет возможность понять, что происходит с его сервисом, и вынужден искать альтернативы, например разбираться по логам.
Критические узлы в пайплайне: балансер, Metrics-коллектор (вход в API), база данных, выход из коллектора.
Первое SLO: пользователь доволен, когда доступность Remote Write API на запись метрик составляет 99% на окне в пять минут. Оно сформировано из тезиса, что важно вовремя и корректно отвечать на запись.Если мы отвечаем, например, 500-ми, у клиентов начинают копиться очереди, они теряют метрики.
Второе SLO — о латентности: пользователь доволен, когда латентность Remote Write API на запись метрик ≤ 500 мс в 99-м перцентиле на окне в пять минут. Если отвечаем медленнее, у клиентов растет лаг на vmagent, очереди переполняются, метрики дропаются на их стороне.
Когда мы описываем SLO, мы описываем влияние на пользователя. Формулировка должна показывать, страдает он или нет.
По моим наблюдениям, на командных созвонах техническим людям эту идею продать на первых этапах трудно, поэтому я сначала использую формулировку «плохая минута, когда…»: она всем понятна. Через два-три созвона, когда у ребят все выстраивалось в голове, я подменял ее на «пользователь доволен, когда…». Все уже понимали, что речь именно про пользователей и их удовлетворенность конкретной услугой.
Пара советов по SLO:
Указывать интервал измерения прямо в формулировке.
Ясность и недвусмысленность. Например, когда мы описали доступность remote_write API, выяснилось, что «недоступность» — это не только 500-е коды. Если мы возвращаем 429 — это тоже проблема, значит, услугу мы не предоставляем. Такие коды нужно описывать явно, в спецификации.
Еще примеры SLO для услуги «загрузка метрик по Remote Write»:
Пользователь доволен, когда прямая запись на краткосрочное хранилище ≥ 90%, а отложенная ≤ 10% на окне в пять минут.
Пользователь доволен, когда отставание (lag) по метрикам < 200 000 на окне в пять минут. 200 000 — эмпирически рассчитанная цифра, которая приблизительно соответствует пяти минутам.
В финальном документе рядом описаны услуга и SLO, за которыми мы будем следить. В описании SLO мы по факту фиксируем не сам индикатор, а то, что мы в итоге будем измерять и куда смотреть. Это помогало в дальнейшей работе.
Этап Discovery — большой и крупный. Он помог нам сформулировать образ результата и погрузить в контекст всех причастных. Дальше — реализация и тестирование, этот блок идет быстрее.
Реализация SLI: как запустили измерение и проверили на сбоях
В Т-Банке есть продукт FineDog, в который мы интегрируемся: регистрируем там те самые услуги, которые описали, добавляем к ним SLO и реализуем SLI.
Реализуем SLI из того, что уже есть. Можно на метриках, можно на логах: задача — как можно быстрее получать обратную связь по уже сделанной работе. Новые метрики вводить на этом этапе не стремимся.
Перед выводом в продакшен тестируем SLO / SLI и корректируем:
Учения. Сами провоцируем сбой и убеждаемся, что индикатор срабатывает и пробивается SLO.
Реальные сбои на проде. Смотрим, как SLI реагирует.
Обращения в саппорт. Если клиенты пишут, что что-то не так, а у нас индикатор не сработал, значит, где-то мы считаем неправильно, надо корректировать.
Наблюдаем 30—60 дней: хотим получить полное временное окно и реальную доступность, с которой сейчас работает услуга. По итогам делаем корректировки услуг, SLO и SLI.
По результатам финализируем и фиксируем с командой / продактами SLO и договариваемся о поддержке их в актуальном состоянии:
ретроспективный анализ показателей;
реагирование на пробитие SLO;
дальнейшее развитие SLO / SLI;
информация о новых услугах и фичах должна попадать в нашу инцидент-менеджмент-систему.
Результаты: 7 услуг, 29 SLO и прозрачность для команд
По итогам работы у нас 7 услуг по подсистеме метрик и суммарно 29 SLO на эти услуги. Показатели реальной доступности:
поиск по свежим метрикам — 99,8%;
поиск по историческим метрикам — 99,8—99,9%;
запись метрик (OpenMetrics и Remote Write) — 99,9%.
Появились новые дашборды с SLI, трешхолдами SLO и потраченным бюджетом за неделю / за день.
Еще один приятный эффект — наши услуги появились на HealthMap. Теперь, прежде чем идти в саппорт, клиент может сам понять, есть ли инцидент на услуге в Sage, и подписаться на инцидент.
Команда подсистемы метрик полностью забрала на себя поддержку и развитие SLI и SLO. Мы, как SRE, скорее выступаем консультантами: помогаем, когда есть вопросы по описанию или написанию индикаторов. Вся ответственность — на команде.
Нам удалось вовлечь всех, кто связан с подсистемой метрик. Отдельно отмечу, что продакты стали внимательнее относиться к тому, что такое надежность и как правильно считать доступность услуги.
Нам удалось получить подход, который мы распространили на логи, трейсы, алертинг и все остальные подсистемы Sage.
Главные выводы: SLO — это не метрики, а диалог с клиентом
SLO и SLI — это сила. Когда мы говорим о надежности продукта, на самом деле говорим о доступности услуг. Рассуждать надо в разрезе тех услуг, что мы предоставляем клиентам.
Чтобы понять, какие есть услуги и как их недоступность влияет на пользователей, надо общаться с клиентами. Либо через продактов, либо напрямую. Если у вас есть возможность — обязательно сходите на звонок с клиентом, хотя бы послушать. Это очень полезно.
Весь наш подход умещается на одном слайде. И главное — его можно переиспользовать. Важно помнить, что качественное Discovery — это экономия на этапе Implementation.
Эффект от работы виден сразу: мы нашли много неожиданных поведений в системе, о которых раньше не знали («о, слушайте, а оно вот здесь отвечает по-другому — интересно»). Работа подсистемы стала прозрачной для всех участников рабочей группы.
SLO — не разовая штука. За ними надо следить и регулярно проводить ревью.
Плохая идея — подгонять SLO под бюджет плохих минут. У нас такой соблазн был: «Что-то часто простреливаем трешхолд — давайте его снизим, и будет полегче». Стоп. Мы потратили столько сил, чтобы пройти Discovery и имплементацию, — надо разобраться, что происходит, а не бездумно двигать планку. Мы должны понимать, зачем и почему мы это делаем.
Наблюдай реальную картину и будь честен с самим собой.
Мы с командой ведем телеграм-канал Sage Community — там эксперты со всей страны развивают observability и готовы к общению. Если тема надежности, SLO и observability вам близка — присоединяйтесь, будем рады.
Дополнительные материалы. Если хочется погрузиться в то, о чем я рассказывал, — вот подборка материалов.
Обзорные доклады про Sage и FineDog:
«Эволюция пайплайна метрик. Как менялась архитектура с ростом нагрузки»;
«Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны»;
«Автоматизация инцидент-менеджмента для 10 000 инженеров в Т-Банке»;
плейлист с остальными докладами команды Sage.
Availability & Reliability:
Доклад «SLI/SLO/SLA в микросервисном приложении» от Павла Лакосникова (Авито);
Google: Site Reliability Engineering и вторая часть — The Site Reliability Workbook;
SigNoz: Availability vs. Reliability — Key Differences in System Design;
FireHydrant: SLA vs. SLO vs. SLI — Differences Explained;
Atlassian: Reliability vs availability: Understanding the differences;
AWS: Availability and Beyond: Understanding and Improving the Resilience of Distributed Systems on AWS;
AWS Well-Architected: Availability;
«Как я пришел к SLO: От хаоса алертов к осознанности» — Дмитрий Синявский.
Про качественные / глубинные исследования (наука продактов):
Открытые стандарты и фреймворки:
Другое, но полезное:
Доклад «Математика надежности»;
Книга Enterprise Roadmap to SRE;
Книга «The Site Reliability Workbook» от Google;