Как 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 пока существует для меня только на скриншоте.

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

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

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

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

#пробую

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

Запустил новый канал про Java и JVM: «Байтить кодом»

Я активно занимаюсь JVM Backend Digest для The Signal. Но формат дайджеста предполагает короткий рассказ о главном, а интересных новостей, релизов и технических деталей заметно больше.

Поэтому в новом канале буду подробнее разбирать происходящее в JVM-мире: Java, Kotlin, библиотеки, инструменты, производительность и внутренности платформы. Не просто пересказывать новости, а добавлять контекст и объяснять, почему они заслуживают внимания.

Всё-таки я Kotlin-разработчик и давно хотел писать о JVM. В идеальном мире как Алексей Шипилёв, но по духу, пожалуй, ближе к Тагиру Валееву и Баруху Садогурскому.

Если вам тоже интересно, куда развивается JVM и что из происходящего действительно важно, подписывайтесь: @bite_code

Lemon Squeezy + Freedom Bank: как выводить деньги с бурж-трафика

Зашел в umami и обнаружил, что у моего расширения speech-to-text почти треть пользователей - из США. Но рост остановился ровно на 1000 WAU. Покопался в логах sentry, почитал комменты — оказалось, юзерам просто не хватает бесплатных лимитов, вот они и отваливаются.

Расширять лимиты на free-тарифе слишком дорого, оплачивать API из своего кармана я бесконечно не могу. Значит, надо прикручивать pay-wall.

Пошел искать варианты приёма платежей из-за рубежа:
Открываешь Stripe — просит EIN или LLC.
Открываешь PayPal — комиссия 4%, конвертация и вечный риск заморозки.
Открываешь Wise — не регистрируют РФ с 2022 года.

В итоге наткнулся на Polar и Lemon Squeezy. Они работают как MoR (Merchant of Record): продают продукт клиенту от своего имени, сами разбираются с VAT в Европе и sales tax в Штатах, а тебе платят чистый остаток.

Остался вопрос, как это выводить.

Первый вариант — гнать на Payoneer, а с него на валютный счёт ИП в РФ, и платить 6% налога. Подвох в том, что Payoneer периодически блокирует выплаты на 180 дней за любую «подозрительную активность». Держать там оборот больше месяца тупо страшно.

Второй вариант интереснее. У Lemon Squeezy есть прямой вывод на любой банк с IBAN (Грузия, Армения, Казахстан). А у меня как раз лежит карта казахского Freedom Bank.

Пока план звучит надежно: Lemon Squeezy -> прямой перевод по IBAN -> Freedom Bank.

Кто-нибудь уже работает по такой схеме с MoR-сервисами? Есть какие-то подводные камни с комплаенсом казахских банков при регулярных поступлениях?

👍 - надо пробовать
🔥 - план точный как швейцарские часы (ирония)

#bip #speech_2_text

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

РКН заблокировал Signal, а под ковровую бомбардировку рикошетом попал мой проект. Просто потому, что в домене app.the-signal.ru есть запретное слово.

9 августа сервис перестал нормально открываться. Оказалось, ТСПУ не просто рубит соединение по SNI, а жестко шейпит (замедляет) трафик. Самая боль вылезает в момент загрузки JS-скриптов — они просто висят в бесконечном ожидании, и фронт не грузится.

Уже сутки пытаюсь вытащить аппку из этого болота. Что уже сделал:

👆Купил и прикрутил несколько новых доменов.

✌️ Поменял пачку IP-адресов. Пока не особо спасает.

Последняя гипотеза, которую буду тестировать — раздавать статику и JS через трастовые CDN от Selectel или Яндекса. По идее, их домены ТСПУ трогать не рискнет.

Пока я воюю с инфрой, веб-версия работает только из-под VPN. Если не хотите костылей — переходите в Telegram-бота, там всё летает без ограничений: https://t.me/the_signal_app_bot

👇 Коллеги, кто уже сталкивался с таким шейпингом статики от ТСПУ? Поможет ли перенос JS на крупный CDN, или проще не мучиться, дроп

