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

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

А ещё про то, как это всё дело чинить.

Привет! Я Маша, лидер стрима в HR Tech команде Альфы. В этой статье расскажу, как мы сделали «Открыточную» и теперь помогаем доставлять эмоции сотрудникам.

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

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

Каждый месяц в игры внутри приложения Альфа-Банка заходят миллионы пользователей. В игре человек выполняет задания ради бонусов или энергии, а для банка эти задания — реальные действия: оплата ЖКХ, заправка через приложение или заказ новой карты. Это отличный способ нативно продвигать продукты без назойливых рекламных баннеров.

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

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

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

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

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

Всем привет! Мы команда прикладных исследований и разработки моделей глубокого обучения Альфа-банка. В этой статье мы хотели бы рассказать о наших самых актуальных разработках в области нейросетевых подходов к решению задачи кредитного скоринга физических лиц. Ранее мы уже писали на эту тему, но последняя статья предыдущего цикла датирована 2023 годом. За это время мы смогли значительно продвинуться в исследовании способов решения данной задачи.

Привет друзья! Меня зовут Тима, я дизайнер в дизайн-системе Альфа-Бизнес.  Когда в крупном финтех-продукте заходит речь об обновлении иконок, со стороны это кажется легкой творческой задачей на пару недель: сел, порисовал в Figma, выгрузил — готово. Но в реальности бигтеха любая попытка просто «освежить визуал» моментально сталкивается с суровой инфраструктурой, сотнями легаси-компонентов и хаосом, который годами копился в коде и макетах.

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

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

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

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

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

Всем привет! Я, Дианов Стас, 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 и столкнулись с неправильным использованием ключа партицирования, сайзингом топика, с ошибками в параметрах топика, с нарушением идемпотентности и тому подобное, то статья сэкономит вам время и силы.