debudLeg

Как Kubernetes, Jira и Keycloak не помогли выпустить продукт

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

Первый кейс сразу интересный. Есть команда из трёх разработчиков, больше 30 репозиториев, Kubernetes, Helm, Argo CD, Keycloak, Jira и куча другой инфраструктуры. Нет только новой версии приложения, которую заказчик может нормально открыть в браузере.

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

Заказчик решил обновить приложение и нанял отдельную команду. Прошло довольно много времени, но внятного результата он так и не увидел.

Разработчики говорят, что проблема в непонятном ТЗ. Заказчик говорит, что команда не отвечает на вопросы, не доводит решения до конца, а то, что показывает, регулярно не работает.

Меня позвали разобраться.

Первым делом я попросил доступ к коду. Код лежит в собственном GitLab. Правда, сам GitLab периодически тоже лежит, поэтому попасть туда получилось не сразу.

Когда доступ появился, меня встретила авторизация через Keycloak.

Напомню: разработчиков трое.

Спрашиваю, как деплоят. Kubernetes, Helm, Argo CD. Открываю список репозиториев, а их больше 30. Часть занята общими библиотеками и Docker images, но большая часть приходится на отдельные сервисы.

Потом выяснилось, что у команды есть собственные registry, Jira, Grafana, VictoriaMetrics и ещё пачка инфраструктурных компонентов.

Всё это работает на мощностях заказчика. Точнее, периодически работает. То GitLab недоступен, то проблемы с кластером, то ломается ещё что-нибудь. А отдельных людей, которые могли бы постоянно следить за этим зоопарком, нет.

Старая версия приложения продолжает обслуживать пользователей. У новой тоже есть production-контур, но он сильно отстаёт от dev и пока не соответствует требованиям.

Frontend вроде бы существует. Но вживую я его до сих пор не видел, только на скриншоте.

Сколько функций действительно готово, тоже непонятно. Приёмочные испытания ещё не начались, потому что критерии приёмки всё ещё согласовывают.

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

Дело не в том, что Kubernetes, Jira или Keycloak плохие. Вопрос в том, зачем всё это понадобилось именно сейчас и кто должен это обслуживать.

Если команда из трёх человек построила инфраструктуру, за которой не успевает следить, значит, сложность уже стала проблемой. Особенно когда она не помогает быстрее выпускать продукт.

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

Забавно, что это полная противоположность истории с The Signal: [ссылка].

Там ребята быстро выкатились на Vercel, но забыли настроить RLS в Supabase. А когда я поднял логи и метрики, мне сказали, что это уже какой-то очень серьёзный подход.

Тут всё наоборот. Логи есть. Метрики есть. Kubernetes есть. Даже Argo CD есть. А работающий frontend пока существует для меня только на скриншоте.

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

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

А вы в какой крайности?

👍 - инфра всему голова
🔥 - пользователь лучший тестер

Дебаж 🐞с ноги 🦶

#Опыт #Консультация #IT

Отцовская тревога

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

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

В России тренд точно такой же. Вакансий для джунов стало на 40% меньше, чем два года назад. На одну стартовую позицию сейчас 19 резюме (против 2,5 на место сеньора). А до живого эйчара доходит в лучшем случае каждый десятый (остальных безжалостно отсеивает ИИ-фильтр еще до человека).

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

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

2)Глобальный баг в системе. Бизнес отказывается от новичков, потому что ИИ дешевле, и компании не хотят брать на себя социальную нагрузку по менторству. Но опытные спецы не вечны!

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

Лучший карьерный совет - это родиться на десять лет раньше. И как всегда с детьми: проще уже было.

Что думаете делать с этим багом в матрице? Учить детей кодить, надеясь, что они пробьются через ИИ-мясорубку, или отправлять их учиться работать руками, куда алгоритмы не дотянутся?

Дебаж 🐞с ноги 🦶

#дети #IT #Мысли

React-приложение и SEO: как я решил проблему индексации практически бесплатно

Сейчас у меня в активной разработке проект The Signal — это платформа с редакторскими новостями для снижения тревожности (как минимум у меня). Ниша «новости» сложная и высококонкурентная, поэтому тут критически важно, чтобы сайт хорошо индексировался поисковиками.