#пробую

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

Чутка пропал из эфира, потому что 9 месяцев назад вписался в один проект с долгим циклом разработки и вот наконец релиз состоялся.

Результат: 3.2 кг, code freeze на графике сна, никакого roadmap на ближайшие пару недель. Бенефиты пока не разобрал полностью и read the docs предстоит на ходу, а документации, как обычно в проде, почти нет.

Скоро вернусь в обычный режим, но пока onboarding в новую роль.

фотки тут -> https://www.instagram.com/p/DcEp61ztZQw/

#лайф

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

С ДР Хидео Кодзима

У каждого разработчика есть тихая мечта сделать свою игру. У меня - точно есть.

Не обязательно Death Stranding с голливудскими актёрами, музыкой и бюджетом уровня "давайте просто построим новую студию".

Хотя бы маленькую. Но такую, где механика, мир и ощущение в руках складываются во что-то большее, чем набор кода и тасок.

Сегодня Хидео Кодзиме - 63.

Кодзима - автор Metal Gear Solid, культовой серии стелс-игр. Почти 30 лет он работал с Konami - японским издателем игр. После расставания с компанией основал Kojima Productions и выпустил Death Stranding игру про курьера в разрушенном мире, которая каким-то образом превратила доставку грузов в культурное явление.
Собрал четыре его урока, которые я бы утащил в разработку, продукт и работу с командами.

1.Имя: актив, который нельзя отжать
Когда Кодзима уходил из Konami, компания убрала его имя с обложки Metal Gear Solid V. Потом не пустила его получать награду за игру, которую он, вообще-то, сделал.
Казалось бы: тебя вычеркнули из главного проекта жизни.
Но Кодзима ушёл, собрал новую студию и выпустил Death Stranding. Люди пришли не в Konami. Люди пришли на фамилию.
Компания владеет репозиторием, доменом, презентациями и продуктом.
Но не репутацией человека.
Мне нравится мысль, что личный актив строится параллельно с корпоративной карьерой.

2. Дорогие идеи надо проверять дёшево
У ранней Kojima Productions не было нормальных павильонов и съёмочных площадок.
Поэтому команда разыгрывала сцены будущей Death Stranding в пустой комнате. Зонты были оружием, сотрудники - персонажами, а съёмка способом понять: сцена вообще работает или команда очень дорого верит в ерунду.
Мне кажется, это хорошее правило и для продукта.
Если ядро продукта нельзя проверить прототипом, схемой на доске или одним абзацем текста возможно, ядра пока нет.


3. Не отдавать машине поиск смысла
Кодзима говорит, что ИИ полезен в творческой рутине. Но саму идею, замысел и искусство он оставляет человеку.

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


4. Случайности не случайны
Кодзима критикует удалёнку (не из любви к офисным турникетам).
Его мысль в другом: в удалённой работе становится меньше случайных столкновений людей. Разговоров у доски. Споров, начавшихся с ерунды. Фраз вроде: "А мы похожую проблему уже решали вот так".
Из таких штук иногда рождаются лучшие решения.
Хорошая случайность это среда, где у людей есть шанс наткнуться на чужую мысль раньше, чем она исчезнет в личных заметках.

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


❤️ - своя игра есть у каждого
😄 - своя игра это мейнстрим

#толки

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

Цифровой рубль = контроль? или новый B2B?

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

В идеале платёж должен быть простым: деньги перешли от одного участника сделки к другому быстро, прозрачно и с минимальной комиссией.

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

Покупатель зарезервировал деньги. Продавец отправил товар. Доставка подтвердила получение. Деньги ушли продавцу.
Вот это уже смарт-контракты и программируемые деньги.

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

DeFi показал, что финансовые правила можно описывать кодом.
Но потом возникает скучный, взрослый вопрос: кто из обычного малого или среднего бизнеса готов перенести туда реальные процессы?

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

А если что-то сломалось взорвалось кому звонить? В поддержку DAO?

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

