Каждый разработчик помнит тот самый момент, когда система, которая только что работала идеально, вдруг начинает вести себя так, будто сошла с ума. Когда дашборд в Grafana показывает что-то страшное, а ты стоишь перед ним с кружкой остывшего кофе и не понимаешь, с чего начать.
На нашем мероприятии Avito Go Loto разработчики поделились своим опытом без прикрас. О блоате в полтора терабайта, о девяти инстансах, которые передрались за один звонок, о бэкенд-разработчице, которая в пятницу вечером открыла чужой фронтовый проект, о нагрузочных тестах за несколько месяцев до большой рекламной кампании, и о транзакции, которую забыли закоммитить тоже в пятницу вечером.
Спойлер: все выжили. Но стали другими людьми.
«Мы были героями до первого алерта»
Борис Голдовский
Тимлид в команде Авито Доставки
Так вышло, что в зону ответственности нашей команды попал легаси-сервис, отвечающий за все логистические данные Авито Доставки. В стареньком Postgres накопилось два терабайта данных, и эта цифра стремительно росла.
Нам показалось классной идеей сделать архивацию: поднять отдельный сервис с шардированной базой и переложить туда все заказы старше полугода. Сказано — сделано: воркеры шуршат ночами, заполняя холодное хранилище, мы гордимся решением.
Спустя некоторое время девяточность основного сервиса падает с 9999 до 999 и не собирается восстанавливаться. Почему — непонятно. Руководство поглядывает с явным осуждением, а цель по стабильности сервисов висит на волоске.
Так мы познакомились с блоатом. Для тех, кто не знает: блоат — это раздувание таблиц и индексов из-за мёртвых строк, которые нагенерили запросы UPDATE и DELETE. Сотни гигабайт пустоты, замедляющих чтение, которые нагенерили наши ночные воркеры.
Команда стала искать решение. Самое очевидное с ходу не подошло: объём базы в два терабайта, ограниченное дисковое пространство и недопустимость длительной монопольной блокировки не позволили нам запустить VACUUM FULL или воспользоваться pg_repack. Пользователи не оценили бы, выключи мы на вечерок Авито Доставку.
В ход пошёл внутренний нетворкинг — спрашивали у коллег, кто сталкивался с подобным и как решал. Выручил коллега из нижегородского офиса — один из тех людей, к которым идут, когда гугл уже не помогает. Он разложил проблему по полочкам и накидал план, как почистить блоат аккуратно, не уронив сервис окончательно. Это базовый вариант решения, но вполне рабочий:
Создаём новые таблицы
Медленно — чтобы не уронить девяточность ещё сильнее — переливаем туда содержимое исходных табличек
Переключаем запросы сервиса на новые таблички
Дропаем старые
Спустя несколько бессонных ночей — чистая база и вернувшаяся девяточность
Прошло полгода. Наш легаси-сервис держит стабильные 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()
Естественно, события обрабатывались, все действия в транзакциях выполнялись — и затем просто отменялись.
Пришлось собирать события из логов — благо, для первого запуска сделали подробные — и руками прогонять их по всем этапам.
Выводы максимально просты: не торопитесь при релизе фичей. И почаще смотрите метрики.
Заключение
Если смотреть на эти истории вместе, в них есть кое-что общее — и это не невнимательность и не недостаток опыта. Просто каждый из нас работает с моделью системы у себя в голове, и в какой-то момент эта модель расходится с реальностью. База данных ведёт себя иначе, когда в ней терабайт мёртвых строк. Сервис ведёт себя иначе, когда его запускают в девяти копиях. Фича выглядит иначе, когда на неё смотрит человек, который будет с ней работать каждый день. Система выглядит иначе, когда на неё приходит в пять раз больше запросов, чем обычно. Код выглядит иначе, когда на тебя смотрит команда с куртками в руках.
Хорошая новость в том, что у каждой из этих историй счастливый конец. И почти в каждой из них помог кто-то другой: бородатый инженер из Нижнего, который сразу понял про блоат; продакт, которому Павел честно объяснил риски вместо того, чтобы сказать «всё нормально»; логи, которые Михаил догадался сделать подробными с первого запуска.
Наверное, в этом и есть главный вывод: не в том, что нужно знать про блоат или про fan-out в Asterisk — это придёт с опытом. А в том, чтобы вовремя остановиться и спросить себя: а не расходится ли моя модель с реальностью? И если есть человек рядом, который знает больше — спросить его.
А у вас были похожие истории — про модель в голове, которая разошлась с реальностью? Расскажите в комментариях.