Но The Signal - это React-SPA (Single Page Application). Проблема SPA в том, что поисковые роботы (особенно Яндекс) плохо переваривают динамический JS-контент. Им подавай готовый HTML, иначе в поиск страница может просто не попасть или попадет криво.

Поднимать полноценный SSR (Server-Side Rendering) было долго, поэтому я нашел хак: индексировать статику на субдомене. То есть основное приложение живет своей жизнью, а статьи публикуются на дополнительный сайт-витрину, который уже легко съедается Google и Yandex.

Как сделать это за копейки
Я использую Yandex Cloud S3 (за хранение HTML и трафик поисковиков там набегают сущие рубли), но подойдет любой провайдер. Инструкция:

Создаем бакет и называем его как наш новый субдомен: у меня это digest.the-signal.ru.

В настройках бакета включаем «Веб-сайт хостинг».

Идем туда, где заводили домен, и создаем CNAME-запись: направляем digest.the-signal.ru на digest.the-signal.ru.website.yandexcloud.net.

Возвращаемся в Yandex Cloud, идем в Certificate Manager и добавляем бесплатный сертификат Let's Encrypt.

Подтверждаем права на домен. Для этого нужно положить специальный файл-ключ от Let's Encrypt в скрытую папку .well-known/acme-challenge/ в нашем бакете. Так сервис по урлу проверит, что домен ваш. Подробнее о том, как вообще работает валидация и подключение SSL (на примере Nginx), я писал в своей статье на Хабре.

Переходим в настройки бакета -> Безопасность -> HTTPS и выбираем созданный сертификат.

Любыми мыслимыми и немыслимыми способами (руками, скриптами, CI/CD) закидываем сгенерированные HTML-странички в бакет.

Не забываем добавить sitemap.xml и robots.txt для поисковиков.

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

А вы как решаете индексацию для SPA? Накручиваете SSR, используете платные пререндеры или есть свои хаки? Делитесь в комментах 👇


Дебаж 🐞с ноги 🦶

#Разработка #Индексация #Опыт

Мой опыт с Supabase: 8 неочевидных костылей, о которых молчат в красивых туториалах.

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

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

Короче, вот за что вы будете страдать на бесплатном тарифе (да и не только на нем).

Логи. Их просто нет
Точнее, они живут ровно 24 часа. Упало что-то в пятницу вечеро - в понедельник с утра ты дебажишь святым духом. Встроенный поиск это вообще кровь из глаз. Без какого-нибудь Datadog или Logflare там тупо не выжить.

Edge-функции и проклятые холодные старты
Это отдельный котел. Писать надо на Deno, так что половина привычных npm-пакетов идет лесом. Лимиты на вызовы жесткие, долгую таску не запустить. Но самое бесячее это холодные старты. Пока поднимется пул коннектов к базе, проходит до трех секунд. В моем сервисе post-cooler.ru edge-функция отдает HTML для линк-страничек. Я смотрю в метрики и плачу: кликов куча, а дожидаются загрузки единицы. Конверсия просто умирает на этапе бесконечного лоадера.

Палево с доменами в OAuth
Юзер логинится через Google, а в окне авторизации торчит <project-id>.supabase.co. Я когда делал photo math, целый час дебажил эту хрень. Думал, что сам где-то накосячил ведь на локалке-то всё выглядело нормально! Оказалось, не баг, а фича. Хочешь свой домен? Плати.

Хаос со схемами БД
Экспорт схем из дашборда выпилили еще в 2025 году. Сейчас помогаю проекту the-signal переехать на селф-хост. До этого код там писали vibe-кодеры, которые вообще не парились про миграции. Вытащить дамп схемы из облака было той еще болью. Без жесткой дисциплины база очень быстро превращается в неуправляемую помойку.

Тормоза локальной разработки
Я постоянно прыгаю между проектами. И каждый гребаный раз supabase start лезет тянуть свеж#Опыт ие Docker-образы. Поднимает 10+ контейнеров, а ты сидишь и тупишь в терминал. Весь кайф от "быстрой" разработки улетучивается.

Тихие RLS-ошибки
RLS (Row Level Security) ошибается молча. Накосячил в политиках? БД тебе не скажет. UPDATE просто вернет 0 affected rows, а SELECT подтянет половину данных.

