Под занавес минувшего года банк МКБ провел IT Squad Meetup, на котором шла речь об инфраструктурных платформах и GitOps, секретах разработки продуктов, выстраивании культуры DevOps и сопровождения разработок. Эксперты сравнивали различные подходы к организации сетей, оценивали преимущества технологий тестирования, подводные камни микросервисного подхода к построению высоконагруженных ИТ-систем, делились секретами подготовки ИТ-специалистов. По интересу к мероприятию, интонации обсуждения заявленных тем и количеству вопросов, адресованных спикерам, было очевидно, что инициатива обмена идеями и опытом среди коллег упала на благодатную почву. Неформальная встреча ИТ-команд обретает силу дискуссионной площадки, где можно встретить и сторонников, и оппонентов в мире технологических идей.
Открыл мероприятие руководитель департамента ИТ-развития Московского кредитного банка Евгений Мальцев, который по воле случая выступает в роли основного лоббиста продвижения неформальных встреч ИТ-команд, причем не только в стенах МКБ. По его словам, основная цель и задача таких собраний – бороться с недостаточной освещенностью классных технологических историй, крутых примеров, опыта, делиться знаниями и благодаря этому развивать технологические решения, которые востребованы на рынке.
Примечательно, что среди нескольких десятков спикеров на этот раз лишь двое были сотрудники МКБ, остальные – представители сторонних компаний. И это дополнительный аргумент в пользу растущего интереса профессионалов к такой площадке обмена мнениями.
«Аферы» с распределением данных
«
Распределенные данные: закэшируй, если сможешь» – такую тему для выступления выбрал архитектор и руководитель группы Presale VK Didgital Tech в команде Tarantool Сергей Харламов. Представляя несколько кейсов под соусом «аферы с распределением данных», он подчеркивал, почему выгодно использовать инструмент Tarantool.
Многие участники рынка заинтересованы в том, чтобы уровень сервиса в каналах ДБО, личном кабинете не уступал предлагаемому такими ИТ-гигантами, как Google, «Яндекс», VK, прежде всего с точки зрения скорости и удобства. В частности, ускорение работы личного кабинета для банков определяет динамику процедур, связанных с выписками, обновлением балансов продуктов, причем не только дебетовых, но и с кредитными начислениями и их хитрыми правилами.
В рамках кейса под условным названием «ускоряем происходящее (показ трат) в личном кабинете» предстояло за короткий срок (примерно два месяца) резко повысить пользовательские метрики, посвященные открытию выписки за последний месяц, предоставить пользователям возможность проанализировать их траты по категориям (на основе кодов). Проблема задачи ускорения в личном кабинете состоит в том, что обычно данные хранятся в core cистеме. «Не столь хорошая затея «мучать» систему, чтобы людям «наживую» на их потоке транзакций что-то вычислять», – отметил эксперт. Специалисты предпочтут микросервисную архитектуру, напишут или выберут готовый сервис, который будет обращаться в хранилище с запросами.
В представленном Сергей Харламовым кейсе это был сервис Personal Finance Manager, который отвечает за демонстрацию пользователям выписок, а также опции показа трат по категориям. Предложенное решение – витрина транзакций (ODS) c глубиной 30 дней и возможностью хранения потоковых агрегатов. К ODS через API обращается система Personal Finance Manager, чтобы получить выписки по клиенту.
Что касается нефункциональных требований, то задачу в данном случае необходимо было решить оперативно и для большого количества объектов: примерно 6 млн клиентов, 10 млн счетов с нагрузкой около 1 тыс. транзакций в секунду.
Если этот кейс отличается удобством и легкостью, с которой достигается цель (за два месяца без реализации прикладного кода), то второй («Распределяем PostgreSQL») – нефункциональными требованиями и серьезностью сервиса. Задача – ускорить работу всех фронтовых сервисов для получения доступа к счетам, картам и клиентским данным, реализовать интерфейс доступа к распределенному региональному хранилищу на PostgreSQL. Предложенное решение – высокодоступный сервис-маршрутизатор и распределенное хранилище маппинга «объект – СУБД», де-факто прикладное шардирование PostgreSQL. Эксперт обратил внимание, что в этом кейсе использовались TarantoolDB и его нативный бинарный протокол.
Третий кейс, о котором шла речь в выступлении, востребован для персонализации сегментов, антифрода, маркетинговых заданий. При наличии большой графоподобной структуры, описывающей, например, клиентов, а также их переводы через СБП, возникает потребность находить связи между объектами, чтобы мгновенно понимать характер транзакций (хорошая или плохая в терминах фрода). Кстати, фрод бывает разный: завладеть чужими деньгами или «отмыть» их, переводя с карты на карту. Фрод второго типа особенно удобно рассматривать на таких графовых структурах, утверждает эксперт. За пределами криминальных историй подобный инструмент эффективен для персонализации сегментов, ML-моделирования.
Эксперт представил способы анализа большого графа, занимающего сотни гигабайт, и поделился оригинальным подходом к организации хранения графов (разделять их на легкие и тяжелые). Хранилище состоит из двух частей. Легкий граф (небольшой по объему) отвечает на вопрос о наличии связи между клиентами. Опционально может хранить и типы связей из тяжелого графа, который, в свою очередь, отвечает на вопросы о характере, типе и происхождении связей между клиентами. Хранится такой граф в шардированном виде.
Луковая архитектура
Большое внимание на мероприятии было уделено вопросам микросервисной архитектуры. Старший разработчик компании IBS Андрей Кузнецов представил микросервис на основе «чистой» архитектуры. Отказываясь от монолитных решений, специалисты нередко сталкиваются с вызовами, в преодолении которых помогает «чистая» архитектура. «Чистой» (или луковой) называется слоистая архитектура (находящиеся в зависимости друг от друга слои напоминают разрезанную луковицу).
Суть такой архитектуры заключается в правиле зависимостей («ничего из внутреннего круга не должно знать о внешнем»). В перечень слоев входят сущности (в нем находятся объекты реального мира – физическое лицо, банковская карта, счет и т. д.). На втором уровне – сценарии или варианты использования (бизнес-логика), на третьем – контроллеры, шлюзы, презентаторы (реализация подзадач различными вариантами). На верхнем уровне – детали (взаимодействие с системой управления базами данных, API и прочие способы взаимодействия).
Слоистой природой обусловлены преимущества «чистой архитектуры». Прежде всего, обеспечивается удобство тестирования и написания осмысленных юнит-тестов – можно проверить не только бизнес-логику, но и каждый подпроцесс. Кроме того, гарантирована независимость от баз данных, фреймворков – их можно заменить, не отказываясь от остальной функциональности. По словам эксперта, такой подход избавляет от страха изменений при внедрении новинки, когда возникает боязнь нарушить старый бизнес-процесс.
При создании микросервиса перед разработчиками стоял ряд задач: обеспечить масштабируемость (бизнес растет, с появлением новых клиентов увеличивается нагрузка), удобство для конечного пользователя (людей, работающих с продуктом), легкий on-boarding для новых разработчиков, которые приходят в команду. Не менее актуальная задача – импортозамещения, поскольку использовалась база данных Oracle. К слову, плохая архитектура хранения данных приводила к тому, что для выборки данных использовались сложные для понимания запросы. Среди других проблем – взаимосвязь с некоторыми внешними системами осуществлялась на уровне базы данных через Db-link. Все это не позволяло взять новую базу данных и перенести туда данные. Возник вопрос, «как жить» с новым микросервисом и старой базой данных. В решении обозначенных проблем помогла «чистая архитектура».
Взаимодействие реализуется на уровне деталей, создается универсальный DB-Adapter, работающий с чистыми моделями данных (выверенными). И как только команда будет готова перейти на импортозамещенную СУБД, например PostgreSQL, можно легко заменить только один модуль, не затрагивая процессы и повышая тем самым надежность.
Как показал опыт использования микросервисов, в результате отказа от «монолитного» решения на 80% повысилась надежность. На момент применения «монолита» насчитывалось 24 открытых инцидента на третьей линии, через восемь месяцев их количество уменьшилось до двух.
Большая часть выступлений на встрече отличались взвешенностью, умением представить не только сильные, но и уязвимые стороны решений. В этом же ряду презентация, с которой выступил эксперт из компании IBS. Несмотря на бесспорные преимущества «чистой архитектуры», в ряде случаев применять ее не стоит. К таковым, например, относятся приложения небольшого и среднего размера («сделал и забыл»), когда не планируется расширять их функциональность или когда не представляется возможным продумать взаимодействие всех модулей.
Правила, выведенные опытным путем
О плюсах и минусах при выборе микросервисной архитектуры в высоконагруженных банковских приложениях шла речь в выступлении java-разработчика Алексея Долженко и руководителя центра компетенций Сергея Генералова из компании ITQ Group. В центре внимания экспертов были «узкие» места микросервисной архитектуры.
Среди преимуществ подхода они отметили высокую отказоустойчивость (падение одного микросервиса не приведет к отказу всей системы), простоту (меньшее количество кода без четкого очерчивания границ ответственности) и гибкость в разработке (можно быстро вносить изменения, пробовать новые технологии), а также выборочное масштабирование (только необходимых сервисов).
Что касается минусов, то один из них – синхронизация между сервисами в случае отдельного сбоя. Сервисы связаны, и данные должны находиться в согласованном состоянии. Если один из сервисов выходит из строя, приходится «откатывать» другие. Еще одна проблема – обращение с версиями модели данных. Поступающие данные могут меняться, поэтому приходится поддерживать несколько версий.
Проблему синхронизации времени можно решить на стороне DevOps и системного администрирования либо программно – за счет добавления в контур тайм-сервиса. По мере увеличения количества микросервисов разрастаются и связи, что приводит к «спагетти-архитектуре» (изменения в одном сервисе требуют изменения в других).
Представив несколько кейсов, эксперты дали ряд рекомендаций относительно микросервисной архитектуры. Правила, выведенные опытным путем, заключаются в следующем: прорабатывать архитектуру как можно раньше, изучать пожелания на старте (а не перед каждым этапом), так как возможные изменения по ходу потребуют переделки всей системы. Не стоит рассчитывать на спокойный рефакторинг – это миф, утверждает Сергей Генералов. Особенно когда просят сделать «как-нибудь», чтобы быстрее запуститься, а потом доделать. В таком случае чаще всего приходится переделывать, причем в режиме аврала. Опрометчиво также, по мнению представителей компании ITQ Group, возлагать надежды исключительно на гибкую методологию (agile).
Одна из ключевых задач разработчика – правильно рассчитать архитектуру на старте. Если предлагают запускаться как можно раньше, рекомендуется сразу делать расширяемую модель. Обязательно стоит закладывать обратную совместимость и работу с несколькими версиями, даже если речь идет о небольшом сервисе и модуле. Не менее важно учитывать особенности ландшафта заказчика.
Индекс стоимости архитектуры и не только
Расчету индекса стоимости архитектуры посвятил свое выступление главный архитектор ГК «ДОМ.РФ» Николай Малихов. Под индексом понимается показатель, отражающий относительную стоимость АС через ее соответствие архитектурным требованиям в разрезе основных характеристик ИТ-ландшафта (надежность, безопасность, технологии, переносимость, минимизация ресурсов, потенциал развития).
Индекс, как обещает эксперт, позволяет сравнивать системы (ранжировать между собой), оценивать, насколько предлагаемое решение даст возможность сократить или, напротив, увеличить стоимость ландшафта. Предлагаемый показатель планируется использовать для принятия решения о признании системы нецелевой, для управления приоритетами технологических и бизнес-задач, а также для оценки перспективности предлагаемых доработок.
Чем выше индекс стоимости (от 0 до 100), тем качественнее система и ниже затраты на владение ею и развитие. В ходе обмена мнениями и ответов на вопросы из зала поступило предложение при определении индекса наряду с архитектурными требованиями, значимостью решения для ландшафта учитывать риски при эксплуатации системы. Еще одно пожелание авторам индекса – предусмотреть возможность перевода баллов в денежный эквивалент для наглядности восприятия.
Руководитель направления в Центре компетенций дистанционных каналов обслуживания МКБ Олег Иванов выбрал тему «Snapshot тестирование в Frontend разработке», чтобы рассказать об автоматизированных способах проверки работоспособности и контроля целостности разработанного пользовательского интерфейса.
Алгоритм работы Snapshot тестирования (сравнения образов или снимков) состоит в следующем. Созданный эталонный образ (снимок) экрана записывается на диск. При очередном запуске тестов генерируется новый образ (снимок) и сравнивается с сохраненным. Если образы отличаются либо эталон не найден, тест считается непройденным. В МКБ ввели Snapshot тестирование при реализации ряда проектов.
На встрече в двух параллельных потоках выступили представители VK Tech, VK Cloud, «Ростелеком», Bell Integrator, «Инфосистемы Джет», Nota.tech, «ДОМ.РФ», IBS, ITQ Group, «МойОфис», ITFB Group, банка «Бланк» и МКБ. В общей сложности несколько десятков спикеров из 12 компаний. И это указывает на то, что обсуждение технологических решений в предложенном формате нашло поддержку среди профессионалов. Особенно если вспомнить, что начиналось формирование дискуссионной площадки в рамках МКБ «среди своих и для своих», когда пятеро ИТ-специалистов решили поделиться с коллегами знаниями о новых технологиях и проверенных решениях.
Темы выступлений на встрече ИТ-команд выбираются исходя из перспективных направлений, в которых специалисты предпочитают развиваться. Профессиональное общение – обязательное условие оптимизации деятельности продуктовых команд. У этой точки зрения руководителей департамента ИТ-развития Московского кредитного банка, как показал третий за год IT Squad Meetup, немало сторонников и последователей.
