Финуниверситет — Информационная безопасность

ВКР по тарификации роуминга: микросервисная архитектура и метрики SLA

26 марта 2026 года оператор T2 объявил, что звонки в РФ из международного роуминга теперь приравниваются к домашним тарифам. За новостной строкой стоит серьёзная инженерная задача: пересобрать логику тарификации так, чтобы биллинг-движок мгновенно подхватывал обновлённые тарифные признаки для миллионов абонентов, работающих через разных роуминг-партнёров. Если вы пишете ВКР по Backend, микросервисам или телеком-платформам — это готовый повод сделать работу с реальной бизнес-мотивацией вместо абстрактного CRUD. Ниже — как разложить такой кейс на главы, какие метрики считать и где студенты обычно спотыкаются.

Темы ВКР и как разворачивается основная часть

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

Тема ВКРЦельЗадачи (сокращённо)Структура глав
«Проектирование микросервисной платформы тарификации роуминговых вызовов» Снизить стоимость владения правилами тарификации при частых изменениях (как в кейсе T2) 1) Анализ CDR-потока; 2) выбор паттерна rule-engine; 3) реализация сервиса расчёта; 4) нагрузочное тестирование Гл.1 — обзор роуминговой модели тарификации; Гл.2 — C4-диаграмма и код ядра; Гл.3 — метрики и отказоустойчивость
«Обеспечение SLA тарифного расчёта в распределённой среде оператора связи» Уложить p99 расчёта CDR в 200 мс при пике 5 000 операций/с 1) Мониторинг через OpenTelemetry; 2) анализ узких мест; 3) кэш тарифных профилей; 4) отчёт по SLA Гл.1 — теория SLA и ISO/IEC 25010; Гл.2 — архитектура наблюдаемости; Гл.3 — эксперимент и графики
«Автоматизация развёртывания тарифных правил для роуминга на Kubernetes» Сократить цикл выпуска новой тарифной политики с 3 дней до 2 часов 1) GitOps-пайплайн; 2) канареечные релизы; 3) откат; 4) замер MTTR Гл.1 — анализ as-is процесса; Гл.2 — стенд и конфиги; Гл.3 — оценка экономии

Как встроить кейс T2 в главы ВКР

Глава 1. Аналитика: откуда взялась задача

Начните с описания домена: как оператор получает Call Detail Record от роуминг-партнёра, почему TAP-файлы приходят с задержкой и как это влияет на биллинг. Здесь уместна BPMN-диаграмма процесса «абонент совершает вызов в роуминге → партнёр отдаёт CDR → тарификатор начисляет стоимость». Укажите в тексте, что по данным новости от 26.03.2026 условия применяются «на некоторых тарифных планах» — это доказывает необходимость версионирования тарифных профилей, а не хардкода.

Глава 2. Проектирование и реализация

Стройте C4-диаграммы: Context → Container → Component. Ниже — пример конфигурации манифеста для тарифного сервиса, который подходит как фрагмент листинга в приложение:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tariff-engine
  labels: { app: tariff-engine, tier: backend }
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
  template:
    spec:
      containers:
      - name: api
        image: registry.local/tariff-engine:1.4.2
        env:
        - name: TARIFF_CACHE_TTL
          value: "30s"
        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://otel-collector:4317"
        resources:
          requests: { cpu: "500m", memory: "512Mi" }
          limits:   { cpu: "1",    memory: "1Gi" }
        readinessProbe:
          httpGet: { path: /healthz, port: 8080 }
          periodSeconds: 5

Этот фрагмент закрывает сразу два пункта защиты: показывает владение Kubernetes и демонстрирует понимание требований наблюдаемости (OpenTelemetry-экспортёр, probe). Добавьте ER-модель хранилища: subscriber → tariff_profile → tariff_rule → cdr_event.

Глава 3. Тестирование и оценка эффективности

Здесь вы доказываете, что решение работает. Минимальный набор метрик поддомена: пропускная способность тарифного расчёта (req/s), задержка p50/p95/p99, доля ошибок расчёта, MTTR после релиза правила. Сравните таблицу «до/после» по ISO/IEC 25010 в разрезах Performance efficiency и Reliability. Если тестировали на локальном кластере — честно укажите это в ограничениях, комиссия такое ценит выше громких обещаний.

Чему вы научитесь на такой работе

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

FAQ по защите и реализации

Где студенту взять реальные данные CDR для эксперимента?

Реальные выгрузки оператора закрыты (152-ФЗ и коммерческая тайна). Рабочий путь: сгенерировать синтетический поток по закону Пуассона с пиками нагрузки утром и вечером, зафиксировать параметры в приложении и обосновать сценарий в главе 3. Это честнее, чем «выгрузил датасет из Kaggle» — комиссия сразу спросит про происхождение.

Обязательно ли делать полную интеграцию с роуминг-партнёром?

Нет. Достаточно эмулировать вход TAP-файлов мок-сервисом и описать контракт REST/gRPC в главе 2. Защищаемость зависит от того, насколько аккуратно вы формализовали контракт, а не от наличия договора с оператором.

Какие схемы ожидает нормоконтроль?

Обычно — контекстную и компонентную диаграммы (C4), ER-модель, BPMN as-is/to-be, а также диаграмму развёртывания. Все — с рамкой, основной надписью по ГОСТ 2.104 и упоминанием в тексте. Ссылка на рисунок обязательна: «см. рисунок 3.2» — иначе вернут без обсуждения.

Как посчитать эффективность, если стенд локальный?

Опирайтесь на относительные величины: снижение p99 на X% при том же железе, сокращение времени выпуска правила с Y до Z часов. Абсолютные рубли берите только с явной оговоркой «оценочно, при допущении…». За такие формулировки не снижают балл, а за «экономия 12 млн ₽» без источника — снижают.

Чек-лист перед сдачей:
  • Каждая задача из введения закрыта разделом в тексте и выводом в заключении.
  • C4/BPMN/ER-схемы пронумерованы и упомянуты в тексте главы.
  • Метрики (p95, req/s, MTTR) имеют единицы измерения и методику замера.
  • Оформление по ГОСТ 7.32-2017 и ГОСТ 34.201-89, единый шрифт и отступы.
  • Уникальность ≥ 70–80% по вузовской системе, ссылки на источники оформлены.
  • Листинги кода в приложениях не дублируются с текстом главы.
  • Ссылка на новость T2 и дата публикации указаны корректно.
Типичные ошибки студентов
  1. Хардкод тарифных ставок в коде. Кейс T2 как раз показывает: правила меняются без пересборки. Выносите их в отдельный тариф-сервис или конфиг с версионированием.
  2. Метрики «по ощущениям». «Работает быстро» — не аргумент. Нужны p50/p95/p99 и графики из нагрузочного прогона, иначе на вопрос комиссии ответить нечем.
  3. Игнор наблюдаемости. Трассировка через OpenTelemetry — не украшение. Без неё вы не докажете, на каком шаге расчёта появляется задержка, а это половина главы 3.

Материал подготовлен экспертами компании Znak-VKR. Мы помогаем студентам с 2010 года. Если вам нужна помощь в разработке темы или оформлении работы, наши специалисты готовы подсказать.

Последнее обновление: 2026-09-30

Источник: T2 отменила международный роуминг для звонков на некоторых тарифных планах (опубликовано 2026-03-26)