Байки погромиста. Если кто-то скажет, что программирование — это скучно

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

Попросил меня как-то клиент отладить его скрипт. Говорит, не работает. Невероятно!

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

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

Смотрим в содержимое функции. Как и положено, это полотно кода на пару экранов, сходу так и не поймёшь, что она делает. Повсюду return что-то там, ветвления всякие итд. То глупое чувство, когда клиент тебя ждёт, а ты ничо не понимаешь и косплеишь рыбу.

Осложнялось всё тем, что отлаживать через клиента — ну такое. Он может запустить скрипт, но вот отладчик для него - страшное слово, и максимум, на что можно рассчитывать — это поставить print() в нужных местах. Разгадка оказалась проста: где-то в середине функции, там, где это было менее всего заметно, вместо return клиент написал yield. А в питоне yield — это магическое слово, которое превращает функцию в генератор, а все return ... - в как бы raise StopIteration(...), и вместо результата возвращается итератор, и выполнение кода останавливается до следующего обращения... Короче говоря, всего-навсего одним ключевым словом клиент полностью раздолбал логику своей программы. Маэстро!

Вообще генераторы в питоне — это и добро, и зло, и я ещё напишу про это в следующей статье (поэтому подписывайтесь, чтобы не пропустить). И хотя я программирую где-то со времён построения египетских пирамид, всё равно я умудряюсь делать ошибки.

Вот, например, кусок кода:

Тут у меня есть функция cache.apply(), которая берет quota_chunks, делает с ними какой-то вжух-вжух и возвращает новые quota_chunks. Я нарисовал диаграмму, чтобы изобразить этот процесс в более понятной форме.

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

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

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

Именно это тут и случилось. Я вызвал этот генератор и проверил, что он отработал без ошибок, но на самом деле генератор отработал совершенно в другом месте — там, где вызывается spy() — и именно там он и упал.

А знаете как я это отловил? В тестах. Поэтому пишите тесты.

Клиенты бывают разные: какие-то умеют немножко в HTML и frontend, а некоторые из наших клиентов умеют в backend. Один из таких клиентов часто сам писал backend логику и давал нам её на проверку, чтобы мы ему исправили баги, а может быть где-то сделали рефакторинг или code review.

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

И вот клиент взял нашу инструкцию и начал следовать тому, что там написано, слово в слово. Надо понимать, что разработчики обычно пытаются понять, что они делают (по крайней мере я на это надеюсь). Соответственно, те, кто читал этот скрипт, понимали, что должно быть сделано, и в случае, если у них, например, вместо pip используется poetry, а вместо apt-get у них pacman (i use arch btw), то они заменяли соответствующие команды.

Клиент же делал всё слово в слово, и он написал нам, потому что на одном из шагов у него случилась проблема. Если быть точнее, у нас в инструкции была описана ветка master, а на гитхабе по умолчанию ветка main, поэтому какая-то команда не находила нужную ветку.

«Изи фикс» — подумал я, созвонился с клиентом объяснил, что нужно делать, и хотел отключаться... когда возникла ещё одна ошибка. Оказывается, в инструкции был косяк, и при выполнении команды шелл делал подстановку, когда видел $SOMETHING — то есть не было экранирования. Мы исправили и это, и буквально через несколько секунд всплыл ещё один косяк. А потом ещё. И ещё.

Где-то через час я сказал клиенту, что пусть он всё бросит и я задеплою всё сам, а потом мы обновим ридми. Было стыдно.

Когда-то я работал на интернет-магазин, и мы заметили, что у нас появляются фейковые заказы каждые утро и вечер. Сначала мы не смекнули, что к чему, но потом поняли фишку: идентификаторы заказа у нас были обычные IDшки из Postgres, поэтому конкурент мог сделать заказ утром (номер заказа 10), сделать заказ вечером (номер заказа 15) и просто вычесть второй номер заказа из первого и получить количество заказов, которые мы получили за день (15 - 10 = 5). Я до сих пор часто нахожу эту ошибку во многих проектах, и примерно могу оценить размер этих проектов.

Эту ошибку легко исправить: достаточно заменить последовательные ID на случайные — например, вместо номера заказа использовать timestamp или UUID.

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

Мой девиз — «кто ищет тот всегда найдёт» (посмотрите мои статьи про уязвимости на хабре - 1, 2). Так и тут, я искал и обнаружил, что конкурент выкладывает розничные прайсы публично, а вот оптовые — только для зарегистрированных и проверенных партнёров. Сам файл он раздаёт nginx'ом с адреса вроде http://some-site.com/files/розничный_прайс.xls. А если так, то, скорее всего, никакой аутентификации при помощи бэкенда для самого файла нет, а значит, можно попробовать найти оптовый прайс.

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

