Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Postman – удобный инструмент, который умеет описывать и исполнять запросы, получать информацию об их статусах, выстраивать цепочки запросов, зацикливать их, создавать сценарии. Главный плюс – код писать при этом практически не нужно.
Некоторое время назад мы уже рассказывали про технологию, по которой мы ставим продукты на мониторинг. На верхнем уровне план действий следующий:
Составить карту пользовательских сценариев – описать по шагам все действия, которые пользователи выполняют в продукте.
Пройти по интерфейсу, зафиксировать запросы, которые стоят за каждым действием пользователя.
Подготовить скрипты, которые будут имитировать пользовательские действия, выполняя цепочки запросов.
Postman отвечает за последний шаг в этом процессе, при этом использовать его фактически может даже инженер с нулевым опытом и без знания кода. Мы проверили – чтобы научиться делать сценарии в этой программе, достаточно пары часов. После этого специалист поддержки может самостоятельно готовить новые запросы, ставить их в расписание и контролировать результаты.
Как работать с Postman
Итак, вы определились со сценариями, которые хотите мониторить, и подготовили список запросов, которые соответствуют действиям пользователя. В Postman сценарии собираются из этих запросов, как из конструктора. Помимо запросов, такими кирпичиками являются коллекции и окружения.
Окружения содержат значения переменных, с которыми мы работаем в рамках сценариев – адреса серверов, имена папок и т.д. Фактически одно окружение – это один продукт.
Коллекция описывает, что с этими переменными делать. Это набор запросов, и в нашем случае одна коллекция – это один сценарий мониторинга. Одну коллекцию можно использовать в разных окружениях, подставляя нужные переменные. Не нужно для каждой системы писать новый сценарий авторизации – можно одним кликом вызвать уже готовую коллекцию.
Таким образом, механика следующая: пишем запрос, сохраняем в коллекцию, выбираем нужное окружение – и вперёд. При необходимости можно сразу добавить тесты, которые нужно выполнять в каждом запросе или на каждом шаге мониторинга. Наша задача – чтобы система по расписанию проверяла модули на работоспособность, поэтому в этом случае мы обошлись без дополнительных тестов.
Как мы встроили Postman в свой процесс
Мы применяем Postman для разработки сценариев мониторинга, тестирования и проработки интеграционных взаимодействий.
Сценарии экспортируются в JSON-файлы и сохраняются в Git-репозиторий TFS.
В пайплайне TFS прописывается проверка по расписанию. Стоит отметить, что для нас интеграция с TFS – это ещё одно преимущество Postman, поскольку с этого года все наши команды работают именно здесь. В TFS можно сразу увидеть результат выполнения запросов, что очень удобно, если Postman используется для отладки продукта. У нас речь про мониторинг, так что не будем углубляться.
JSON-файл вызывается через утилиту Newman – это инструмент для запуска коллекций из командной строки, который также разработала команда Postman. Он умеет выполнять запросы, принимать ответы на них, высчитывать метрики, которые указаны в сценарии.
Результаты выполнения сценариев сохраняются в БД Influx, откуда данные отправляются в дашборды Grafana. Здесь можно настроить критические пороги, чтобы автоматически сообщать, если какой-то показатель выходит за заданное значение.
Итого
Когда мы отрабатывали технологию мониторинга, мы планировали использовать Zabbix. При ближайшем рассмотрении выяснилось, что для наших целей он не подходит – написать сценарий нативными средствами невозможно, приходится готовить их на Python. Причём без такого инструмента, как Postman-овские коллекции, делать это приходится каждый раз заново.
Здесь же вся логика зашита в интерфейс. Так что инженеру достаточно подставлять нужные данные в отдельные участки кода. Это существенно снижает порог входа для всех, кому нужно работать с запросами, будь то разработчики, аналитики, тестировщики или кто-то ещё.
Результат – поддержка становится надёжнее, не зависит от того, как тот или иной инженер владеет кодом. И при этом легко переносить опыт от команды к команде и никаких компромиссов с точки зрения качества процессов.
