Снова про мониторинг продуктов: как Postman избавляет поддержку от написания кода

    Postman – удобный инструмент, который умеет описывать и исполнять запросы, получать информацию об их статусах, выстраивать цепочки запросов, зацикливать их, создавать сценарии. Главный плюс – код писать при этом практически не нужно.

    Некоторое время назад мы уже рассказывали про технологию, по которой мы ставим продукты на мониторинг. На верхнем уровне план действий следующий:

    1. Составить карту пользовательских сценариев – описать по шагам все действия, которые пользователи выполняют в продукте.

    2. Пройти по интерфейсу, зафиксировать запросы, которые стоят за каждым действием пользователя.

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

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

    Как работать с Postman

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

    • Окружения содержат значения переменных, с которыми мы работаем в рамках сценариев – адреса серверов, имена папок и т.д. Фактически одно окружение – это один продукт.

    • Коллекция описывает, что с этими переменными делать. Это набор запросов, и в нашем случае одна коллекция – это один сценарий мониторинга. Одну коллекцию можно использовать в разных окружениях, подставляя нужные переменные. Не нужно для каждой системы писать новый сценарий авторизации – можно одним кликом вызвать уже готовую коллекцию.

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

    Как мы встроили Postman в свой процесс

    Мы применяем Postman для разработки сценариев мониторинга, тестирования и проработки интеграционных взаимодействий.

    • Сценарии экспортируются в JSON-файлы и сохраняются в Git-репозиторий TFS.

    • В пайплайне TFS прописывается проверка по расписанию. Стоит отметить, что для нас интеграция с TFS – это ещё одно преимущество Postman, поскольку с этого года все наши команды работают именно здесь. В TFS можно сразу увидеть результат выполнения запросов, что очень удобно, если Postman используется для отладки продукта. У нас речь про мониторинг, так что не будем углубляться.

    • JSON-файл вызывается через утилиту Newman – это инструмент для запуска коллекций из командной строки, который также разработала команда Postman. Он умеет выполнять запросы, принимать ответы на них, высчитывать метрики, которые указаны в сценарии.

    • Результаты выполнения сценариев сохраняются в БД Influx, откуда данные отправляются в дашборды Grafana. Здесь можно настроить критические пороги, чтобы автоматически сообщать, если какой-то показатель выходит за заданное значение.

    Итого

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

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

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

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 5 953 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое