Привет, Хабр! Меня зовут Раиса. Я работаю в компании DINS старшим инженером по нагрузочному тестированию. Сегодня я хочу поговорить об энваройнментах. Ни для кого не секрет, что энвайронмент (environment) — это основная рабочая площадка тестировщика. Если у программиста — это любимая IDE, то у тестировщика — милый и родной энвайронмент.

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

Я уверена, что каждый из вас подумал: «Забрать у всех доступы!». И в целом это самое простое и очевидное решение. Нет бардаку! Или «You shall not pass» еще на доступах к энву. 

Однако, я хочу показать, как мы никому ничего не запрещали и превратили «You shall not pass» в «You shall not pass without notification». А именно расскажу, как мы настроили мониторинг для наших окружений и живём мирно и счастливо. 

Проблема

В нашей компании очень большие стенды. Эти стенды включают в себя компоненты не только команды, в которой мы работаем, но и компоненты других команд, которые постоянно релизятся, то есть их нужно обновлять. Кроме того, эти компоненты могут иметь зависимости, а значит обновление одного компонента может повлечь за собой обновление всего стенда или проблемы несовместимости. Процесс этот, как вы понимаете, занимает время. Но это ещё не вся проблема. С энвами работают много инженеров — разработчики могут прийти что-то потраблушутить, в процессе изменив конфиги. Тестировщиков в команде несколько. Работать они могут распределено и над разными задачами, то есть необходимы разные конфигурации. И частые проблемы, с которыми мы сталкиваемся, — это мисконфигурации (ошибки конфигурации) или одновременная работа, когда один обновляет энв, а другой решил потестировать и т.п. 

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

Что можно мониторить?

Давайте прикинем, что именно можно мониторить. 

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

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

3. Запуски автотестов
   Если запуски происходят через специальные инструменты (например, gitlab CI, Jenkins, TeamCity), то можно и их отслеживать. Запустились тесты — все знают, что бежит прогон и лучше энв не трогать. 

4. Репорты от автотестов
   Лень — двигатель прогресса. Зачем ходить смотреть, когда прогон закончится, когда можно мониторить это автоматом, а ещё в придачу слать короткий репорт — успешно, не успешно. 

5. Логи (ошибки в логах)
   Представьте, вы запустили прогон или гоняете тесты, а серверов у вас несколько сотен (кстати, актуальная проблема для перфоманс-тестирования). Долго и неудобно ходить на каждый сервер и смотреть, нет ли в логах ошибок. Это могут быть ошибки нескольких видов: Uncaught Exceptions, Null Pointer Exceptions и другие. Можно написать скрипт, который будет ходить за вас и проверять. А можно следить за базовыми критическими ошибками с помощью специальных инструментов и получать нотификации сразу, когда они возникают. Речи о таких инструментах в данной статье не будет (попрошу коллег-экспертов про это написать). 

Как мониторить? 

Итак, мы определились с тем, что  хотели бы мониторить. Теперь можно подумать, как именно это делать? Ну, и в век мессенджеров грех не воспользоваться API мессенджеров и интеграциями, чтобы отслеживать состояние энва. 

Чем это удобно? 

• Во-первых, нет необходимости специально куда-то ходить. Ведь чатами мы пользуемся постоянно. Таким образом, если с энвом что-то происходит, то нотификация придет в настроенный чат, и вы сразу об этом узнаете. 

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

• В-третьих, все заинтересованные люди могут подписаться на этот чат и следить на энвом вместе с вами.

Именно так мы и сделали (тем более что пользуемся корпоративным мессенджером) —  мы стали слать хуки в наш мессенджер от всех сервисов: внутренней деплоймент-системы, «Гитлаба», «Дженкинса» и др. Теперь, когда у нас кто-то изменяет значение переменной в деплоймент-системе, мы об этом сразу узнаем. Когда кто-то нажимает даже кнопку «Построить деплоймент-план»  — мы тоже об этом знаем. Запустили прогон автотестов — нотификация, закончился прогон — нотификация. И всё это в одном чате. 

Реализация

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

Бывают разные механизмы отправки таких сообщений — вебхуки, боты, API. Хоть что-то из этого есть в любом современном мессенджере.

Механизм вебхуков

Вебхук (webhook) — это автоматическая отправка сообщения о событии.

То есть на стороне мессенджера в нужном чате мы создаем средствами этого мессенджера вебхук (по сути специальный URL), и теперь у нас есть возможность отсылать в этот чат из любых скриптов, систем, просто curl-ом или постманом сообщения. Сообщения эти должны содержать определённый пейлоад, который поддерживает вебхук. 

Пример:  

POST "https://hooks.some_messenger.com/webhook/1ww4345345" 

{
   "icon":"https://icon-library.com/images/gitlab-icon/gitlab-icon-19.jpg",
   "activity":"Gitlab pipeline start/stop environment",
   "body":"Run graceful shutdown; Current EC pool: $INSTANCE_ID"
}

Механизм чат-ботов 

Чат-бот — это программа, которая ведёт себя как пользователь, может писать в чат сообщения, выполнять логику. В случае с чат-ботом есть несколько способов реализации. Например, когда вы по сути реализуете вебхук в чат-боте и дальше работаете с ним как с вебхуком. 

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

API мессенджера 

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

Примеры нотификаций

