Быстрый фронт в базе размером 9.8 терабайт – наши требования и подходы при разработке интеграций

Меня зовут Артем Кузнецов, я руководитель направления разработки фронт-систем в ООО «Финтех Решения». Продолжу делиться опытом нашей компании – традицию, начатую на предыдущих конференциях, материалы которых уже были опубликованы:

• В 2021 году я рассказывал про наши стандарты при разработке и рефакторинге запросов.

• В 2022 году – про наши стандарты при разработке компонентов системы.

• А сейчас расскажу о том, как мы обеспечиваем скорость при интеграции с внешними или внутренними сервисами на нашей базе, которая уже перевалила за 10 терабайт.

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

Требование бизнеса при интеграциях – фронт не должен стать медленнее!

Под термином «фронт» я имею в виду нашу самописную систему на базе БСП, в которой менеджеры ведут оперативный и управленческий учет. Эта же база предоставляет АПИ и является бэком для мобильного приложения и личного кабинета на сайте. В ней автоматизированы все процессы, связанные с обслуживанием клиентов – от привлечения до контроля качества результата обслуживания. И любые доработки, которые замедляют эти процессы, напрямую влияют на показатели эффективности компании.

Перечислю неполный список интеграций, присутствующих непосредственно в основном процессе выдачи займа:

1. СМС как Аналог собственноручной подписи (АСП) – при заключении договора или оплате клиенту присылается короткий код, подтверждение которого валидирует операцию. Это подтверждение должно происходить моментально.

2. Информационные СМС – клиентам отправляются напоминания о предстоящем платеже, уведомления по остаткам платежей, с данными договора сразу после заключения и прочее.

3. Одно из требований регулятора – рассчитывать предельную долговую нагрузку (ПДН) на основании дохода клиента, а для этого получать все его долговые обязательства из Бюро кредитных историй (БКИ). У нас установлен запрет на выдачу клиентам с высоким ПДН – для соблюдения ограничений мы обязаны рассчитывать этот показатель при заключении договора займа в режиме онлайн.

4. Поскольку мы все равно делаем запрос в БКИ для расчета ПДН (а он платный), почему бы еще не предложить клиенту рефинансироваться – это тоже дополнительный процесс.

5. Выгрузка в БКИ – мы должны оперативно выгружать в БКИ не только заключенные или изменившиеся договора, но и отказы по заявкам.

6. Проверка паспорта по реестру недействительных паспортов – ее необходимо делать перед любой операцией, где используется паспорт клиента.

7. Проверка по перечням – государственные списки людей, с которыми запрещено взаимодействовать, например, из-за связей с террористами.

8. Проверки Федеральной службы судебных приставов (ФССП) – здесь мы смотрим наличие у клиента судебных производств по долгам, закрывая свои риски.

9. Проверка на банкротство – если клиент является банкротом, работа с ним также имеет определенный риск.

10. Скориста – внешний сервис, который присваивает клиентам скоринговый балл на основании своих алгоритмов, давая нашим менеджерам дополнительные данные для принятия решения.

Все эти интеграции нагружают основной процесс выдачи займа дополнительными проверками и расчетами.

Асинхронные и синхронные интеграции

По способу встраивания в основной процесс интеграции можно разделить на два вида – асинхронные и синхронные. Мы стараемся делать большинство интеграций смешанными, давая процессу-потребителю возможность использовать их так, как ему удобнее.

Про особенности каждого вида интеграций я расскажу по отдельности.

Схема асинхронных интеграций:

• При определенном событии определяются необходимые и достаточные данные и помещаются в очередь для последующей обработки регламентным заданием. В качестве очереди, как правило, выступает регистр сведений, потому что запись в регистр – это быстро, особенно если после обработки он очищается.

• Регламентное задание – это управляющий поток, который порождает дочерние потоки и порционно передает в них данные в рамках заданных настроек (размер и количество потоков).

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

• Размер и количество потоков должны настраиваться в пользовательском режиме, чтобы можно было гибко управлять нагрузкой на базу и корректировать пропускную способность. У нас настройки хранятся в настройках подсистемы интеграции.

