Привет!

Данная статья преследует цель осветить проблему непонимания бизнесом и смежными специалистами того, кто такой monitoring engineer. Есть ли вообще такой специалист? Зачем и где он нужен? Почему это не SRE, тестировщик-автоматизатор, разработчик или кто-то еще? Какие задачи он решает? Как им стать и не полысеть? Рассмотрим ключевые вопросы.

Что это?

Самый главный вопрос у компаний, не понимающих, зачем нужен мониторинг инженер: «Что он делает и зачем это нужно?»

Мониторинг инженер занимается разработкой сервисов непрерывного отслеживания состояния системы будь то web-ресурс, мобильное приложение, маршрутизатор, сервер, да хоть ИБП.

Кому надо?

Аналитикам и руководству для отслеживания состояния системы. Первой/второй линии поддержки для своевременного реагирования на различные изменения в метриках. Ответственным за систему командам для улучшения качества системы (перекликается с задачей тестировщика).

Основные инструменты

• Приятный лично вам язык программирования для разработки высокоуровневого мониторинга веб-ресурсов и серверной части. Мой выбор – python, т. к. его разнообразие библиотек позволяет мне решать задачи не только высокоуровневого, но и низкоуровневого мониторинга;

• Умение работать на Linux и скриптить на bash. Для низкоуровневого мониторинга, например, физических ресурсов;

• Контейнеризация и управление контейнерами – Docker и Kubernetes, как вытекает из предыдущего пункта. Нужно уметь запаковать свой проект, доставить его в вашу CI, например в GitLab CI, а также управлять множеством своих контейнеризированных проектов;

• Prometheus и Grafana. Естественно, нужно уметь работать с системами мониторинга и графическими представлениями метрик. И про сбор логов не забудем. Для Grafana лучше loki (разработка самой Grafana);

• Желательно бы еще иметь представление о виртуализации. Хотя бы виртуальную машинку себе создать. Вдруг придется;

• Еще можно отметить навыки сбора требований и умение вытрясти из людей нужную информацию. Но я надеюсь, что вам просто повезет с аналитиками 0_w0.

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

Аналитик vs Мониторинг инженер

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

В сухом остатке

Если в компании отлично выстроены процессы, то сбором требований должен заниматься аналитик. Он же должен и определить, что является нормой, а что интерпретировать как отклонение от нормальных показателей.

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

Личный пример

Я работаю именно в сервисной команде, цель которой в том, чтобы разрабатывать и поддерживать мониторинг-сервисы и автотестирование в продуктовых командах компании (на данный момент около 15 систем). По мимо DIXY Group по опыту собеседований знаю, что расширение подобной команды было в OZON пару месяцев назад. Судя по всему, сервисные команды авто-тестировщиков и мониторинг инженеров – тренд в крупных компаниях. Было бы здорово почитать о ваших наблюдениях, если вы заняты в этой сфере.

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

SRE vs Мониторинг инженер

Как ясно из названия, SRE (Site Reliability Engineer) – специалист, занимающийся техническим обеспечением надежности сайтов (лучше сказать веб-ресурсов). Инструменты и подходы могут быть очень похожи, однако важнейшее отличие кроется в самом названии. SRE отвечает за веб-ресурсы. Возможно, частично и за серверную часть (не берусь утверждать, лучше дайте знать в комментариях). В то время как мониторинг специалист может отвечать за надежность любой системы. Веб-ресурс? Да. Кластер серверов? Почему бы и нет. Сеть маршрутизаторов? Пожалуйста. ИБП? Хоть десять. Задачи бизнеса могут быть самые разные. Но опять-таки, если для вашей компании жизненно важен только веб-ресурс, то нет смысла нанимать мониторинг-специалиста, а лучше раскошелиться на SRE.

Из личного

Если взять в пример мою компанию, то только две тысячи физических торговых точек заставили нас мониторить сотни тысяч физических устройств и серверов.

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

Типичные задачи

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

• Нужно мониторить доступность сайта доставки, проходить путь пользователя, замерять время на прохождения этого пути и его этапов и при этом еще и UX тестить? Отлично, тогда вам нужен мониторинг.

