Как в продакшене память потекла

Захожу вчера в консоль Digital Ocean и вижу там такое. Глаза по пять рублей сразу - ну как так?! Вроде ж нормально программировал, а оно вон как повернулось.

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

Как думаете, поможет этот подход обнаружить, где днище протекает? 🤔

Скоро вернусь к вам с историей про память, а пока принимаю поздравления, т.к. сдал местный экзамен по вождению 😁

Наконец-то НУЖНЫЙ эй-ай подвезли 😁

Что же случилось с памятью?

Я не забыл про обещанную вторую часть истории про текущую память.

Закопался в делах: и работы привалило (взял классный проект на несколько месяцев), и куча любопытного и интересного приключилось - скоро расскажу! 😍

Итак, увидев 96% съеденной оперативки, я удивился и испугался одновременно. Где я мог настолько сильно накосячить в питоне с его garbage collection? Посмотрел на графики, а там ступеньки. Ещё более таинственно: что такого может приводить к одномоментному скачку в потреблении памяти?

Обычно, если течёт, то течёт постепенно, а тут по 10-15 процентных пунктов за раз. И так уже на протяжении нескольких месяцев, то есть даже с какими-то последними изменениями это не связать 🤯

Решил отлаживать. Поднял локальный стенд в продакшен-режиме, начал туда наливать запросов: 10,000 фейковых запросов от телеграма, 10,000 запросов из страйпа. Хотя там и близко столько не бывает, у нас сотни человек пользуются ботом, а не десятки тысяч.

Не течёт. Чудеса в решете! Коллеги-друзья накидали вариантов, что какие-то древние питонячьи сетевые либы могут течь - но и это, в моём понимании, не очень-то объясняет ступеньки. Плюс у меня-то uvicorn + джанга, вроде как без палеонтологии. Ничего не понимаю.

А потом как понял!

Я много запускаю django shell прямо в проде. Что-то посмотреть, вручную сообщения отправить, поменять какие-то поля в модельках, которые в админке read-only. Каждый запуск - это ipython в веб-консоли (да, пока самый большой минус PaaS от Digital Ocean в отсутствии SSH). И консоль эта крайне кривая: скролл тупит, выделение нормально не работает, зависает ещё постоянно 🤬

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

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

Вот так вот просто всё разрешилось. Спасибо хоть чуйка на ступеньки сработала, и кучу времени не потратил!

Как вчера, например, когда час убил на подвисающие миграции в prisma (это такая модная ORM для ноды) - а оказалось, что она просто запускалась в интерактивном режиме и ждала от меня названия миграции. А я этого просто не видел, потому что запускаю всё в докере локально 🤣

А у вас какие банальные ошибки при отладке приключались?

Ну что, айда в Threads?

https://www.threads.net/@ogrmv

Думаю, может попробовать там контент на английском публиковать полезный 🤔

А помните, был такой Clubhouse?

Ужасы отладки

Делаю приложение, которое запускается через pm2. Это такой модный-молодёжный сервис-супервизор, написанный фронтендерами, который следит за приложениями, перезапускает, если надо и т.п.

Все секреты в приложение попадают, как обычно, через env-переменные. Их там уже было N штук, и всё работало.

Процесс такой:
1. Новый код попадает на VPS
2. Собирается
3. Запускается скрипт prod-run-app-migrations.sh
4. Внутри читаются из амазоновского хранилища и экспортируются env-переменные
5. Запускается pm2 ./build/server/app.js
6. app.js проверяет, все ли переменные на месте, ругается и умирает, если нет

Добавил пару новых, credentials для амазоновской SQS. Везде прокинул, в скрипте они есть, всё проверил - но приложение на шаге 6 просто падает, жалуясь, что именно новых двух переменных нет.

Крутил скрипты, крутил pm2, запускал руками, даже переменные переименовывал - то работает, то не работает.

Оказалось! 🤬

