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

Ранее я объяснял, как Pipedrive переходит от развертывания к действенным выводам (менее чем за минуту)». На этот раз я объясню, как Pipedrive переходит от действенных выводов к автоматизации в наблюдаемости.

В настоящее время (начало 2022 года) инженерные силы Pipedrive состоят из более чем 400 сотрудников, более 20 команд/племен и бесчисленных инициатив, выполняемых ежедневно.

Некоторое время назад, когда наш инженерный отдел был не таким уж большим, мы помогали нашим инженерам с обучением. Мы помогали им настраивать информационные панели в Grafana, повышать их навыки NRQL в NewRelic и помогать им осваивать PromQL. Затем эти инженеры могли распространять знания среди своих команд. «Обучите модель тренера», если хотите. Однако сегодня мы сталкиваемся с новыми проблемами, связанными с обучением новых сотрудников, большинство из которых — джуниоры, никогда не видевшие и не слышавшие о NRQL или PromQL. Учитывая текущий уровень сложности, процесс обучения наших новых членов команды ограничен инструментами, процессами и обучением в области разработки продукта.

Мы уже давно проводим онбординг-сессии, как минимум знакомим новичков с инструментами, которые используем в Pipedrive. Для текущей настройки мы используем NewRelic для мониторинга и отслеживания производительности приложений, Zabbix для инфраструктуры, Prometheus для мониторинга микросервисов, Graylog для управления журналами и Grafana для объединения всех этих источников в единое представление. Как вы, наверное, понимаете, этот список может быть ошеломляющим для любого новичка. И это только один вводной сеанс.
Мои коллеги написали несколько статей о нашем процессе адаптации, и я рекомендую вам прочитать их. В частности, как нам удается за месяц превратить джуниоров в готовых к работе Pipedrivers.

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

Итак, что мы сделали?

Pipedrive начал использовать Fastify в качестве де-факто среды NodeJS, что позволило нам оснастить подключаемые модули для Fastify для соответствия показателям любого сервиса, который его использует. Имея это в виду, мы создали набор основных метрик для каждой службы и всех зависимостей, которые они используют, таких как Kafka, RabbitMQ, MySQL и т. д. Поскольку все службы отслеживаются нами, командой наблюдения, мы знакомы с метрики, которые мы собираем, и можем преобразовать их в набор информационных панелей или панелей для инженеров, которым необходимо собирать информацию о своих услугах.

Это решение было бы частично функциональным. Тем не менее, это также привело бы к большому количеству метрик в нашей TSDB Prometheus и не использовалось бы на полную мощность. Еще одна идея, которая у нас была, заключалась в создании решения с нуля.

Представляем GraDaTor (или, выражаясь по-человечески, Grafana daсоздатель доскиda), простой инструмент, который позволяет любому создавать информационные панели из простого пользовательского интерфейса. Например, предположим, что у вас есть служба под названием WWW-API, созданная с помощью платформы Fastify. Все ваши HTTP-вызовы автоматически обрабатываются плагинами Fastify, и ваши данные собираются, как только служба находится в активной среде и принимает запросы. Теперь, как инженер, вы хотели бы знать, сколько запросов работоспособны, какие из них отвечают 4xx и т. д. Вам просто нужно зайти в Gradator и выбрать свой сервис в раскрывающемся меню, подтвердить, что ваш сервис использует HTTP-сервер. и нажмите кнопку, чтобы создать панель инструментов прямо в Grafana. Вы можете сделать все это, не написав ни единой строки кода для наблюдения или вручную создав панель мониторинга и написав запросы.

Как выглядит рабочий процесс?

Сначала мы выбираем услугу из нашего предопределенного списка, который автоматически отображается на основе услуг Pipedrive.

Далее мы можем выбрать шаблон для нашего сервиса. У нас есть предопределенный набор шаблонов, поэтому разработчикам не нужно беспокоиться о PromQL, метриках или стандартизированных способах мониторинга своего сервиса.

Добавьте пустую панель мониторинга и основные переменные или более подробную информацию о работоспособности службы, KPI и аннотациях по развертыванию.

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

Выберите дополнительные показатели на основе вашего сервиса, если он использует HTTP, Kafka, MySQL и т. д.

Теперь пользователь может настраивать свои информационные панели, редактируя панели и перемещая их.

Наконец, пришло время дать инструментальной панели осмысленное имя и добавить ее в Grafana, чтобы все могли ее видеть и использовать.

Что дальше?

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

Хотите работать в Pipedrive?

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

Посмотрите и посмотрите, подходит ли вам что-то

Позиции включают в себя:

  • Инженер по инфраструктуре
  • Инженер по качеству
  • Инженер-программист в DevOps Tooling
  • Младший разработчик
  • Ведущий инженер
  • И еще несколько