Когда-то мне сказали, что математики – ленивые люди, поэтому они придумывают себе инструменты для упрощения жизни. С сотрудниками службы поддержки все так же: мы максимально пытаемся упростить себе жизнь и автоматизировать все, что только можно автоматизировать. В предыдущей части я рассказывала про траблшутинг. В этой я поведаю о том, какие инструменты мы в GlowByte разрабатывали для автоматизации и упрощения своего труда.
Мониторинг
Многим известны службы 2–3-й линии поддержки, где нужно сидеть смотреть в монитор и в любое время дня и ночи реагировать на критические показатели, часто еще и исправлять их, случись баг днем или ночью. Прекрасно, когда для таких людей есть настроенные дашборды и выставленные показатели. Однако не все системы поддаются настройке дашбордов: например, если система имеет закрытый исходный код и это готовая коробка, внутрь которой попасть сложно для забора информации, то такой трюк не сработает. У нас на практике в GlowByte была система, которая именно таким образом не поддавалась настройке под готовые инструменты мониторинга. Каждый ее компонент писал логи в файлы, часть информации о ее работе сохранялась в БД, у системы были sh‑скрипты администрирования (проверка статусов, перезагрузка, изменение параметров конфигурации и т. д.).
Поработав немного, ко мне пришла задача построения системы мониторинга, где я планировала почти с нуля и архитектуру, и инфраструктуру, писала код. История началась с того, что команда энтузиастов до моего прихода на проект собрала sh‑скрипты, которые они чаще всего использовали при анализе различных инцидентов в системе SAS MA (решение для enterprise‑заказчиков, призванное управлять маркетинговыми коммуникациями). Эти же энтузиасты сделали вывод результатов этих скриптов в Графану. Какое‑то время все это работало, выглядело простым. Собрался большой беклог фичей, которые можно было бы внедрить, и, кроме того, у коллег было желание масштабировать это и превратить в отдельный сервис. Мне дали возможность переписать функционал, сделать из решения полноценное приложение, которое бы не нагружало целевую систему.
Мониторинг планировался внедрятся на серверах заказчика с закрытой сетью. Чтобы не было проблем переносов с одного контура на другой, я стала сразу планировать использование Docker для поднятия приложений: в единый Docker Compose подключались отдельные микросервисы сборщиков метрик, анализаторы логов, Grafana, Graphite, PostgreSQL (как хранилища метрик) и т. д. Далее я выбрала инструменты для разработки сборщиков метрик и анализаторов логов, переписала все sh‑скрипты на Python, создала единое конфигурируемое расписание запусков и подключила это к хранилищу и визуализации. Также систему, которую нужно было мониторить, можно было администрировать. И я сделала скрипты ее перезагрузки, чистки логов, проверку статусов компонент, на Angular написала интерфейс кнопок, которые запускают эти скрипты.
Это был большой проект, который мы реализовывали маленькой командой, и у меня был огромный простор для творчества в определении подходов разработки, выборе инструментов, придумывании фичей. У меня получилось глубже погрузиться в «Докер», особенности работы сетевых протоколов, метрик «здоровья» системы. Также удалось познакомиться с визуализацией данных, настройкой почтовых коммуникаций и отсеиванием важных событий от неважных.
Глобально этот проект дал мне обширные понятия в области устройства ELK‑систем, разного способа хранения метрик, решения проблем наката приложений в Docker. В будущем все эти знания я использовала при решении инцидентов на проектах заказчика GlowByte. Благодаря им мне было легко разобраться в конфигурации Zabbix (как дашбордов, так и сборщиков), отобрать из тысячи метрик нужные и собрать дашборд в Zabbix или Grafana, настроить фильтры логов в Graylog или Kibana.
Хотя потом я поняла, что в ряде случаев был придуман велосипед и в некоторых моментах можно было подключать уже готовые репозитории с открытым исходным кодом для сбора метрик. Но я получила полезный опыт как в проработке архитектуры, так и в разработке, анализе логов и показателей, описывающих состояние системы.
Алерт-бот
Еще одной разработкой автоматизации, которой я занималась, был Telegram‑бот, который уведомляет сотрудников службы поддержки GlowByte об обновлениях в Jira. На момент начала разработки мы имели около 40 проектов, на которых осуществляли поддержку, и около 25 сотрудников.
Ответственность за проекты была разделена на подкоманды. От бота хотелось следующего:
Каждый получает только те уведомления, на которые он подписан. Если проект и обновления по нему в Jira не важны сотруднику А, потому что проект не входит в его зону ответственности, то и уведомления по нему ему не нужны.
Бот должен иметь систему конфигурации. Кто‑то хочет получать обновления в Telegram только по критическим событиям, кто‑то — только по всем трекам, но только о событиях слива SLA. Кто‑то хочет получать информацию только про новые треки и т. д. Мы разбили уведомления по типам и сделали гибкую настройку подписок через кнопки в Телеграме.
Если нужна какая‑то метаинформация о команде или проектах (документация, часы работы на проектах, данные про команду и т. д.), то достать это также можно через бота.
Бот должен быть приватным, и только сотрудники команды могут им пользоваться.
Должен быть реализован функционал построения регулярных отчетов. Если руководителям на постоянной основе хочется из Jira вытаскивать информацию, то они могут это сделать через бота.
В боте было еще несколько функций, которые мы внедрили. В итоге мы с моей командой сделали монорепозиторий внутреннего REST API, в который включили наиболее типовые функции (работу с Google‑таблицами, манипуляции с Jira, получение и обработку наиболее часто используемой информации и т. д.). Также мы сделали конструктор чат‑ботов, в котором кнопки и экшны на них можно конфигурировать через JSON‑конфиг. Для реализации использовали Python, JAVA.
Бот для 1-й линии и дежурств
Когда я рассказывала про мониторинг, я упомянула людей, которые обычно следят за дашбордами и мониторят показатели. На части проектов у нас есть сервис дежурного консультанта, в задачи которого входит реагирование на важные события в любое время. Дежурными консультантами сотрудники становятся по желанию, но и им хочется автоматизировать свой труд.
В какой‑то момент у нас в GlowByte стали появляться кейсы, когда дежурному нужно следить за почтой и уведомлениями в них по критическим событиям. Для решения таких сценариев мы с моей командой разработали инструмент, который читает все почтовые письма, обрабатывает их по конфигурационным параметрам (эти параметры пользователи могут выставлять и настраивать сами, поскольку они имеют гибкие настройки, и можно фильтровать письма по любым условиям вхождения), а затем отправляет в Телеграм дежурному. Таким образом, дежурному не нужно следить за почтой, он может всего лишь просматривать Телеграм.
Но это еще не все. Если в Телеграм реакции от дежурного не поступило, то бот напомнит ему еще раз. Если и повторно реакции не поступило, то бот позвонит. Если никакая реакция не следует, то запрос уходит на вышестоящего человека. Так мы реализовали систему эскалаций, чтобы наши заказчики не волновались, если кто‑то из сотрудников пропустит алерт.
Разрабатывая это решение, мы уже использовали наш монорепозиторий от alert‑бота.
Несмотря на то что это не была масштабная разработка, для которой нужна команда 10+ человек, она дала мне опыт технического характера:
Python (Flask, REST API, Google Suite, RabbitMQ, SMTP),
JAVA,
навыки построения архитектуры, ревью кода, проектирование многоразово используемых API.
Также я приобрела опыт нетехнического характера:
управление командой,
распределение задач между людьми,
обучение других людей писать код,
Agile-практики управления сроками исполнения.
Для меня этот опыт также внес ответы на некоторые противоречивые вопросы, например, как успевать быть и менеджером, и техническим лидом, и разработчиком; как при этом не обделить вниманием команду и сделать проект качественно и в короткие сроки. Порой казалось, что сделать что‑то одной легче, чем с командой. Решением этой проблемы было осознанное делегирование и распределение по ролям. Об этом расскажу в одной из следующих статей про менеджмент.
В качестве ложки дегтя — не обошлось без проблем. Разрабатывая по наитию, без четких ТЗ, мы столкнулись с тем, что несколько раз переписывали свой код, доводя его до состояния масштабируемости. Кроме того, изначально мы никак не рассматривали эту активность как основной стрим и поэтому не планировали спринты, подзадачи и подобное. И только осознав, что эти проекты больше, чем просто занятие на досуге в свободное от задач время, мы пришли к управлению задачами через Scrum.