Легаси: сначала фасад, потом хранилище

Алексей — с Урала: родился в конце восьмидесятых в Красноуфимске, живёт в Екатеринбурге, школу закончил с серебряной медалью, а домашний компьютер появился у него классе в одиннадцатом. В IT его завёл УПК — учебно-производственный комбинат, где школьникам давали рабочую специальность: девочкам швеи и машинистки, парням автодело, а общей была специальность оператора ЭВМ. Отбирали туда тестом на сообразительность вроде петуха, снёсшего яйцо на скате крыши: правильный ответ в том, что петух яиц не несёт. Учили Basic и Turbo Pascal, а когда информатика появилась и в самой школе, Алексей сдал задачу, ушёл в столовую и, вернувшись, застал весь класс вместе с преподавателем за переписыванием его решения. Поступал он в доегэшную эпоху, когда экзамены в вузах пересекались, и выбрал профессионально-педагогический университет: много педагогики и психологии, мало компьютерных наук, а самым интересным предметом оказались базы данных — единственный экзамен, заваленный с первого раза.

После вуза он вернулся в родной город решать вопрос с армией и стал системным администратором финансового управления городского округа: учиться было не у кого, рабочий день начинался с включения сервера и заканчивался его выключением, а на собеседовании ему читали распечатанный список вопросов с ответами и сверяли формулировки — Александр называет это классическим антипаттерном интервью. Через два года Алексей вернулся в Екатеринбург, пофрилансил на PHP и попал в консалтинговую компанию с двумя департаментами: один внедрял стандарты менеджмента качества, другой — систему документооборота ижевской разработки. Главной точкой оптимизации у заказчиков оказалось параллельное согласование: бумага идёт от человека к человеку последовательно, а система позволяет ставить визы независимо. Александр вспоминает своего педантичного преподавателя по ISO 9000 — качество продукта обеспечивается только отлаженностью процессов, — и эта мысль вернётся ближе к концу разговора.

Уйти из консалтинга Алексею не дало предложение возглавить новое направление: не дорабатывать закрытую платформу, а собрать свою технологическую базу. Экономика была простой — лицензия плюс обязательная ежегодная поддержка, а многие функции мелким компаниям не нужны; тогда же пошли идеи open source и импортозамещения, а старые решения требовали Windows. Он выбрал Java и фреймворк одной самарской компании, который тогда назывался Cuba Platform: Spring, отрисовка интерфейсов и встроенный BPM-движок в одной коробке. Первый продукт для соседнего департамента качества делали почти год, и, признаёт Алексей, идея не взлетела — взлетело другое. Их с коллегой позвали аутстафферами в екатеринбургский банк на том же фреймворке писать кредитный конвейер: заявка проходила шаги до скоринга, процессы крутились в отдельно стоящей Camunda. Один из факапов он рассказывает сам: многопоточность они не понимали, на одной заявке всё работало, а на проде заявки встали и обрабатывалась ровно одна.

Через пару лет Алексей перешёл в штат сеньор-разработчиком, а когда ушёл коллега, исполнявший роль тимлида, возглавил разработку — десять-пятнадцать человек, — продолжая плотно писать код: настроечные таблицы скоринга и очереди на Oracle взамен общего MQ, который под их нагрузкой ронял остальные очереди банка. В ковид он вышел на рынок, выбирал не домен, а компанию — в крупной всегда есть ротация — и пришёл в Т-Банк разработчиком в команду реинжиниринга процессов, которая отключала Siebel. Иронично, что на прошлом месте он эту же CRM только что внедрял. Александр шутит, что система, призванная Siebel похоронить, закончилась раньше, чем Siebel выключили, и отдельно замечает, что «десант» разработчиков в чужие сервисы — практика скорее плохая. Причину отказа Алексей объясняет масштабом: бизнес вырос кратно, система под такое не проектировалась, падение Siebel означало падение банка, а подъём занимал шесть часов.

Дальше ему предложили поднять команду домена компаний: дали разработчика из Екатеринбурга, аналитика и тестировщика из Siebel и задачу отдать потребителям REST API вместо SOAP. Он спроектировал API, согласовал его со стейкхолдерами и быстро выкатил как прокси поверх Siebel — потребители переезжают на контракт, пока под капотом строится своё хранилище. Примерно за год так и вышло: появились двусторонняя репликация с выбранным мастером, где приоритет у того, что долетело в старую систему, и сервис сверки данных в разных базах по настраиваемым правилам, чтобы о расхождениях узнавать самим. Сервисы репликации сделали конфигурируемыми: правишь конфиг, перезапускаешь — подхватываются новые топики Kafka, таблицы и вызовы. Александр называет это классическим способом организации миграции: контракт согласован заранее, фасад прячет реализацию, этапы идут параллельно. Забавный эффект: без нагрузки Siebel стал работать стабильно, и оставшиеся команды не видели причин уезжать; в его команде поломки в нём иногда специально не чинили быстро, а готовность к полному шатдауну проверяли уже централизованно — отключениями на день, на два, на три, сначала на тесте, потом на проде.

Став архитектором, Алексей делал общие инструменты отдела: например, Entity Constructor, который по JSON через REST поднимает хранилище с готовым CRUD и пригодился при запуске на Филиппинах. Потом CTO сказал, что о надёжности надо думать сильнее: появились цели по доступности и инцидент-менеджмент, а Алексея назвали CRO — главным по надёжности. Здесь и пригодился стандарт менеджмента качества: инцидент — это коррекция последствий, поиск причины и корректирующее действие. Он начал с прозрачности и вопроса «почему мы об этом не знали», настроил метрики, карту услуг и наблюдаемость. Стандартных платформенных решений не хватало: Postgres шардировали, балансировщики остались своими из-за прав доступа и маскирования телефона и ФИО, поисковый индекс живёт отдельно. Про AI он говорит, что продукту тот даёт скорость, а джунам вредит: ответ на интервью есть, глубины нет. Себя он считает инженером, но сейчас ему ближе менеджмент нескольких доменов; арх-ревью он сначала писал сам, потом собрал пул ревьюеров, оставив решение за командой.