Что делает интеграционный системный аналитик в банке

В каждом из направлений разработки в Ренессанс Банке работает своя группа системных аналитиков. Соответственно, их задачи, обязанности и стек технологий будут отличаться. Даниил Пронин — руководитель группы системного анализа направления интеграции — рассказал, чем занимается интеграционный системный аналитик в банке, какими инструментами он пользуется, а также поделился, что ждут в компании от соискателей. Бонусом — несколько советов о том, как готовиться к собеседованию на эту позицию.

Даниил Пронин

Руководитель группы системного анализа направления интеграции

Обязанности интеграционного системного аналитика
Хард скилы интеграционного системного аналитика
Инструменты системного аналитика
Софт скилы системного аналитика
Советы при подготовке к собеседованиям

Обязанности интеграционного системного аналитика

Системный аналитик — это переводчик с бизнес-языка на технический.

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

Чаще системный аналитик принимает требования от бизнес-аналитика. Наши системные аналитики изучают предоставленные документы (BRF, заключения бизнес-анализа), уточняют требования и согласуют их. Бывают случаи, когда требования даёт сразу заказчик, то есть бизнес. Тогда нужно в том числе провести небольшой бизнес-анализ.

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

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

Для части интеграций мы используем корпоративную шину (IBM ESB). В планах полностью отказаться от неё, однако этот процесс трудоёмкий и надо позаботиться о том, чтобы наши потребители не сильно страдали от перехода на новую архитектуру. Сейчас наше целевое решение в части интеграционных взаимодействий — это микросервисная архитектура с использованием REST API и брокеров сообщений (Kafka, IBM MQ, который потенциально будет заменён на ActiveMQ).

Первым значимым результатом работы с микросервисами является контракт сервиса. Контракт — это описанный формат взаимодействия, который включает в себя доступные методы для вызова. По сути, инструкция для пользователя. Ему неважно, что происходит внутри сервиса, главное — показать, что он может передать на вход и что получить на выход. Например, ввести фамилию, имя, отчество, дату рождения и паспорт и получить идентификатор клиента.

Во многих организациях подход code first. Аналитики объясняют, что должно приходить на вход и выход, и передают эту информацию разработке в виде оформленной спецификации, либо в виде ТЗ. Дальше разработчики реализуют модель данных на уровне кода, алгоритмов, и на её основе автоматически генерируется контракт сервиса. Это Swagger-контракт или API-спецификация.

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

Есть два способа описать Swagger-контракт: JSON-формат, либо YAML-разметка. Мы используем последнюю. В YAML-разметке мы описываем, что получится в ответ на обращение, все ограничения, и отдаём потребителям. Благодаря этому они понимают, как им работать с сервисом, и могут начать разработку. То есть им не надо ждать, пока мы напишем ТЗ и код, так как в code first контракта без кода не получится.

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

Описание сервиса дополняется UML-диаграммой последовательности. Мы визуализируем работу алгоритмов сервиса, включающих как внутренние вычисления, так и обращение к другим системам и сервисам. Это как раз удобно с композитными сервисами, потому что наглядно видно всех участников процесса.

Хард скилы интеграционного системного аналитика

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

Микросервисы

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

Наши микросервисы реализуются на Java Spring Boot, развёртываются в OpenShift и публикуются на платформе управления API под названием IBM API Connect.

Также важно уметь использовать средства просмотра логов. Мы используем Kibana, а также Zipkin для трассировки цепочки вызовов.

ESB

Это промежуточное ПО, которое представляет собой большой транспортный пересадочный узел для входящих и исходящих потоков. То есть такой хаб, на котором публикуются различные сервисы. Обращение к ним происходит через SOAP, MQ, JMS и т. п. В SOAP-протоколе, например, описывается строго типизированный формат интеграции, то, как должны выглядеть входные и выходные сообщения. Они валидируются по XSD-схеме, при этом используется XML-разметка.

Через шину потребители могут обращаться к конечным системам. Она преобразует входное сообщение в другую форму: вызов хранимой процедуры или другие интерфейсы.

Виды интеграций

Мы задаём стандартные вопросы про виды интеграций и ждём развёрнутый ответ с как можно большим количеством вариантов. Дальше предметно спрашиваем про те виды, которые у нас используются:

— REST API. В чём отличие REST API от SOAP-сервисов. Как правило, все дают базовый ответ, что REST — это архитектурный стиль, а SOAP — это протокол.

