Yandex Monium: от сбоя к решению за минуты

Инциденты невозможно исключить полностью. Даже если команда долго работает над надёжностью инфраструктуры, улучшает архитектуру и снижает количество сбоев, рано или поздно случаются уникальные проблемы, от которых сложно защититься заранее.

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

Здесь важна observability — способность системы давать команде достаточно данных, чтобы понять, что происходит внутри сервиса: по метрикам, логам, трассировкам, алертам и связанному контексту. Чем меньше времени команда тратит на переходы между инструментами и ручной поиск нужных данных, тем быстрее она может перейти от сигнала к действию.

Надёжность — это не про количество инцидентов

Один из базовых показателей надёжности — аптайм, показатель, отражающий, сколько времени система, сервис или устройство работает без сбоев. В разных продуктах он может считаться по-разному.

Иногда аптайм можно представить как общее время работы системы минус время, когда система работала неправильно. Но для бизнеса этого может быть недостаточно. В одних системах важнее работоспособность в пиковые периоды, в других — количество успешно завершённых заказов, в третьих — недополученная прибыль.

Поэтому универсальной формулы аптайма для всех продуктов нет. Метрика зависит от того, как устроен конкретный бизнес и что для него считается пользовательским влиянием.

Но общий принцип сохраняется: инциденты уменьшают надёжность сервиса. Улучшать надёжность можно двумя большими способами:

• снижать количество инцидентов — улучшать инфраструктуру, архитектуру и процессы так, чтобы сбоев становилось меньше;
• сокращать продолжительность инцидентов — быстрее обнаруживать проблему, находить причину и устранять влияние на пользователей.

Первое направление помогает реже ломаться. Второе — быстрее восстанавливаться, когда сбой всё-таки произошёл.

Из каких этапов состоит инцидент

Инцидент можно разделить на две большие фазы.

• Первая — горячая. В это время есть влияние на пользователей, а команда должна как можно быстрее вернуть систему в нормальное состояние.
• Вторая — холодная. После устранения влияния команда проводит разбор, делает ретроспективу и работает над тем, чтобы похожие инциденты не повторялись.

В горячей фазе можно выделить четыре основных этапа.

Часто в командах используют метрики вроде mean time to recovery, mean time to root cause и похожие показатели. Но у средних значений есть проблема: они сглаживают картину и не показывают, где именно теряется время.

Полезнее смотреть не только на среднее, но и на распределение по этапам: где большинство инцидентов проходят быстро, а где появляется длинный «хвост».

Почему важно смотреть на распределение времени

Представим, что большинство инцидентов обнаруживается в первые три минуты. На первый взгляд, всё хорошо. Но если у распределения есть длинный «правый хвост», это значит, что часть инцидентов команда замечает значительно позже.

Причины могут быть разными:

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

То же самое можно сделать для остальных этапов: реагирования, поиска причины и устранения влияния.

Если реагирование в среднем занимает четыре минуты, стоит понять, на что именно они уходят. Люди долго собираются? Неудобно авторизоваться? Нужно переходить между несколькими системами? Дежурный тратит время на поиск нужного дашборда?

Если поиск корневой причины стабильно занимает 10–15 минут — это повод посмотреть, какие шаги команда каждый раз проходит вручную и где можно сократить путь.

Что замедляет поиск причины

Во время инцидента команда постоянно переключается между контекстами.

Сначала нужно понять, какой сервис пострадал. Потом — перейти на дашборд этого сервиса. Затем посмотреть, какая метрика аномальна, перейти к зависимому сервису, открыть его дашборд, посмотреть логи, трассировки, ошибки, хосты, поды и другие детали.

Путь может выглядеть так:

1. На верхнеуровневом дашборде видно, что API начал ошибаться.
2. Нужно перейти на дашборд API.
3. На дашборде видно, какой эндпоинт отвечает долго или с ошибкой.
4. Нужно перейти в трассировки по этому эндпоинту.
5. Потом — в логи с тем же контекстом.
6. Затем — сгруппировать ошибки по пользователям, подам или хостам.
7. После этого — понять, какое действие может убрать влияние.

Каждый переход сам по себе может занимать немного времени: 10, 20 или 30 секунд. Но если таких переходов 10–15, суммарно они превращаются в минуты.

Поэтому для ускорения устранения инцидентов важно не только иметь данные, но и быстро находить нужные данные в нужном контексте.

Как начинается инцидент

По опыту, команда узнаёт об инциденте двумя основными способами.

Первый — уведомление или звонок: сработал алерт, система сообщает, что что-то сломалось.

Второй — TV-дашборд. Это верхнеуровневый дашборд на экране рядом с командами разработки. На нём собраны ключевые показатели системы: например, количество заказов, процент успешного завершения, время поиска исполнителя или другие бизнес-метрики.

Такой дашборд нужен, чтобы за несколько секунд понять:

• работает ли система корректно прямо сейчас;
• в какой части системы может быть проблема;
• похоже ли это на кратковременный всплеск или на устойчивую аномалию.

