Платформа Origination: чужой сбой — твоя проблема

Дмитрий родился в Серпухове, но осознанное детство прожил в Рязани. Он из поколения, у которого компьютера в детстве ещё не было, и появление машины сильно на него повлияло: после четвёртого класса — гимназия, к восьмому — физмат, а информатика с Паскалем и средами для алгоритмического мышления стала любимым предметом. Абстрактная математика увлекала меньше: в программировании он увидел середину между алгоритмами и результатом, который можно потрогать. Потом были сайты на WordPress за деньги и первая, отпугнувшая его попытка зайти в C++. В классе царил культ Москвы, но мотивации готовиться с репетиторами в столичный вуз он в себе не нашёл и поступил в рязанский радиотехнический университет, кажется, на прикладную информатику. Из учёбы Дмитрий вынес тайм-менеджмент и привычку самому отвечать за то, что узнал, а ярче всего запомнил учебный проект первого курса, где писал и усложнял игру. Отсюда же вывод о себе: первичен продукт, а не технология.

Первую постоянную работу он нашёл на четвёртом курсе: одногруппник обмолвился, что уже работает в банке, Дмитрий попросил порекомендовать его и получил от рекрутера неделю на подготовку — Java он толком не знал и всю неделю подтягивал её вместе с SQL. Работодателем была компания-подрядчик, директором которой стал бывший сотрудник банка, а сам банк — её основным заказчиком. Резюме попросили выложить на HeadHunter, на следующий день написали из Сбера, он сходил и туда, получил два офера и выбрал не технологии и не зарплату, а компанию: маленький молодой банк, где, казалось, что-то получится. Вышел он в 2016 году на позицию Java Junior Developer, хотя Java в работе было мало — продукты IBM, JavaScript и SQL. Отдел BPM из одиннадцати человек делал всё подряд, поэтому он трогал и заявочный процесс, и скоринг, и верификацию; клиентов тогда было около пяти миллионов, а продукты жили в одном монолите.

Переписывание коробочных решений Дмитрий называет везением: он попал к двум матёрым инженерам — оба, кажется, архитекторы, — которые отвечали за ядро заявочного процесса и сами его переписывали, рядом с ними постоянно чувствовал себя тупым — и дорос от джуна до инженера, в одиночку перенёсшего верификацию с IBM. Больших итераций было две. В первой IBM меняли на Java и Java EE с их серверами приложений, с минимумом изменений, но расширяемым флоу; сложнее всего дался самописный движок задач, хранящий состояние процесса, а шаги вынесли в отдельные пакеты с интерфейсами: запуск SIM-карт означал расширение модели и несколько ифов, ведь SIM-карте нужно меньше скоринга, чем кредитке. Главная проблема оставалась — одна команда, один сервис и одно планирование на продукты с совершенно разной экономикой. Во второй итерации общие шаги — хранение заявки, оформление, скоринг, дедупликацию — оставили в ядре, а специфику вынесли в продуктовый процесс; начали, по его воспоминаниям, с инвестиций. Александр видит здесь здоровый драйвер: автономию бизнес-вертикалей.

Следующий поворот вырос из бытовой боли: команда росла, репозитории появлялись иногда по несколько за неделю, их захотели шаблонизировать, наняли двух стажёров — и Дмитрий, став их ментором, оказался лидом первой инфраструктурной команды разработки в департаменте. Команда сделала шаблоны репозиториев, инструмент со статистикой по сломанным заявкам, чтобы поддержка приоритизировала починку, инструмент здоровья заявки — по сути бизнес-траблшутинг: понять, где заявка споткнулась по дороге через скоринг и доставку, — и общий тулинг для моков, ставший в компании популярным, потому что интеграций много и шанс, что на тесте работают все, невелик. Идея, что бизнес рисует кубики BPMN, а инженеры их реализуют, реальностью не стала: диаграмма лежит в коде и в VCS, монополии на неё нет, и рядом с заказчиком и аналитиком всё равно нужен инженер. Популярность Camunda Дмитрий объясняет золотой серединой, а обещание, что бизнес спроектирует всё сам, называет лукавством.

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

Через заместительство и группу надёжности Дмитрий пришёл к роли, где отвечает и за надёжность, и за платформу Origination, — уже два с лишним года. Само слово, объясняет он, рынку известно скорее как активация или онбординг: платформа начинается сразу после привлечения и ведёт клиента до момента, когда тот стал активным участником экосистемы. Сложность — в уравнении из полусотни с лишним крупных продуктов, каналов привлечения и требования не убить клиента этим выбором, поэтому платформа меряет конверсию в открытие и в экосистему, клиентский опыт, а как любая внутренняя платформа — time to market и time to change, налог на собственные ограничения. Ближайшие вызовы: мультипродуктовая корзина, ломающая парадигму «один клиент — одна заявка», и два разных флоу для физлиц и юрлиц. Себя он зовёт техническим менеджером: код пишет дома, влияет через крупные технические RFC и процессы, а слушателям советует найти интересный домен, встроить чтение в расписание и не запирать себя в роли «я только Java-разработчик».