• При успешной обработке – удаляем из очереди, при неуспешной обработке – пропускаем, фиксируем статус и дальше не обрабатываем. Впоследствии неотправленные записи обрабатываются пользователями вручную с помощью специальных инструментов.

• Контроль размера очереди дашбордом в режиме реального времени. В таком дашборде можно, в том числе, контролировать количество ошибок, например, а дальше уже отчетом получать детализацию и принимать по ней решение – корректировать настройки в ту или иную сторону.

Плюсы асинхронных интеграций:

• Основная операция не замедляется, потому что мы пишем только в регистр сведений, а это быстро. Удобно, что процесс гарантирует уникальность ключей записей очереди – не требуется контролировать наличие дублей в регистре, что дополнительно снижает нагрузку.

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

• Ниже вероятность блокировок, потому что мы управляем распределением потоков и имеем возможность разграничивать данные (данные в потоках не пересекаются).

• При необходимости можно обработать запись «вне очереди» – с помощью специального экспортного метода можно сымитировать синхронную работу, обработать конкретную запись прямо в основном процессе, не дожидаясь выполнения регламентного задания.

Минусы асинхронных интеграций:

• Запаздывание данных при отображении у клиента. Даже если регламентное задание срабатывает каждые 5 секунд, клиент в личном кабинете должен ждать, пока регламент отработает и выдаст нужный ему расчет. При проектировании интерфейса пользователя требуется учитывать этот лаг на запуск РЗ и обработку данных.

• При возникновении ошибки можно получить «снежный ком» в очереди. Нужно предусмотреть возможность ошибок внешнего сервиса и их корректную обработку.- проектировать обработчик таким образом, чтобы любое падение обрабатывалось явно. Если причиной падения являются некорректные данные в строках очереди, процесс должен продолжаться, иначе очередь начинает крутить одну и ту же запись, а дальше все копится. Мы несколько раз получали «снежный ком», пока не пришли к корректной архитектуре управления этими ошибками, исключениями. Также нужны инструменты контроля для ответственных за процесс.

• Поскольку процессы распределенные и ошибка может возникнуть в другом сеансе – для анализа цепочки требуется связанное логирование, нужны сквозные ключи, по которым можно будет воспроизвести в логах полную цепочку событий, даже если они происходили в разное время и в разных сеансах.

Пример асинхронной интеграции – та самая выгрузка в бюро кредитных историй.

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

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

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

• договор, по которому произошло событие;

• БКИ;

• событие;

• дата добавления в очередь;

• текстовая дополнительная информация – например, номер задачи при загрузке ретроданных разработчиком.

Раз в сутки регламентное задание собирает из этих накопленных данных пакет и отправляет его в микросервис – для каждого бюро у нас свой микросервис и свой формат выгрузки.

Результат отправки фиксируется в документе «Отправка в БКИ». Даже если возникает ошибка, мы все равно убираем данные из очереди и фиксируем в документе описание ошибки. И дальше уже пользователи с помощью специальных инструментов обрабатывают документы с ошибками и при необходимости заново добавляют в очередь на выгрузку те или иные события.

Ключевые принципы схемы синхронной интеграции:

• Фиксация связанных данных – в транзакции, чтобы при падении того или иного метода не потерять данные. Если что-то из связанных данных записать не получилось, отменяется запись всего, что было записано до этого – или всё успешно, или всё отменяем.

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

• Если длительность процесса превышает определенный порог, система должна выдавать алярм с возможностью провести анализ – отреагировать и, возможно, скорректировать, доработать. Тут, в отличие от асинхронного подхода, более явно видны проблемы быстродействия, так как их моментально замечает конечный пользователь..

Плюсы синхронной интеграции:

• Основной плюс синхронной интеграции – актуальность данных в режиме онлайн у пользователя. Особенно важно для процессов, где ожидание данных пользователем воспринимается особенно негативно.

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

• Проще анализировать процесс при ошибках – поскольку все вызовы происходят в рамках одного процесса, с точки зрения разработчика воспроизвести ошибку в отладке проще.

Минусы синхронной интеграции:

• Увеличение времени выполнения операции. Любая синхронная интеграция замедляет работу основного процесса. Если на стороне внешнего сервиса возникают проблемы, это негативно влияет на наш UI: мы судорожно ищем причину у себя, а она может заключаться в неисправности внешнего сервиса.

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

