Привет!

Проходя множество собеседований, я не раз слышал вопросы по типу: «Что такое мониторинг?», «Как это связано с тестированием?», «Зачем это нужно?». Для меня, волей случая ставшего специалистом по мониторингу чуть больше года назад, это тривиальные вопросы, однако многие компании либо не знают, что это такое, либо не видят в этом пользы. На одном из последних интервью я услышал интересное мнение от QA Lead о том, что assert должен быть в каждом тесте. Смелое заявление, подумал я. Поэтому, собственно, вы и читаете эту статью.
Разберёмся, что такое мониторинг и с чем его едят. А главное, зачем он нужен вообще.

Немного обо мне

Думаю, начать с небольшого введения обо мне будет наиболее верным для погружения в тему. Сейчас я занимаю должность middle SDET в ООО «МИТ» (если проще, то DIXY Group). Попал я туда как AQA, причём единственным. Я находился в группе по мониторингу корпоративных сервисов, соответственно, кроме меня там были только специалист по мониторингу (мой Lead), DevOps и системный админ. Похоже на стандартное начало анекдота…

Моим заданием на испытательный срок стало написание сервиса по мониторингу интернет-соединения на торговых точках компании. И тут я подумал: какой, блин, мониторинг? С другой стороны, работа на дороге не валяется, тем более настолько приятная. Дело было вечером, делать было нечего…

По итогу этого задания ко мне пришло осознание того, как тесты могут трансформироваться в нечто большее, чем проверки, прогоняемые раз в релиз. Они могут быть целой экосистемой, даже можно сказать: «Глазом Бога» (кто понял отсылку к Форсажу, спасибо).

Начнем погружение

Начнём мы, конечно же, с поверхности и определим для себя, что такое мониторинг и как он связан с тестированием. В самом распространённом смысле под тестированием понимают сверку ожидаемого и фактического результатов на конечном наборе тестов. Если мы берём стандартные парадигмы тестирования, то такие проверки могут выполняться при добавлении новой фичи, раз в спринт, при релизе и много когда ещё. Однако все эти тестовые прогоны не преследуют цель отслеживать состояние продукта (программного или бизнесового) постоянно.

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

Думаю, будет проще понять наглядно.

def test_example_site(driver):
    driver.get("https://example.com")
    assert "Example Domain" in driver.page_source

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

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

from base.base_class import BaseClass


class Test(BaseClass):
    def test_example_site(self, driver):
        driver.get("https://example.com")
        driver.is_clickable(find_by="text", selector="More information...",
                            error_message="More information button is not clickable").click()

Сразу бросается в глаза отсутствие assert. Но в таком случае, как такой скрипт вообще можно считать информативным, если он не выводит ошибки? Именно поэтому мы добавим дополнительное действие. Например, найдём какую-то кнопку и нажмём на неё. Теперь, если ресурс не прогрузился или сломался, мы получим TimeoutException и сообщение о том, что именно скрипт не смог сделать.

Возникает вопрос: почему бы тогда точно так же не поставить assert и не ждать лишнее время для выпадения TimeoutException ? Справедливо! Однако возьмём во внимание, что данный скрипт не нацелен на то, чтобы просто проверить доступность ресурса и отследить ошибку в отчёте. Если мы предполагаем, что скрипт гоняется бесконечно, пока смерть сервера не разлучит вас, то отчётом в данном случае будет не Allure, например (хотя я и его прикрутил к скриптам для Project Manager’а), а сервисы для графического отображения типа Grafana или сервисы мониторинга типа Prometheus. Да и сам скрипт, помимо успеха или провала теста, должен собирать ещё кучу полезных данных. В данном примере это может быть время прохождения скрипта, что может дать нам представление о том, в каком состоянии находится сервис. Особенно если учесть, что всегда можно настроить параметры интернет-соединения или любые другие моменты, имитирующие пользователя. И тут мы плавно перейдём к другому вопросу.

Человек, но паук. Он куда-то делся вдруг…