Нужно знать, какие методы используются в REST-сервисе. Многие впадают в ступор, что подразумевается под ними. Это HTTP-глаголы, поскольку REST базируется на HTTP-протоколе. Многие ограничиваются двумя методами — GET и POST, но на деле их больше. Важно понимать, чем они отличаются, если не приходилось с ними работать. Также ожидаем, что кандидат представляет, что такое REST-запрос: где можно передать входные параметры, где техническую информацию, что такое статус-коды, какие категории у них бывают.

— SOAP-сервисы. У нас они остались на шине, но иногда приходится обращаться в мастер-системы по SOAP-протоколу. Важно понимать, из каких артефактов состоит сервис, например, XSD, WSDL.

Очереди и брокеры сообщений

У нас это IBM MQ и Kafka, но важен опыт работы с любым брокером сообщений, так как их концепции похожи. Если соискатель работал с этими инструментами, то спрашиваем, какая разница в построении очередей. Нужно описать, как выглядит взаимодействие — кто подписчик, кто поставщик сообщений. Как брокер себя ведёт: толкает сообщения, либо просто хранит, пока их сам не прочитает подписчик, сколько хранит, удаляет ли. Нам важно, чтобы человек понимал принцип работы системы. Предметно знать необязательно, потому что всё-таки аналитики не проверяют средство просмотра и администрирования очередей или топиков.

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

Инструменты системного аналитика

• Спецификации. YAML-разметка, Swagger и OpenAPI.
• Для документации мы используем не стандартные страницы в Confluence или документы Word, а разметку AsciiDoc. Она лежит рядом с кодом, и в Confluence мы её подтягиваем через плагин.

• Мы работаем в инструменте PlantUML, он позволяет текстом описывать UML-диаграммы, которые затем верстаются в картинку. Всю документацию мы кодим в различных разметках и храним рядом с кодом. В принципе, работа с документацией для интеграционного аналитика в Ренессансе — это скорее кодинг, чем работа в графических и текстовых редакторах.
• Gitlab и Jira.
• Средства для отладки тестирования: Postman, SoapUI для отладки сервисов или автоматизации вызовов. Иногда аналитику необходимо сымитировать вызов. Так он самостоятельно и быстро поймёт логику работы сервиса, входные и выходные параметры и сможет решить, нужны ли доработки. Если бы он лазил в документацию (которая не всегда может быть корректно составлена), то на это бы ушло больше времени, чем предметно что-то вызвать и смотреть на результат.
• Базы данных. Как правило, системный аналитик редко ходит в БД. Но, тем не менее нужно уметь составлять базовый SQL-запрос с выборкой.
• СМЭВ — это контурное взаимодействие с различными государственными ведомствами. С его помощью можно получить актуальную информацию, соответствующую законодательству, не спрашивая клиента.

Софт скилы системного аналитика

Навыки общения будут универсальными для любого системного аналитика. Без софт скилов здесь не обойтись, потому что аналитик — связующее звено между бизнесом и разработкой. Поэтому ему важны такие навыки:

• Быть коммуникабельным. Регулярно участвовать во внутренних митингах с разработчиками. Также общаться с бизнес-аналитиками, архитекторами и отстаивать свою позицию. Поскольку не всегда те решения, которые предлагают общебанковские архитекторы, могут быть реализованы.
• Не стесняться задавать вопросы. Самый плохой вопрос — незаданный. Нужно включаться в диалог, чтобы собрать максимум требований и закрыть максимум вопросов.
• Участвовать в оценках. Мы оцениваем работу в человеко-днях, также у нас введён процент риска по ней. Чем больше неопределённости, например, непроработанных требований со стороны бизнес-анализа, отсутствие адекватной архитектуры, тем больше риска мы закладываем.

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

• Уметь собирать требования различными способами. Можно использовать различные приёмы для того, чтобы снижать степень неопределённости: брейншторминг или опросы. Участвовать также не только в опросе бизнес-аналитики, но и напрямую с бизнесом.
• Быть инициативным. В команде всегда ценны те люди, которые готовы помогать коллегам, включаться, чтобы причесать общий бэклог, забрать оттуда для себя задачу.
• Не стесняться границ, зон ответственности. Бывают случаи, когда участники команды разработки коммуницируют с коллегами только через лидов. Это порочная практика, поскольку тратится время на эту лишнюю цепочку.
• Оставаться ответственным. Не только за свои задачи, но и перед командой.

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

Советы при подготовке к собеседованиям

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

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