Транзакции и боль SQL-функций
Через REST API нельзя сделать нормальную транзакцию на несколько таблиц. Нужно атомарно создать юзера, профиль и настройки? Обломись. У меня пока ничего не отвалилось, но я с ужасом жду, когда в базе начнут копиться "осиротевшие" записи.
Чтобы это обойти, приходится писать логику на PL/pgSQL прямо в базе. Редактор там примитивный, автокомплита толком нет и дебажить то еще удовольствие.

Вендор-лок
Клиентский SDK намертво завязан на специфичный синтаксис PostgREST и их собственные токены. Если однажды решишь переехать на нормальный самописный бэк: придется рефакторить вообще весь клиентский код.

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

Кто еще сидит на Supabase или Firebase? С чем боретесь? И есть тут те, кто уже психанул и переехал на свой бэк?

Дебаж 🐞с ноги 🦶

#Разработка #Опыт

Экономика ИИ-продуктов. Покупаешь подписку за $200, а сжигаешь серверного времени на $14 000.

Забавно, но сейчас OpenAI и Anthropic фактически оплачивают мне разработку пет-прожектов из своего кармана. Ребята из SemiAnalysis провели крутой стресс-тест: купили максимальные тарифы ChatGPT Pro и Claude Max (по $200 в месяц) и гоняли на них хардкорные агентурные таски, пока не уперлись в недельные лимиты. Потом они пересчитали потраченные токены по официальным API-прайсам. Оказалось, что из Claude Max за 200 баксов можно выжать лимитов на $8 000. А из ChatGPT Pro (20x) — на безумные $14 000.

Для меня это вообще не абстрактные цифры. Я постоянно юзаю агентов (в связке с тем же Cursor) и скармливаю им гигантские простыни кода. При таком подходе маржинальность OpenAI улетает в жесткий минус: они работают в убыток уже после того, как юзер тратит 5,7% от лимита. По сути, люди, которые за $20 генерят по три письма в день, спонсируют технарей вроде меня, выжимающих из моделей все соки.

Какой продуктовый вывод я делаю для себя?

Для честной работы по API надо искать аналоги у китайских друзей — те же DeepSeek или Qwen стоят копейки, а с кодом справляются отлично.

А вот для тяжелых локальных тасков, парсинга и агентов, пока эту дыру не прикрыли, выгоднее веб-подписка OpenAI/Anthropic (через эмуляцию или прокси), чем платить им за API.

А вы как гоняете нейронки для рабочих задач?

Дебаж 🐞с ноги 🦶

#Искусственный_интеллект #Разработка #Опыт

Я встроил браузер в браузер

Недавно писал, что вписался консультантом в проект Signal. Бекенд развернут на self-host Supabase. Мне дико не нравится работать с их логами, поэтому решил поднять VictoriaLogs + VictoriaMetrics и прикрутить Grafana как UI.

Вся эта связка живет на одной железке в докере. У такого конфига есть только одна огромная проблема это безопасность. Виктория из коробки вообще не идет ни с какой авторизацией. Обычно это не парит: засовываешь всё за VPN и забываешь. Но с 2025 года с VPN всё туго. Его надо постоянно поддерживать и оживлять, а времени на это нет.

Отсюда вопрос: как не светить Викторию голой в сеть, но при этом иметь доступ к админке, если вдруг что сломается?

Докер сам строит внутри себя сети, и контейнеры отлично общаются по адресам типа grafana:3000. Мой локальный браузер про эти внутренние адреса на VPS, конечно, ничего не знает. Но оказалось, что кто-то уже столкнулся с этой проблемой до меня и собрал докер-образ с Хромом (lscr.io/linuxserver/chromium).

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

Штука прикольная. Можно даже срезать качество картинки и FPS, если инет тупит. Но есть боль с буфером обмена. Текст просто так не скопируешь, приходится пихать его в отдельное окошко. Плюс у меня Мак с cmd+c/v, а на сервере крутится линукс с ctrl и мозг при переключении немного ломается.

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

А как вы сейчас прячете внутренние тулзы на пет-проектах? Страдаете с ключами и туннелями или есть решения проще?

Дебаж 🐞с ноги 🦶