В одном из моих проектов я использовал api ВКонтакте, чтобы анализировать кожаные мешки. Там не нужна была супер-скорость, поэтому я не полез в async, а просто написал функцию и распараллелил её по потокам при помощи ThreadPoolExecutor.

Программа начала просто летать! Вот как это делают сеньоры! Саенс, бич!

В одном из моих проектов я использовал api ВКонтакте, чтобы анализировать кожаные мешки. Там не нужна была супер-скорость, поэтому я не полез в async, а просто написал функцию и распараллелил её по потокам при помощи ThreadPoolExecutor.

Программа начала просто летать! Вот как это делают сеньоры! Саенс, бич!

Потом я начал подозревать, что программа работает слишком быстро даже для такого классного парня, как я. Я полез смотреть результаты, а там ничего не было, потому что в каждом из потоков программа очень быстро падала с ошибкой, а так как это потоки, то exception в потоке не «всплывал» в основную программу, и я думал, что всё норм.

Поэтому если всё работает слишком хорошо, то, возможно, всё очень плохо.

Пришел ко мне клиент и говорит: Саня, давай позумимся и посмотрим, что-то вебхук отвалился и ничего не принимает.

Ну я такой про себя «опять клиент что-то сломал, бывает», полез туда смотреть. Глядел-глядел, глаз вообще ни за что не цеплялся. Ошибок в sentry не было. Потом нашёл вот такой код:

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

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

И вот я смотрю, а этот код написал... я сам. Вот так я примерно выглядел:

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

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

Я человек простой, мне сказали задеплоить — я и задеплою, хоть на AWS, хоть на тапок.

Запускаю я скрипт, он всё делает, и теперь я хочу зайти на сервер и вручную проверить, что всё работает. И тут всё заверте...

Сначала пробую ssh -i ключ root@ip. Не работает. Потом вспоминаю, что юзер в AWS обычно ec2-user, поэтому пробую ssh -i key ec2-user@ip. Не работает. Может, там авторизация не по ключу? Пробую ssh ec2-user@ip. Не работает. Сделал dig, попробовал подключиться не напрямую, а через load balancer. Согласен, тупая затея.

Пошел в дэшборд AWS смотреть настройки файрволла. Вижу два странных айпишника. Очень странно. Беру первый, проверяю геолокацию по ip. По локации понимаю, что это, кажется, статический ip девопса. Какого хрена? У нас же есть бастион, и все соединения должны проходить через него... Проверяю второй ip из файрволла. О, так это же и есть бастион. Ну отлично, теперь делов-то — добавить всю эту конфигурацию с бастионом в .ssh/config, чтобы в будущем было легко подключиться. Лезу в конфиг, а там уже есть эта конфигурация.

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

На sentry прилетел отчёт об ошибке, попросили посмотреть. Стал разбираться. Мой код двухгодичной давности.

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

Единственное, что я не учел — что клиент может просто всё забросить, ничего не отменяя. И вот на протяжении года наш сельдерей-разнорабочий (celery worker) запускался, пытался списать у клиента деньги, получал отлуп, жаловался в sentry, и засыпал, чтобы назватра всё повторилось, и так каждый день, без конца и края.

Я заметил, что очень часто клиенты могут сэкономить неплохую такую кучу денег, сделав просто какое-то минимальное телодвижение. Вот несколько примеров:

У нас есть шаблон для новых проектов на cookiecutter. Он удобен тем, что если мы что-то меняем в шаблоне, то можем легко обновить проекты клиентов при помощи cruft.

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

И вот дело подходит к концу, у них куча изменений, у меня столько же. Мы говорим «ну мы всё», они такие «мы тоже вот уже заканчиваем». Начальник мне пишет: «Заливай быстрее в мастер, пока они не залили своё, а то будем потом всю жизнь конфликты разбирать!!!одинодин». Ну я на скорости слил наши обновления в мастер-ветку и мысленно пожелал удачи их разрабам: наша работа сделана, мастер мы обновили, а то, что их разработчики отстали от мастера и у них конфликты — ну штош.

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

Ага, меня.

Настраивал я как-то инстанс elasticsearch. Там была отдельная машина, я на ней с помощью docker разворачивал ElasticSearch. Сначала делал всё в ручном режиме, проверял, потом писал скрипт для автоматизации. Для начала просто запустил сервер без всего, потом начал разбираться с авторизацией.