Быстрые ссылки: переход к нужному дашборду без поиска

Первый инструмент Yandex Monium, который помогает сокращать время, — быстрые ссылки.

Обычно после сигнала на верхнеуровневом дашборде нужно вручную найти подробный дашборд: по API, базе данных, дискам, CPU, зависимостям или конкретному сервису. Если дашбордов много, поиск занимает время.

В Yandex Monium быстрые ссылки можно добавлять:

• на отдельные виджеты;
• на дашборд целиком;
• к основным техническим и продуктовым графикам.

Например, у виджета с API может быть быстрый переход на дашборд с деталями по API, а у виджета базы данных — переход к показателям по базам.

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

Контекстные ссылки: переход из графика в логи и трассировки

Следующий уровень — контекстные ссылки.

На вебинаре в демонстрационном инциденте после перехода на дашборд API стало видно, что один из эндпоинтов — Orders API — начал отвечать очень долго. В 99-м перцентиле время выросло до 15 секунд, и появились ошибки.

Обычный путь в такой ситуации — перейти в трассировки или логи и заново ввести контекст:

• сервис;
• эндпоинт;
• код ошибки;
• временной интервал;
• другие селекторы.

Но это снова занимает время. Контекстные ссылки позволяют кликнуть по конкретной линии на графике и перейти в другой тип телеметрии с уже заполненными параметрами. Например, из графика по эндпоинту можно перейти в трассировки или логи сразу с нужным эндпоинтом и кодом ошибки.

Такие ссылки могут вести не только внутрь Yandex Monium, но и во внешние системы: например, в систему оркестрации, если нужно посмотреть конкретный под или выполнить действие с ним.

Как трассировки помогают локализовать проблему

После перехода в трассировки команда видит несколько трейсов с 503-й ошибкой. Внутри трейса есть десятки или сотни спанов: по ним можно понять, какие операции выполнялись, сколько они длились и чем завершились.

В демонстрации на вебинаре в трейсе были успешные и быстрые запросы к базе данных. А затем был спан обращения к внешнему сервису payment. Именно он выполнялся долго и завершался ошибкой.

В деталях спана было видно:

• имя спана;
• длительность около 15 секунд;
• ошибку;
• признак тайм-аута.

Ровная длительность в 15 секунд дополнительно подсказала, что где-то мог сработать тайм-аут. Но этого ещё недостаточно, чтобы завершить расследование: ошибки возникали не в 100% случаев, поэтому нужно было искать закономерность дальше.

Как логи помогают проверить гипотезы

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

В демонстрационном инциденте в логах было видно, что ошибки 503 появились в определённый момент времени. Дальше можно было быстро отфильтровать только эти ошибки.

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

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

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

Вторая гипотеза: возможно, проблема относится к одному конкретному пользователю. Для проверки логи сгруппировали по user ID. Оказалось, что пользователи разные, значит, проблема не в одном пользователе.

Как команда нашла реальную закономерность

Дальше в логах стала видна другая закономерность: все ошибки 503 приходили с одного и того же пода. Но и это нужно было проверить. Если проблема не в одном поде, а, например, во всех подах одного дата-центра, действия будут другими.

В Yandex Monium для этого можно использовать статистику по группировкам параметров в логах. Команда перешла в раздел статистики, сгруппировала события по идентификатору пода и увидела, что ошибки действительно приходят только с одного пода.

После этого проверили ещё один вопрос: под полностью «умер» или только часть запросов завершается с ошибкой. Для этого запрос сгруппировали по коду ответа. Выяснилось, что на проблемном поде есть и успешные 200-е ответы, и 503-и ошибки.

Альтернативный путь: распределение по хостам сразу из графика

Разбор через трассировки и логи полезен, но в реальном инциденте проблемы на одном поде — типовой сценарий. Такие гипотезы часто проверяют в первую очередь.

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

В демонстрации этот путь позволял без перехода в дополнительные виды телеметрии увидеть, что:

• почти везде запросы завершаются 200-ми или клиентскими 400-ми ошибками;
• 503-и ошибки есть только на одном поде.

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

Алерты с детализацией по селектору

Ещё один способ ускорить диагностику — сделать так, чтобы верхнеуровневый дашборд сразу показывал более точную информацию.

После инцидента с одним проблемным подом action item мог бы звучать так: команда хочет быстрее получать с TV-дашборда агрегированную информацию о конкретной части системы.

Для этого в Yandex Monium есть виджет алертов. Он показывает, какие алерты сейчас в состоянии «ОК», а какие «горят». При наведении на алерт можно увидеть детализацию.

Например, алерт API errors может загореться не просто по API целиком, а по конкретному поду. Остальные поды при этом останутся зелёными.

Это настраивается через разбивку алерта по селектору — например, по лейблу host. После этого Yandex Monium создаёт подалерты, каждый из которых мониторит конкретный хост или под.

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

Блокноты для ранбуков: инструкции рядом с данными

