Детектив kesn всегда готов помочь!
Вообще я, как правило, нормально программирую. Иногда даже такое заворачиваю, что сам тащусь весь день.
Но если б я писал, какой я красавчик, то никому не было бы интересно. Поэтому сегодня — очередная партия программистских историй от меня любимого, с косяками, багами и болью. Иногда это происходило по запарке, или когда я торопился, или после нудной работы, когда мозг уже плавился, а иногда просто я тупил, потому что я человек. В общем, такие вот типичные будни кодера. Наслаждайтесь!
❯ Функция не выполняется
Попросил меня как-то клиент отладить его скрипт. Говорит, не работает. Невероятно!
Я, когда клиент говорит, что ничего не работает
Скрипт секретный — ну как, для трейдинга на бирже, и принесёт миллионы денег, конечно же, но только когда заработает без ошибок. Поэтому клиент не пересылает мне его, а запускает 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.
Программа начала просто летать! Вот как это делают сеньоры! Саенс, бич!
Слева направо: саенс, бич
Потом я начал подозревать, что программа работает слишком быстро даже для такого классного парня, как я. Я полез смотреть результаты, а там ничего не было, потому что в каждом из потоков программа очень быстро падала с ошибкой, а так как это потоки, то exception в потоке не «всплывал» в основную программу, и я думал, что всё норм.
Поэтому если всё работает слишком хорошо, то, возможно, всё очень плохо.
❯ Бог рефакторинга
Пришел ко мне клиент и говорит: Саня, давай позумимся и посмотрим, что-то вебхук отвалился и ничего не принимает.
Ну я такой про себя «опять клиент что-то сломал, бывает», полез туда смотреть. Глядел-глядел, глаз вообще ни за что не цеплялся. Ошибок в sentry не было. Потом нашёл вот такой код:
На этом моменте я распушил свой хвост и начал рассказывать клиенту, что нельзя вот так декорировать метод, ибо этот декоратор только для функций, да и вообще аргумент self пропущен. Короче, комбо из двух ошибок.
К несчастью, у меня стоит расширение git lens, которое пишет, кто именно написал каждую строчку кода. Я в основном использую это, когда вижу какую-то хрень: если автор кода — чувак из наших, то, скорей всего, это я тупой и что-то не понимаю в задумке автора; в других же случаях это, как правило, обычный плохой код.
И вот я смотрю, а этот код написал... я сам. Вот так я примерно выглядел:
Самое смешное, что в оригинале клиент написал рабочий код, потом пришёл я всё рефакторить и случайно сломал. Я много раз извинялся перед клиентом. Ух, до сих пор стыдно.
❯ Детектив kesn и тайна ssh
Говорят мне как-то: клиент, с которым мы работали год назад, восстал из мертвых, и теперь ему нужно перенести и обновить проект в 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, и засыпал, чтобы назватра всё повторилось, и так каждый день, без конца и края.
❯ Лёгким движением руки сэкономить кучу денег
Я заметил, что очень часто клиенты могут сэкономить неплохую такую кучу денег, сделав просто какое-то минимальное телодвижение. Вот несколько примеров:
Чувак хостил видео на aws s3 и раздавал через амазоновский CDN. Выходило $655 в месяц. Потом нашёл BunnyCDN, я перенастроил приложение (заменил где-то 4 строчки минуты за две), и внезапно с новым CDN в месяц стало уходить только $70. Ну не эпично ли за пару строчек кода?
Клиент платил сотни долларов за жирный инстанс Elasticsearch на AWS. Почему — я хз. Потом он заподозрил неладное. Мы замерили реальную нагрузку и перенесли Elastic на одну из самых дешёвых машин в digital ocean, за которую клиент теперь платит $24 в месяц. Профит!
У клиента было много файлов на s3, платил он тоже много. Потом перенесли всё на b2, там даже делать почти ничего не надо — у них интерфейс совместим с s3. Получили экономию раза в 4.
❯ От судьбы не уйдёшь
У нас есть шаблон для новых проектов на cookiecutter. Он удобен тем, что если мы что-то меняем в шаблоне, то можем легко обновить проекты клиентов при помощи cruft.
Как-то меня наняли как раз обновить проект. Проект был старый, отстал от нашего шаблона очень прилично, и когда я попытался его обновить, то обнаружил, что изменилось почти всё. Я начал аккуратно разрешать конфликты, и как раз примерно в этот момент штатные сотрудники клиента начали пилить что-то эпичное в своей ветке.
И вот дело подходит к концу, у них куча изменений, у меня столько же. Мы говорим «ну мы всё», они такие «мы тоже вот уже заканчиваем». Начальник мне пишет: «Заливай быстрее в мастер, пока они не залили своё, а то будем потом всю жизнь конфликты разбирать!!!одинодин». Ну я на скорости слил наши обновления в мастер-ветку и мысленно пожелал удачи их разрабам: наша работа сделана, мастер мы обновили, а то, что их разработчики отстали от мастера и у них конфликты — ну штош.
Прошло много месяцев, и угадайте, кого они наняли, чтобы разрешить все конфликты и залить их ветку в мастер?
❯ Детектив kesn и поиски пароля
Настраивал я как-то инстанс 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. Читаю доки и там говорится:
All of these settings can be added to the elasticsearch.yml configuration file, ...
... with the exception of the secure settings
which you add to the Elasticsearch keystore. For more information about creating and updating the Elasticsearch keystore, see Secure settings
Ну я полез читать, что за 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 и загадочные тормоза
Серьёзно, я уже подумываю написать книгу про похождения детектива kesn'а.
Как-то я отлаживал асинхронный код, он читал бинарные данные с девайса, парсил их и отправлял куда подальше. Конечно, меня позвали, когда этот код начал тупить и кое-как работать, поэтому на входе меня ждала портянка спагетти-кода. Нам не привыкать, и я начал рефакторить и замерять скорость при помощи @funcy.log_durations.
Я кэшировал функции, пропускал ненужные фрагменты данных, уменьшал циклы. Сначала стало быстрее, но потом чем больше я отлаживал, тем медленнее код работал. Может, мой рефакторинг упустил какую-то важную деталь, и поэтому я делаю что-то совсем не то? Я начал логгировать и отлаживать даже самые маленькие функции. В конце концов дошло до того, что я, кажется, всерьёз начал задумываться об оптимизации скорости словарей в питоне (sic!), и в то же время моя версия работала медленнее, чем оригинальный код.
Чем больше я добавлял отладочной инфы, тем больше был оверхед. То есть я делал программу быстрее, но отладочная инфа делала программу медленнее.
Ха-ха. Я выключил отладочную инфу, и всё залетало. Ну и дурак!
Если вам понравилась эта статья, то посмотрите вот эту, она тоже весёлая: Погромист. Мои самые эпичные провалы за всю карьеру.
Если вам понравился я лично, как умная и образованная гиена, то вот моя тележка: Блог погромиста
Подпишись на наш блог, чтобы не пропустить новые интересные посты!
