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

Думали сделать один «фулл-стековый» текст, но материала набралось столько, что пришлось делить его на части. И сейчас перед вами «утренняя» первая часть, в которой пообщались с Java-разработчиками Максимом Гореликовым и Кириллом Толкачёвым. Оба они как раз недавно выступили на нашей конференции Joker.

Максим Гореликов

— Для начала скажите, сколько вы уже времени в компании, на какую позицию пришли изначально, и чем занимаетесь сейчас?

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

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

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

— Интересно, а такое превращение хакатонной идеи в реальный продукт банка было единичным, или есть и другие примеры?

— Не единичным. Например, в прошлом году мы участвовали на хакатоне командой, состоящей из одних разработчиков (без product owner, дизайнера и так далее). Команда подобралась достаточно упоротая: мы там на самом деле 24 часа от ноутбуков не отходили, так что к концу были выжатые, как лимон. И так появился проект, направленный на других разработчиков Альфы… Боюсь произносить слово «Платформа», потому что все компании, стоит им чуть вырасти, лепят что-то под таким названием. Зачем мы свою «платформу» начали:

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

В какой-то момент мы прикинули и поняли, что новые команды много времени тратят на то, чтобы настроить проекты в JIRA, поднять себе Jenkins (сидеть всем на одном Jenkins — большой риск, поэтому чаще всего каждая команда у нас сама поднимает его себе). И мы сделали штуку, которая интегрирует все эти вещи: разработчик кнопку нажал, а она настроила проект в JIRA, создала job в Jenkins и так далее, вплоть до того, что нагенерила код и создала pull request с какой-то основой сервиса. Когда появится сборка этой штуки, разработчик может нажать deploy, и всё раскатится на тест. Благодаря этому разработчик и быстро начинает понимать, как всё происходит, и видит базовую структуру сервиса, который принят в этом продукте, понимает его стиль.

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

— Бывали и совсем безумные идеи, которые делались исключительно ради веселья, их нет никакого смысла потом всерьёз продвигать, зато в процессе все получили много удовольствия. Например, на одном из хакатонов мы с Кириллом и большой командой делали умный холодильник. Это вообще никак не вяжется с основными продуктами банка, но это были 24 часа веселухи. Сидели, паяли, парсили какой-то магазин с продуктами. Посреди ночи внезапно вспомнили, что самого холодильника нет, так один человек из команды его ночью раздобыл и привез, заслуженный такой, ЗИЛ:



Я вообще воспринимаю Альфу как место, где есть дух эксперимента. Когда в команде человек семь, это разработчики на всех слоях (от Java до iOS), и по девопс-религии они ещё и инфраструктуру могут себе организовать, это сохраняет атмосферу стартапа. Эта команда сама может решать все свои проблемы и принимать решения.

— Обычно слово «банк» ассоциируется у людей не со словами «дух эксперимента», а, наоборот, с безопасностью, осторожностью и консерватизмом. Насколько в ваших условиях возможно экспериментировать? Можете ли использовать что-то «интересное, но ещё не ставшее стандартом индустрии», вроде Kotlin? И насколько быстро при выходе новых версий Java или Spring переходите на них?

— Понятно, что стабильность нам в любом случае нужна. Но при этом необязательно новое тащить сразу в production. Достаточно много задач есть в техническом бэклоге. Мы пишем какие-то инструменты, если нет готовых, которые нас полностью удовлетворяют — можно экспериментировать на них.

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

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

Про скорость перехода на новые версии — от случая к случаю, зависит от того, насколько это нам реально необходимо. На Java 9, кажется, пока ни один проект ещё не переехал, но у неё релиз не так давно был. А вот со Spring 5 активно ведём эксперименты, на недавнем Joker я как раз рассказывал про него. Время близится, там есть интересные фишечки, и как только, например, выйдет Spring Boot 2.0, можно будет часть микросервисов на него перегнать. Скорее всего, там будет достаточно быстрая миграция некоторых микросервисов, из разряда «появился релиз — на следующей неделе или в конце этой недели какой-нибудь микросервис на этом появится». Потому что milestone-версии я уже попробовал, и в релизе буду более уверен, потому что буду знать, какие баги там уже позакрывали, какие критичные остались.

— А жёсткие требования со стороны законодательства («хранить такую-то информацию») и безопасности («чтобы эта информация не стала доступна посторонним») не приводят к тому, что вместо полёта фантазии приходится заниматься по пунктам тысячей скучных требований?

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

