Импортонезависимый процессинг в дипломе: архитектура ядра, метрики миграции и защита на синтетических данных
26 марта 2026 года «Солантек» и Fplus показали совместное процессинговое решение для банков, собранное целиком из отечественных аппаратных и программных компонентов. Для рынка это новость про импортозамещение. Для вас — готовый каркас темы ВКР: процессинг живёт под нагрузкой в тысячи TPS, требует отказоустойчивости, разграничения доступа по PCI DSS и стыковки с ISO 20022. Дипломнику такого масштаба не дадут ни стенда, ни транзакционных данных — и именно поэтому тема защищаема: вы проектируете архитектуру и считаете метрики на модели, а не пересказываете пресс-релиз поставщика.
Частые вопросы студентов по теме
Реальный банк даст доступ к процессингу для ВКР?
Нет. И это не блокирует работу. Стандартный путь: вы строите прототип на открытом стеке (PostgreSQL/Postgres Pro, Kafka, Go или Java), а нагрузку подаёте генератором — Locust, k6 либо собственным эмулятором клиентского потока. Данные — синтетические, но с реалистичным распределением: 70–80 % авторизаций, остальное — возвраты, reversal, сверка. В тексте ВКР явно фиксируйте допущения модели — комиссия это ценит выше, чем попытку имитировать «боевой» контур.
Импортозамещение — это техническая тема или публицистика?
Техническая, если вы работаете с совместимостью. Разбирайте форматы обмена (ISO 20022 / ISO 8583), драйверы и СУБД, схемы миграции с проприетарной платформы, стоимость переобучения персонала. Как только появляются XSD-схемы, маппинг полей и план миграции — это уже инженерия, а не лозунги.
Какой стек брать для прототипа, чтобы не переусложнить?
Минимум, покрывающий тему: сервис авторизации на Go/Java, Kafka как шина транзакций, PostgreSQL с Patroni для отказоустойчивого хранения, Kubernetes для развёртывания, OpenTelemetry для трассировки. Redis — опционально, под кэш лимитов. Не тащите микросервисную россыпь из 15 сервисов: три-четыре компонента с честной диаграммой лучше, чем двадцать нарисованных.
Как посчитать эффективность миграции, если нет «до» и «после»?
Считайте не деньги банка, а инженерные метрики: TPS при фиксированном p95, RTO/RPO после отказа узла, долю успешных авторизаций, стоимость часа на выбранной конфигурации (TCO стенда). Плюс качественная часть — покрытие требований ISO/IEC 25010 (надёжность, производительность, сопровождаемость). Этого достаточно для третьей главы.
Три темы ВКР, которые вырастают из новости
-
1. Проектирование отказоустойчивого ядра процессинга на импортонезависимом стеке.
Актуальность: кейс «Солантек» + Fplus подтверждает переход банков на отечественный стек, а значит нужны специалисты, умеющие проектировать отказоустойчивость без вендорских «коробок».
Цель: разработать архитектуру ядра авторизации с заданными RTO/RPO.
Задачи: анализ требований и стандартов; выбор паттернов резервирования; реализация прототипа; нагрузочные испытания и отчёт по метрикам.
Структура: Гл. 1 — анализ предметной области и ГОСТ 34/ISO/IEC 25010; Гл. 2 — проектирование (C4 L1–L3, UML deployment); Гл. 3 — реализация, отказы узлов, расчёт метрик. -
2. Модель миграции банковского процессинга с проприетарной платформы.
Актуальность: решение позиционируется как замена зарубежных продуктов, а сам процесс перехода почти не описан в открытых источниках.
Цель: построить план миграции с оценкой рисков и критериями переключения.
Задачи: инвентаризация компонентов; маппинг форматов и API; сценарии cutover и отката; расчёт TCO.
Структура: Гл. 1 — анализ рынка и требований; Гл. 2 — BPMN-модель перехода; Гл. 3 — расчёт экономики и проверка сценариев. -
3. Наблюдаемость транзакционного конвейера на OpenTelemetry.
Актуальность: чем сложнее связка «железо + софт» от нескольких вендоров, тем дороже простой и важнее сквозная трассировка.
Цель: спроектировать контур мониторинга с привязкой метрик к бизнес-событиям.
Задачи: выбор метрик и SLO; инструментирование сервисов; настройка дашбордов и алертов; проверка на инциденте.
Структура: Гл. 1 — теория наблюдаемости и SLA/SLO; Гл. 2 — схема сбора телеметрии; Гл. 3 — эксперимент с деградацией и выводы.
Как разложить материал статьи по главам
Глава 1: анализ — что берём из кейса и что проверяем по стандартам
Не пересказывайте пресс-релиз. Выделите три проверяемых сущности: аппаратный компонент (серверный парк Fplus), программное ядро («Солантек») и интеграционный слой (обмен с АБС, платежными системами, ЦБ). Дальше — сравнение с требованиями. Здесь уместны ГОСТ 34 (стадии и виды АС, требования к документации) и ISO/IEC 25010 для модели качества: надёжность, производительность, безопасность, сопровождаемость. Схема для первой главы — контекстная C4 Level 1:
Клиент (мобильный банк / POS)
|
v
[API Gateway / Front-end процессинга]
|
+--> [Сервис авторизации] --(sync)--> [Лимиты, Redis]
|
+--> [Kafka: очередь транзакций]
|
+-----------+-----------+
v v
[Клиринг/сверка] [Журнал операций]
| |
+----------> [PostgreSQL + Patroni] --> [Хранилище отчётности]
|
[OpenTelemetry Collector] --> [Метрики / Трейсы / Логи]Глава 2: проектирование и реализация — где комиссия ломается чаще всего
Прототип должен демонстрировать минимум три свойства: идемпотентность операций, устойчивость к падению узла и отсутствие единой точки отказа. Идемпотентность решается ключом транзакции и уникальным индексом в СУБД, отказоустойчивость — антиаффинностью подов и PodDisruptionBudget в Kubernetes:
apiVersion: apps/v1
kind: Deployment
metadata:
name: auth-core
spec:
replicas: 3
template:
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels: {app: auth-core}
topologyKey: kubernetes.io/hostname
containers:
- name: auth-core
image: registry.local/auth-core:0.3
env:
- name: OTEL_EXPORTER_OTLP_ENDPOINT
value: http://otel-collector:4317
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: {name: auth-core-pdb}
spec:
minAvailable: 2
selector:
matchLabels: {app: auth-core}Диаграммы этой главы: UML deployment (узлы, сети, кластеры), диаграмма последовательности для авторизации с таймаутами и повторными попытками, при желании — BPMN для процесса сверки. Не смешивайте нотации на одном листе: комиссия читает схему как документ, а не как коллаж.
Глава 3: тестирование, метрики и безопасность
Нагрузочный сценарий стройте в трёх профилях: пиковый (распродажа, зарплатный день), ровный и с деградацией узла. Фиксируйте метрики в таблице — так их проще защищать.
| Метрика | Инструмент | Что доказывает |
|---|---|---|
| TPS при p95 ≤ 300 мс | k6 / Locust | производительность ядра |
| Доля ошибок (error rate) | OpenTelemetry + Prometheus | стабильность под нагрузкой |
| RTO / RPO после отказа узла | chaos-эксперимент, Patroni | отказоустойчивость |
| Покрытие требований ISO/IEC 25010 | экспертная оценка, чек-лист | качество решения |
| TCO тестового стенда, ₽/час | калькуляция ресурсов | экономику миграции |
Безопасность не «прикручивайте» в конце. OWASP API Security Top 10 закрывает типовые дыры: broken object level authorization (доступ к чужой транзакции по ID), неограниченный расход ресурсов, недостаточная валидация входных сообщений ISO 20022. Требования PCI DSS описывайте на уровне зон: где хранятся PAN, где только токены, кто видит логи. Это ровно тот пункт, за который на защите задают неудобные вопросы, — лучше ответить заранее.
Чему вы научитесь на этой теме
- Проектировать отказоустойчивые схемы и обосновывать RTO/RPO, а не «просто рисовать кластер».
- Строить диаграммы C4 и UML deployment так, чтобы они совпадали с кодом.
- Считать инженерные метрики эффективности и защищать их перед комиссией.
- Оформлять документацию АС по ГОСТ 34 и требования — по ISO/IEC 25010.
- Закладывать безопасность по OWASP и PCI DSS на этапе архитектуры.
- Задачи во введении дословно совпадают с выводами по главам — построчная сверка.
- Все диаграммы имеют подпись, номер и ссылку в тексте; нотации не смешаны.
- Метрики сопровождены методикой замера и условиями эксперимента.
- Оформление ссылок и списка литературы — по ГОСТ Р 7.0.5, схемы — по ГОСТ 34.
- Код в приложении воспроизводим: есть версии зависимостей и команды запуска.
- Проверка на заимствования пройдена, цитаты из пресс-релиза оформлены как цитаты.
- Допущения модели (синтетические данные, стенд, ограничения) описаны явно.
1. Пересказ новости вместо инженерии. Первая глава превращается в рекламу решения «Солантек» + Fplus без единой диаграммы и критерия сравнения. Как избежать: сравнивайте минимум по четырём параметрам — производительность, отказоустойчивость, соответствие ГОСТ 34/ISO 25010, стоимость владения.
2. Микросервисы ради микросервисов. Студент рисует 12 сервисов, а в приложении — три заглушки. Как избежать: количество сервисов равно количеству реально запущенных контейнеров, иначе схема расходится с реализацией и это вскрывается первым же вопросом.
3. Метрики без условий замера. «Ускорили обработку на 40 %» без указания нагрузки, железа и профиля трафика. Как избежать: фиксируйте конфигурацию стенда, число виртуальных пользователей и длительность прогона.
FAQ по оформлению и защите
Где брать данные для экспериментов?
Генератор синтетических транзакций плюс открытые форматы ISO 20022 для сообщений. Обязательно опишите распределение операций и допущения — это снимает половину замечаний.
Нужен ли реальный сервер Fplus для ВКР?
Нет. Важна архитектурная совместимость: класс процессоров, требования к СУБД, отсутствие зависимости от проприетарных драйверов. Достаточно виртуального стенда и честного раздела «ограничения исследования».
Как защищать тему, если банк-партнёр не подтверждает внедрение?
Формулируйте результат как модель и прототип, а не как внедрённую систему. Комиссия оценивает методологию, воспроизводимость и обоснованность выводов, а не справку о промышленной эксплуатации.
Источник: «Солантек» и Fplus представили импортонезависимое процессинговое решение для банков (опубликовано 2026-03-26)