В эластике есть специальный скрипт — elasticsearch-setup-passwords — он настраивает пароли. Ну я его запустил, он мне выдал списки паролей для apm_system, kibana_system, kibana, logstash_system, beats_system, remote_monitoring_user и, собсна, elastic. И хотя мне показалось, что паролей было слишком мало и вообще-то для приличной поисковой системы их должна быть хотя бы сотня, но пароль для elastic был, я его забил в систему автоматизации и пошёл дальше настраивать. Дальше было SSL — не знаю, почему это не встроено (наверно, потому что если не будет https, то и взламывать elastic будет сложнее, а куда без этого!). Ну я пошёл в гугол и говорю: пацаны, сертификаты для эластика привезли? Когда я заикнулся про letsencrypt, они мне сказали, что у нас тут не загнивающий запад и мы сами сертификаты делаем, свои собственные. Короче, прям на официальной странице лежит огроменный docker-compose.yml, в котором вжух-вжух, сертификаты настраиваются, конфиги генерируются. Я его скопировал, применил, всё заработало, и я добавил это в автоматизацию.

Через несколько дней (когда я ужё наполовину всё забыл) мне вдруг понадобилось всё снести и настроить заново (спасибо, digital ocean, за то, что не умеешь даунскейлить диски!). Я запустил скрипт автоматизации, всё развернулось, и тут я вспомнил, что вроде как пароль генерируется сам и его можно узнать, если запустить elasticsearch-setup-passwords. Ну я полез на машину, чтобы запустить эту команду — а она не работает! Сначала был не тот url инстанса, пришлось узнать, что есть опция --url. Окей, теперь не хочет подключаться, т.к. кастомные сертификаты. Как добавить сертификаты? Прописать их в elasticsearch.yml. Читаю доки и там говорится:

ура! так просто!

ffuuuuuuuuu...

Ну я полез читать, что за Elasticsearch keystore и зачем он нужен, и даже прочитал про bootstrap password и keystore passphrase. Мне показалось, что ещё чуть-чуть, и я дойду до чтения про большой взрыв и основы зарождения вселенной, а ведь я просто хотел узнать пароль от эластика!

Тут я бросаю взгяд на docker-compose.yml, и вижу, что там везде мелькает $ELASTIC_PASSWORD, и оказывается всё это время пароль был у меня в настройках и я сам его задавал!

Сказочный... эээ... патруль!

Клиенты любят нанимать фрилансеров или брать сотрудников в штаты, чтобы они работали над фичами — потому что нанимать нашу компанию достаточно накладно >:)

Ну и вот как-то клиент нанял стороннего разработчика, чтобы он перенёс систему поиска с эластика на postgres full-text search. Он сделал это именно так, как делал я лет 7 назад. Следите за руками:

То есть это прям классическая, железная точка невозврата. Угадайте, что случилось.

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

Я откатил git revision на сервере на рабочий коммит, а СЕО зашёл в админку Digital Ocean и восстановил снэпшот базы данных, назвав его production-db-backup-Mar-24. Всё запустилось. Из-за использования снэпшота мы потеряли немного новых данных, но ничего критичного.

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

Через много месяцев (да, много историй именно после этого и начинаются) клиент говорит: а чё это за production-backup-Mar-24, давайте её удалим. Как же здорово, что он спросил у нас. Потому что программист клиента на самом деле ничего не починил, а просто свалил в закат, и вся инфра осталась в этом «пофикшенном» состоянии. И база использовалась резервная. Поэтому удалять нужно было сломанную БД с названием production, а рабочей была именно production-backup-Mar-24.

Такие дела.

Серьёзно, я уже подумываю написать книгу про похождения детектива kesn'а.

Как-то я отлаживал асинхронный код, он читал бинарные данные с девайса, парсил их и отправлял куда подальше. Конечно, меня позвали, когда этот код начал тупить и кое-как работать, поэтому на входе меня ждала портянка спагетти-кода. Нам не привыкать, и я начал рефакторить и замерять скорость при помощи @funcy.log_durations.

Я кэшировал функции, пропускал ненужные фрагменты данных, уменьшал циклы. Сначала стало быстрее, но потом чем больше я отлаживал, тем медленнее код работал. Может, мой рефакторинг упустил какую-то важную деталь, и поэтому я делаю что-то совсем не то? Я начал логгировать и отлаживать даже самые маленькие функции. В конце концов дошло до того, что я, кажется, всерьёз начал задумываться об оптимизации скорости словарей в питоне (sic!), и в то же время моя версия работала медленнее, чем оригинальный код.

Потом до меня допёрло.

Чем больше я добавлял отладочной инфы, тем больше был оверхед. То есть я делал программу быстрее, но отладочная инфа делала программу медленнее.

Ха-ха. Я выключил отладочную инфу, и всё залетало. Ну и дурак!

Если вам понравилась эта статья, то посмотрите вот эту, она тоже весёлая: Погромист. Мои самые эпичные провалы за всю карьеру.

Если вам понравился я лично, как умная и образованная гиена, то вот моя тележка: Блог погромиста

А ещё вы не поверите, но я сам написал этим ребятам, что хочу их прорекламировать. А всё потому, что я уже больше года держу у них 4 своих проекта, а ни одной проблемы до сих пор не было. Даже скучно.