Автоматизация возвратов в телеком-биллинге: архитектура self-service и метрики для ВКР
30 марта 2026 года «Билайн» запустил необычную для рынка процедуру: абонент может запросить возврат списанных средств без объяснения причин. Технически за такой «кнопкой» в приложении стоит целый контур — от идемпотентного API приёма заявки до сверки с биллингом, антифрод-скоринга и аудита в хранилище. Для ИТ-специальностей это почти готовый кейс: бизнес-требование простое, а архитектурных решений и вопросов по качеству — на целый диплом.
Почему это важно для выпускника прямо сейчас. Телеком отказывается от тяжёлой кастомизации в сторону продуктовой модели: клиенту дают управляемы�� сервис, а внутри — событийная шина, сага-паттерны для распределённых транзакций, наблюдаемость. Тема, построенная на таком сценарии, автоматически попадает в тренд, не выглядит надуманной и легко защищается: у вас есть реальный публичный кейс и понятная бизнес-метрика — процент возвратов и время обработки заявки.
Темы ВКР, которые «ленятся» из этой новости
Тема 1. Сервис возвратов в биллинге на микросервисной архитектуре
Актуальность. Кейс «Билайна» показывает: возврат больше не отдел ручных заявок, а продуктовая функция. Значит, нужна система, устойчивая к пиковым нагрузкам и к повторным запросам пользователя.
Цель. Спроектировать и прототипировать сервис обработки заявок на возврат с гарантией идемпотентности и полным журналом операций.
- Разобрать бизнес-процесс возврата (as-is и to-be) и сформулировать функциональные требования.
- Обосновать выбор архитектурного стиля (микросервисы или модульный монолит).
- Реализовать прототип приёма заявки с идемпотентным ключом.
- Провести нагрузочное тестирование и оценить стоимость владения.
Возможная структура. Глава 1 — анализ предметной области и стандартов (ГОСТ 34.602-89, ISO/IEC 25010). Глава 2 — проектирование: диаграммы компонентов, последовательностей, схема БД. Глава 3 — реализация, тестирование, расчёт экономического эффекта.
Тема 2. Наблюдаемость контура возвратов на OpenTelemetry
Актуальность. «Возврат без объяснения причин» — это поток операций, которые надо мониторить: аномалии по суммам, всплески отказов, деградация времени ответа. Без метрик такой сервис выпускать нельзя.
Цель. Построить систему сбора трассировок и метрик для сервиса возвратов и связать их с SLO.
- Классифицировать метрики по категориям (RED, USE) и обосновать выбор.
- Настроить экспорт телеметрии через OpenTelemetry-коллектор.
- Определить SLO для сценария «возврат за 1 минуту».
- Построить дашборд и оценить накладные расходы на инструментацию.
Структура. Глава 1 — обзор подходов к наблюдаемости и стандартов качества ISO/IEC 25010. Глава 2 — архитектура контура телеметрии. Глава 3 — эксперименты, дашборды, расчёт эффекта от снижения среднего времени разбора инцидента.
Тема 3. Интеграция CRM и биллинга по паттерну Saga
Актуальность. Возврат — типичная распределённая транзакция: списать из биллинга, вернуть через платёжного провайдера, обновить статус в CRM. Классический ACID тут не работает, и без корректной модели компенсаций не обойтись.
Цель. Спроектировать оркестрацию саги для процесса возврата с гарантией согласованности и отказоустойчивости.
- Сравнить хореографию и оркестрацию применительно к конкретному сценарию.
- Описать компенсирующие транзакции и сценарии отказа.
- Реализовать прототип на Kafka или RabbitMQ.
- Оценить RTO/RPO и подготовить чек-лист устойчивости.
Структура. Глава 1 — анализ распределённых транзакций и обзор паттернов. Глава 2 — проектирование саги и диаграммы состояний. Глава 3 — эксперименты с отказами (chaos-тестирование), выводы.
Аналитическая глава: как встроить кейс «Билайна»
Здесь не нужно пересказывать новость. Задача первой главы — доказать, что ваша тема не выдумана. Работает такая связка: сначала обзор рынка телеком-продуктов с self-service возвратами, потом — анализ требований к таким системам, затем — сравнение архитектурных подходов.
| Критерий | Монолит | Модульный монолит | Микросервисы |
|---|---|---|---|
| Скорость первого релиза | Высокая | Высокая | Низкая |
| Независимое масштабирование | Нет | Частично | Да |
| Сложность эксплуатации | Низкая | Средняя | Высокая |
| Пригодность для возвратов | Средняя | Высокая | Высокая при зрелом DevOps |
Отдельный подраздел стоит отдать нормативке: ГОСТ 34.602-89 для ТЗ на автоматизированную систему, ГОСТ 19.701-90 для схем алгоритмов, ISO/IEC 25010 для нефункциональных требований. Это не «для галочки» — на защите часто спрашивают, почему вы выбрали именно эти метрики качества.
Проектная часть: что рисовать и как
Минимальный набор диаграмм, который ожидает комиссия по теме возвратов:
- Контекстная диаграмма системы (кто вызывает API возврата, кто получает уведомления).
- Диаграмма компонентов с событийной шиной и хранилищем аудита.
- Диаграмма последовательности для happy-path и для отказа платёжного провайдера.
- Диаграмма состояний заявки: создана → проверяется → одобрена → исполнена / отклонена / отменена.
Пример идемпотентного приёма заявки — маленький, но показательный фрагмент, который хорошо смотрится в приложении:
POST /api/v1/refunds
Idempotency-Key: 7c1a...e2
{
"subscriber_id": "42-0001",
"amount": 149.00,
"reason": "no_explanation_required"
}
# 202 Accepted → возвращает refund_id и текущий статусПроектная глава выигрывает, если вы явно свяжете решение с кейсом статьи: «требование возврата без указания причины означает, что сервис обязан строить решения о сумме и периодичности возвратов на собственной риск-модели, а не на тексте обращения». Дальше — описание риск-модели, порогов, аудита.
Тестирование и метрики: чем доказать качество
Третья глава — то, где большинство работ проваливается. Студент описывает «мы протестировали», но не показывает цифры. Соберите компактный, но честный набор:
- Нагрузочное тестирование — RPS на приём заявок, p95 и p99 времени ответа, поведение при пиковой нагрузке.
- Отказоустойчивость — RTO и RPO для контура возвратов, сценарий потери одного узла.
- Наблюдаемость — число покрытых трассировкой операций, доля операций с метками, алерты по SLO.
- Качество кода — покрытие тестами (хотя бы для критичных модулей), доля успешных сборок в CI/CD.
| Метрика | Инструмент | Целевое значение |
|---|---|---|
| p95 времени ответа API возврата | JMeter / k6 | ≤ 300 мс |
| RTO при отказе узла | Chaos Mesh | ≤ 60 с |
| Доля операций с трассировкой | OpenTelemetry Collector | ≥ 95 % |
| Покрытие критичных модулей | JUnit / pytest | ≥ 70 % |
По каждой цифре на защите должен быть ответ «как измерил». Приложите конфигурацию тестов и выгрузку отчётов — комиссия это любит.
Чему вы научитесь на такой теме
Не абстрактному «проектированию ИС», а конкретным вещам: формулировать нефункциональные требования и связывать их с ISO/IEC 25010; выбирать между монолитом и микросервисами с обоснованием, а не по вкусу; работать с событийными брокерами и паттерном Saga; настраивать OpenTelemetry и читать метрики; оформлять техническую документацию по ГОСТ 34 и 19; и, что важно для интервью, — объяснять бизнес-логику решения.
- Подмена терминов SaaS/PaaS/BaaS без обоснования. На защите сразу спросят, почему вы назвали внутренний сервис SaaS. Используйте точную терминологию, привязанную к модели поставки.
- Отсутствие метрик эффективности. «Стало удобнее» — не аргумент. Любой эффект должен иметь числовое выражение: время обработки, доля автоматических возвратов, стоимость транзакции.
- Игнорирование требований ГОСТ 34.602-89 и ГОСТ 19.701-90. ТЗ и схемы оформляются по стандарту. Формальные «претензии» рецензента часто касаются именно этого.
- Копирование схем из открытых источников без адаптации. Комиссия узнаёт картинки. Рисуйте свои, под свою систему.
FAQ: короткие ответы на частые вопросы
Обязательно ли писать код, если тема про архитектуру возвратов?
Формально — нет, но прототип сильно повышает защищаемость. Достаточно реализовать один-два ключевых сценария (приём заявки с идемпотентностью и обработка отказа платёжного провайдера). Остальное допустимо оставить в проектных диаграммах и обоснованиях.
Где брать тестовые данные, если нет доступа к реальному биллингу?
Синтетические данные + генератор на Faker/собственном скрипте. Обязательно опишите модель данных и правила генерации — это отдельный подраздел приложения. Реальный объём абонентов не нужен, важна реалистичность распределения сумм и частоты обращений.
Как оценить экономический эффект от автоматизации возвратов?
Сравните стоимость ручной обработки заявки (время оператора × ставка) и автоматической (стоимость транзакции + эксплуатация). Умножьте на прогнозный объём обращений. Даже приблизительная модель с явными допущениями выглядит убедительнее, чем её отсутствие.
Какой объём анализа в первой главе считается нормальным?
Обычно 25–35 страниц на главу. Не растягивайте теорию: лучше меньше общих слов, но больше анализа конкретных архитектур и стандартов, применимых к вашей задаче.
Чек-лист «что проверить перед сдачей»
- Каждая задача из введения отражена в выводах и в оглавлении.
- В тексте есть ссылка на источник темы и дата (актуальность не «по слухам»).
- Диаграммы оформлены по ГОСТ 19.701-90, есть подписи и легенды.
- Метрики качества привязаны к ISO/IEC 25010 и имеют целевые значения.
- ТЗ на систему оформлено по структуре ГОСТ 34.602-89.
- Все цифры и графики имеют источник: собственный эксперимент или отчёт инструмента.
- Список литературы содержит актуальные источники за последние 3–5 лет.
- Аннотация, введение и заключение не противоречат друг другу.
Источник: Билайн запустил возврат денег за связь без объяснения причин (опубликовано 2026-03-30)