При разработке архитектуры все это нужно тщательно контролировать.

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

Список наших текущих проверок: террористы, МВК, РОМУ, ООН и так называемые «отказники» – если клиент совпадает с одним из перечней, выдавать ему кредит или принимать от него деньги нельзя.

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

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

Ключевой вывод: асинхронный подход при правильной архитектуре и логировании предпочтительнее. И легким движением руки он при необходимости может быть использован синхронно. Для этого необходимо правильно организовать программный интерфейс в подсистеме интеграции.

Интеграции через прямое подключение и через микросервисы

Мы применяем два основных подхода при интеграциях:

• прямое подключение из 1С к внешнему сервису;

• и использование прослойки в виде собственного микросервиса.

Для каждого случая нужно анализировать и выбирать, какой вариант больше подходит. Потому что микросервис нужен не всегда, и иногда он как «микроскоп для гвоздя».

Все наши интеграции имеют важную особенность: прод ни в коем случае не должен иметь доступа в интернет без какой-либо прослойки, потому что это опасно.

Поэтому даже прямые интеграции по HTTP у нас идут через свой отдельный микросервис. Получается интеграция через микросервис, но мы его считаем прямой интеграцией, потому что микросервис просто проксирует запросы к внешним HTTP-сервисам.

Преимущества прямых интеграций:

• Вся логика описана в одном месте – в 1С. Всю интеграцию может поддерживать 1С-разработчик, получая напрямую все ошибки от внешнего АПИ и оперативно на них реагируя.

• Нет дополнительной потенциальной точки отказа в виде микросервиса. Чем меньше этапов между начальной и конечной точкой – тем стабильнее интеграция. А используемый HTTP-прокси настолько простой, что практически не является точкой отказа – там риски минимальные.

Недостатки прямых интеграций:

• При изменении внешнего протокола или API требуются корректировки на стороне 1С и выпуск нового релиза 1С, а обновление – это остановка базы и монопольный режим.

• Документация многих внешних сервисов доступна только на иностранном языке, и не все 1С-разработчики любят и умеют с этим разбираться. Однако этот фактор нельзя считать однозначным минусом, потому что разработчики получают новые компетенции, а это развитие.

Поскольку прямых интеграций в основном клиентском процессе у нас нет, то развернутого примера не будет – постараюсь сэкономить время и рассказать больше именно про фронтовые интеграции.

Микросервисы. Схема подхода:

• У нас есть отдельный отдел, который занимается написанием микросервисов на Python. Там разработчики разбираются с внешним АПИ, делают с ним полноценную интеграцию, а мы уже работаем с этой прослойкой.

• 1С интегрируется с микросервисом по согласованному типовому внутреннему протоколу через RabbitMQ/Kafka. В итоге разработка в 1С сильно сокращается, потому что разработчики работают как привыкли – быстро, просто и по шаблонам.

• Микросервис чаще всего имеет собственную БД – которая хранит данные, используемые в качестве кеша при повторных запросах, сокращая число обращений к внешнему АПИ, а также понижая шанс потери данных.

• У микросервиса есть свои логи – иногда возникают ситуации, когда решить проблему помогают именно логи микросервиса, а не логи конфигурации.

• И микросервис может валидировать данные – как исходящие (перед отправкой в 1С), так и входящие (при получении из внешнего сервиса). При необходимости можно настраивать, что идет дальше, а что – нет.

Плюсы:

• Единый типовой подход, не нужно придумывать обвязки. Даже новый разработчик, не имеющий опыт интеграций, может очень легко по документации и примерам подключится через микросервис к внешнему АПИ, не разбираясь в нем – интегрироваться с внешними сервисами, работая по нашим шаблонам.

• Быстрая адаптация к изменениям во внешнем АПИ. При изменении протокола внешнего АПИ зачастую достаточно внести корректировки в микросервис и не менять ничего в 1С. Это сильно уменьшает time to market для корректировок при изменении внешнего АПИ.

• Микросервис выступает в качестве прокси, который может валидировать как данные, так и запросы из внешнего сервиса, обеспечивая безопасность прода. Плюс возможность балансировки нагрузки или отключения без доступа в 1С.

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

Минусы:

