В поисках эффективности: дебажим на проде

Шел третий день после переключения АПИ, к проведению которого мой проект не был готов. Где-то в 9 вечера в среду, вместо того, чтобы отдохнуть, размять мышцы после целого дня у монитора, я словил себя на мысли, что я дебажу проект на проде и без тестов. И вот как я из этой ситуации выбирался.

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

В чем соль?

Давайте я погружу для начала вас в контекст проекта. Все имена и названия будут изменены. Начнем с того, что я с нуля разработал проект на питоне, который работает на проде и отгружает в бэкэнд сайта данные о товарах в key-value хранилище. А бэкэнд показывает эти рекоммендованые товары из key-value клиентам сайта. Поломка в таком загрузчике ведет к тому, что посетители сайта вместо результатов поиска и рекомендаций будут видеть пустую страницу. От этого, скорее всего, они захейтят магазин и уйдут к конкурентам.

А он че?

В этот момент на сцену выхожу я. Для меня проект загрузчика был первым полноценным сервисом, который я разработал с нуля и запустил на проде спустя 3-4 года опыта работы. Да, было неприятно признаться себе в этом. Хочется представлять себя успешным money-мейкером, который в условиях кризиса поднимает проект с колен умным однострочником и делает за пару месяцев иксы по доходам для всей компании.

А они че?

Как-то в понедельник, когда я вернулся после отпуска свежим, заряженным и отдохнувшим, с чашечкой кофе на столе, узнаю про отключение текущего HTTP-АПИ для отгрузки данных в key-value хранилище.

Первая попытка починить все

А это значит, что данные на проде не обновляются. Я сразу упал на измену, перепугался и засуетился: "Как же, как же!? Сейчас прод поломается, у клиентов на сайте исчезнет контент и мой проект, т.е. я буду в этом виноват. Нужно что-то срочно делать!". Дело в том, что у меня в первый же день аварии был рабочий код нового HTTP-АПИ, но мне потребовалось более недели, чтобы во всем разобраться, успокоить нервы и трезво решить проблему.

Во-первых, мне не хватило терпения полностью прочитать структуру и доку апи, который мне передали. Слишком сильно хотелось побыстрому запустить код и проверить его работу. За часик накидал новый код, HTTP-прокси вернул дежурный OK и на этом я успокоился. Проект починен.

Вторая попытка починить все

После этого оказалось, что последовательные http-запросы работают в 10 раз медленнее, чем работал проект до аварии. А это значит, что данные фактически не доезжают для половины клиентов. Пишу сокеты для нового АПИ. Работает.

Третья попытка починить все

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

Неделю спустя

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

А теперь внимание: все работы я проводил прямо в папке проекта, который каждые 10 минут перегружает данные в прод. Это точно не добавляло комфорта и надежности в процесс обновления проекта.

И что с этим делать?

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

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

В следующей части блога я планирую рассказать о том, как я настроил процессы надежности и качества кода в моем проекте