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

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 3 месяца
Сообщений: 27286

news_bot ^® написал(а)
26-Фев-2021 12:33

Цитировать

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

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

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

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

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

Сценарии экспортируются в JSON-файлы и сохраняются в Git-репозиторий TFS.
В пайплайне TFS прописывается проверка по расписанию. Стоит отметить, что для нас интеграция с TFS – это ещё одно преимущество Postman, поскольку с этого года все наши команды работают именно здесь. В TFS можно сразу увидеть результат выполнения запросов, что очень удобно, если Postman используется для отладки продукта. У нас речь про мониторинг, так что не будем углубляться.
JSON-файл вызывается через утилиту Newman – это инструмент для запуска коллекций из командной строки, который также разработала команда Postman. Он умеет выполнять запросы, принимать ответы на них, высчитывать метрики, которые указаны в сценарии.
Результаты выполнения сценариев сохраняются в БД Influx, откуда данные отправляются в дашборды Grafana. Здесь можно настроить критические пороги, чтобы автоматически сообщать, если какой-то показатель выходит за заданное значение.

ИтогоКогда мы отрабатывали технологию мониторинга, мы планировали использовать Zabbix. При ближайшем рассмотрении выяснилось, что для наших целей он не подходит – написать сценарий нативными средствами невозможно, приходится готовить их на Python. Причём без такого инструмента, как Postman-овские коллекции, делать это приходится каждый раз заново.Здесь же вся логика зашита в интерфейс. Так что инженеру достаточно подставлять нужные данные в отдельные участки кода. Это существенно снижает порог входа для всех, кому нужно работать с запросами, будь то разработчики, аналитики, тестировщики или кто-то ещё.Результат – поддержка становится надёжнее, не зависит от того, как тот или иной инженер владеет кодом. И при этом легко переносить опыт от команды к команде и никаких компромиссов с точки зрения качества процессов.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_upravlenie_produktom (Управление продуктом), #_monitoring (мониторинг), #_rabotosposobnost_po (работоспособность по), #_monitoring_itproduktov (мониторинг ИТ-продуктов), #_upravlenie_produktom (
Управление продуктом
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 14-Май 03:18
Часовой пояс: UTC + 5