• Нужен отдельный специалист для разработки и поддержания микросервисов. Как правило, у 1С-ников нет таких компетенций, и требуется иметь не-1С разработчика, который будет всё это делать. Это дополнительные расходы.

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

Пример интеграции через микросервис в основном процессе: когда приходит клиент, он проходит идентификацию, мы делаем запрос в НБКИ и считаем его ПДН (предельную долговую нагрузку).

Здесь мы используем внешний кэш микросервиса для ускорения – у него есть своя база, в которой данные хранятся 30 дней, и мы при обращении к микросервису можем указывать достаточный для нас срок актуальности. Если в базе уже есть записи для этого клиента с таким сроком актуальности, мы возьмем их из базы, поскольку запросы к самому сервису БКИ платные. Это сокращает расходы: когда несколько процессов в разных местах запрашивают данные по одному и тому же клиенту, мы получаем одни и те же данные, потому что актуальность день-два нас устраивает, и мы делаем это, не платя за дополнительные запросы.

Интеграция идет через AMQP. Также проксируются данные, что тоже добавляет безопасности.

Микросервисы сильно упрощают жизнь, хотя и требуют дополнительных ресурсов – как правило, в виде дополнительного не-1С разраба или целого отдела. Но мы за эти ресурсы готовы платить, чтобы обеспечить и безопасность, и упрощение работы именно 1С-разработчикам.

Ну и микросервисы не всегда востребованы, потому что это как микроскоп там, где достаточно молотка, то есть прямой интеграции.

Так или иначе – проксируйте любые запросы! Не отправляйте прод в интернет напрямую – это очень плохо. Или за вами ночью придет ИБ :D

Внутреннее АПИ для внешних потребителей. Архитектура и стандарты, а также процесс разработки

Теперь немного про наше внутреннее АПИ, которое является бэком для локального мобильного приложения.

Основная архитектура:

• Атомарные методы – принцип «лего», кубики, из которых собираются процессы. Каждый метод АПИ выполняет одну конкретную завершенную операцию и может быть использован как обособленно, так и в рамках большого процесса.

• Валидация входящих параметров – все входящие параметры должны валидироваться.

• Методы-обертки – эти методы содержат в себе цепочки атомарных для прохода конкретного процесса, чтобы внешние потребители могли одним вызовом выполнять связанные операции.

• Единые служебные методы – методы валидации параметров, логирования, авторизации которые должны быть в одном месте, чтобы обеспечивать универсальность и простоту работы для всех процессов.

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

Процесс разработки:

1. Кейсы возможного использования – когда приходит запрос на добавление новых методов АПИ, желательно получить от заказчика закрытый список кейсов, в которых планируется использовать доработки. В первую очередь – для планирования сроков. Новые кейсы в процессе – новые сроки.

2. Сначала протокол, а потом уже разработка – 1С-разработчик перед реализацией метода «на берегу» договаривается с внешними разработчиками о протоколе, фиксируя его в OpenAPI (Swagger). И только потом происходит реализация у всех задействованных сторон. Есть общие соглашения по протоколу – форматы дат, коды ошибок, служебные поля.

3. Тестирование, mock-и и контур для проверки – методы внутреннего АПИ выпускаются сразу с покрытием тестами, а также с mock-расширениями или обработками, позволяющими тестировать их локально – использовать для того, чтобы дорабатывать, не опасаясь сломать.

4. Релиз только после проверки заказчиком, потому что это тоже риски – заказчик иногда просит что-то переделать. И проверка обязательно идет по тем кейсам, которые были определены вначале.

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

• для методов получения настроек подсистемы;

• для методов с фиксированным числом параметров.

Все методы получения настроек ведут к модулю ПовтИсп, который напрямую не вызывается в потребителях. А метод в модуле ПовтИсп обращается к методу модуля ПодсистемаСлужебный.

В модуле ПодсистемаСлужебный наш шаблон для получения настроек выглядит так, как показано на слайде.

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

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

Фундамент нашего АПИ – атомарные методы, позволяющие конструировать процессы, которые при необходимости могут быть вызваны внешним потребителем отдельно, поскольку они не являются служебными методами.

Логирование внутреннего АПИ – структура, к которой мы пришли со временем

