Вебинар 22 апреля «Токсичные клиенты: навыки эффективной работы без выгорания и потери отношений»

Фатальная ошибка мандриЛла:
история сбоя 4-5 февраля 2019

Лицо, принимающее решения в Юздеске
Сергей Будяков
В понедельник утром в мониторинге появился алерт о том, что уже несколько минут в таблице новых тикетов не появляются новые письма. Иногда такие алерты приходят ночью, когда активность клиентов наших клиентов не очень высокая. Утренний алерт показался странным, потом пришел еще один, и стало понятно, что что-то случилось.

У Юздеска есть две схемы подключения почты: пересылка и подключение по IMAP. Со вторым методом все понятно: мы напрямую забираем все новые непрочитанные письма из подключенных ящиков. Первый — пересылка — нужен, когда по какой-то причине подключиться к ящику напрямую нельзя: политика безопасности, недоступность почтового сервера извне, специфический протокол и т.д.

Для сбора почты по пересылке мы используем внешний сервис — Mandrill. Эта платформа является техническим бэкендом MailChimp, одного из крупнейших мировых сервисов почтовых рассылок. Стабильность Mandrill всегда была на уровне 99.99% (много девяток). Небольшие сбои чинились за пару минут, и все сообщения за периоды простоя приходили в течение нескольких следующих минут.

Время этого сбоя совпало с поздней ночью в офисе Mandrill в Атланте. Каково же было наше, а позднее — не только наше удивление, что ни саппорт, ни девопсы компании не проснулись. О проблеме им стало известно только утром в начале их рабочего дня, о чем свидетельствует твиттер-аккаунт.

Поддержка действовала крайне непрофессионально: обновления публиковались раз в несколько часов и не содержали деталей происходящего. Сравните с ответом их же коллеги из Mailchimp. Кто-то в комментариях спрашивал фотографию команды девопсов, которые ночью разбираются в проблеме. Фотография не последовала.
скрин твиттера
скрин твиттера
Ситуация в Mandrill нормализовалась только спустя почти трое суток. Мы столько ждать не могли. Проблемы с нашими внутренними схемами и технологическими провайдерами не должны волновать наших клиентов.

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

Почтовые сервера в интернете работают через специальные MX-записи в DNS доменных имен. DNS указывает вашему браузеру, к какому серверу пойти, когда вы пишете тот или иной URL в адресной строке или кликаете на результаты поиска в Гугле. MX-запись указывает на сервера, которые должны получить письмо, отправленное на какой-либо адрес на каком-либо домене. Письма на @usedesk.ru приходят на адреса Яндекс.Почты, а письма на @inbound.usedesk.ru указывали на Mandrill, который возвращал их нам — так и работала пересылка. Особенность заключается в том, что для одного домена может быть только один провайдер, и запустить частичную резервную схему с тем же самым доменом невозможно.

Спустя день стало понятно, что ничего хорошего в ближайшее время ждать не стоит — и мы начали работать над подключением альтернативного провайдера. Мы не делали этого раньше, потому что Mandrill довольно плотно сидит в архитектуре Юздеска и смена провайдера в нормальном режиме заняла бы пару недель разработки. Но режим не был нормальным. В общей сложности разработчикам понадобилось 10 часов на интеграцию нового провайдера, тестирование и доставку до всех продакшен-серверов. Все другие задачи были отложены.

К концу вторника 5 февраля мы переключили провайдера, поправили ошибки, пойманные уже в продакшене, и первый раз за 2 дня пошли спать. Теперь мы можем переключаться между почтовыми провайдерами в течение 5 минут, даже во сне.
Вместо заключения
P.S. Если вы не были клиентом Юздеска в эти дни, то можете посмотреть в телеграм канале подробный таймлайн ситуации и ее решения. Я не могу обещать, что у нас больше никогда не случится подобного сбоя, но могу обещать максимально быструю реакцию и честный подробный рассказ о происходящем, без сокрытия инцидентов со стороны нашей команды.

Приношу извинения всем нашим клиентам, которые столкнулись со сложностям в обслуживании своих клиентов.
P.S.S. Прочитать, что в итоге случилось у ребят, можно в их письме. Что-то там с Postgres базой данных и уход в read-only mode.
Поделиться с коллегами:
Поделиться с коллегами:
Оцените пожалуйста нашу статью
Знаем, что такое клиентский сервис
Раз в две недели будем присылать интересное и полезные материалы про клиентский сервис – выпуски подкаста, кейсы и обновления системы. Вы не против?
Практические советы о клиентском сервисе, которые работают.
Мы написали книгу!