Во многих командах к алертам прикреплены ранбуки — инструкции, что делать, когда сработал конкретный сигнал. Но часто они лежат в отдельных системах: в документации, Вики, заметках или внешних файлах.

Из-за этого во время инцидента команда снова теряет контекст: нужно перейти в другое место, найти нужную инструкцию, скопировать запросы, вставить их в систему мониторинга и выполнить.

В Yandex Monium для этого есть блокноты. Их можно использовать как ранбуки:

• добавлять текстовые инструкции;
• прикреплять запросы к метрикам;
• задавать параметры;
• использовать временной диапазон — например, последние 30 минут или последний час;
• получать уже выполненные запросы рядом с описанием действий.

К примеру, если сработал алерт API errors, в блокноте можно сразу указать запрос, который раскладывает ошибки по эндпоинтам. Команде не нужно переходить в другой дашборд или вручную собирать запрос — она остаётся в одном окне и быстрее проверяет типовые гипотезы.

Какие данные помогают находить причину сбоя

В расследовании инцидентов используются три основных типа телеметрии, и у каждого своя роль:

В демонстрации на вебинаре метрики подсказали первоначальный путь: проблема не выглядела массовой на 100%, поэтому нужно было искать закономерности. Трассировки помогли увидеть тайм-аут на обращении к payment. Логи позволили проверить гипотезы и найти общий признак — один проблемный под.

Как SLO помогает управлять надёжностью

В Yandex Monium есть отдельная сущность SLO. Её можно настраивать так же, как дашборды, алерты или каналы уведомлений.

SLO обычно связан с метриками. При настройке нужно определить:

• на какую метрику смотрим;
• какие события считаются хорошими;
• какие события считаются плохими;
• как именно считаем показатель;
• за какой период считаем;
• какой порог используем — например, три девятки, 99,95 или четыре девятки.

После этого можно смотреть статистику по SLO: насколько быстро или медленно он «сгорает».

На SLO также можно настроить алерты. Если происходит fast burn, то есть SLO начинает «сгорать» слишком быстро, это может считаться инцидентом. В зависимости от канала уведомления система может позвонить дежурному или отправить сообщение в чат.

Логика может быть разной: если SLO «горит» быстро, стоит будить дежурного; если он регулярно «сгорает» понемногу, это тоже повод разобраться, но необязательно поднимать человека ночью.

Что Yandex Monium даёт при анализе сбоев

Главная ценность Yandex Monium в разборе инцидентов — не в одном отдельном графике или типе телеметрии, а в сокращении пути между ними.

Платформа помогает:

• Быстрее переходить от верхнеуровневого сигнала к деталям.
  Быстрые ссылки ведут с TV-дашборда на нужные технические дашборды.

• Не терять контекст при переходах.
  Контекстные ссылки передают эндпоинт, код ошибки, сервис и другие селекторы в логи, трассировки или внешние системы.

• Быстрее проверять типовые гипотезы.
  Распределение по хостам или подам помогает сразу понять — массовая проблема или локальная.

• Работать с разными типами телеметрии в одном UX.
  Метрики, логи и трассировки устроены единообразно, поэтому проще переходить между ними во время инцидента.

• Держать инструкции рядом с данными.
  Блокноты можно использовать как ранбуки: хранить инструкции, параметры и готовые запросы рядом с контекстом инцидента.

• Использовать SLO как сигнал для инцидентов.
  Алерты по fast burn помогают реагировать не только на отдельные метрики, но и на деградацию надёжности.

Итоговый пример: как сокращается путь к решению

В демонстрационном инциденте на вебинаре путь расследования выглядел так:

Альтернативный путь через распределение по хостам позволил бы быстрее прийти к тому же выводу: 503-и ошибки сосредоточены на одном поде.

Ключевые выводы

Yandex Monium помогает сокращать время инцидентов за счёт того, что делает путь расследования короче и удобнее.

Главные идеи:

• Надёжность зависит не только от количества инцидентов, но и от их продолжительности.
• Средние значения вроде mean time to recovery полезны, но важнее смотреть распределения по этапам.
• Данные из постмортемов можно использовать, чтобы найти этапы, где команда чаще всего теряет время.
• Во время инцидента критично быстро переходить между метриками, логами, трассировками, дашбордами и внешними системами.
• Быстрые и контекстные ссылки сокращают количество ручных действий.
• Метрики показывают масштаб проблемы, трассировки локализуют место, а логи помогают искать закономерности.
• Алерты с разбивкой по селекторам позволяют увидеть проблему на уровне конкретного пода или хоста.
• Блокноты помогают держать ранбуки, инструкции и готовые запросы рядом с контекстом инцидента.
• SLO и алерты по burn rate помогают управлять надёжностью на уровне пользовательского влияния.

В итоге Yandex Monium не просто показывает графики. Он помогает команде быстрее пройти путь от первого сигнала до конкретного действия: понять масштаб проблемы, сохранить контекст при переходах, проверить гипотезы и найти точку, где можно снизить влияние на пользователей.