Расскажу о той структуре полей логов, которая достаточна нам для анализа большинства проблем с методами нашего внутреннего АПИ. К этой структуре мы пришли спустя почти два года активного использования наших методов в наших же Личном кабинете и Мобильном приложении. Каждое поле было добавлено в результате расследования того или иного факапа для сокращения времени на последующий анализ. В таком виде логирование используется уже больше полугода, разве что недавно было добавлено еще одно поле – сквозной идентификатор запроса для связи с операциями вне 1С (gateway, RabbitMQ), потому что было необходимо понять, на каком месте у нас происходит задержка.

В дополнение к логированию событий в журнал регистраций мы логируем события в Graylog, используя метод Событие() обработки КлиентЛогированияGraylog. Такое логирование реализовано для событий (исключений) обработки очереди программного интерфейса, а также для конкретных методов.

Первый блок – «Технические данные». Сюда входят поля:

1. Служба – техническое поле для отборов в логах, этому полю мы устанавливаем значение «ПрограммныйИнтерфейс».

2. ОтметкаВремени – используется ТекущаяУниверсальнаяДатаВМиллисекундах(), в том числе для того, чтобы отслеживать даже небольшие промежутки между логируемыми событиями.

3. И уровень логов (поле level):

   • 3 (ERROR) – аналогично уровню журнала регистрации «Ошибка», при ошибках валидации входящих параметров.

   • 4 (WARN) – аналогично уровню журнала регистрации «Предупреждение», при исключениях и ошибках, возникающих при исполнении методов.

   • 6 (INFO) – аналогично уровню журнала регистрации «Информация», во всех остальных случаях.

Второй блок – «Данные соединения». Для разбора проблем нам на текущий момент достаточно полей:

1. _UserName = ИмяПользователя()

2. _connectID = НомерСоединенияИнформационнойБазы()

3. _session = НомерСеансаИнформационнойБазы()

4. _correlation_id = CorrelationId. Передается в свойствах сообщения при приеме сообщения из очереди программного интерфейса.

5. _request_id = сквозной идентификатор запроса (Headers.X-Request-ID). Нужен для того, чтобы выстроить полный лог процесса, включая не-1С-ные события. У нас была проблема, что мы не могли понять, где задерживается запрос. 1С-ка говорит: «Я его выполняю за 3 миллисекунды», а внешний сервис RabbitMQ говорит: «Я его вам отправил три секунды назад». Где запрос бродил 3 секунды – никто не понимает. Как раз добавление сквозного идентификатора позволило нам найти проблему с передачей на транспортной стороне.

6. _azp = идентификатор потребителя API программного интерфейса, одноименное поле из данных авторизационного токена внешнего потребителя.

И третий блок – «Данные события»:

1. _transactionStatus = XMLСтрока(ТранзакцияАктивна()) = Активность транзакции.

2. _Event = short_message = Имя события в формате «ОбщийМодульПрограммныйИнтерфейс.ПолучениеИнформации()», то есть информация о том, какой метод вызывался.

3. _login = логин контрагента, полученный из данных токена.

4. _client = контрагент, найденный по логину контрагента.

5. _operation = вызываемый метод API программного интерфейса (Headers.X-HTTP-Path).

6. _success = успешность выполнения метода – соответствуют значению success, содержащемуся в response_body при его наличии.

7. _exception = полное описание ошибки – при вызове исключения передается максимально возможный текст ошибки.

8. _request_body = тело запроса (если есть).

9. _response_body = тело ответа (если есть).

Поля _request_body и _response_body зачастую бывают крупными. Чтобы не засорять ими логи, мы, во-первых, удаляем оттуда Символы.ВК, а во-вторых, записываем значения этих полей только при установленном уровне логирования программного интерфейса «Отладка». При стандартном уровне логирования мы эти поля не пишем.

Используйте сквозные идентификаторы запросов при логировании в цепочке вызовов. По сквозному идентификатору мы потом сможем эту цепочку в логах собрать из разных сеансов и даже разных объектов инфраструктуры. Это сильно экономит время на анализ.

Контур препрод тестирования. Инструменты разработчика и бизнеса

С тестированием у нас, к сожалению, пока не все радужно. Но все же некоторый опыт в этом мы уже накопили и выработали определенные правила, которых стараемся придерживаться:

