Баги, которые нас воспитали: инженерные истории с Go Loto

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

На нашем мероприятии Avito Go Loto разработчики поделились своим опытом без прикрас. О блоате в полтора терабайта, о девяти инстансах, которые передрались за один звонок, о бэкенд-разработчице, которая в пятницу вечером открыла чужой фронтовый проект, о нагрузочных тестах за несколько месяцев до большой рекламной кампании, и о транзакции, которую забыли закоммитить тоже в пятницу вечером.

Спойлер: все выжили. Но стали другими людьми.

Так вышло, что в зону ответственности нашей команды попал легаси-сервис, отвечающий за все логистические данные Авито Доставки. В стареньком Postgres накопилось два терабайта данных, и эта цифра стремительно росла.

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

Спустя некоторое время девяточность основного сервиса падает с 9999 до 999 и не собирается восстанавливаться. Почему — непонятно. Руководство поглядывает с явным осуждением, а цель по стабильности сервисов висит на волоске.

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

Команда стала искать решение. Самое очевидное с ходу не подошло: объём базы в два терабайта, ограниченное дисковое пространство и недопустимость длительной монопольной блокировки не позволили нам запустить VACUUM FULL или воспользоваться pg_repack. Пользователи не оценили бы, выключи мы на вечерок Авито Доставку.

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

1. Создаём новые таблицы
2. Медленно — чтобы не уронить девяточность ещё сильнее — переливаем туда содержимое исходных табличек
3. Переключаем запросы сервиса на новые таблички
4. Дропаем старые
5. Спустя несколько бессонных ночей — чистая база и вернувшаяся девяточность

Прошло полгода. Наш легаси-сервис держит стабильные 9999 и чувствует себя отлично. А мы регулярно посматриваем на метрики блоата и не планируем наступать на эти грабли вновь.

Выводы? Во-первых, массовые DELETE и UPDATE в Postgres оставляют мусор, за этим нужно следить. Во-вторых, никогда не стесняйтесь обращаться за помощью к более опытным коллегам: вместе мы можем больше.

Мне однажды дали починить сервис звонилки. Довольно древний кусок системы: слушал события из виртуальной АТС и пытался понять, на каком этапе находится звонок. Код представлял собой занятную комбинацию технологий: PHP, Redis и собственная реализация RabbitMQ — тоже на Redis и на PHP. Вся эта конструкция жила своей жизнью и временами начинала вести себя странно.

Стало понятно, что вносить изменения в существующую систему будет невероятно дорого. Код запутанный, логика размазана по нескольким слоям, любое изменение рискует сломать что-то ещё. Поэтому я принял классическое инженерное решение — переписать сервис как отдельный микросервис на Go.

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

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

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

До меня дошло. Этот сервис, в отличие от большинства, не принимал входящие запросы — он сам подключался к Asterisk и слушал поток событий. А прод у нас развёрнут в нескольких датацентрах и запускается в нескольких подах. После деплоя у меня оказалось девять инстансов сервиса, и каждый из них подключился к Asterisk и начал слушать.

Asterisk рассылает события всем подключённым клиентам в режиме fan-out. Это значит, что все девять сервисов одновременно получали один и тот же поток и каждый независимо пытался определить состояние звонка. Классический race condition: несколько инстансов параллельно обновляли состояние одного звонка, интерпретируя одни и те же события, но с разными временными задержками.

Решение оказалось простым. У каждого звонка есть уникальный идентификатор — мы использовали его хэш для распределения обработки между подами. События конкретного звонка теперь всегда попадают в один и тот же инстанс, и только он обновляет его состояние. Sticky-маршрутизация — и система внезапно заработала идеально.

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

Я запускала интеграцию с сервисом модерации. Мы всё красиво спроектировали: API работает, статусы летают, логи пишутся — бэкенд счастлив. Команда посмотрела, всем нравится. Я уже мысленно ставлю галочку «сделано» и начинаю думать о следующей задаче.

И вот наступает пятница — презентация для модераторов.

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

В 18:30 в пятницу я узнаю, что мне нужно немного «подправить фронт». Напомню: я бэкенд-разработчик.

Дальше всё как в тумане. С одной стороны — документация, с другой — Google и где-то рядом ещё AI. Я открываю фронтовый проект, смотрю на него как археолог на древние письмена и думаю: «Ну, наверное, это кнопка…».

В какой-то момент я поймала себя на мысли: удивительно, как быстро переходишь от «это не моя зона ответственности» к «так, ладно, сейчас разберёмся».

В итоге всё поправили, согласовали с модераторами и запустились без боли.

