Как поддержка True Engineering работает с алертами в мониторинге продуктов

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

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

Как работают метрики

Для сбора технических и бизнес-метрик сервисов мы используем инструмент Prometheus. Показатели визуализируются в Grafana, где настроены дашборды с ключевыми метриками. При этом развертывание этих информационных панелей идет сразу для всех окружений – в том числе, и на проде у заказчиков.

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

Например, так мы отслеживаем в одном из наших решений количество выгрузок в интегрированные системы – хранилище данных Bitrix и систему управления каталогом товаров Opus. Эти выгрузки делятся по типам файлов, каждый из которых обозначается своим цветом. Каждые пять минут метрика обновляется. Ещё один показатель – продолжительность загрузки по стадиям. Прогресс-бар показывает в секундах, сколько времени занимает каждый этап загрузки.

На этих же метриках настраиваются и алерты. Они приходят в Slack и позволяют командам быстро реагировать на поломки, без траты времени на просмотр графиков. Другой вариант – настроить прием алертов в Jira, где по ним будут автоматически заводиться тикеты.

Здесь главное правильно настроить условия для каждого уведомления, чтобы команда не тревожилась из-за ложноположительных срабатываний. Или наличие хотя бы одного Error-сообщения служит поводом к разбору. А при формировании очереди в RabbitMQ поводом обратить внимание будет превышение цифры в условные 50 сообщений.

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

Также в каналы Slack имеют доступ заказчики. Таким образом они тоже могут отслеживать статус алертов и реагировать на них при необходимости.

Как мы отрабатываем алерты

Сначала все уведомления берут в работу инженеры сопровождения. Некоторые алерты они закрывают сами, когда им удается понять в чем причина ошибки и починить ее. А дальше рождается несколько типов задач для команд разработки.

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

Система алертов должна жить и развиваться

В качестве заключения – несколько слов о том, как создавать и поддерживать систему метрик. Первое, что нужно сделать – это погрузить инженеров сопровождения в работу продукта, чтобы они хорошо знали, как она устроена и как бизнес-процессы находят выражение в процессах технических. Вместе с разработчиками и PM-ами они должны разобрать все основные сценарии и определить метрики, которые будут говорить о работоспособности продукта в целом и частных его компонентов по отдельности.

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

Например, среди наших продуктов есть система учета продаж, где очень важно отслеживать поступление определенных данных из внешних источников. Часть этих данных загружается автоматически, часть – вручную. Документы, которые поступали вторым способом, прогружались позже, из-за чего у поддержки срабатывал алерт. Решили создать в системе мониторинга новый признак, чтобы разделять автоматическую загрузку и ручную – ложных срабатываний больше не было.

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

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