1. Для тестирования текущих разработок используется специальная демобаза, которая регулярно обновляется из DEV-хранилища.

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

3. Демо внешних сервисов/потребителей АПИ. У внешних потребителей и сервисов не всегда есть тестовые контуры, поэтому мы закрываемся mock-ами и своими обработками, имитируя их вызовы. Иногда даже приходится тестировать на боевых интеграциях, а потом подчищать данные в прод-контуре.

4. Тестирование из локальной базы разработчика. На локальной базе разработчика тоже зачастую проблема с данными, разработчик не умеет их готовить и пытается по примеру бизнеса проводить свои тесты на копии. Но мы над этим работаем! Например, в автотестах на сборках у нас уже приличное количество поставляемых данных, загрузив которые в пустую базу – уже можно проверить основные процессы без проблем.

5. Требуется стыковать специалистов разных блоков для финальных тестов – каждый смотрит в свой огород. Тут иногда тоже возникает некая дезорганизация – для этого нужен хороший ПМ, который спланирует эти моменты еще до этапа «завтра надо релизить – давай быстрее хоть как-то протестируем все вместе».

6. Отчетность «на коленке» для тестов. Даже если бизнес не заказывал, желательно потратить пару часов, но сделать для бизнеса простенькие отчеты, чтобы он не бегал во время теста к разработчику с вопросами: «Что у меня здесь регистре записалось? Чего это у меня здесь какие-то документы создались?», чтобы был какой-то объект, где он сможет все посмотреть. Это сильно упрощает жизнь. И может стать основой для боевых отчетов по процессу.

7. И очень важно – управляемость запуска фичи, возможность ее развертывания на ограниченный круг пользователей. Последние тесты все равно проводятся на проде. И тут важно построить архитектуру фичи так, чтобы ее можно было включить для части пользователей, а уже потом – для всех. Мы для этого используем расширения с дополнительными ролями.

Автотесты запускаются на предрелизной среде. На слайде показано количество тест-кейсов, которое покрыто на текущий момент.

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

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

Тестировать на проде – плохо, но иногда, к сожалению, приходится. Мы стараемся от этой практики уходить.

Выводы

Подведем итоги и сделаем выводы:

1. Для каждой ситуации нужен свой подход. Не всегда это микросервис, не всегда это прямая интеграция, даже не всегда нужен асинхронный режим работы, синхронного может быть достаточно. Всегда нужно предварительно анализировать, как будет использоваться микросервис, для чего все это в дальнейшем будет нужно, и прогнозировать развитие. У нас даже не везде есть многопоточность, потому что она там не нужна и даже в прогнозе нет потребности.

2. Используйте прокси с валидацией. В идеале прямого доступа в интернет у системы быть не должно. Только через прослойку, валидация данных в которой повышает как безопасность, так и отказоустойчивость. Валидируйте параметры, чтобы не получить какие-то необработанные exception-ы. И используйте свою БД у микросервисов в качестве быстрого кеша. Например, при получении данных из БКИ, чтобы не платить за лишние запросы – мы указываем необходимую актуальность, и микросервис возвращает данные из своего кеша, если они подходят.

3. При разработке бэк-АПИ важна универсальность – чем более атомарные методы вы используете, тем более быстрый time to market и гибкие возможности «конструирования» процессов вы получите. Организуйте для интеграций свои точки подключения в открытом АПИ, позволяющие при необходимости вызывать их обособленно в личном кабинете или мобильном приложении, не требуя доработки процесса на стороне 1С.

4. Планируйте единую структуру логирования – необходимо найти ключевые поля и сделать их логирование сквозным для всех этапов, в том числе за пределами 1С, чтобы легко разбираться в возникающих проблемах, не ходя в прод, не имитируя процессы, а прямо по логам.

5. Не ленитесь тестировать до релиза. Это вечная проблема у разработчиков, у которых нет своего QA-отдела. Лучше один раз подготовить полноценные тестовые данные, запаковав их в макеты для автоматической загрузки в любой контур тестирования, чем чинить «на горячую» на проде фичу после релиза. Написание mock’ов и автотестов при локальной разработке экономит в десятки раз больше времени при доработках, а доработки в любом случае неизбежны.

