Техническая поддержка микросервисов 24/7: как мы строили процесс
Всем привет. Меня зовут Андрей Трубицын, я сотрудничаю с ЕРАМ как Java Solution Architect. В этой статье расскажу, как мы построили процесс технической поддержки микросервисов в режиме нон-стоп для крупного американского клиента.
Это был первый опыт внедрения такого подхода за моих 4 года работы в харьковском офисе ЕРАМ, и он оказался непростым для команды: надо было разобраться в новой для нас системе — Opsgenie и ее интеграции, найти желающих для ночных дежурств, спланировать работу и поставить процесс на рельсы. На нашем проекте в силу микросервисной архитектуры очень частые релизы и динамичный ритм. Мы всегда в тонусе, многим ребятам такой интенсив по душе. Однако важно, чтобы баланс работы и личной жизни сохранялся без ущерба для качества непрерывных поставок обновлений (в том числе и в среду промышленной эксплуатации).
Если вы работаете над решением на микросервисах или имеете дело с частыми релизами для достаточно требовательного клиента, то, возможно, вам будет интересен наш опыт использования Opsgenie как системы управления авариями.
Бизнес-проблема
Сейчас практически любая компания находится в условиях острой конкурентной борьбы. Важно вместе с клиентами успевать за изменениями рынка с помощью своевременной цифровой трансформации бизнеса. Платформы должны быть быстрыми и адаптивными — это одно из условий выживания и залог роста доходов клиента. Микросервисы, в частности, дают возможность уменьшить time to market. Обратная сторона медали: частые релизы, отложенное end-to-end-тестирование и другие факторы могут приводить к сбоям, на которые бизнес хочет быстро реагировать.
Это и стало причиной того, что однажды прекрасным вечером на очередном созвоне один из наших американских клиентов сообщил, что хочет организовать техническую поддержку своего продукта 24 часа в сутки 7 дней в неделю.
Как я упоминал ранее, что продукт построен на микросервисной архитектуре и для него используется подход непрерывной поставки обновлений. Это значит, что изменение, внесенное инженерами, после прохождения по CI/CD-процессу с различными тестами и уровнями контроля качества попадает в промышленную среду примерно через
Над продуктом работают свыше 200 человек, более 70 из них — в Харькове. В состав каждой проектной команды входят разработчики, системные инженеры, автоматизаторы. Вместе они отвечают за написание кода и тестов, за процесс обновления микросервиса в продукте (CI/CD pipeline) и «выкатывание» в промышленную среду эксплуатации. Требования к качеству высокие: на проекте используется статический анализ исходного кода, поузловая проверка тестами, тестирование компонентов на моделях, интеграционное и функциональное тестирование, проверка на наличие уязвимостей и производительности и т. д.
Но все же иногда в промышленной среде происходят сбои. Инженеры не всегда могут устранить их оперативно: клиент предоставляет свои сервисы в Северной Америке, разница во времени составляет
Однако клиент хотел, чтобы в момент возникновения неполадок кто-то начал работать над ними в течение 30 минут в любое время суток. Значит, должен быть некто, кто мог бы получить сообщение о сбое и включиться в работу в течение получаса. Это подразумевает, что непрерывно на расстоянии вытянутой руки у «дежурного» инженера должны находиться телефон и ноутбук с надежным интернет-соединением.
Также клиент хотел иметь возможность эскалировать проблему, если по каким-то причинам в заранее оговоренное время инженер не ответил, что взялся за работу; лид команды должен получать звонок с описанием сложностей, следующим — принять сообщение архитектор, после него — сам заказчик. Если эта иерархия станет «пробиваться» и проблема доходить до клиента, нам будут грозить финансовые санкции.
Начало пути
На старте наша работа состояла из следующих этапов:
1. Понять, на какие события должна реагировать система управления авариями, а какие может игнорировать. Надо было проанализировать весь продукт, собрать перечень всех потенциальных негативных моментов и направить его клиенту.
2. Обсудить каждое событие из перечня с заказчиком, чтобы выявить критично важные для него моменты.
3. Сформировать финальный список задач, которые программисты будут контролировать 24/7. На самом деле, не все сбои требуют немедленного реагирования и оправдывают дополнительные расходы клиента на круглосуточную техподдержку.
Критерии, по которым мы сформировали список критичных для нас событий, касаются основного бизнес-флоу заказчика. Если один из микросервисов, который обслуживает эту часть системы, дает сигнал об отказе (выдает ошибку, отрабатывает медленнее определенных SLA или оказывается недоступен), это проблема, которая требует немедленного вмешательства программистов.
4. Сделать PoC. Мы изучили документацию выбранной системы управления авариями, получили доступ к их «песочнице», построили свой Proof of Concept на базе тестового сервиса, который моделировал бы разные исключительные ситуации, и отработали схему взаимодействия с Opsgenie.
После презентации результатов клиенту и документирования процесса команды взяли систему в работу, чтобы в плановой имплементации добавить функционал техподдержки 24/7 в бизнес-флоу заказчика. Техническую сторону вопроса выполнили архитектор и технический лидер одной из команд.
5. Отладить и внедрить новый процесс в работу команды. Этим занимался в основном наш проектный менеджер, и он столкнулся с непростой задачей. С самого начала стало ясно, что команде на «дежурстве» нужны именно разработчики (обычно сбои случаются в ходе бизнес-процесса сервисов, а не с конфигурацией стендов например). Однако это не могут быть те же люди, которые трудятся над расширением функционала, техническим долгом и другими задачами. Их режим предполагает днем регулярные встречи, написание кода, время на обед.
Вечером такие разработчики могут пойти на встречу с друзьями / кататься на велосипеде / смотреть кино — в общем, распоряжаться временем по собственному усмотрению. Да и ночью они должны отдыхать. Также мы поняли, что инженерам постарше и семейным людям такой режим в принципе не подходит.
В то же время мы осознавали, что «дежурными» не могут быть сторонние специалисты, так как необходимо понимать, как работает тот или иной сервис в продукте. Получается, что на связи все-таки должны быть отдельные разработчики из команды. Мы узнали, кому из ребят интересно взяться за эту задачу и раз в полтора-два месяца «дежурить» в течение недели с хорошим интернет-соединением и ноутбуком всегда под рукой (за дежурства 24/7, к слову, полагаются определенные денежные бонусы).
Примерно половина людей согласились участвовать в процессе, и с начала 2019 года мы работаем в таком режиме. Отмечу, что во время смены у инженеров получается жить обычной жизнью, без особо жестких ограничений. Главное — в случае аварии быть доступным практически мгновенно.
Как работает система управления авариями
Как я уже упоминал, для автоматизации процесса управления авариями клиент выбрал сервис Opsgenie. Все примеры, которые я буду приводить, относятся к нему.
Opsgenie позволяет создать команду, для которой вы можете составить расписание дежурств. Если по каким-то причинам нужно точечно изменить расписание, то нет необходимости переделывать его полностью, можно просто обновить некоторые даты и сервис сам адаптирует расписание и правки и выдаст финальный вариант. Пример — на картинке ниже.
Далее, мы настраиваем правила эскалации: сколько времени выделяется на подтверждение, что команда знает о проблеме и работает над ее устранением; что делать, если сотрудник на смене не подтвердил начало работы над проблемой. В приведенном ниже примере после 30 минут ожидания система позвонит администратору группы, а если проблема не будет решена за два часа, то по тревоге поднимается уже вся команда.
После того как в Opsgenie внесены команда, расписание и правила эскалации, надо настраивать его интеграцию с вашими сервисами в промышленной среде эксплуатации. У выбранного нами сервиса управления авариями есть возможность интегрироваться с несколькими сотнями систем и сервисов. Для выгрузки микросервисов на стенды мы используем публичное облако AWS.
Как мы интегрировали микросервисы и Opsgenie
Для примера предлагаю рассмотреть конфигурацию реакции системы управления авариями на остановку одного из сервисов (например, в Java-приложении закончилась память в контейнере), запущенном в ECS-кластере AWS. Такая конфигурация работает на нашем проекте, но некоторые детали изменены в силу политик конфиденциальности компании.
Первый шаг — создание интеграционной ссылки в системе управления авариями в разделе интеграции. Она включает в себя уникальный ключ, по которому сервис определит наш микросервис. Никаких параметров вводить не нужно, система все сделает сама.
Для интеграции с Opsgenie со стороны микросервиса создаем SNS Topic и прописываем ссылку, которую мы сгенерировали на предыдущем шаге.
Resources:
MicroserviceECSAlarmTopic:
Type: AWS:: SNS::Topic
Condition: InLive
Properties:
TopicName: "MicroserviceECSAlarmsTopic"
Subscription:
- Endpoint: https://api.opsgenie.com/v1/json/amazonsns?apiKey=eeeeeeee-cccc-ffff-bbbb-aaaaaaaaaaaa
Protocol: https
Далее, создаем правило, по которому мы будем слушать определенный тип сообщений от ECS-кластера и отправлять на созданный нами SNS Topic сообщение о том, что Docker-контейнер с нашим микросервисом остановился.
ECSStoppedRule:
Type: "AWS::Events::Rule"
Condition: InLive
Properties:
Name: 'MicroserviceECSStoppedRule'
Description: "Notify when the microservice goes down"
EventPattern:
source: ["aws.ecs"]
detail-type: ["ECS Task State Change", "ECS Container Instance State Change"]
detail:
clusterArn: #############
lastStatus: [ "STOPPED" ]
stoppedReason: [ "Essential container in task exited", "Task stopped by user" ]
group: #############
State: "ENABLED"
Targets:
- Arn: !Ref MicroserviceECSAlarmTopic
Id: " MicroserviceECSAlarmTopic "
InputTransformer:
InputPathsMap:
detail: "$.detail"
InputTemplate: '"The microservice has stopped working with the following details: <detail>"
Здесь в секции EventPattern мы описываем сообщения, которые хотим слушать. Для этого в параметре source: [«aws.ecs»] указываем, что слушаем сообщения от ECS-кластера в облаке AWS; в параметре detail-type мы задаем конкретные типы сообщений: запуск/остановка задачи нашего микросервиса или изменение состояния Docker-контейнера с нашим микросервисом. Из указанных сообщений мы выбираем только те, что привели к остановке Docker-контейнера с нашим микросервисом; это делается через параметр detail, в котором мы прописали последний статус и причины остановки.
Далее, в секции Targets указываем, что мы хотим сделать в случае получения вышеописанных сообщений. В приведенном примере мы готовим новое сообщение на основе извлеченной информации из полученного. Она извлекается в параметре InputPathsMaps, где мы объявляем новую переменную detail и заносим в нее значение из параметра detail полученного сообщения. В параметре InputTemplate мы формируем тело нового сообщения и используем переменные из InputPathsMaps.
Теперь нам нужно выгрузить описанный CloudFormation-шаблон на стенд в облаке Amazon и надеяться, что ночью нас беспокоить не будут :) У нашей команды, кстати, в первый месяц работы по такой системе было 26 критичных ситуаций, во второй — 5, а дальше максимум одна в месяц. То есть активными дежурства бывают нечасто. Все благодаря тому, что код инженеры стали писать качественнее.
К слову, о ночном беспокойстве. На старте работы у нас была забавная история. Когда мы с проектным менеджером и техническим лидером занимались PoC, то создали тестовое расписание и распределили между собой тренировочные дежурства. Обсудили, что можем получать SMS и звонки ночью в случае сбоев, были готовы. PoC прошло успешно, мы внедрили систему, начали работать и благополучно об этом забыли.
И вот однажды проектному менеджеру ночью поступил звонок. Он подумал, что произошла эскалация на тот сервис, который мы недавно отправили в production (в нашем обычном флоу менеджер получает сообщение, если команда долго не может решить проблему), и стал звонить дежурному инженеру, выяснять, почему тот не занимается вопросом. В онлайн-режиме среди ночи они зашли в Opsgenie и убедились, что никакой проблемы нет. Но у нас хороший, ответственный менеджер: он решил докопаться до истины, удостовериться, что все в порядке. Так что среди ночи разбудили и архитектора, который спросонья тоже не понял, что произошло, и позвонил в свою очередь тимлиду.
В результате к рассвету сонные менеджер, дежурный инженер, архитектор и технический лидер наконец-то решили еще раз прочитать SMS и увидели, что тревогу поднял тестовый сервис из старого PoC, который система удалила из среды разработки за ненадобностью. После этого все успокоились, удалили тестовое расписание и спокойно пошли досыпать оставшиеся часы. Вывод: будьте внимательны, чтобы не просыпаться по ложной тревоге :)
Выученные уроки
Подумайте заранее, кто в вашей команде согласится на дежурства. Молодежь охотнее берется за периодическую работу в формате 24/7, людей семейных и тех, кто постарше, бонусы не всегда мотивируют.
Сформируйте полный список исключительных ситуаций и обсудите его с клиентом. Это непростой процесс, который требует итеративной работы. При этом именно заказчик поможет понять, какие из потенциальных проблем критичны для бизнеса и требуют немедленного решения, а какие, несмотря на техническую важность, могут подождать (например, отказ обслуживания одного из экземпляров микросервиса по причине закончившейся памяти — технически существенный дефект, но он не является для бизнеса критичным, так как облачная микросервисная платформа просто запустит новый экземпляр другого сервиса или использует механизмы повторных запросов).
Уделяйте время тестированию. На нашем проекте кросс-функциональные команды. То есть разработчики пишут unit-, компонентные, интеграционные и end-to-end-тесты. Они не всегда любят это делать, но после внедрения техподдержки 24/7 осознали всю важность процесса и стали относиться к нему более ответственно. В конце концов, от качественного тестирования во многом зависит их спокойствие на дежурстве.
Объясните команде, почему не стоит играть в пинг-понг (фигурально выражаясь). Если во время дежурства возникла проблема в чужом коде или на чужом «участке работы», это не повод переводить стрелки. В экстренных случаях надо не перебрасывать ответственность, а засучив рукава исправлять ситуацию. Индивидуализму в таком процессе не место, и менеджерам стоит обратить на это внимание команды. Привлекать коллег желательно только в случае эскалации или особой сложности задачи.
Выводы
За время работы с Opsgenie и техподдержкой микросервисов 24/7 мы убедились, что этот подход позволяет значительно улучшить качество кода в системе (к слову, одной из первых его применила Amazon). Отмечу, что техническая сторона вопроса не требует много времени: чтобы прописать одну исключительную ситуацию на одном микросервисе, хватит одного-двух дней. В нашем случае самыми сложными в запуске техподдержки 24/7 были все же нетехнические моменты.
Особых усилий потребовало формирование расписания и обсуждение финансовых вопросов с клиентом так, чтобы и процесс работал, и ребята, которые согласились страховать продукт посменно, были довольны. На это у нас ушло около полугода — от подписания контракта и бюджетирования до написания кода и выхода ребят на новый режим. Зато сейчас клиент доволен результатами и скоростью реакции, а команда адаптировалась к такому особому графику. Изначальный контракт был подписан на год, но мы уже знаем, что продлим его.
Если вы делаете продукт с микросервисной архитектурой или на проекте много релизов и клиент хочет иметь возможность устранения неполадок в режиме 24/7, подумайте об использовании Opsgenie или другой системы управления авариями для качественной отладки процесса. Но главное — слушайте команду и уделяйте внимание человеческому фактору.