У pm2 есть флажок --update-env, который надо использовать, чтобы эта поделка подхватила новые переменные из окружения. ЧТО?! И после этого мне говорят, что все эти новые сиюящие утилитки классные, удобные! Вот проверенный годами supervisord таких проблем не имеет. По крайней мере, я не сталкивался.

В итоге час в трубу 🤬

Публично о неудачах

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

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

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

Образовательного проекта с моим другом Витей не будет

Сегодняшняя, а точнее уже месячной давности "плохая" новость в том, что мы с Витей разбежались. Проинтервьюировали 8 человек, много обсуждали и планировали, но так и не пришли к общему понимаю того, что же нам делать, для кого, зачем и почём. Витя хотел более камерный проект, больше для фана и коммьюнити. Мне же в большей степени хочется делать настоящий бизнес, который работает сам, растёт, может обеспечивать нас и будущую команду. Хотя меня пугала громадная конкуренция на рынке онлайн-образования.

Слово "плохая" в кавычках неспроста. Хоть моей первой реакцией и были раздражение и обида, мол, как же так, опять! - это, на мой взгляд, к лучшему. Хорошо, что потратили не так много времени, что не затащили глубокие разногласия далеко в совместный проект. Что сумели поговорить честно и по душам и понять, что хотим разного (как минимум, на данном этапе).

Не рассориться, наконец, оставшись друзьями 🙂

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

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

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

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

Ещё мои представляения о бизнесе постепенно трансформируются.

Спросить меня полгода-год назад о том, нужны ли инвестиции - и мой ответ сходу был бы "нет". Дескать, если не понимаешь своих клиентов настолько хорошо, что можешь сам сделать первые 10-100 продаж руками, заработать, подтвердить гипотезу и принести пользу, то и нафиг такой бизнес (в качестве первого). Но есть же и более капиталоёмкие проекты, есть маркетинг, который, как показывает опыт, даже при наличии бьющего в цель продукта всё равно необходим и стоит денег. Жить на что-то надо, в конце концов, пока твой бизнес ещё не генерирует прибыль.

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

Совпадения и хорошие новости

Я не большой любитель всяческой мистики. Совпадения считаю если не случайностями, то закономерностями. Меняется восприятие - начинаешь замечать новое, говорить "да", когда обычно сказал бы "нет". Получаются совпадения, иногда даже судьбоносные.

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

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

Буквально в этот же день я натыкаюсь на классный проект. И сейчас занимаюсь им - с огромным удовольствием. Проектов на самом деле несколько: это утилиты для предпринимателей, основанные на ChatGPT и других публчиных API.

Кайфовый формат, в котором я работаю: один, как хочу, без какого-либо контроля и с полным доверием со стороны клиента. Фулстек, всё от инфраструктуры и devops до бэкенд-сервисов, фронта и UX, prompt engineering ещё. Не то чтобы я всё это одинаково люблю, но мне намного комфортнее делать всего по чуть-чуть, чем одни джейсоны гонять или формы полировать. Дизайн делает дизайнер клиента, но фундаментально на продукт я влияю, кажется, в большей степени.

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

Результат получается тоже супер: уже спустя 3 недели работы (из них 2/3 - это архитектура системы и простые деплои) и самый первый прототип тулзы, я сам с огромным удовольствием с ним балуюсь. Очень интересно выходит. И я всерьёз задумываюсь о том, как использовать LLM и прочие нейронки в бизнесе и собственных проектах. Огромный класс задач на классификацию, экстракцию любой информации из текста, саммаризацию (как по-русски будет?) покрывается с громадной точностью и почти бесплатно.

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

А вот второе совпадение уже в куда меньшей степени совпадение, и в куда большей - "судьбоносное". О нём в следующем посте.

Немного английских развлечений вам в ленту :)

Код-ревью: убрать нельзя оставить 😱

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


Мой знакомый Алекс написал о том, какие негативные последствия бывают от код-ревью. И хотя я сам обожаю катать в прод без каких-либо тестов и, уж тем более, код-ревью, я не согласен! 😇