Ключевой момент по разработке, который я для себя вывел: план разработки до написания первой строчки кода – это 90% решения задачи. А кодирование – это только оставшиеся 10%

Вопросы и ответы

Вы отнесли к плюсам то, что у вас вся логика находится в коде 1С. При этом вы уточнили в минусах, что любое изменение бизнес-логики требует релиза. Не оценивали ли вы возможность выделения бизнес-процессов в отдельную систему вроде BPMN Camunda, чтобы прозрачно смотреть бизнес-процессы и мониторить их протекание? Допустим, обстоятельства меняются, добавляются новые проверки, могут удаляться какие-то старые, и если оркестрацию самого бизнес-процесса выносим во внешнюю систему, то можно корректировать процесс прямо там.

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

Мы думали над выделением блоков программного интерфейса в расширения – отделить и, возможно, переиспользовать, релизить без самого релиза, дорабатывать на лету.

Такое выделение функциональности позволило бы добиться ускорения time to market, но, к сожалению, это возможно не везде. Есть только узкий пул операций, которые и так при необходимости дорабатываются расширениями, после чего изменения переносятся в релиз, а расширение удаляется. Но в остальном на текущий момент у нас слишком много связанностей – много легаси, которое мы так или иначе переиспользуем. Поэтому пока это все только на этапе планов.

По поводу преимуществ, что все в одном месте – это удобно в плане разбора проблемы. У 1С-разработчика все перед глазами, не нужно ходить в логи микросервисов или еще куда-то, можно все смотреть в одном месте, что очень удобно.

А минус – это релизы: если нужно добавить новые метаданные, приходится выпускать релиз. Метаданные в расширения мы пока не планируем выносить, это слишком сложно.

Как вы за 30 минут обновляете базу 9,8 терабайта?

Сейчас она уже больше 10 терабайт. В течение дня готовится конфигурация релиза, собирается cf-ник, потом база устанавливается в монопольный режим, останавливаются все сеансы, и джоба в Jenkins сама все накатывает.

Вы обновляете в фоновом обновлении?

Нет. Обычным.

Какой режим реструктуризации используете: V1 или V2?

Сейчас у нас все время используется V2. Даже если в релизе нет плановых реструктуризаций, изменен только код, все равно всегда стоит 2.0.

Вам хватает 30 минут, чтобы обновиться?

Да. Если нет реструктуризаций, обновление, как правило, происходит быстрее – за 5-10 минут.

Как вы организовали логирование при асинхронном подходе?

Для каждого процесса логируются свои поля. Например, для внутренних интеграций логируется _correlation_id – ID объекта (договора, по которому идет процесс), и сквозной идентификатор – _request_id. В уникальный ключ может входить несколько полей, это вполне могут быть объекты 1С.

Почему вы не используете для микросервисов отдельную 1С-конфигурацию с HTTP-сервисами?

Так исторически сложилось. У нас есть свой Python-разработчик, который, кроме микросервисов еще работает с нейронками – у нас есть несколько нейронок, которые мы сами создали и обучили. В 1С это тяжелее сделать.

Какие инструменты используется для планирования архитектуры АПИ?

Архитектура описывается в Confluence в текстовом виде – прописываются схемы в формате Service Blueprint, структура таблиц и т.д.

Структуру АПИ прописываем в Swagger в формате JSON – у нас отдельно есть ветка в Git, которая потом портируется в Confluence. СППР мы не используем.

Как вы решаете вопрос наполнения тестовой базы? Генерируете тестовые данные скриптами?

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

С помощью этих макетов можно себе развернуть полноценную работающую настроенную локальную базу. Там будут минимальные данные, нужные для тестирования процессов – клиенты, договора и еще что-то.

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

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

Что производительнее при работе с базой в 10 терабайт – синхронные или асинхронные интеграции?

Синхронные интеграции удобнее и производительнее в плане управления потоками и компоновки данных. Но у нее есть риски: если внешний API работает с ошибками, клиент во время операции может «положить» базу или сильно замедлить ее. Асинхронная интеграция гибче: ее проще регулировать, можно уменьшить число потоков, и хотя появится лаг в обновлении данных, основной процесс не остановится.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.