Поэтому мне интересен цифровой рубль.
На YouTube его чаще обсуждают в жанре «у вас заберут свободу»: тревожное лицо на превью, красная стрелка, тотальный контроль, «всё пропало».

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

Он потенциально может стать трастовым, регулируемым аналогом части DeFi-идей.
Открытости и независимости здесь будет меньше, чем в публичной крипте. Зато у реального бизнеса может появиться то, чего ему обычно не хватает в DeFi: юридическая определённость и понятная ответственность.
Из такой инфраструктуры могут вырасти вполне земные сценарии:
- оплата поставщику после подтверждённой доставки;
- escrow для маркетплейсов и B2B-сделок;
- расчёт с подрядчиком после приёмки этапа;
- факторинг и расчёты в цепочках поставок;
- страховые выплаты по подтверждённому событию;
- целевые выплаты, субсидии и корпоративные бюджеты.

И экономика тут не менее важна, чем технология.
Для бизнеса тариф на приём платежей в цифровых рублях заявлен до 0,3% от суммы операции. Карточный эквайринг часто стоит 1–3%.

Пока, правда, неизвестно слишком многое.
Кто сможет писать такие смарт-контракты? Каким будет API? Насколько открытой окажется платформа? Как будут проверять код, разбирать спорные случаи, назначать ответственность за ошибку в контракте и подключать внешние данные?
Но именно поэтому я вижу тут интересную будущую нишу для B2B SaaS.

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

А вы как на это смотрите?
❤️ - большой брат следит за тобой
👍 - 1 сентября пойду покупать цифровые рубли
#толки

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

Взял новую консультацию по Go-проекту и тут выяснилось, что Go в нём не главный язык.

Почти вся бизнес-логика живёт в хранимых процедурах PostgreSQL: проверки, расчёты, смена статусов, куски пользовательских сценариев. Go-сервис часто просто дёргает SQL-функции и передаёт результат дальше.

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

Но когда туда постепенно уезжают правила продукта, начинается квест. Чтобы понять, почему у пользователя не сменился статус или не посчиталась сумма, нужно пройтись по Go-коду, SQL-функциям, триггерам и RLS-политикам. Новая фича легко превращается в поиски того, где на самом деле живёт нужное правило.

Раньше за такое быстро прилетало: «бизнес-логика должна быть в приложении». Сейчас, на фоне Supabase, database-first подхода и вайб-кодинга, толстая база уже не выглядит чем-то совсем диким. SQL-функция генерируется за минуту, RPC вызывается удобно, MVP собирается быстро.

Но в какой момент это перестаёт быть прагматизмом и превращается во второй backend, который тихо живёт внутри базы?

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

Если нужно посмотреть на проект, архитектуру сервиса или AI-интеграции - собрал, чем занимаюсь и как со мной связаться, здесь: https://debug-leg.ru/

#bip

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

Stripe не пропустил. Проверяю Lava для монетизации Speech to Text

Я почти дожал четвёртую версию Speech to Text моего расширения для браузера, которое за пару кликов превращает аудио в текст.

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

Я уже писал, что хочу монетизировать это чудо техники. Сначала казалось, что всё просто: есть Lemon Squeezy, есть Polar, подключай и живи.

А потом выяснилось, что под капотом всё равно Stripe.

По российскому паспорту KYC я не прошёл. Казахстанский e-residency тоже не помог. Пока моя инвестиция в казахскую экономику не окупилась (надеюсь, хотя бы Google-рекламой когда-нибудь отобьётся).

Пошёл искать дальше и, кажется, нашёл вариант: Lava.

Вот страница: app.lava.top/eryabyshev

Пока тесты такие: казахстанской картой Freedom Bank оплатить не получилось. Виртуальной британской - получилось.

То есть решение вроде есть, но радоваться рано. Надо ещё проверить, как оно ведёт себя с картами из разных стран, 3DS, подписками, возвратами и выплатами.

Дальше хочу прогнать весь happy path, разобраться, как оформить платное расширение в Chrome Web Store, и уже наконец катнуть Speech to Text v4.

