Всем привет! Меня зовут Мазеин Михаил, я бэкенд-разработчик в компании ManyChat. Одна из моих задач — анализировать и улучшать качество нашего продукта с помощью систем мониторинга, сигнализации и сопутствующих процессов.
На собственном опыте я понял, что мониторинга зданий недостаточно.
Сегодня я поделюсь тремя историями из жизни нашей команды: расскажу, как мы искали решения и к каким выводам пришли.
На мой взгляд, пост может быть полезен разработчикам, QA-инженерам, системным администраторам и тимлидам/техлидам.
Эта статья основана на моем докладе с онлайн-конференции.
Если вы предпочитаете посмотреть видео, оно доступно на YouTube .
В ManyChat мы обрабатываем более 2 миллиардов событий в день.
При таких объемах неизбежны различные ошибки — при выполнении кода, в различных нестандартных случаях, при взаимодействии со сторонними сервисами.
При этом мы стартап и работаем в парадигме небольших кросс-функциональных продуктовых команд. У нас нет выделенных команд платформы или отдела тестирования.
Для контроля качества продукта и корректной работы всех сервисов мы решили проводить следующие виды мониторинга:
- Мониторинг ошибок во время выполнения: показывает, как работает наш код, позволяет ловить ошибки в режиме реального времени, получать уведомления, иметь полный контекст для каждой ошибки — кто ее вызвал и при каких условиях, а также осуществлять поиск по ошибкам и фильтровать события;
- Метрики инфраструктуры: показывают состояние оборудования, уровень загрузки базы данных, очереди и все такое;
- «Функциональные» метрики: помогают гарантировать, что количество ошибок при выполнении бизнес-логики в различных функциональных компонентах не увеличивается, а количество успешных выполнений не уменьшается.
Но когда настроен мониторинг и уведомления сыпятся нон-стоп, возникает необходимость в процессах.
Чтобы проанализировать ситуацию, понять причину ее возникновения и устранить ошибку, нужны люди и практики, регламентирующие работу специалистов.
Некоторые компании решают подобные проблемы с помощью DevOps-инженеров.
Для нас DevOps — это не роль, а идеология разработки и поставки качественного программного обеспечения.
Поэтому в нашей компании каждый инженер участвует в процессе реагирования на мониторинг.
И на примере следующих историй станет понятно, как это работает.
Первая история.
Исправляем ошибки В службу поддержки был отправлен тикет, в котором говорилось, что у пользователя что-то не работает. Ребята из поддержки проверили и подтвердили, что у пользователя возникла ошибка, связанная с редким случаем, который не был учтен при разработке.
В общих метриках мы этого не видим, так как проблема не является массовой, но мы не хотим оставлять пользователя в беде, и проблему нужно исправить, чтобы никто с ней не столкнулся в будущем.
Есть два пути решения проблемы:
- Помещаем ошибку в бэклог
- Решаем проблему здесь и сейчас
А если этот баг заблокирует пользовательский скрипт, то мы можем потерять клиента.
Поэтому хотелось бы записать это здесь и сейчас.
Возникает задача - передать баг из поддержки в разработку? Если вы подойдете к случайному разработчику с просьбой посмотреть и исправить ошибку, скорее всего, вы услышите от него слезливую историю о том, что у него теперь самая важная задача в спринте, цель спринта под угрозой и он не может отвлекись прямо сейчас.
И это будет справедливо.
Однако в фреймворке LeSS (который мы используем) есть такая практика, как команда Stop and Fix (S’n’F), которую мы применили в своей работе.
Это «черная метка», которая переходит от команды к команде каждый спринт. Команда S'n'F не берет продуктовые задачи в спринт; его цель — взаимодействие со службой поддержки, работа над ошибками, поступающими от пользователей.
В процессе S’n’F участвует вся кросс-функциональная команда.
В него входят не только разработчики, но и дизайнеры, даже продакт-менеджеры.
Ведь ошибки случаются не только в коде, но и в UX, и на уровне продукта.
Еще одним преимуществом является то, что эта практика позволяет разработчикам команды S'n'F погрузиться в кодовую базу ранее незнакомых компонентов, которые они не трогали во время своих спринтов.
В результате члены команды неизбежно расширяют свою экспертизу в работе всей системы.
А наличие бесплатного ресурса позволяет ребятам из S'n'F работать не только с ошибками пользователей, но и следить за сигналами мониторинга и реагировать на них.
Такой подход позволил нам реагировать на любые ошибки, не прерывая спринты и не откладывая важные дела на второй план (бэклог).
Вторая история.
Снижение уровня шума Два года назад мы разрабатывали сложную функцию, которая предоставила нашим пользователям широкие возможности настройки автоматизации.
Событийная система отслеживает любое изменение состояния абонентов в системе и по заданным триггерам запускает необходимую автоматизацию.
Все это работает в реальном времени и на аудитории в 500+ миллионов подписчиков.
Функция могла негативно сказаться на производительности нашей инфраструктуры, и мы начали ее внедрять постепенно, отслеживая основные метрики системы.
На первом этапе мы распространили эту функцию на пару десятков наших самых лояльных пользователей, чтобы они могли ее протестировать и оставить отзыв.
Мы настраиваем метрики для отслеживания ошибок в обработке событий и изменений контекста, а также фактов об успешной обработке бизнес-логики.
Алармы были настроены только на ошибки, так как у нас еще не было какого-то базового показателя, относительно которого мы могли бы настроить уведомления об успешном внедрении.
Через пару дней пришло сообщение об ошибке.
Мы сразу же обнаружили небольшую ошибку и быстро выпустили исправление.
Это было субботнее утро (вы уже догадались, что в этот момент началось веселье?).
Конечно, прежде чем запустить исправление в производство, я протестировал его на стадии разработки.
Все было ок.
Выкатили фикс на продакшн, мониторинг сказал, что ошибок обработки больше нет, и мы отправились наслаждаться выходными.
В понедельник мы поняли, что наша функция полностью перестала работать.
К счастью, пользователи этого не заметили, поскольку функция находилась на очень ранней стадии внедрения, и на нее еще никто особо не полагался.
Мы разобрались в этой ситуации внутри команды и проанализировали свои ошибки.
Мы сознательно не ставили оповещения об отсутствии успешной обработки, так как функция находилась на ранней стадии разработки и мы бы получили большое количество ложных срабатываний.
Небольшие различия в сериализации данных в промежуточной среде и в производственной среде привели к тому, что данные больше не доходили до компонента.
А отсутствие обработки привело к отсутствию ошибок - всё логично.
Но ошибка все равно присутствовала на этапе сериализации, и нам пришлось отлавливать ее с помощью инструмента мониторинга ошибок во время выполнения.
Они действительно были там, но почему-то никто не ответил, даже несмотря на уведомление в слабом канале.
Решение оказалось тривиальным: в этот канал стало поступать слишком много уведомлений, в результате чего сообщение просто терялось.
К сожалению, когда продукт становится достаточно сложным и загруженным, во время выполнения может произойти много чего: интеграция с внешними сервисами может дать сбой, исключения обрабатываются некорректно, некоторые мелкие ошибки и случаи также могут попасть в систему мониторинга.
В какой-то момент у нас накопилось достаточно большое количество мелких вещей, которые никак не влияли на производительность и корректную работу системы, но создавали много шума в канале уведомлений, среди которых реальные ошибки, на которые нужно было реагировать.
были потеряны.
С этим надо было что-то делать.
Эвремя эксперимента
Мы договорились, что команды разбирают ошибки во время выполнения в оставшееся от основных задач в спринте время.
Проходим пару спринтов, смотрим на динамику – а ее нет! Количество ошибок/уведомлений остается примерно на том же уровне шума.
У каждой команды свой спринт, горят особенности, нет времени разбираться с ошибками.
Становится понятно, что мы не решим эту проблему в рамках обычного рабочего процесса.
Ээксперимент второй
Мы помним, что у нас есть команда С'н'Ф и передаем все это в их зону ответственности!
После нескольких спринтов мы видим, что количество ошибок/уведомлений не увеличивается, но и не уменьшается.
Команда S'n'F в ходе своей работы успевает разобраться с новыми ошибками и уведомлениями, но заниматься старыми некогда.
Ээксперимент третий
Пятничный хакатон с пивом и пиццей.Мы проводим два хакатона среди волонтеров.
В них участвует практически вся команда, ребята воодушевляются.
Две пятницы подряд мы с командой по вечерам в веселой, неформальной обстановке исправляем мелкие ошибки.
Есть результаты! Мы несколько снизили уровень шума, но всего на 10-15 процентов.
Формат решения задачи интересный и классный, но как разовое мероприятие.
Мы не можем и не хотим брать взаймы у команды каждый пятничный вечер по объективным причинам — все удовольствие от такого формата со временем превратится в рутину.
Ээксперимент четвертый
Нам нужна команда, которая сможет победить этот процесс.Поскольку мы исправляем ошибки в нашем коде, нам нужны только разработчики, а точнее бэкендеры, и вся команда должна состоять из таких людей.
Мы пытаемся собрать команду из 2-3 разработчиков.
Но у нас нет свободных разработчиков; все они состоят в кросс-функциональных командах.
Появляется идея — создать временные команды, которые будут заниматься этим не дольше одного спринта.
Нехорошо долго заставлять людей заниматься рутинными задачами, а отключать ребят от разработки продукта на долгое время не хочется.
Эту команду волонтеров мы начали собирать заново каждый спринт, пока такая необходимость не отпала.
В таком формате мы работали тремя недельными спринтами, трижды пересобирая команду.
В результате нам удалось снизить уровень шума до приемлемого для нас уровня, а также решить некоторые вопросы, связанные с техническим долгом, до которых мы раньше не доходили руки.
Это успех! Разобравшись со всем ненужным шумом в системе мониторинга, мы вернулись к формату эксперимента №2 — команда S'n'F может справиться с текущим потоком уведомлений, сортируя их по мере поступления.
Третья история.
Подключение поддержки Другая история возникла потому, что мы работаем на международном рынке, и пользователи из разных стран круглосуточно запускают свои рекламные кампании.
Они тратят свои деньги и мы должны оперативно реагировать на любые происшествия в любое время суток.
Но S’n’F – это обычная кросс-функциональная команда, которая работает в том же режиме, что и другие команды, только над другим типом задач.
Однажды ночью партнерская служба выпустила обновление, нарушившее обратную совместимость.
Да, факапы случаются не только у нас, но и у них! Это была критически важная функция для нашего сервиса; на проблему нужно было ответить «здесь и сейчас».
Естественно, в это время все благополучно спали, уведомление своевременно не было замечено, и мы отреагировали на инцидент только через час.
Провел анализ.
Мы поняли, что это неприемлемо.
Что делать? Ночные смены для бригад С'н'Ф – это излишество, учитывая тот факт, что подобные инциденты довольно редки.
Эти вопросы было решено передать в службу поддержки, которая взаимодействует с S'n'F и работает 24/7. Мы добавили ребят в канал оповещения о тревогах и создали протокол реагирования на тревоги.
Для этого введена стандартная градация инцидентов: Критический, Ошибка и Предупреждение.
Критический - Вася, мы горим! Бегите за пожарными! Поддержка должна связаться с дежурным разработчиком из команды S'n'F или кем-то еще в течение 5 минут, если дежурный недоступен.
Команда сама выбирает своих дежурных.
Дежурному достаточно оставить телефон включенным на ночь и ответить на звонок, чтобы в случае чего начать тушение пожара.
Не исключено, что в случае крупного пожара понадобится не только команда С'н'Ф, но и подкрепление.
Ошибка — Количество ошибок увеличилось, но это не так критично.
Однако если такое уведомление не будет отправлено обратно в течение 30 минут, вам необходимо обратиться к дежурному офицеру.
Предупреждение «Что-то происходит, но в целом мы можем подождать до утра».
Полученные результаты
Возможно, эти истории покажутся многим знакомыми.Они показывают, что инструменты не работают без людей и процессов вокруг них.
Мы должны постоянно совершенствовать практики, искать слабые места и экспериментировать с подходами к решению проблем.
Если одна тактика не работает, нужно попробовать другую! В следующем посте я расскажу подробнее о самих инструментах мониторинга — как они работают, как мы их настраиваем, с какими нюансами столкнулись с технической стороны.
Так что подписывайтесь на Блог ManyChat , если эта тема вас интересует. Буду рад прочитать ваши истории и решения в комментариях, ведь нам всем гораздо дешевле учиться на чужих ошибках! Теги: #Управление разработкой #Управление продуктом #мониторинг #процессы #manychat #manychat команда #techlead conf #techlead conf 2020 #остановись и исправь
-
Отличные Предложения С Bluetooth-Гарнитурой
19 Oct, 24 -
Важность Контроля При Создании Вашего Блога
19 Oct, 24 -
10 Мифов О Бешенстве
19 Oct, 24
