Привет!
Данная статья преследует цель осветить проблему непонимания бизнесом и смежными специалистами того, кто такой monitoring engineer. Есть ли вообще такой специалист? Зачем и где он нужен? Почему это не SRE, тестировщик-автоматизатор, разработчик или кто-то еще? Какие задачи он решает? Как им стать и не полысеть? Рассмотрим ключевые вопросы.
Что это?
Самый главный вопрос у компаний, не понимающих, зачем нужен мониторинг инженер: «Что он делает и зачем это нужно?»
Мониторинг инженер занимается разработкой сервисов непрерывного отслеживания состояния системы будь то web-ресурс, мобильное приложение, маршрутизатор, сервер, да хоть ИБП.
Кому надо?
Аналитикам и руководству для отслеживания состояния системы. Первой/второй линии поддержки для своевременного реагирования на различные изменения в метриках. Ответственным за систему командам для улучшения качества системы (перекликается с задачей тестировщика).
Основные инструменты
Приятный лично вам язык программирования для разработки высокоуровневого мониторинга веб-ресурсов и серверной части. Мой выбор – python, т. к. его разнообразие библиотек позволяет мне решать задачи не только высокоуровневого, но и низкоуровневого мониторинга;
Умение работать на Linux и скриптить на bash. Для низкоуровневого мониторинга, например, физических ресурсов;
Контейнеризация и управление контейнерами – Docker и Kubernetes, как вытекает из предыдущего пункта. Нужно уметь запаковать свой проект, доставить его в вашу CI, например в GitLab CI, а также управлять множеством своих контейнеризированных проектов;
Prometheus и Grafana. Естественно, нужно уметь работать с системами мониторинга и графическими представлениями метрик. И про сбор логов не забудем. Для Grafana лучше loki (разработка самой Grafana);
Желательно бы еще иметь представление о виртуализации. Хотя бы виртуальную машинку себе создать. Вдруг придется;
Еще можно отметить навыки сбора требований и умение вытрясти из людей нужную информацию. Но я надеюсь, что вам просто повезет с аналитиками 0w0.
Специалист этот весьма многозадачный. Давайте для наглядности сравним компетенции и зоны ответственности смежных специалистов. Сразу сделаем оговорку на то, что данные утверждения верны больше для крупных компаний с десятками и сотнями сервисов, где существует четкое разделение на отделы и группы, а также существуют не только продуктовые, но и сервисные команды. Мониторинг специалист, по моему мнению, будет чувствовать себя лучше всего именно в сервисной команде. Наименее верно для небольших компаний с парой-тройкой команд, где все и так все знают про продукт.
Аналитик 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 с памятью, написания пайплайнов и много чего еще… Это из-за того, что профессия узкоспециализированная и специфичная в каждой компании. Это еще не учитывая то, что представлена она в основном в крупных компаниях.
