[Управление разработкой, Управление продуктом] Настроили мониторинг. Что дальше?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет! Меня зовут Мазеин Михаил, я занимаюсь бекенд-разработкой в ManyChat.
Одна из моих задач — анализ и повышение качества нашего продукта через системы мониторингов, алармов и сопутствующих процессов. Я на своем опыте убедился в том, что выстроить мониторинг — недостаточно. Сегодня я поделюсь тремя историями из жизни нашей команды: расскажу, как мы искали решения и какие выводы сделали. На мой взгляд, пост может оказаться полезен и разработчикам, и QA-инженерам, и системным администраторам, и тимлидам/техлидам.
Эта статья основана на моем докладе с онлайн-конференции TechLead Conf 2020. Если вам приятнее смотреть видео, оно доступно на YouTube.
Мы в ManyChat обрабатываем больше 2 миллиардов событий в сутки. При таких объемах неизбежны различные ошибки — при выполнении кода, на различных корнер-кейсах, при взаимодействии со сторонними сервисами. При этом, мы — стартап и работаем в парадигме небольших продуктовых кросс-функциональных команд. У нас нет выделенных платформенных команд или отдела тестирования.
Чтобы следить за качеством продукта и корректностью работы всех сервисов, мы решили вести следующие виды мониторинга:
- Мониторинг ошибок в runtime: показывает, как работает наш код, позволяет отлавливать ошибки в реальном времени, получать нотификации, иметь полный контекст для каждой ошибки — у кого и при каких условиях она возникла, а также искать по ошибкам и фильтровать события;
- Инфраструктурные метрики: показывают состояние железа, уровень загруженности БД, очередей и всего такого;
- “Фичевые” метрики: помогают следить за тем, чтобы количество ошибок выполнения бизнес логики в разных фичевых компонентах не росло, а количество успешных выполнений не падало.
Чтобы работать было удобно — мы настраиваем нотификации в отдельные каналы в Slack. Так удается получить максимальный охват аудитории. Но когда мониторинги настроены и нотификации сыпятся безостановочно, возникает потребность в процессах. Для того, чтобы проанализировать ситуацию, понять причину ее возникновения и устранить ошибку нужны люди, практики, которые регламентируют работу специалистов.
Некоторые компании решают подобные проблемы силами DevOps-инженеров. Для нас же DevOps – это не роль, а идеология о разработке и доставке качественного программного обеспечения.
Поэтому в нашей компании в процесс реагирования на мониторинг вовлечен каждый инженер. А на примере следующих историй станет понятно, как это работает.
Первая история. Чиним баги
В саппорт прилетел тикет, о том, что у пользователя что-то не работает. Ребята из саппорта проверили и подтвердили, что у пользователя наблюдается баг, связанный с редким корнеркейсом, который не учли при разработке. На общих метриках мы этого не видим, так как проблема не массовая, но пользователя в беде бросать не хотим, да и проблему исправить нужно, чтобы в будущем никто с ней не столкнулся.
Есть два пути решения проблемы:
- Кладем баг в бэклог
- Решаем проблему здесь и сейчас
Если мы положим баг в бэклог, то его исправление может попасть в следующий спринт, а может и не попасть. В худшем случае проблема несчастного пользователя может проваляться в бэклоге очень долго. А если этот баг блокирует пользовательский сценарий, то мы можем потерять клиента. Поэтому хотелось бы фиксить здесь и сейчас.
Возникает задача — передать баг из саппорта в разработку? Если подойти к рандомному разработчику с просьбой посмотреть и пофиксить баг, скорее всего вы услышите от него душещипательную историю о том, что у него сейчас самая важная задача в спринте, цель спринта под угрозой и он никак не может отвлечься именно сейчас. И это будет справедливо.
Однако в фреймворке LeSS (по которому мы работаем) существует такая практика, как Stop and Fix (S'n'F) команда, которую мы применили в своей работе. Это “черная метка”, которая переходит от команды к команде каждый спринт. S'n'F команда не берет в спринт продуктовые задачи, ее цель — взаимодействовать с командой саппорта, работать над багами, которые приходят от пользователей. В процессе S'n'F задействована вся кросс-функциональная команда. В нее входят не только разработчики, но и дизайнеры, даже менеджеры продукта. Ведь баги бывают не только в коде, но и в UX, и на продуктовом уровне.
Еще один плюс в том, что эта практика позволяет разработчикам S'n'F команды погружаться в кодовую базу незнакомых ранее компонентов, которых они не касались в ходе работы над своими спринтами. В результате участники команды неизбежно расширяют свою экспертизу в работе всей системы. А наличие свободного ресурса позволяет ребятам из S'n'F работать не только с пользовательскими багами, но и следить за алармами с мониторингов, и реагировать на них. Такой подход позволил нам реагировать на любые баги, не прерывая спринтов и не откладывая важные вещи в долгий ящик (бэклог).
Вторая история. Снижаем уровень шума
Два года назад мы разрабатывали сложную фичу, которая давала широкие возможности настройки автоматизации нашим пользователям. Event-based система мониторит любое изменение состояния подписчиков в системе, и при заданных триггерах запускает нужную автоматизацию. Все это работает в реальном времени и на аудитории в 500+ миллионов подписчиков.
Фича могла негативно сказаться на производительности нашей инфраструктуры, и мы начали выкатывать ее постепенно, следя за основными метриками системы. На первом этапе раскатали фичу на пару десятков наших самых лояльных пользователей, чтобы они её протестировали и дали фидбек.
Мы настроили метрики на вылавливание ошибок процессинга событий и изменения контекста, а также на факты успешного процессинга бизнес логики. Алармы были настроены только на ошибки, так как у нас еще не было какого-то baseline, относительно которого можно настраивать уведомления об успешной реализации.
Через пару дней пришло сообщение об ошибке. Мы сразу же отловили мелкий баг, и быстро выпустили исправление. Дело было в субботу утром (вы уже догадались, что веселье началось именно в этот момент?).
Конечно же перед тем, как выкладывать исправление в продакшен, я протестировал фикс на стейджинге. Все было ок. Выкатили фикс в продакшен, мониторинг сказал, что ошибки процессинга больше не стреляют, и мы пошли наслаждаться выходными. В понедельник мы поняли, что наша фича совсем перестала работать. Благо пользователи этого не заметили, так как фича была на очень раннем этапе раскатки, и на неё еще никто толком не полагался.
Мы разобрали эту ситуацию внутри команды и проанализировали наши ошибки. Мы осознанно не настроили алармы на отсутствие успешного процессинга, так как фича была на ранней стадии раскатки и мы бы получили большое количество ложных срабатываний. Небольшие различия в сериализации данных на стейджинге и в продакшн-среде привели к тому, что данные перестали доходить до компонента. А отсутствие процессинга привело и к отсутствию ошибок — все логично.
Но ошибка все-таки присутствовала на этапе сериализации, и мы должны были отловить её через инструмент мониторинга runtime ошибок. Они там действительно были, но почему-то никто не отреагировал, даже не смотря на нотификацию в slack-канале.
Разгадка оказалась банальной: в этот канал начало сыпаться слишком много нотификаций, в результате чего сообщение просто затерялось. Увы, когда продукт становится достаточно сложным и нагруженным, в рантайме может происходить много чего: интеграция с внешними сервисами может сбоить, происходить некорректная обработка исключений, какие-то мелкие ошибки и кейсы могут тоже попадать в систему мониторинга. В какой-то момент у нас накопилось достаточно большое количество мелких вещей, которые никак не сказывались на производительности и корректности работы системы, но создавали очень много шума в канале нотификаций, среди которого терялись реальные ошибки, на которые нужно было реагировать. С этим нужно было что-то делать…
Эксперимент раз
Мы договариваемся о том, что команды разгребают ошибки в runtime в оставшееся время от основных задач в спринте.
Проходит пара спринтов, смотрим на динамику — а ее нет! Количество ошибок/нотификаций остается примерно на том же уровне шума. У каждой команды свой спринт, фичи горят, нет времени заниматься ошибками. Становится понятно, что в рамках привычного workflow мы эту проблему не решим.
Эксперимент два
Вспоминаем, что у нас есть S'n'F команда и передаем всё это в их зону ответственности!
Через несколько спринтов видим, что количество ошибок/нотификаций не растет, но и не падает. S'n'F команда в ходе своей работы успевает разбирать новые ошибки и нотификации, но старыми заниматься времени нет.
Эксперимент три
Пятничный вечерний хакатон с пивом и пиццей. Проводим два хакатона среди добровольцев. Почти вся команда принимает в них участие, ребята воодушевлены. Две пятницы подряд мы с командой по вечерам в веселой неформальной обстановке фиксим мелкие ошибки.
Результаты есть! Мы несколько снизили уровень шума, но только процентов на 10-15. Формат решения проблемы интересный и прикольный, но как разовая акция. Занимать у команды каждый пятничный вечер мы не можем и не хотим по объективным причинам — весь fun от такого формата со временем перейдет в рутину.
Эксперимент четыре
Нам нужна команда, которая сможет победить этот процесс. Так как мы чиним ошибки в нашем коде, нам нужны только разработчики, а точнее — бэкендеры, и вся команда должна состоять из таких людей. Мы пробуем собрать команду из 2-3 разработчиков. Но свободных разработчиков у нас нет, они все в кросс-функциональных командах.
Появляется идея — сделать временные команды, которые занимаются этим не дольше, чем один спринт. Не хорошо надолго в рутинные задачи загонять людей, да и не хочется выключать на длительное время ребят из продуктовой разработки.
Мы стали пересобирать эту команду из добровольцев каждый спринт, пока не пропала такая необходимость. В этом формате мы проработали три недельных спринта, трижды пересобрав команду.
В результате удалось снизить уровень шума до приемлемого для нас значения, а также решить некоторые вещи, связанные с тех-долгом, до которых у нас раньше не добирались руки.
Это успех! Разобрав весь лишний шум в системе мониторинга, мы вернулись к формату эксперимента №2 — команда S'n'F может справиться с текущим потоком нотификаций, разгребая их по мере поступления.
Третья история. Подключаем саппорт
Еще одна история появилась потому, что мы работаем на международном рынке, и пользователи из разных стран запускают свои рекламные кампании круглосуточно. Они тратят свои деньги и мы должны оперативно реагировать на любые инциденты в любое время суток. Но S'n'F — это обычная кросс-функциональная команда, которая работает в том же режиме, что и остальные команды, просто над иным типом задач.
Однажды ночью партнерский сервис выкатил обновление, которое сломало обратную совместимость. Да, факапы бывают не только у нас, но и у них! Это была критичная для нашего сервиса функциональность, на проблему нужно было отреагировать “здесь и сейчас”. Естественно, в это время все благополучно спали, уведомление не было замечено своевременно, и мы отреагировали на инцидент только через час.
Провели анализ. Поняли, что это неприемлемо. Что же делать?
Ночные смены для S'n'F команд — это перебор, с учетом того, что подобные инциденты бывают достаточно редко. Было решено отдать эти вопросы команде саппорта, которая взаимодействует с S'n'F и работает в режиме 24/7. Мы добавили ребят в канал с нотификациями об алармах и создали протокол реагирования на алармы. Для этого была введена стандартная градация инцидентов: Critical, Error и Warning.
Critical — Вася, мы горим! Беги за пожарными! Саппорт должен в течение 5 минут связаться с дежурным разработчиком из S'n'F команды или с кем-то другим, если дежурный недоступен. Дежурных команда выбирает самостоятельно. Дежурному достаточно не выключать телефон на ночь, и отреагировать на звонок, чтобы в случае чего инициировать тушение пожара. Не исключено, что в случае большого пожара потребуется не только S'n'F команда, но и подмога.
Error — Количество ошибок выросло, но это не так критично. Однако, если такое уведомление не отстрелило обратно в течение 30 минут, нужно связываться с дежурным.
Warning — Что-то происходит, но в целом мы можем подождать до утра.
Итоги
Возможно, эти истории многим покажутся знакомыми. Они показывают, что инструменты не работают без людей и процессов вокруг них. Мы должны постоянно улучшать практики, искать слабые места, экспериментировать с подходами к решению проблем. Если не сработала одна тактика — нужно попробовать другую!
В следующем посте я расскажу подробнее о самих инструментах мониторинга — как они работают, как мы их настраивали, какие встретили нюансы с технической стороны. Так что подписывайтесь на блог ManyChat, если эта тема вам интересна. Буду рад прочитать в комментариях ваши истории и решения, ведь всем нам намного дешевле учиться на чужих ошибках!
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-инфраструктура, Сетевые технологии, DevOps] Сегодня, 12 ноября в 18 часов(MSK) состоится Online Monitoring Meetup
- [Системное администрирование, Серверное администрирование, Управление разработкой, DevOps] Приглашаем на митап «Apache Kafka в вопросах и ответах» 17 ноября в 19:00
- [Программирование, Управление проектами, Управление продуктом, Карьера в IT-индустрии] Pet-проекты: зачем они нужны, и стоит ли тратить на это время в 2020 году + опрос
- [Интерфейсы, Дизайн мобильных приложений, Управление продуктом, Дизайн] Friends of Figma Moscow
- [Бизнес-модели] BPIUM —конструктор исполняемых бизнес-процессов
- [Управление разработкой, Управление проектами, Управление продуктом, Бизнес-модели, IT-компании] Как запустить IT-продукт за 1,5 месяца и не закрыться через полгода с колоссальными убытками
- [Управление разработкой, Управление проектами, Управление продуктом, Управление персоналом, Конференции] Управление разработкой в «горизонтальных» компаниях: расшифровка онлайн-встречи. Часть 1
- [Разработка веб-сайтов, Управление продуктом] Как мы создавали первый онлайн-сервис Автокредит
- [Дизайн мобильных приложений, Управление разработкой, Управление проектами, Управление продуктом] Система «сделал-измерил-узнал» (перевод)
- [Управление разработкой, Управление проектами, Управление продуктом] Delivery Club x GIST
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_produktom (Управление продуктом), #_manychat, #_manychat_team, #_techlead_conf, #_techlead_conf_2020, #_monitoring (мониторинг), #_protsessy (процессы), #_stop_and_fix, #_blog_kompanii_konferentsii_olega_bunina_(ontiko) (
Блог компании Конференции Олега Бунина (Онтико)
), #_blog_kompanii_manychat (
Блог компании ManyChat
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:09
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Всем привет! Меня зовут Мазеин Михаил, я занимаюсь бекенд-разработкой в ManyChat. Одна из моих задач — анализ и повышение качества нашего продукта через системы мониторингов, алармов и сопутствующих процессов. Я на своем опыте убедился в том, что выстроить мониторинг — недостаточно. Сегодня я поделюсь тремя историями из жизни нашей команды: расскажу, как мы искали решения и какие выводы сделали. На мой взгляд, пост может оказаться полезен и разработчикам, и QA-инженерам, и системным администраторам, и тимлидам/техлидам. Эта статья основана на моем докладе с онлайн-конференции TechLead Conf 2020. Если вам приятнее смотреть видео, оно доступно на YouTube.  Мы в ManyChat обрабатываем больше 2 миллиардов событий в сутки. При таких объемах неизбежны различные ошибки — при выполнении кода, на различных корнер-кейсах, при взаимодействии со сторонними сервисами. При этом, мы — стартап и работаем в парадигме небольших продуктовых кросс-функциональных команд. У нас нет выделенных платформенных команд или отдела тестирования. Чтобы следить за качеством продукта и корректностью работы всех сервисов, мы решили вести следующие виды мониторинга:
Чтобы работать было удобно — мы настраиваем нотификации в отдельные каналы в Slack. Так удается получить максимальный охват аудитории. Но когда мониторинги настроены и нотификации сыпятся безостановочно, возникает потребность в процессах. Для того, чтобы проанализировать ситуацию, понять причину ее возникновения и устранить ошибку нужны люди, практики, которые регламентируют работу специалистов. Некоторые компании решают подобные проблемы силами DevOps-инженеров. Для нас же DevOps – это не роль, а идеология о разработке и доставке качественного программного обеспечения. Поэтому в нашей компании в процесс реагирования на мониторинг вовлечен каждый инженер. А на примере следующих историй станет понятно, как это работает. Первая история. Чиним баги В саппорт прилетел тикет, о том, что у пользователя что-то не работает. Ребята из саппорта проверили и подтвердили, что у пользователя наблюдается баг, связанный с редким корнеркейсом, который не учли при разработке. На общих метриках мы этого не видим, так как проблема не массовая, но пользователя в беде бросать не хотим, да и проблему исправить нужно, чтобы в будущем никто с ней не столкнулся. Есть два пути решения проблемы:
Если мы положим баг в бэклог, то его исправление может попасть в следующий спринт, а может и не попасть. В худшем случае проблема несчастного пользователя может проваляться в бэклоге очень долго. А если этот баг блокирует пользовательский сценарий, то мы можем потерять клиента. Поэтому хотелось бы фиксить здесь и сейчас. Возникает задача — передать баг из саппорта в разработку? Если подойти к рандомному разработчику с просьбой посмотреть и пофиксить баг, скорее всего вы услышите от него душещипательную историю о том, что у него сейчас самая важная задача в спринте, цель спринта под угрозой и он никак не может отвлечься именно сейчас. И это будет справедливо. Однако в фреймворке LeSS (по которому мы работаем) существует такая практика, как Stop and Fix (S'n'F) команда, которую мы применили в своей работе. Это “черная метка”, которая переходит от команды к команде каждый спринт. S'n'F команда не берет в спринт продуктовые задачи, ее цель — взаимодействовать с командой саппорта, работать над багами, которые приходят от пользователей. В процессе S'n'F задействована вся кросс-функциональная команда. В нее входят не только разработчики, но и дизайнеры, даже менеджеры продукта. Ведь баги бывают не только в коде, но и в UX, и на продуктовом уровне. Еще один плюс в том, что эта практика позволяет разработчикам S'n'F команды погружаться в кодовую базу незнакомых ранее компонентов, которых они не касались в ходе работы над своими спринтами. В результате участники команды неизбежно расширяют свою экспертизу в работе всей системы. А наличие свободного ресурса позволяет ребятам из S'n'F работать не только с пользовательскими багами, но и следить за алармами с мониторингов, и реагировать на них. Такой подход позволил нам реагировать на любые баги, не прерывая спринтов и не откладывая важные вещи в долгий ящик (бэклог). Вторая история. Снижаем уровень шума Два года назад мы разрабатывали сложную фичу, которая давала широкие возможности настройки автоматизации нашим пользователям. Event-based система мониторит любое изменение состояния подписчиков в системе, и при заданных триггерах запускает нужную автоматизацию. Все это работает в реальном времени и на аудитории в 500+ миллионов подписчиков. Фича могла негативно сказаться на производительности нашей инфраструктуры, и мы начали выкатывать ее постепенно, следя за основными метриками системы. На первом этапе раскатали фичу на пару десятков наших самых лояльных пользователей, чтобы они её протестировали и дали фидбек. Мы настроили метрики на вылавливание ошибок процессинга событий и изменения контекста, а также на факты успешного процессинга бизнес логики. Алармы были настроены только на ошибки, так как у нас еще не было какого-то baseline, относительно которого можно настраивать уведомления об успешной реализации. Через пару дней пришло сообщение об ошибке. Мы сразу же отловили мелкий баг, и быстро выпустили исправление. Дело было в субботу утром (вы уже догадались, что веселье началось именно в этот момент?). Конечно же перед тем, как выкладывать исправление в продакшен, я протестировал фикс на стейджинге. Все было ок. Выкатили фикс в продакшен, мониторинг сказал, что ошибки процессинга больше не стреляют, и мы пошли наслаждаться выходными. В понедельник мы поняли, что наша фича совсем перестала работать. Благо пользователи этого не заметили, так как фича была на очень раннем этапе раскатки, и на неё еще никто толком не полагался. Мы разобрали эту ситуацию внутри команды и проанализировали наши ошибки. Мы осознанно не настроили алармы на отсутствие успешного процессинга, так как фича была на ранней стадии раскатки и мы бы получили большое количество ложных срабатываний. Небольшие различия в сериализации данных на стейджинге и в продакшн-среде привели к тому, что данные перестали доходить до компонента. А отсутствие процессинга привело и к отсутствию ошибок — все логично. Но ошибка все-таки присутствовала на этапе сериализации, и мы должны были отловить её через инструмент мониторинга runtime ошибок. Они там действительно были, но почему-то никто не отреагировал, даже не смотря на нотификацию в slack-канале. Разгадка оказалась банальной: в этот канал начало сыпаться слишком много нотификаций, в результате чего сообщение просто затерялось. Увы, когда продукт становится достаточно сложным и нагруженным, в рантайме может происходить много чего: интеграция с внешними сервисами может сбоить, происходить некорректная обработка исключений, какие-то мелкие ошибки и кейсы могут тоже попадать в систему мониторинга. В какой-то момент у нас накопилось достаточно большое количество мелких вещей, которые никак не сказывались на производительности и корректности работы системы, но создавали очень много шума в канале нотификаций, среди которого терялись реальные ошибки, на которые нужно было реагировать. С этим нужно было что-то делать… Эксперимент раз Мы договариваемся о том, что команды разгребают ошибки в runtime в оставшееся время от основных задач в спринте.  Проходит пара спринтов, смотрим на динамику — а ее нет! Количество ошибок/нотификаций остается примерно на том же уровне шума. У каждой команды свой спринт, фичи горят, нет времени заниматься ошибками. Становится понятно, что в рамках привычного workflow мы эту проблему не решим. Эксперимент два Вспоминаем, что у нас есть S'n'F команда и передаем всё это в их зону ответственности!  Через несколько спринтов видим, что количество ошибок/нотификаций не растет, но и не падает. S'n'F команда в ходе своей работы успевает разбирать новые ошибки и нотификации, но старыми заниматься времени нет. Эксперимент три Пятничный вечерний хакатон с пивом и пиццей. Проводим два хакатона среди добровольцев. Почти вся команда принимает в них участие, ребята воодушевлены. Две пятницы подряд мы с командой по вечерам в веселой неформальной обстановке фиксим мелкие ошибки.  Результаты есть! Мы несколько снизили уровень шума, но только процентов на 10-15. Формат решения проблемы интересный и прикольный, но как разовая акция. Занимать у команды каждый пятничный вечер мы не можем и не хотим по объективным причинам — весь fun от такого формата со временем перейдет в рутину. Эксперимент четыре Нам нужна команда, которая сможет победить этот процесс. Так как мы чиним ошибки в нашем коде, нам нужны только разработчики, а точнее — бэкендеры, и вся команда должна состоять из таких людей. Мы пробуем собрать команду из 2-3 разработчиков. Но свободных разработчиков у нас нет, они все в кросс-функциональных командах. Появляется идея — сделать временные команды, которые занимаются этим не дольше, чем один спринт. Не хорошо надолго в рутинные задачи загонять людей, да и не хочется выключать на длительное время ребят из продуктовой разработки. Мы стали пересобирать эту команду из добровольцев каждый спринт, пока не пропала такая необходимость. В этом формате мы проработали три недельных спринта, трижды пересобрав команду.  В результате удалось снизить уровень шума до приемлемого для нас значения, а также решить некоторые вещи, связанные с тех-долгом, до которых у нас раньше не добирались руки. Это успех! Разобрав весь лишний шум в системе мониторинга, мы вернулись к формату эксперимента №2 — команда S'n'F может справиться с текущим потоком нотификаций, разгребая их по мере поступления.  Третья история. Подключаем саппорт Еще одна история появилась потому, что мы работаем на международном рынке, и пользователи из разных стран запускают свои рекламные кампании круглосуточно. Они тратят свои деньги и мы должны оперативно реагировать на любые инциденты в любое время суток. Но S'n'F — это обычная кросс-функциональная команда, которая работает в том же режиме, что и остальные команды, просто над иным типом задач. Однажды ночью партнерский сервис выкатил обновление, которое сломало обратную совместимость. Да, факапы бывают не только у нас, но и у них! Это была критичная для нашего сервиса функциональность, на проблему нужно было отреагировать “здесь и сейчас”. Естественно, в это время все благополучно спали, уведомление не было замечено своевременно, и мы отреагировали на инцидент только через час. Провели анализ. Поняли, что это неприемлемо. Что же делать? Ночные смены для S'n'F команд — это перебор, с учетом того, что подобные инциденты бывают достаточно редко. Было решено отдать эти вопросы команде саппорта, которая взаимодействует с S'n'F и работает в режиме 24/7. Мы добавили ребят в канал с нотификациями об алармах и создали протокол реагирования на алармы. Для этого была введена стандартная градация инцидентов: Critical, Error и Warning. Critical — Вася, мы горим! Беги за пожарными! Саппорт должен в течение 5 минут связаться с дежурным разработчиком из S'n'F команды или с кем-то другим, если дежурный недоступен. Дежурных команда выбирает самостоятельно. Дежурному достаточно не выключать телефон на ночь, и отреагировать на звонок, чтобы в случае чего инициировать тушение пожара. Не исключено, что в случае большого пожара потребуется не только S'n'F команда, но и подмога. Error — Количество ошибок выросло, но это не так критично. Однако, если такое уведомление не отстрелило обратно в течение 30 минут, нужно связываться с дежурным. Warning — Что-то происходит, но в целом мы можем подождать до утра. Итоги Возможно, эти истории многим покажутся знакомыми. Они показывают, что инструменты не работают без людей и процессов вокруг них. Мы должны постоянно улучшать практики, искать слабые места, экспериментировать с подходами к решению проблем. Если не сработала одна тактика — нужно попробовать другую! В следующем посте я расскажу подробнее о самих инструментах мониторинга — как они работают, как мы их настраивали, какие встретили нюансы с технической стороны. Так что подписывайтесь на блог ManyChat, если эта тема вам интересна. Буду рад прочитать в комментариях ваши истории и решения, ведь всем нам намного дешевле учиться на чужих ошибках! =========== Источник: habr.com =========== Похожие новости:
Блог компании Конференции Олега Бунина (Онтико) ), #_blog_kompanii_manychat ( Блог компании ManyChat ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:09
Часовой пояс: UTC + 5