Как стать профессиональным IT- коллекционером? Часть 4. Упрощаем работу в поддержке и познаем код
Когда-то мне сказали, что математики — ленивые люди, поэтому они придумывают себе инструменты для упрощения жизни. С сотрудниками службы поддержки все так же: мы максимально пытаемся упростить себе жизнь и автоматизировать все, что только можно автоматизировать. В предыдущей части я рассказывала про траблшутинг. В этой я поведаю о том, какие инструменты мы в 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.