До этого мы грузили логи напрямую в Elastic, но в этом случае строить дашборды и заниматься мониторингом удобно, а вот если пустить туда кого-то, кто попытается разом выгрузить оттуда много данных, то есть вероятность, что они это всё положат. И мы выстроили инфраструктуру логирования через Kafka и очереди как раз для того, чтобы те, кто должен работать с этим, могли в любой момент прийти в эту очередь и выгрузить оттуда последние данные. А сколько они будут храниться и в каком виде — это уже, скажем так, их задача.

Человек, который хочет поэкспериментировать, у нас всегда найдёт, на чём.

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



— Со стороны банк может представляться строгой организацией со штрафами за минутное опоздание — а на практике у вас рабочие часы заданы жёстко или нет?

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

Но при этой свободе отдельные команды зачастую вводят какие-то собственные дисциплинирующие практики. Сейчас как раз будет daily scrum meeting команды, где было решено за опоздание на DSM брать маленькие штрафы. DSM у команды в 11:30, а в банке уже сумма накопилась ощутимая. Ещё немного накопится и сходим на эти деньги командой в бар.

— Как устроена коммуникация между IT-подразделением и Альфа-Банком в целом, приходится ли рядовому разработчику много взаимодействовать с не-айтишниками и получать указания от них?

— Обычно product owner конкретного продукта обсуждает планы на продуктовом комитете банка, а с командой разбирается в технических деталях реализации этого плана. При этом он не просто «получает от банка ТЗ на два листа», всё куда более гибко. Наши продакт-оунеры сами приносят идеи, а не работают чётко по директивам.

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



Если вся команда понимает, что делается и зачем, создавать что-то качественное становится легче. Ответственность несёт вся команда, поэтому и право голоса есть у каждого.

— А насколько разработчику в Альфе требуется погружаться в какую-то банковскую специфику вроде особенностей выдачи кредитов?

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

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

— К вопросу «чем больше пытаешься охватить сразу всё взглядом»: вы уже сказали, что перешли на более общую роль «за пределами продуктовых команд» — а можно подробнее?

— Да, ещё по мере набора опыта есть… Даже не буду называть это ростом, скажем, «смена направленности» разработчика. Чаще всего, когда разработчик приходит, он погружается в продуктовую команду и постепенно понимает специфику, принципы, процессы. Когда после первой пары-тройки месяцев осваивается, и у него уже нет ситуации «всё вокруг новое», он начинает заниматься ещё какой-то вспомогательной техникой. А когда он дорастает до того, что понимает все технологии и может притаскивать новые, понимает, как нужно обсудить это с другими разработчиками, чаще всего в этот момент он начинает выделяться и перестаёт работать в команде full-time. Он скорее экспериментирует с технологиями, создаёт какие-то прототипы, помогает новичкам освоиться, работает с техническим бэклогом и привлекает других. Смотрит, где что нестабильно, где что надо подтянуть, какую технологию или подход внедрить.

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



— Вы говорили про независимость команд и взаимодействие внутри команды — а сколько взаимодействия межкомандного? И часто ли люди переходят из одной команды в другую?

— Взаимодействия хватает, конечно. Если в команде всего один джавист, ему может быть скучно, может хотеться общения на Java-темы. У нас народ активно ходит по митапам и конференциям, поэтому в любом случае оказываешься в сообществе, но у нас есть и собственное сообщество Java-разработчиков. Мы проводим вечерние встречи, когда просто обсуждаем интересные вопросы: народ накидывает темы, мы за них голосуем, выстраиваем и обсуждаем. Либо в течение часа, либо (если желание обсуждать не кончилось) до бесконечности, это обычно происходит в пятницу вечером. Кто-то иногда перед конференцией доклад репетирует. Иногда обсуждаем банковские темы, иногда общетехнологические, поклонник Kotlin может прийти и вбросить: «А давайте обсудим корутины в Котлине». И пошла…

Перейти в другую команду обычно не проблема. Команды между собой общаются, и если человеку нравится чем-то другим заниматься, могут и поменяться два джависта, и нового могут найти… И смена профиля тоже возможна: если хочешь освоить что-то совсем новое для себя, можно прийти к своему товарищу по команде и сказать «Петя, мне было бы интересно попробовать там разработку. Можешь меня покоучить, можешь стать моим наставником?». Он даёт тебе небольшую задачку, и вместе с тобой делает. Такое регулярно встречается, и люди развиваются: например, разработчик развивается в full stack, тестировщики переходят в разработку.

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

— У Альфа-Банка есть продукты вроде мобильного приложения, которые наглядно видны его рядовым клиентам (в том числе среди читателей Хабра). А можешь ли привести пример проекта, над которым вы тоже ведёте или вели работу, но который для обычных физических лиц неочевиден?

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

