Сегодня расскажем, как можно обеспечить эффективный мониторинг для сложного ИТ-продукта и какие процессы можно автоматизировать, чтобы упростить работу саппорт-инженеров.
Именно с мониторинга стоит начинать постановку продукта на техподдержку. И уже на этом фундаменте выстраивать технологию обработки обращений (Incident Management) и развивать системный подход к решению проблем (Problem Management).
Мониторинг даёт возможность выстраивать проактивный подход в техподдержке. Специалисты узнают о проблемах не когда сбой уже произошёл, а реагируя на первые тревожные сигналы.
В общем и целом мониторинг отвечает на два главных вопроса:
Жива ли вообще система?
Могут ли пользователи выполнять нужные им операции?
Далее расскажем, как организовать мониторинг, который даст вам эти ответы.
Какой бывает мониторинг
Технический – проверяет состояние программно-аппаратных компонентов.
Этот мониторинг отвечает на вопросы: как работает каждый отдельный компонент системы? Все ли сервисы пингуются? Не теряются ли запросы к модулям? Всё ли в порядке с сетевой инфраструктурой?
Бизнесовый – проверяет состояние ключевых фич и их влияние на бизнес-показатели.
Здесь применяются пользовательские сценарии, чтобы проверить, как система справляется со своими верхнеуровневыми функциями.
Как правило, с техническим мониторингом у команд проблем не возникает. Трудности зачастую вызывает настройка бизнес-мониторинга – нашему подходу к решению этой задачи и посвящен этот выпуск.
Четыре шага к запуску бизнес-мониторинга
1. Встаем на место пользователя
На первом шаге вы описываете все действия, которые пользователи выполняют в продукте. Расписываете по шагам, что нужно сделать в интерфейсе, чтобы получить тот или иной результат.
Удобно это делать в таблице. На этом этапе в ней появляются колонки:
цель
действия,
критерии критичности,
тип ситуации (штатная/нештатная)
На выходе вы получаете подробное руководство по всем операциям, для которых в принципе используется продукт. По этим данным далее можно готовить тесты, чтобы автоматически проверять, выполняет ли система свои задачи с точки зрения непосредственных пользователей.
2. Переводим с человеческого на машинный
Чтобы автоматизировать эти проверки, это руководство нужно перевести на язык скриптов. Действия пользователя нужно соотнести с конкретными запросами в конкретные сервисы.
Чтобы понять, на что смотреть в выдаче, в таблице добавляем данные:
URL,
тип запроса,
данные,
на что смотрим в ответе.
По результатам этой работы ваша таблица превращается из описания сценариев в полное руководство со всеми запросами, данными в логах, которые говорят о положительном или негативном результате (работает – не работает).
3. Налаживаем авторизацию (опционально)
Большинство корпоративных систем закрыты от внешнего интернета, и для таких случаев нужно решить вопрос авторизации. То есть технически обеспечить возможность системам мониторинга отправить запрос в микросервис и получить данные.
Для этого пишется отдельный модуль, который умеет получать авторизационные данные и передавать их службе мониторинга. Технически это похоже на кукисы в браузере – система, которую мы отслеживаем, передаёт авторизационному сервису токен с ограниченным периодом жизни, а средства мониторинга по этому токену подтверждают право доступа.
4. Автоматизируем и запускаем в работу
Теперь можно начинать автоматизацию и готовить алёрты для процессов. Разработчики пишут скрипты, чтобы имитировать пользовательские действия по списку сценариев. Здесь нужно опираться на бизнес-задачи, смотреть, к какому времени поддержка должна узнать о сбое процесса, чтобы успеть предпринять действия.
Эти скрипты можно «скормить» практически любой системе мониторинга. Лично нам нравится Zabbix, но это может быть Grafana или другой аналитический движок, с которым вы работаете. В вашей таблице есть всё что нужно для настройки.
В результате у нас появляется механизм, который умеет авторизоваться в системе и отправить post-запросы её службам. Остаётся обозначить пороговые значения алёртов и настроить логику отчётов. И ваш мониторинг запущен в эксплуатацию.
Заключение
Наш опыт показывает, что зачастую продуктовая команда сама усложняет себе задачу, слишком погружаясь в технологические параметры. На самом деле процесс прост и прозрачен. Мы показали это на живом примере.
Ключ к решению – это побывать в шкуре пользователя, который каждое утро заходит в систему и проверяет, справляется ли она с его задачами. Если идти к технике через смысл продукта, путь к цели становится гораздо короче, а результаты мониторинга оказывается проще трактовать и контролировать.
В следующем посте поделимся инструментами, которые помогают нашей поддержке работать с мониторингом без лишних манипуляций с кодом.