Давайте посмотрим примеры всех этих уведомлений.

Событие: деплоймент на энве

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

• факт события, 

• идентификацию того, кто совершил действие, 

• статус деплоя, 

• ссылку на более детальный статус. 

Можно добавить креатива: кастомные сообщения, картинки, данные о том, как меняются версии компонент и т.п.

Событие: изменение конфигурации энва

Здесь мы также видим кто, какой параметр и на что изменил. Бывает даже полезно смотреть на историю. Сколько было случаев, когда кто-то поменял один параметр и тесты упали?! Когда у нас есть чат, мы видим, вот изменился параметр и следом был запуск тестов, которые упали. Возможно, параметр и не причина, но уже есть с чего начать исследование. 

Событие: запуски автотестов

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

Пример кода для gitlab-ci конфига, чтобы такие нотификации поддержать: 

.run_custom_test:
 stage: run
 script:
   - |
     curl -H "Content-Type:application/json" \
     -X POST "https://hooks.some_messenger.com/webhook/1ccc3456-56456-7687-ba435" \
     --data "{\"icon\":\"https://gitlab.com/uploads/-/system/project/avatar/1045538/runner_logo.png\", \
     \"activity\":\"Gitlab pipeline performance run\",\"body\":\"custom test ${TEST} STARTED\"}"
      cd performance && ./custom_test.bash -t \"${TEST}\" -p \"${PARAMS}\" -l \"${LOGGING}\""
   - mkdir $CI_PROJECT_DIR/report
   - |
     curl -H "Content-Type:application/json" \
     -X POST "https://hooks.some_messenger.com/webhook/1ccc7f26-ba94-d38" \
     --data "{\"icon\":\"https://pbs.twimg.com/profile_images/676931722437619713/ut7aoBH3_400x400.png\", \
     \"activity\":\"Gitlab pipeline performance run\",\"body\":\"custom test ${TEST} FINISHED\"}"
 allow_failure: false
 artifacts:
   paths:
     - report

Событие: репорты или отчёты о прогонах

Можно выводить репорты от любых прогонов с любыми кастомными полями.

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

Событие: ошибки в логах

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

Вроде есть много информации о состоянии энва. Но что, если часть энва (как у нас) задеплоена в Амазоне (AWS Amazon) и включается, выключается, частично конфигурится, изменяется с помощью Terraform-скриптов и Ansible. 

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

Пример кода такой же, как и для запуска тестов через «Гитлаб»: 

graceful_shutdown:
  stage: graceful_shutdown
  variables:    ANSIBLE_CONFIG: ansible.cfg
  script:
    - |
      curl -H "Content-Type:application/json" \
      -X POST "https://hooks.some_messenger.com/webhook/1ww-4309-ba94" \
      --data "{\"icon\":\"https://icon-library.com/images/gitlab-icon/gitlab-icon-19.jpg\", \
      \"activity\":\"Gitlab pipeline start/stop environment\",\"body\":\"Run graceful shutdown; Current EC pool: $INSTANCE_ID\"}"
    - ansible-playbook services.yml -v --extra-vars "service_state=$STATE" --tags "stop"
    - |
      curl -H "Content-Type:application/json" \
      -X POST "https://hooks.some_messenger.com/webhook/1ww-4309-ba94" \
      --data "{\"icon\":\"https://icon-library.com/images/gitlab-icon/gitlab-icon-19.jpg\", \
      \"activity\":\"Gitlab pipeline start/stop environment\",\"body\":\"All services shutdown successfully; Current EC pool: $INSTANCE_ID\"}"
  tags:
    - docker
    - ansible
    - perf
  only:
    refs:
      - web
      - schedules
    variables:
      - $STATE == "off"

Кроме таких уведомлений в чат (скорее о действиях на эвне, чем о состоянии) у нас ещё есть дашборд о состоянии самих сервисов. В нем отображаются следующие вещи: 

• определяется состояние: включен или выключен.

• Запрашиваются сервис чеки. 

• Определяется состояние зависимостей каждого компонента. 

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

Выводы

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

Всё ли теперь мы знаем про энв? На самом деле нет. И вот почему: 

• мы не отслеживаем, если кто-то выключит или изменит машины напрямую (не через Terraform и Python скрипты), а в Amazon консоли. В этом случае мы останемся в неведении. То же самое распространяется на активности на самих машинах.

• Если кто-то  выключит что-то руками, включит, изменит — мы об этом не узнаем. 

• Если кто-то запустит вручную тесты — мы тоже об этом не узнаем. 

Можно ли это тоже мониторить? Можно. Но стоит ли игра свеч? Я считаю, что пока нет, и поэтому эти действия остаются на совести каждого, кто использует наш энвайронмент. 

Можно поспорить, что это не совсем мониторинг, а скорее алертинг. Но я исходила из логики, что в переводе «monitoring» — это наблюдение, отслеживание, контроль. И мы пристально следим за действиями на нашем энве, то есть мониторим его. 

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

You shall not pass without notification! 

Спасибо, что прочитали! Пишите в комментариях, мониторите ли свои энвы? Может быть у вас есть другие способы решения этой задачи? 

P.S.: Напоследок хочу сказать спасибо всем, кто помогал вычитывать эту статью и предлагал идеи по улучшению. А также команде Glip за огромное количество чатов с нотификациями =)