— Перспективы блокчейна (и технологические, и юридические) до сих пор не ясны полностью — не страшно ли было компании вкладывать ресурсы в такое?

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

Стабильность нам точно важна, мы всё-таки банк, но если не будем экспериментировать и запускать что-то новое, можем ведь и отстать.

Кирилл Толкачёв

Подошедшего позже Кирилла мы в тот день как следует не расспросили — зато позже поймали на нашей конференции Joker и там задали несколько вопросов вдогонку:

— Вы в Альфе уже «Java-авторитет», от разработчиков Альфы про вас можно услышать в контексте «и тут я пошёл спросить у Кирилла» — а большая ли часть работы состоит в обсуждениях с менее опытными разработчиками? А много кода сейчас пишете самостоятельно?

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

Про то, что делаю сам — часто я начинаю какую-то работу, но не всегда заканчиваю. Моя проблема заключается в том, что времени в сутках всего 24 часа, и чтобы с пользой его проводить, не всегда приходится делать что-то самому. Если я засяду что-то делать на неделю, то много задач и важных вещей пройдёт мимо меня.

— К словам «решаем, как это пофиксить»: а можете привести недавний пример какой-нибудь жести, которую приходилось исправлять?

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

Вот этот порт у нас пересёкся между двумя группами приложений, которые отвечают за разные функции. Народ начал тыкаться. Сначала начала тыкаться поддержка, потом разработчики, причём не сразу было понятно, что случилось. И тут проблему помог разрешить Spring. В endpoint, который возвращает информацию о сервисе (какой коммит, из какого репозитория всё это было собрано — внутренние endpoint’ы), он вернул вот что: дёргаешь один раз, попадает на один инстанс приложения из одной группы, а там возвращает, что это приложение Х (определили по заголовку X-Application-id). Дёргаешь второй раз тот же самый endpoint, балансировщик маршрутизирует на другое приложение Y. Потребовалось время, чтобы выяснить, что кто-то неправильно сконфигурировал, а мы дали возможность сконфигурировать неправильно и замаршрутизировать одни и те же запросы на разные приложения.

— Уже задавали Максиму похожий вопрос, но поскольку тут на Joker у вас с Евгением Борисовым такой мощный доклад про Spring Boot, что он даже в один временной слот не влез, хочется сравнить показания: что думаете насчёт использования новых версий Spring/Spring Boot в продакшне? И как вообще в Альфе решается вопрос перехода к новым версиям?

— Доклады про Spring Boot не то, что в один слот не влезают, они уже не влезают в один день тренинга, и мы с Женей сделали два тренинга — каждый по дню — про Spring Boot, который плавно перетекал в Spring Cloud.

А про переход — зависит от ситуации. Есть технологии, которые мы, конечно же, щупаем, проверяем milestone-версии. Есть технологии, на которые мы просто смотрим, например, на gRPC сейчас смотрим. Пытаемся в Spring как-то вкрячить — написал стартер, проверил, нашёл какие-то шероховатости, понял, что нужно ждать новых релизов. Жду новых релизов, бац, и в них фичи, которые мне нужны. Например, абстракции, связанные с discovery, load balancing и так далее.

Часто приходится следить за параллельными платформами. Из самого страшного — Node.js. Например с тем же gRPC — смотришь на реализацию балансировки и восстановления коннектов для node, а там в коде комментарии в духе «to do: implement this», с пометкой «возможно когда нибудь, кому нибудь, да понадобится». Судя по коду, люди вообще не думали, что это в принципе кому-нибудь понадобится. Так как я не являюсь профессионалом в Node, то даже не взялся это допиливать — слишком долго без какой-либо абстракции реализовывать что-то в незнакомой мне системе. И получается, что даже если технологии удовлетворяют нас с точки зрения сервера, то клиенты на разных платформах не могут их использовать по причине отсутствия необходимого для надёжной работы API. Не всегда находятся люди, готовые править такие вещи, готовые вкладываться в публичные решения, продвигать свои идеи. Всегда очень радуемся, когда появляется разработчик, способный вести не только внутреннюю разработку, но и «затачивать» внешний код под нас. Благодаря таким людям, мы порой можем не ждать мейнтейнеров какого либо решения, а выпустить либо локальный фикс, либо получить исправления прям в официальной версии.

С точки зрения инфраструктуры Spring — смотрим на майлстоуны, смотрели и Spring Boot 2.0, и Spring 5.0, когда он ещё не вышел.

— Спасибо за ответы! А мы будем готовить продолжение поста.