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

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

Всем привет! Я, Дианов Стас, product manager. Сегодня разработка фичей и продуктов действительно очень похожа на сложный производственный конвейер, только вместо токарных станков — Jira, пайплайны CI/CD и вечный, леденящий душу вопрос «а когда в прод?» от бизнеса.

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

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

Всем привет! С вами Песковацков Илья (@ilia_peskovatskov), лид DevOps-направления. Мы два года жили прекрасно с Istio Sidecar, решали свои проблемы, в частности, с метриками и безопасностью. Но просто спокойно работать любознательным инженерам скучно и мы решили посмотреть на новый режим Ambient. В статье расскажу, как мы прорабатывали, провели и с чем столкнулись в рамках миграции своих кластеров Istio с Sidecar режима на Ambient.

Вроде познакомились, тогда погнали.

Всем привет, меня зовут Алина, я работала в роли Delivery Manager и прожила ее изнутри, поэтому хорошо понимаю, почему в большинстве компаний роль есть, а эффекта от роли нет. Сейчас объясню.

Для меня Delivery Manager отвечает не за отдельную задачу или проект, а за устойчивость delivery в целом: условно, за конвейер, через который любой проект или фича проходят предсказуемо. В первую очередь это роль, которая работает на уровне системы:

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

Он не пишет код, но влияет на условия, в которых работает вся система разработки. 

Но это в теории. А в реальности чаще всего есть некая «бумага», на которой прописано, что существует роль, отвечающая за delivery. При этом зона ответственности размыта, особенно там, где есть пересечение ролей Team Lead, SM, PO,PM, метрик нет, а влияние на результат ограничено.

Потому и эффекта нет, зато есть срывы сроков и перегруженные команды, а эскалации не снижаются.

Привет, я Максим, лидер AI-powered разработки. В 2024 году я пришёл в банк руководителем проектов, потом занимался партнёрскими интеграциями, а теперь привет, Enterprise Vibe Coding!

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

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

Я читаю IT-книги уже много лет. И много лет мирюсь с одним и тем же: «управление транзакций с помощью повествований» вместо саги, «многоразовый код» вместо переиспользуемого, «конечная точка» вместо эндпоинта. Переводчикам памятник надо ставить за то, что они пытаются, но читать от этого не легче. Особенно когда книга стоит 3000 рублей и ты застрял на одном абзаце, потому что мозг зациклился на не правильном термине.

Оказалось, я не один такой. Есть сообщество разработчиков, которые вычитывают книги до печати — проверяют терминологию, подписи к схемам, логику изложения. Я присоединился и взял на ревью книгу про промт-инжиниринг и разработку приложений на основе LLM от создателей GitHub Copilot. Это дало неожиданный эффект — я читал эту книгу настолько внимательно, насколько это возможно.

Однажды у нас появилась задача, которая (на первый взгляд) выглядела очень простой: сделать опросник в приложении. На макетах всего лишь пара экранов, несколько вопросов, кнопка «Далее». Всё красиво, не сухо, с картинками у вариантов ответа и нормальной подачей, а не в формате «Заполните обязательные поля»

Судя по макету всё просто: сверстать флоу и отправить все ответы одним POST в конце. Самый короткий путь — зашить вопросы, переходы и тексты на клиенте. Делов на пару дней — сделал и забыл. 

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

Каждая правка текста, картинки, порядка вопросов или маршрута снова уезжает в релизный цикл web, iOS и Android. А синхронизировать такие изменения между тремя платформами намного сложнее, чем кажется на старте.

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

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

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

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

На Хабре я молчал с 2014 года. Но эта история вытащила меня наружу: слишком уж хотелось зафиксировать момент, где красивая сказка про AI‑видео заканчивается и начинается реальная работа — долгая, нервная и почему‑то всегда ручная. 

Мне нужно было сделать ролик. Можно было по классике нанять видеодизайнера, можно было собирать ролик своими руками, но тут появляется он — AI. Красивый, модный, весь из обещаний. Мол, зачем тебе команда, бюджет и сложный процесс? У тебя же есть пара подписок и вера в технологии.

Я в это поверил, и вот что получилось в итоге.

В школе на переменах я играл в простую, но очень залипательную аркаду про самолётики. Почти 10 лет в голове крутилась идея возродить эту старую (но любимую) Java-игру на Android: с управлением, стрельбой, ботом и Bluetooth-режимом против второго игрока.

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

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