Ну и главный вопрос: не отпугнёт ли Lava зарубежного пользователя?

👍 — Lava норм, я бы оплатил
🔥 — без Stripe или привычного checkout было бы стрёмно

#bip #speech_2_text

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

Резервная АКБ. Неисправность.

На приборке машины загорелось: «Резервная АКБ. Неисправность». В этот момент я понял, что моя собственная батарейка села наглухо ещё в прошлую среду.
Неделя решила проверить на прочность все мои точки отказа:

💻 На работе. В понедельник ИБ-софт намертво заблокировал рабочий ноутбук. Выбор в хелпдеске был прост: либо переход на Windows, либо сброс Mac в ноль. В итоге полнедели ушло на переустановку окружения, поиск доступов и восстановление ключей.

💳 Платёжки. Пока настраивал систему, параллельно советовался с Perplexity и тут закончилась подписка. Пошёл пополнять: на Freedom Finance пусто, шлюз через Цифра Банк отвалился из-за санкций, а в Cursor тем временем тоже сгорели лимиты. Запасной финтех-сервис с виртуальными картами сначала выдал экспайр старой карты, а при выпуске новой забраковал почту партнёрский банк. Полная блокировка рабочего инструментария.

🔌 Упал прод. Утренняя сводка метрик принесла сюрприз: ивенты new_user в speech-to-text сервисе идут, а открытий welcome-страницы нет. Оказалось, провайдер Serverspace попал под раздачу в Нидерландах и дата-центр просто обесточили силовики. Прод лежит, чинить нечем.

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

Любой успешный продукт на самом деле продаёт не фичи. Он продаёт резервную батарейку: уверенность, что если внешний мир штормит, конкретно этот кусок системы не подведёт.

Случались у вас такие каскадные недели, когда отказывало вообще всё подряд? Что в вашем сетапе сейчас самое тонкое место, если отрубятся привычные сервисы?

#толки

Вышел новый видос на YouTube 👇

Почему в 2026 году опасно жить на одну зарплату в IT.

Буду рад вашей поддержке: поставьте лайк, если зашло, и напишите в комментариях, что думаете или какой у вас был опыт. Это правда помогает ролику добраться до тех, кому тема тоже может быть полезна 🙌

👉 https://www.youtube.com/watch?v=uBW0UgkUEOs

P.S. Комментарий даже из пары слов уже супер. Алгоритмы YouTube такое любят.

Только расписал, как не вывожу и режу все сайд-активности, как вечером приходит жена:

Женя, надо помочь, у нас ЧП

Контекст: жена участвует в проекте Нейро-мама. Это не про модный AI, а про раннее развитие детей и помощь семьям, где у малышей есть неврологические отклонения и травмы.

Проблема: прямо перед стартом нового потока мам уходит единственный программист (он же саппорт и всё в одном лице). Оплаты принимаются на одном сайте, платформа с курсом и упражнениями вообще в другом месте, ничего не связано, а база годами правилась руками. Я полез разбираться, что там под капотом, и это тянет на отдельный триллер (про код и подходы «разработчика по ТЗ» расскажу отдельно, там волосы дыбом).

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

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

Как отец я вижу такие сообщения и просто физически не могу закрыть ноутбук со словами «до завтра, у меня work-life balance». Личная планка ответственности улетает в космос, а границы стираются в ноль.

А у вас как с границами в сайд-проектах?
👍 - строгие рамки: нет времени - не впрягаюсь, своё здоровье дороже
❤️ - я просто гляну одним глазком на полчаса ...и очнулся в 4 утра за дебагом

#пробую

У вас есть ровно 5 рублей. Соберите рабочий Яндекс:

Yandex Cloud - 7 ₽
Яндекс Директ - 6 ₽
Яндекс Такси - 6 ₽
Яндекс Доставка - 4 ₽
Кинопоиск - 3 ₽
Яндекс Музыка - 2 ₽
Яндекс Недвижимость - 1₽