Как стать профессиональным IT- коллекционером? Часть 4. Упрощаем работу в поддержке и познаем код

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

Мониторинг

Многим известны службы 2-3-й линии поддержки, где нужно сидеть смотреть в монитор и в любое время дня и ночи реагировать на критические показатели, часто еще и исправлять их, случись баг днем или ночью. Прекрасно, когда для таких людей есть настроенные дашборды и выставленные показатели. Однако не все системы поддаются настройке дашбордов: например, если система имеет закрытый исходный код и это готовая коробка, внутрь которой попасть сложно для забора информации, то такой трюк не сработает. У нас на практике в GlowByte была система, которая именно таким образом не поддавалась настройке под готовые инструменты мониторинга. Каждый ее компонент писал логи в файлы, часть информации о ее работе сохранялась в БД, у системы были sh-скрипты администрирования (проверка статусов, перезагрузка, изменение параметров конфигурации и т. д.).

Поработав немного, ко мне пришла задача построения системы мониторинга, где я планировала почти с нуля и архитектуру, и инфраструктуру, писала код. История началась с того, что команда энтузиастов до моего прихода на проект собрала sh-скрипты, которые они чаще всего использовали при анализе различных инцидентов в системе SAS MA (решение для enterprise-заказчиков, призванное управлять маркетинговыми коммуникациями). Эти же энтузиасты сделали вывод результатов этих скриптов в Графану. Какое-то время все это работало, выглядело простым. Собрался большой беклог фичей, которые можно было бы внедрить, и, кроме того, у коллег было желание масштабировать это и превратить в отдельный сервис. Мне дали возможность переписать функционал, сделать из решения полноценное приложение, которое бы не нагружало целевую систему.

Мониторинг планировался внедрятся на серверах заказчика с закрытой сетью. Чтобы не было проблем переносов с одного контура на другой, я стала сразу планировать использование Docker для поднятия приложений: в единый Docker Compose подключались отдельные микросервисы сборщиков метрик, анализаторы логов, Grafana, Graphite, PostgreSQL (как хранилища метрик) и т. д. Далее я выбрала инструменты для разработки сборщиков метрик и анализаторов логов, переписала все sh-скрипты на Python, создала единое конфигурируемое расписание запусков и подключила это к хранилищу и визуализации. Также систему, которую нужно было мониторить, можно было администрировать. И я сделала скрипты ее перезагрузки, чистки ее логов, проверку статусов компонент, на Angular написала интерфейс кнопок, которые запускают эти скрипты.

Это был большой проект, который мы реализовывали маленькой командой, и у меня был огромный простор для творчества в определении подходов разработки, выборе инструментов, придумывании фичей. У меня получилось глубже погрузиться в “Докер”, особенности работы сетевых протоколов, метрик “здоровься” системы. Также удалось познакомиться с визуализацией данных, настройкой почтовых коммуникаций и отсеиванием важных событий от неважных.

Глобально этот проект дал мне обширные понятия в области устройства ELK-систем, разного способа хранения метрик, решения проблем наката приложений в Docker. В будущем все эти знания я использовала при решении инцидентов на проектах заказчика. Благодаря им мне было легко разобраться в конфигурации Zabbix (как дашбордов, так и сборщиков), отобрать из тысячи метрик нужные и собрать дашборд в Zabbix или Grafana, настроить фильтры логов в Graylog или Kibana.

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

Алерт-бот

Еще одной разработкой автоматизации, которой я занималась, был Telegram-бот, который уведомляет сотрудников службы поддержки GlowByte об обновлениях в Jira. На момент начала разработки мы имели около 40 проектов, на которых осуществляли поддержку, и около 25 сотрудников.

Ответственность за проекты была разделена на подкоманды. От бота хотелось следующего:

В боте было еще несколько функций, которые мы внедрили. В итоге мы с моей командой сделали монорепозиторий внутреннего REST API, в который включили наиболее типовые функции (работу с Google-таблицами, манипуляции с Jira, получение и обработку наиболее часто используемой информации и т. д.). Также мы сделали конструктор чат-ботов, в котором кнопки и экшны на них можно конфигурировать через JSON-конфиг. Для реализации использовали Python, JAVA.

Бот для 1-й линии и дежурств

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

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

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

Разрабатывая это решение, мы уже использовали наш монорепозиторий от alert-бота.

Несмотря на то что это не была масштабная разработка, для которой нужна команда 10+ человек, она дала мне опыт технического характера:

Также я приобрела опыт нетехнического характера:

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

В качестве ложки дегтя – не обошлось без проблем. Разрабатывая по наитию, без четких ТЗ, мы столкнулись с тем, что несколько раз переписывали свой код, доводя его до состояния масштабируемости. Кроме того, изначально мы никак не рассматривали эту активность как основной стрим и поэтому не планировали спринты, подзадачи и подобное. И только осознав, что эти проекты больше, чем просто занятие на досуге в свободное от задач время, мы пришли к управлению задачами через Scrum.