Синтетический
мониторинг
Узнавайте о сбоях раньше пользователей за счет непрерывного тестирования интерфейсов, проактивно реагируйте на возможные ошибки и сократите время расследования причин аварий.
Проблема
Пользователи жалуются на неработоспособность сервисов, а мониторинг «молчит»
Невозможно зайти в мобильное приложение, записаться к врачу, оплатить покупку в интернет-магазине, не работают кассы, подрядчик нарушает SLA по доступности сервисов, а инженеры поддержки приступают к поиску проблем после жалоб пользователей и проверяют вручную десятки, а иногда и сотни информационных систем – типичный процесс эксплуатации в быстро развивающихся и сильно зависящих от стабильной работы IT крупных компаниях.
Инженерам сложно выполнять KPI по доступности и проактивно работать со сбоями, а бизнес несет финансовые и репутационные потери.
Инженерам сложно выполнять KPI по доступности и проактивно работать со сбоями, а бизнес несет финансовые и репутационные потери.
Решение
Воспроизводите действия пользователей и будьте в курсе любых аномалий
Помочь справиться с валом ручных проверок пользовательских интерфейсов в растущих и разнородных инфраструктурах может синтетический мониторинг. Именно он позволяет создавать и автоматизированно выполнять сценарии и тесты, имитирующие действия реальных пользователей.
Результаты таких тестов анализируются, выявляя возможные проблемы и узкие места в инфраструктуре и приложениях до того, как они начнут массово влиять на конечных пользователей.
Результаты таких тестов анализируются, выявляя возможные проблемы и узкие места в инфраструктуре и приложениях до того, как они начнут массово влиять на конечных пользователей.
Принципы автотестирования в Monq
Monq не имеет собственной среды тестирования и работает только с внешними. Однако платформа умеет:
- выступать в роли планировщика;
- принимать отчеты;
- обрабатывать их результаты;
- визуализировать взаимосвязи;
- создавать Сигналы в случае провала сборок;
- на основе Сигналов выполнять уведомления, запускать скрипты, выполнять другую автоматизацию.
У платформы есть два вида взаимодействия с внешней средой тестирования:
Автономные проектыВ этом случае у среды тестирования есть собственный планировщик (как например GitLab CI, Travis, Jenkins и др.). Конфигурация и выполнение тестов – по какому расписанию запускать, какие библиотеки для тестов и отчетов использовать – происходит там. Monq в этом случае только принимает отчет, сгенерированный и отправленный по API системой тестирования.
- Управляемые проектыВ качестве планировщика синтетического мониторинга выступает агент Monq, установленный на сервер среды тестирования. В таком случае расписание заданий, переменные среды окружения и команда запуска задаются в самой платформе и выполняются с помощью её агента.
В обоих случаях среда тестирования после выполнения теста должна сгенерировать zip-отчет и по API отправить его в Monq.
Рассмотрим подробнее, как настраиваются Управляемые проекты в Monq.
Исходим из того, что у нас уже есть настроенная среда тестирования с использованием Selenium WebDriver, фреймворка отчётов автотестов Allure и написан pytest для проверки доступности сайта документации.
1. Первый шаг: конфигурация автотест-проекта.
В проекте необходимо написать задание на YAML.Это может быть как простейшая CMD/SH-команда, указывающая, какой скрипт на тест-сервере необходимо запустить, так и более сложное задание, с указанием переменных, которые необходимо передать в удаленный скрипт, а также последовательность шагов. Пример такого задания может иметь следующий вид:
Рассмотрим подробнее, как настраиваются Управляемые проекты в Monq.
Исходим из того, что у нас уже есть настроенная среда тестирования с использованием Selenium WebDriver, фреймворка отчётов автотестов Allure и написан pytest для проверки доступности сайта документации.
1. Первый шаг: конфигурация автотест-проекта.
В проекте необходимо написать задание на YAML.Это может быть как простейшая CMD/SH-команда, указывающая, какой скрипт на тест-сервере необходимо запустить, так и более сложное задание, с указанием переменных, которые необходимо передать в удаленный скрипт, а также последовательность шагов. Пример такого задания может иметь следующий вид:
Далее, поскольку в управляемом проекте планировщиком выступает сам Monq, необходимо задать расписание запуска. Оно указывается в формате CRON. Допустим, тест будет выполняться каждые полчаса: в 15 и 45 минут:
Затем нужно указать метку агента, предварительно установленного на сервер тестирования. Именно он и будет выполнять описанное задание.
Далее - указать, к какой Конфигурационной Единице на карте РСМ будет привязываться результат теста.
2. Второй шаг: настройка сценария парсинга.
Независимо от типа проекта в систему будут поступать отчеты. Чтобы обрабатывать их содержимое, необходимо на low-code движке автоматизации создать сценарий парсинга. Готовый демонстрационный сценарий парсинга для отчетов в формате Allure можно импортировать из нашего GitHub-канала и после импорта его нужно будет только скомпилировать и активировать.
Независимо от типа проекта в систему будут поступать отчеты. Чтобы обрабатывать их содержимое, необходимо на low-code движке автоматизации создать сценарий парсинга. Готовый демонстрационный сценарий парсинга для отчетов в формате Allure можно импортировать из нашего GitHub-канала и после импорта его нужно будет только скомпилировать и активировать.
Уже с этими минимальными настройками система начнет принимать, обрабатывать и отображать результаты сборок.
3. Шаг третий: генерация Сигналов.
Для любой автоматизации, будь то уведомление на почту, заведение заявки во внешней Сервис-деск системе или запуск автохилинг-скрипта – необходим Сигнал. Чтобы в случае провального теста открывался соответствующий сигнал, необходим второй сценарий: создания сигналов. Его также можно импортировать из готовых примеров на GitHub.
Для любой автоматизации, будь то уведомление на почту, заведение заявки во внешней Сервис-деск системе или запуск автохилинг-скрипта – необходим Сигнал. Чтобы в случае провального теста открывался соответствующий сигнал, необходим второй сценарий: создания сигналов. Его также можно импортировать из готовых примеров на GitHub.
Теперь, если в сборке автотестов будет присутствовать провальный шаг, в системе будет открываться соответствующий сигнал.
На этом базовая настройка завершена. Теперь создаваемые Сигналы будут привязываться к той же Конфигурационной Единице, к которой мы прикрепили Автотест-проект. Здоровье этой КЕ будет снижаться в случае поврежденного zip-отчета, проваленного шага/кейса/теста, а если на карте РСМ настроены связи влияния, то наша автотест-КЕ снизит здоровье зависимых.
На этом базовая настройка завершена. Теперь создаваемые Сигналы будут привязываться к той же Конфигурационной Единице, к которой мы прикрепили Автотест-проект. Здоровье этой КЕ будет снижаться в случае поврежденного zip-отчета, проваленного шага/кейса/теста, а если на карте РСМ настроены связи влияния, то наша автотест-КЕ снизит здоровье зависимых.
На этом можно остановиться. А можно настроить:
- Правила
- при выполнении условий которых будут выполняться…
- Действия
- такие, как запуск скриптов или отправка уведомлений на любые поддерживающие API системы. Это может быть как извещение ответственных за сервис команд, так и открытие кейса во внешней сервис-деск системе, webhook-запрос или запуск скрипта рестарта службы, расположенного на удаленном сервере.
При желании можно пойти еще дальше: допилить low-code сценарий парсинга, добавить еще несколько других (также готовых демонстрационных) и настроить Правила порогов метрик – и тогда из автотестов, помимо прочей информации, можно будет еще и генерировать метрики/временные ряды (например, времени выполнения шагов тестов). И уже по ним создавать отдельные сигналы, тоже привязывать к КЕ и получать еще более обогащенную модель информационной системы.
Результаты тестирования каких интерфейсов можно обрабатывать с помощью Monq?
Monq принимает и обрабатывает результаты любых внешних систем тестирования без ограничений – веб-интерфейсов, CRM, мобильных приложений, телефонии и др.
Monq принимает и обрабатывает результаты любых внешних систем тестирования без ограничений – веб-интерфейсов, CRM, мобильных приложений, телефонии и др.
Кейс: от ручного тестирования к полной автоматизации
Проблема
4 000 ручных проверок интерфейсов в день
Клиент – крупный государственный орган:
- проверял вручную 80 информационных систем по пяти сценариям
- это давало в общей сложности 400 сценариев для обработки, сценарии запускали вручную минимум 10 раз в день
- в сумме получалось 4 000 ежедневных ручных проверок
- на каждую проверку уходило минимум 20 минут
- на проверках были заняты 50 инженеров и 22 подрядчика
Решение
Полная автоматизация процесса мониторинга пользовательских интерфейсов
Как именно это было достигнуто?
- к платформе подключили все ИС и связку Zabbix+Jenkins+Selenium+Allurе;
- запустили автоматическое тестирование: в среднем 3-7 тестов по 10 шагов на каждую систему;
- настроили более 7 000 метрик и более 2600 триггеров;
- настроили автоэскалацию событий, их автоматическую регистрацию в ITSM,
- настроили оповещение ответственных команд, подсказки для инженеров по разрешению проблем;
- настроили скрипты автохилинга для рутинных задач.
Бесплатно
Функционал синтетического мониторинга в Monq бесплатный
Узнайте больше о возможностях Monq во время демонстрации системы