Да, код-ревью может замедлять разработку. Например, в одной из прошлых команд мы даже замеряли и лечили излишне раздутый cycle time (сколько времени уходит на фичу от карточки в трекере до продакшена). Одним из результативных действий стало как раз изменение правил код-ревью: требуется меньше одобрений, мёржит тоже сам автор.

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

Так зачем вообще код-ревью? Если мы сами как будто бы стараемся дать командам разработки больше свободы и выжать побольше скорости.


☠️ Увеличить bus factor. Если кто-то из команды "попадёт под автобус", работа не должна остановиться. В коде часто бывает очень много легаси, особенно в стабильно работающих продуктах, которое знает только один бородатый синьор, а остальные боятся его трогать.

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


🤯 На раннем код-ревью можно понять, что ты делаешь не так. Изобретаешь велосипед или вообще решаешь задачу, которую не нужно решать. Особенно актуально в сложных проектах.

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

Важно сознательно подойти к процессу и не вываливать 1500 строк на проверку спустя месяц работы. Лучше обозначить основные компоненты и решения, пусть даже в тексте, и заслать PR для обсуждения как можно раньше.


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

Да, не за всё в ответе разработчики, их код и его качество. Но думаю, в случае с рентгеновским аппаратом - убийцей (гуглите Therac 25, он убил троих), можно было бы пожертвовать нервами и самооценкой разработчика в пользу хоть сотни раундов код-ревью! Правда не уверен, что в конце 80-х в принципе была такая практика. Agile точно не было.


🚫 Получается, если вы с другом пилите крипто-стартап, скорее всего, код-ревью вам не нужно.

✅ А вот в команде с большой ответственностью, сложной кодовой базой, либо когда много новеньких или команда очень молодая, обязательное ревью кода может быть совершенно необходимым.


Ну и, конечно, код-ревью нужно правильно готовить.

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

🙇‍♂️Обсуждайте код, а не автора. Критикуйте аккуратно и с уважением. Хорошее тоже подмечайте, особенно если вы выше по рангу (тим/тех-лид).

🏋️‍♂️Не ждите, что за вас решат вашу задачу во время ревью. Позаботьтесь об этом заранее, ведь нет ничего поганее, чем тратить время на ревью явной халтуры. Ну и проявляйте инициативу, делайте всё, чтобы ваш код попал в продакшен/тестирование.

🙏 Не пишите код за автора, когда делаете ревью. Дайте ему совершить ошибки или сделать по-своему, если только это не приведет к катастрофе, либо вашему увольнению 🤪 Нет ничего хуже, чем когда тебе подсовывают десятки предложений как "сделать лучше", хотя всё отлично работает, и давно можно мёржить.

Как деплоить свои веб-проекты

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

🔥 Цель простая: быстро писать код и быстро отправлять его в прод. Желательно имея возможность легко откатиться на предыдущую версию (за вычетом миграций схемы данных).

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

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

🚫 Железный выделенный сервер в чьём-то датацентре: не рассматриваю, т.к. слишком дорого и не нужно под игрушечную нагрузку сайд-проектов

✅ Виртуальный сервер в облаке (VPS) от Digital Ocean, AWS, GCP, etc: нормальный вариант, требующий настройки, но достаточно недорогой, нагрузка может быть любой - толькло плати и настраивай горизонтальное масштабирование

⚠️ Платформа (Platfform as a Service): более удобный, но одновременно и более дорогой вариант, который легче настроить. Зависимость стоимости от нагрузки вроде тоже линейная, если не учитывать замороченные pricing схемы облачных провайдеров

🚫 Serverless: не рассматриваю, т.к. не фанат и не вижу практической ценности для своих проектов

Для своих проектов, как личных, так и клиентских, я использовал GCP как PaaS, AWS с ручной конфигурацией (поднять EC2, RDS, SQS, настроить Cloudfront), VPS, а также AppPlatform от DigitalOcean. Ещё баловался с Firebase (тоже PaaS от гугла), но на них забил.