Привет! Меня зовут Абакар, я работаю главным техническим лидером разработки в Альфа-Банке, а в свободное время экспериментирую с ИИ разработкой и YouTube :) В этой статье расскажу, какие модели использовал, где ИИ приятно удивил, где бесславно упёрся в стену, почему Bluetooth оказался сложнее, чем казалось, и как проект в итоге доехал до релиза в RuStore.

Всем привет! С вами Артемий Лямин (@lyaminartemiy) и Иван Тренёв (@123-39). Мы работаем специалистами по разработке нейронных сетей в команде автоматизации машинного обучения Альфа-Банка. В данной статье рассказываем, как провели масштабную модернизацию нашей внутренней AutoDL-библиотеки, пересмотрев её с самых основ.

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

В результате мы покажем как превратили набор разрозненных моделей в единую воспроизводимую и расширяемую AutoDL-платформу. Предлагаем пройти этот путь вместе с нами.

Всем привет! На связи Антон Воробьёв — архитектор в Альфа‑Банке. Некоторое время назад у нас появился нативный порт C‑клиента librdkafka, который сделали наши коллеги из компании BTC. Чтобы порт работал быстрее, мы допортировали последнюю на тот момент версию librdkafka 2.3, разобрались с оптимизациями под нашу специфичную ОС, починили все юнит‑автотесты в её составе, сделали свои, и внедрили в июне 2024 года. На сегодня порт отправляет ежедневно 100 миллионов сообщений в 50+ топиков и суммарно в сотни партиций, примерный объём — 200 ГБ в неделю.

Плотно поработав с Apache Kafka мы собрали список типичных ошибок, которые появляются во время проектирования и разработки продюсеров и консьюмеров. Эти ошибки не зависят от используемой платформы, могут встретиться где угодно и могут быть совершены любым участником, как со стороны процесса приёма, так и передачи.

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

Привет! Я Женя, тимлид одной из команд Альфы. В статье расскажу, как наша команда скептиков вайб‑кодинга за две недели вывела в прод новый сервис и почему я переменил своё мнение.

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

Однажды мне понадобился быстрый способ получить мониторинг SIP-трафика в Prometheus — без установки агентов на серверы, без настройки SPAN на коммутаторе, без привязки к конкретному софту — просто подключиться к сетевому интерфейсу и видеть всё, что происходит. Причём с минимальной задержкой и без влияния на производительность самой телефонии — мониторинг не должен становиться источником проблем.

В этой статье — как я решил данную задачу мониторинга SIP-телефонии с помощью eBPF: от захвата пакетов в ядре Linux до метрик RFC 6076 с разбивкой по источникам трафика и типам устройств в Prometheus/VictoriaMetrics.

Или как дизайнеру продукта решать проблемы бизнеса и причём тут заводы с конвейерами.

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

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

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

Привет! Я Оля, лид дизайн‑системы Альфа‑Банка на мобильных платформах и я всерьёз считаю, что знания о вёрстке незаслуженно списали со счетов, особенно в 2026 году, когда дизайнеры всё чаще думают, что ИИ сделает за них всю работу, а вёрстку вообще можно не трогать.

Увы и ах. Вёрстка — это не просто «разложить прямоугольники на макете». Это мост между дизайном и кодом.

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

Всем привет! Меня зовут Мельников Виктор, middle data scientist в Альфа-Банке в Управлении по разработке инструментов автоматизации моделирования.

Год назад вышла статья о первой open source библиотеке Альфа-Банка для автоматического построения uplift-моделей Automatic Uplift Framework или же, сокращённо, AUF🐺. В ней мы рассмотрели основной функционал библиотеки с примерами кода. Также в ней можно найти ссылку на ноутбук с примером кода на открытом датасете.

Прошел год, пришла пора рассказать о новшествах, а также о результатах применения библиотеки в Альфа-Банке. Также в конце будет ссылка на обновленный пример кода, с которым ты сможешь сразу начать строить uplift-модели быстро и качественно! Достаточно создать окружение с Python 3.8 и выполнить в нем команду pip install auf. Также доступен исходный код библиотеки на GitHub.

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

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

Кровосмешение, поедание детей, похищение женщин, изувечивание мужчин, обман и предательство — так началось мое утро семиклассницы на уроке литературы 20 лет назад. Темой недели были мифы Древней Греции.

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

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

Давайте посмотрим на известных с детства героев мифов глазами взрослых людей.

Послушный ребёнок это мечта большого количества родителей. И это катастрофа.

В этой главе поговорим о цене детского послушания, субъектности ребенка и применении детерминизма как инструмента. Обсудим чувство вины и ответственности и немного затронем тему «Мужского движения».