• Нужно проверить, есть ли интернет-соединение на ваших торговых точках по всей России, замерять скорость ответа маршрутизаторов и процент потери пакетов каждого? Отлично! Вам нужен мониторинг.

• Нужно максимально оперативно снабжать первую линию поддержки информацией для эффективной работы? Мониторинг вам поможет.

Мониторинг решает много задач, без сомнений. Но нужен ли отдельный специалист для этого?

Мое мнение: однозначно да! С задачами web-ресурсов может помочь SRE. Но вот кто должен заниматься задачами низкоуровневого мониторинга?

Разработчики? Точно нет. Разработчики сосредоточены на создании и улучшении программного обеспечения. Их главная задача — писать код, внедрять новые функции и исправлять баги. Вовлечение разработчиков в задачи мониторинга отвлекает их от основной работы и требует от них специализированных знаний в области сетевой инфраструктуры и системного администрирования.

Тестировщики? Тестировщики занимаются обеспечением качества программного обеспечения через тестирование и сопоставление ожидаемых и фактических результатов. Хотя они и имеют навыки работы с автоматизацией и выявлением дефектов, их основной фокус направлен на проверку работоспособности и функциональности до выпуска в продакшн. Мониторинг же требует постоянного наблюдения за работой систем в реальном времени и быстрого реагирования на возникающие проблемы.

Аналитики? Аналитики специализируются на сборе и интерпретации бизнес-данных для поддержки принятия решений. Их работа направлена на анализ бизнес-процессов, рыночных трендов и пользовательского поведения. Задачи мониторинга, связанные с техническим состоянием инфраструктуры, требуют глубинного понимания сетевых протоколов, серверных систем и методологий разработки.

От автора

Расскажу про мой стандартный день.

Каждый день в нашем заведении начинается одинаково – с просмотра Grafana. Смотрим все +100500 своих дашбордов, проверяем что все работает как надо, метрики точные, графики красивые, данные пишутся.

Все да не все. Один вышел за допустимый процент отказа и горит красным. Замечаем, что при прохождении пользовательского пути скрипт не смог оформить заказ. Топаем на корпоративную почту и видим, что разработчики вкатили апдейт в пятницу вечером, в котором поменяли HTML-код фрейма оформления заказа. Топаем менять селекторы в скрипте и ставить тех-работы в Grafana на выходные, пока скрипт откисал, не то по шапке влетит. После можно со спокойной душой и кофе испить, и продолжить писать мониторинг на мобильное приложение.

В обед прилетают доделки от команды первой линии поддержки по поводу мониторинга маршрутизаторов и bash скрипты эпохи динозавров. Добавляем исключения в IP, переписываем на python и возвращаем им таску. Топаем писать мониторинг мобилки дальше.

Как только соберешься уходить, обязательно позвонит отдел корпоративных сервисов и скажет, что их новые автотесты не работают. Так как ребятам сложно прочитать документацию к проекту, идем объяснять на пальцах, как в GitLab CI нажать на кнопку запуска тестов. После можно закругляться. Но тут звонит DevOps’ер и просит попробовать выпилить одну из библиотек, так как образ не хочет билдиться с ней. Теперь сидим вдвоем и пытаемся собрать образ. Докер образ собран, на часах восемь вечера. Можно отдохнуть.

Как прийти в мониторинг?

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

Второй путь для совсем отчаянных: зайти с нуля. Но это нужно быть прямо-таки очень хорошо обучаемым. Нужно будет освоить тонны материала.

На собеседовании могут гонять по совсем разным темам. Иногда даже может сложиться впечатление, что они ищут кого-то другого. Например, на одном из собеседований мы ушли в дебри баз данных, я даже подумал, что им нужен администратор баз, а не тестер. Аналогично могут утащить в тему работы python с памятью, написания пайплайнов и много чего еще… Это из-за того, что профессия узкоспециализированная и специфичная в каждой компании. Это еще не учитывая то, что представлена она в основном в крупных компаниях.

Ссылочка на группу в тележке о^о