Лично мне больше всего нравится DigitalOcean из-за простоты и доступности. Бот и сайт Стильного клуба работают на App Platform (PaaS), а мой сайт на выделенном droplet (VPS).

Также нужно настроить Cloudflare (в частности, для TLS termination), nginx как reverse proxy, хранилище файлов (S3-подобная штука, либо просто раздавать с диска через тот же nginx), postgres и redis. Последние я беру в managed-исполнении, то есть не заморачиваюсь с настройкой и просто плачу $15 за инстанс.

Единственное неудобство - собственно деплои. Пробовал я следующее:

⚠️ ansible на VPS: геморно в настройке, очень многословно, секреты хранятся в зашифрованном виде прямо в репозитории. От yaml тоже подташнивает

⚠️ github actions + рукописные скрипты для примитивных деплоев в стиле "big bang", секреты для сборки в гитхабе, секреты в продакшене из AWS Systems Manager

✅ деплои на App Platform через git push: работает практически из коробки, включая откаты релизов, но много ограничений, неэффективные пересборки и перезапуски. Секреты берутся из настроек на самой платформе

😍 докер-контейнеры под каждый сервис: собираем всё локально/в гитхабе - фронтенд, бэкенд, воркеры и т.п., кладём в DockerHub/любой container registry, на сервере делаем docker pull и docker compose up.

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

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

А вы как, куда и почём деплоитесь?

Ждём с нетерпением! 🤡

Не деплойся с краю 🐺

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

По просьбе CTO компании-клиента, который не любит питон, свой текущий проект делаю на node/ts + react/ts. Прикольно, конечно, типы шарятся туда-сюда, express мне тоже очень нравится - простой, быстрый, очевидный. Типизация в TS просто огонь в сравнении с этими class User(TypedDict) в питоне. Асинхронность более привычная, чем с asyncio. Короче, кайф, жить можно. Хотя питон тоже огонь с dataclasses, fast-api и прочими sqlalchemy.

В общем, полез я смотреть что там у deno сейчас происходит, а они уже конкурента vercel строят вовсю 🤯

Всю эту молодёжную серверлесс красоту я воспринимаю скептически (а NextJS вообще уродец жуткий и тормозной, как по мне). Но тут взгляд зацепился. Потому что идеи, стоящие за deno, мне нравятся.

- простая cистема зависимостей (в теории)
- лучшая совместимость с привычными API браузеров
- адекватная система ограничений
- typescript из коробки

Ну и всяко-разное ещё, выглядит многообещающе 😍 bun тоже прикольный, но в нём мне больше сам код на сишке zig нравится, а в deno функциональность.

Так вот, сначала взгляд зацепился за Deno KV (key-value что ли?). Это какая-то чудо-юдо serverless edge database as a function 🥴 Там всё на свете сразу: и распределённость c масштабированием, и (де-)сериализация прям в/из JS. Хоть товарищи и говорят, что подобных БД на рынке уже хватает, мне всё равно любопытно (как человеку, у которого железный сервер под столом стоит).

Потом оказалось, что у них и Deno Deploy есть. Выглядит похоже на почти идеальное решение для того, что обсуждали в посте про деплои.

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

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

Bloom filter

Ковырял мануалы по редису, наткнулся там на Bloom/Cuckoo filter и понял, что не помню, что это такое. Полез искать и наткнулся на две потрясающие визуализации:

- тык
- тыдык

Очень круто и наглядно сделано! 🔥

Вкратце: bloom filter - это set, который поддерживает 2 операции:
- достоверно определить, что элемента в множестве нет
- с некоторой вероятностью определить, что элемент в множестве есть

Реализуется на основе хэш-функции с хорошим распределением.

При добавлении любой элемент сначала превращается в N битов, и эти биты устанавливаются в 1.

Для проверки делаем то же самое, и если все биты взведены, то элемент вероятно в множестве. Если нет, его точно нет.

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

Enjoy!