Опыт Ситимобил: как мы повышали стабильность сервиса, который вырос в 15 раз

Быстрый рост сервиса — это не только больше прибыли и довольные инвесторы, но и испытание для технарей.

Директор по информационным технологиям Mail.ru Group Денис Аникин рассказывает, как за шесть месяцев в Ситимобил увеличили стабильность, изменив процессы разработки и автоматизации.

В 2018 году Ситимобил по количеству поездок вырос более чем в 15 раз. Когда сервис растет так быстро, вероятность сбоев в работе увеличивается. Во-первых потому, что повышается нагрузка на серверы: в нашем случае она взлетела в 100 раз. Во-вторых, становится больше функций — мы, например, стали релизиться в шесть раз чаще, — а это значит больше кода и выше вероятность ошибок.

Перед нами встала задача сделать так, чтобы рост бизнеса не снижал стабильность сервиса: чтобы клиент всегда мог вызвать такси, а водитель — принять заказ. В этой статье я расскажу, какие шаги мы для этого предприняли.

Прежде всего нужно было установить измеримые критерии успеха: определить, как мы поймем, что стабильность повысилась.

Я советую выбирать критерии, которые соотносятся с бизнес-целями вашего продукта. Для Ситимобил важнейший параметр — количество успешно совершенных поездок: именно по нему нас оценивают инвесторы.

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

Итак, мы поставили цель минимизировать число потерянных поездок. Теперь нужно было провести анализ: что приводит к потере поездок и как этого можно избежать. Для этого мы начали журналировать все отказы в обслуживании сервиса, которые привели к потери поездок. Мы завели таблицу, куда заносили:

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

В ходе разбора аварий мы поняли важную вещь: нельзя использовать словосочетание «человеческий фактор». Как только вы это произнесли, все расслабляются: ничего делать не надо, выводы не нужны, люди ведь ошибались, ошибаются и будут ошибаться.

Вместо произнесения этого словосочетания надо делать конкретный вывод. Вывод — это маленький, но шажок в изменении процесса, улучшении мониторинга, автоматических инструментов. Из таких шажков шьется ткань стабильного сервиса.

Когда данных набралось достаточно, мы смогли классифицировать сбои и выработать алгоритмы для каждого случая.

Ошибки сервера после релиза. Отказ в обслуживании проходит через два состояния: пассивная стадия, когда мы еще не знаем про отказ (у нас простой в среднем составлял 20-25 минут), и активная, когда мы уже в курсе (около 15 минут). В сумме две стадии давали около 40 минут простоя. В течение всех этих 40 минут мы теряли поездки.

Что делать. Во-первых, нужно держать руку на пульсе. Мы сделали SMS-алерты о превышении порогового количества 500-х (internal server error) ошибок. Эти алерты помогали нам быстрее узнавать об отказе, что сократило пассивную стадию с 25 до 3 минут.

Потом мы ввели правило: разработчик выкатывает код и в течение трех минут следит за мониторингом. Если есть 500-е ошибки — значит, проблемы с его кодом, ему и разбираться. Так мы уменьшили пассивную стадию до минуты (разработчик часто замечал проблему по графикам быстрее, чем приходила SMS).

У этого решения был приятный побочный эффект: активная стадия тоже сократилась — с 15 до 5 минут. Поскольку разработчик встречает проблему в тонусе, он и готов сразу откатить свой код и тратит на это в три раза меньше времени.

Во-вторых, важно быстро локализовать причину ошибки. Для этого нужно избежать параллельных релизов, которые затрудняют разбирательство. Мы установили еще одно правило: перед релизом разработчик пишет в чат, что и для чего выкатывает, а в случае аварии сигналит: «Авария, не катите!». Это позволило сократить активную стадию с 5 до 3 минут.

Потом мы автоматизировали этот процесс: после каждого релиза CI/CD-система в течение 5 минут запрещает релизить всем, кроме автора последнего релиза (чтобы у него была возможность править ошибки). Также система не дает релизить, если обнаружена авария. Автоматизация позволила сократить активную стадию до минуты. Средняя длительность аварий (активная + пассивная стадия) упала с 40 до 2 минут.

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

В итоге длительность аварий, вызванных ошибками в релизе, упала до нуля.

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

Что делать. Вводить обязательную проверку кода на оптимальность. Ее проводит наш спецназ — самые опытные разработчики.

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

Что делать. Настраивать SMS-алерты на все уже свершившиеся аварии — они поднимают планку качества сервиса и позволяют далее в спокойном ритме повышать надежность.

Очень важно после каждой аварий делать выводы, не скатываться в комфортную ситуацию «увидели проблему, починили и забыли».

Мина замедленного действия в коде. Ошибка, которая существует уже давно, но дала о себе знать только сейчас.

Что делать. Искать старые мины и не допускать появления новых. Поиск у нас сопряжен с постоянной оптимизацией кода.

Внешние причины. У подрядчика ломается эквайринг, геосервисы, датацентр и т. д.

Что делать. Собирать статистику по таким авариям и ждать накопления критической массы. Если накопится — менять подрядчика. Пока не накопилась, проводить post-mortem-анализ каждого падения и искать способы сделать так, чтобы все работало при недоступном внешнем сервисе.

Плохой релиз, сломанная функциональность. Единственный вид отказов, который нельзя выявить ни по каким симптомам, кроме жалоб пользователей/бизнеса.

Что делать. Всеми силами сводить этот вид отказа к категории «Ошибки сервера после релиза».

Идеально, чтобы баги в коде сохранялись в лог в виде ошибки или хотя бы оставляли следы в базе данных. По этим следам можно понимать, что случился баг, и тут же алертить. Чтобы этому поспособствовать, мы начали разбирать каждый крупный баг и находить решения, какой мониторинг/ SMS-алертинг можно сделать, чтобы этот баг проявлял себя так же, как 500-я ошибка. Для сокращения активной стадии аварии этого типа мы сделали автооткат на предыдущий релиз по некоторым видам алертинга.

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

Мы завели файл с dos & don’ts, куда записываем выводы на тему разработки. Файл показываем всем новичкам. Каждый раз, когда файл дополняется, постим его в общем чате разработчиков и просим всех прочесть еще раз.

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

Степень автоматизации процесса росла: мы решили сделать веб-интерфейс, в котором отображается состояние процесса выкатки, а также доступна возможность сабмитить отчеты об авариях, апрувить и отклонять их, смотреть аналитику по авариям и выводам из них.

Этот веб-интерфейс мы назвали «Котан» — от слова «катить». В нем есть список инцидентов, справочник типов инцидентов, отчеты с выводами.

Если вы собираетесь увеличить стабильность сервиса, решения об изменениях должны приниматься не умозрительно, а на основе опыта, фактов и цифр.

Процесс должен строиться не по директиве сверху, а с участием всех заинтересованных членов команды: тогда при отступлении от процесса сотрудники будут поправлять друг друга.

Все, что можно автоматизировать, нужно автоматизировать. Отдайте контрольные функции машине — человек постоянно ошибается.

Успехов вашему бизнесу и поменьше потерянных заказов, транзакций, покупок, поездок и всего, что для вас критично!