Теперь стоит сказать и о том, что мониторинг может быть как на микро-, так и на макроуровне. Под микроуровнем обычно понимают низкоуровневый мониторинг, например, физического оборудования, элемента большого сервиса или что-то подобное. На макроуровне мониторинг предстает как UX-тестирование или тестирование пользовательских путей.

Немного про микроуровень. Вернёмся к проекту по мониторингу интернет-соединения на торговых точках компании. По сути, скрипт достаёт из базы данных ID магазинов, конвертирует их в IP-адреса маршрутизаторов в магазинах и пингует их несколько раз. Помимо того, что в таблице в Grafana этот скрипт отображает «Up» или «Down» в зависимости от доступности каналов, он также собирает время отклика, хранит историю падений и содержит в себе данные об операторе SIM-карты, номере телефона и многое другое. Не очень-то похоже на тест.

Теперь про макроуровень. Высокоуровневый мониторинг уже больше похож на UI/UX-тестирование. В его основе лежит постоянное отслеживание пользовательского пути через UI. Например, для сайта доставки продуктов — от захода пользователя на сайт и выбора товаров до оплаты. Помимо прочего, такой скрипт также собирает множество данных.

Ведьмаку заплати чеканной монетой… 

В чём, собственно, разница? Основными критериями, отличающими мониторинг от тестирования, являются:

• Цель в постоянном наблюдении. Мониторинг — большой брат для ваших сервисов, который безустанно следит за ними;

• Сбор данных. Помимо отчётов о тестировании, мониторинг собирает ещё кучу данных;

• Быстрое реагирование. Думаю, тут и пояснять не надо. Если у вас есть тестовый сервер или синтетика, то критической баге будет сложно пролезть в прод;

• Имитация пользователя. Хоть UX-тесты и тесты пользовательских путей позволяют имитировать действия пользователя, но пишут их далеко не в первую очередь (информация со 100+ собеседований. Всем API подавай, а на пользователей мы кладём...).

Что в итоге польза? Ну, тут я расскажу лучше пару «До и После» примеров.

До разработки мною сервиса мониторинга интернет-соединения на валидацию проблем и выезд оперативной группы на точку уходило два-три рабочих дня. Более того, часто это были ложные вызовы, так как при неработающем основном канале включался резервный. Мониторинг позволил проходить весь процесс за два часа. Процент ложных вызовов за год его работы составляет не более 0,2%. А уж сколько денег это экономит компании, говорить не приходится, если учитывать, что к этому мониторингу подключена вся первая линия поддержки. Во всех магазинах Дикси. По всей России. Даже не думал, что час простоя торговой точки может стоить так много…

А как вам такая новость в ленте: «Основной сайт и сайт доставки магазина Дикси не работают!»? Именно такую новость прочло руководство компании, заваривая утренний кофе. Да, узнавать о падении основных сервисов компании из новостей — это, видимо, не весело. Мне кажется, кофе точно не полезет после такого. Стоит ли говорить, что после этого случая мониторинг был внедрён на все сервисы?

Забавно, правда?

Но остался ещё один вопрос. Специалист по мониторингу и специалист по тестированию — это один и тот же профессионал? Мне кажется, специалист по мониторингу ближе к SDET, чем к AQA. Всё-таки я считаю, что автоматизатор тестирования должен знать и уметь меньше. AQA как бы и должен иметь представление о контейнеризации, но как бы и просто собрать контейнер в Docker достаточно. Специалист по мониторингу должен бы и под каждый свой мониторинг собрать контейнер, и доставить его, и обслужить если что, и k8s знать бы по-хорошему, ноды и воркеры – лучшие друзья. И опять-таки, ты же не знаешь, что может быть важно для бизнеса. Возможно, придётся выйти за рамки PyTest, Selenium и Appium. Уметь разобраться в различных библиотеках, знать асинхронные подходы, парадигмы проектирования, сильные и слабые стороны рабочего языка программирования — всё это важные навыки специалиста по мониторингу. Так что да, SDET более подходящее описание для его деятельности.

Ссылочка на телегу