Выводы я сделала для себя такие. Чем раньше показываешь фичу реальным пользователям — тем меньше шансов провести пятничный вечер в компании чужого фреймворка. Граница между «фронтом» и «бэком» в критический момент становится очень условной: есть только одна настоящая роль — человек, который доводит фичу до результата. И, наверное, самое важное: иногда самый полезный инженерный навык — это не знание конкретного стека, а готовность зайти на незнакомую территорию и сказать: «Окей, сейчас разберёмся».

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

Жили спокойно пару месяцев. И вот однажды продакт приходит с новостью: планируется рекламная кампания для нашей фичи. На много-много миллионов. Реклама в метро, на билбордах, на ТВ. Вместе с новостью — логичный вопрос: «А выдержат ли сервисы рост нагрузки в несколько раз?»

Я понимаю: регулярных проблем нет, графики рисуют 200, в 999-м персентиле, всё отлично по NFR, в таймауты укладываемся, алерты не стреляют. Первое, что хотелось сказать: конечно не сломается, у нас всё четенько, работает как часы. Но что-то подсказывало, что не может быть всё настолько идеально. Я взял пару дней на аудит.

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

• Алерты — устаревшие и базовые: смотрят на статусы ответов и на метрики, некоторые из которых уже не пишутся.
• Логи — без контекста, по которым сложно исследовать проблемы.
• Мониторинг — неактуальный: пустые графики по фичам, которых уже нет, новые чувствительные части не добавлены.
• В беклоге висят баги разной критичности, которые постоянно сдвигаются.
• Тестовое покрытие оставляет желать лучшего.

И ещё мы решили провести нагрузочное тестирование. В системе такого никогда не делали, это отняло около недели — зато мы получили важный инсайт. Наша система имела запас прочности ×2: после этого сервисы начинали деградировать, не укладывались в таймауты, пользовательские сценарии ломались. А нагрузка во время кампании должна была вырасти в три-пять раз. Хьюстон, у нас проблемы.

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

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

Павел успел затормозить перед обрывом. И аудит, и нагрузочные тесты, и разговор с продактом требуют времени и определённой смелости признать, что «работает как часы» и «готово к ×5 нагрузке» — разные вещи.

Последняя история — про ситуацию, когда времени нет совсем. Команда ждёт, пятница вечер, ноутбук вот-вот закроется.

Мой кейс, возможно, не самый драматичный. Я не успел накопить так уж много косяков за всю карьеру. А если вы где-то работали со мной и знаете о них — это было давно и вообще неправда.

Мы в команде решили собраться в офисе и потом вместе куда-то сходить — устали сидеть по домам, захотели тимбилдинга. Расписали поминутно, кто куда и во сколько. И параллельно на нас висела задача: добавить обработку события из очереди, которое должно было инициировать одну бизнес-логику. Как это всегда бывает, задача дотянула до вечера пятницы и свалилась на мои плечи.

Время подходит к семи вечера. Я заканчиваю тестировать и ловить осуждающие взгляды команды, которая уже забрала куртки и смотрит в мой затылок. Начинаю торопиться — не хочу заставлять всех ждать. По-быстрому закидываю PR, ловлю апрувы, раскатываю сервис. Ноутбук закрывается, и мы отправляемся смотреть на красоты Москвы сквозь кальянный туман.

Но прошедший запуск не давал мне покоя и зашел посмотреть метрики. И увидел, что за последний час число обработанных событий стоит на нуле. Сервис был не очень нагруженный — вполне могло быть, что за пару часов ничего не пришло. Но с каждым обновлением графика я всё больше пугался надписи «no data» в Grafana.

Решил проверить. Начал изучать PR — и нашёл огромную ошибку. Пока тестировал, чтобы не зааффектить тестовые данные, написал:

// tx.Commit()

tx.Rollback()

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

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

Выводы максимально просты: не торопитесь при релизе фичей. И почаще смотрите метрики.

Если смотреть на эти истории вместе, в них есть кое-что общее — и это не невнимательность и не недостаток опыта. Просто каждый из нас работает с моделью системы у себя в голове, и в какой-то момент эта модель расходится с реальностью. База данных ведёт себя иначе, когда в ней терабайт мёртвых строк. Сервис ведёт себя иначе, когда его запускают в девяти копиях. Фича выглядит иначе, когда на неё смотрит человек, который будет с ней работать каждый день. Система выглядит иначе, когда на неё приходит в пять раз больше запросов, чем обычно. Код выглядит иначе, когда на тебя смотрит команда с куртками в руках.

Хорошая новость в том, что у каждой из этих историй счастливый конец. И почти в каждой из них помог кто-то другой: бородатый инженер из Нижнего, который сразу понял про блоат; продакт, которому Павел честно объяснил риски вместо того, чтобы сказать «всё нормально»; логи, которые Михаил догадался сделать подробными с первого запуска.