Автоматическая активация абонента за 3 минуты: телеком-кейс Visible для ВКР по архитектуре сервисов
28 марта 2026 года оператор Visible (виртуальный оператор, работающий на инфраструктуре Verizon) выкатил предложение: новые клиенты получают iPhone 17e бесплатно при подключении тарифа Visible+, причём без обязательного трейд-ина. Для маркетинга это строчка в ленте новостей. Для инженера — задача на стыке процессинга заказов, управления eSIM-профилями и биллинга. Промо держится всего несколько недель, а значит, система обязана выдержать пиковый наплыв регистраций, не развалив воронку подключений.
Именно поэтому новость полезна выпускнику ИТ-специальности. Абонентская активация — это классический сценарий, который можно защитить в дипломе: он проверяем по метрикам, ложится на стандартные архитектурные паттерны (очереди, саги, идемпотентные API) и опирается на нормативную базу вроде ГОСТ 34.602-89 и ГОСТ 19.701-90. Ниже — как превратить эту новость в содержательную ВКР, а не в пересказ пресс-релиза.
Три темы ВКР, которые вырастают из одной акции
Тема 1. Сервис цифрового онбординга абонентов MVNO
Актуальность. Акция Visible показывает: подключение за считаные минуты стало нормой рынка. Виртуальные операторы конкурируют скоростью оформления, а не покрытием — значит, узкое место смещается в область интеграций.
Цель: спроектировать и реализовать прототип сервиса сквозного подключения абонента с электронной SIM.
- проанализировать жизненный цикл заказа в терминах eTOM и выделить точки отказа;
- построить архитектуру интеграции с системами KYC, биллинга и профилирования eSIM по GSMA SGP.22;
- реализовать идемпотентный REST API на OpenAPI 3.1 и сагу отката при сбое оплаты;
- оценить время до первой услуги (time-to-first-value) на нагрузочном стенде.
Структура. Глава 1 — обзор рынка MVNO, модели eSIM и стандартов GSMA/3GPP. Глава 2 — проектирование: контекстная диаграмма, диаграммы последовательности, схема развёртывания. Глава 3 — реализация прототипа, нагрузочное тестирование, расчёт экономического эффекта от автоматизации ручных операций.
Тема 2. Микросервисный тарифный движок с поддержкой промо-кампаний
Актуальность. Бесплатное устройство в обмен на привязку к тарифу — это не подарок, а расчёт: оператор зарабатывает на удержании. Промо-условия должны корректно применяться в биллинговом цикле, иначе компания теряет деньги на каждой активации.
Цель: разработать сервис расчёта тарифов и применения скидочных правил с проверяемой моделью данных.
- спроектировать модель тарифа, опций и промо-правил в терминах SID;
- обосновать выбор хранилища (реляционное ядро + кэш горячих правил);
- реализовать правила начисления в виде изолированных модулей с юнит-покрытием;
- проверить корректность на граничных кейсах: досрочное расторжение, смена тарифа, неоплата.
Структура. Глава 1 — биллинговые модели и стандарты. Глава 2 — проектирование сервиса и схемы данных. Глава 3 — тестирование, включая мутационное, и оценка трудоёмкости поддержки.
Тема 3. Контур наблюдаемости и надёжности телеком-платформы
Актуальность. Пиковая промо-нагрузка — идеальный полигон для SRE-подхода: без метрик активаций и трейсинга заказов инцидент ищут «на глазок».
Цель: построить систему мониторинга ключевых бизнес-операций телеком-сервиса и обосновать целевые SLO.
- инструментировать сервисы через OpenTelemetry (трассы, метрики, логи);
- определить SLO и бюджет ошибок для операции «активация eSIM»;
- настроить алерты по симптомам, а не по причинам, и проверить их на chaos-экспериментах;
- рассчитать RTO/RPO для профилей и биллинговых транзакций.
Структура. Глава 1 — обзор подходов к наблюдаемости и стандарта ISO/IEC 25010 в части надёжности и производительности. Глава 2 — архитектура телеметрии. Глава 3 — эксперименты, дашборды, расчёт стоимости хранения метрик.
Аналитическая глава: как обосновать стек, а не «выбрать модное»
Первая глава диплома чаще всего проваливается в перечисление технологий. Спасает сравнительная таблица с явными критериями — и желательно с весами, чтобы вывод был не вкусовым, а вычислимым.
| Критерий | Собственный сервис на Kubernetes | Готовый BSS-as-a-service | Серверлесс-функции |
|---|---|---|---|
| Скорость запуска | 6–9 месяцев | 4–8 недель | 2–4 месяца |
| Гибкость промо-правил | Высокая | Ограничена вендором | Высокая |
| Зависимость от поставщика | Низкая | Критичная | Средняя |
| Прогноз TCO на 3 года | Средний | Высокий (лицензии + трафик) | Низкий при плавающей нагрузке |
| Соответствие требованиям хранения ПДн | Полный контроль | Требует проверки договором | Зависит от региона облака |
| Порог входа для студента | Высокий | Низкий | Средний |
Такой таблицы достаточно, чтобы обосновать собственный вариант разработки: контроль над персональными данными и гибкость промо-механики перевешивают более длительный срок вывода на рынок. Веса критериев задайте экспертным методом (метод парных сравнений Саати — хорошо защищаемая штука на защите) и приложите расчёт в приложение.
Проектная часть: что рисовать и что кодировать
Здесь статья даёт вам готовый набор сценариев. Возьмите поток подключения: заявка → проверка личности → выбор номера → резервирование eSIM-профиля → оплата первой подписки → выдача профиля → подтверждение активации в сети. Семь шагов, шесть интеграций, минимум три точки отказа.
- Контекстная диаграмма (ГОСТ 19.701-90 для схем, UML для потоков): внешние системы — шлюз оплаты, провайдер KYC, менеджер профилей eSIM, система расчёта, CRM.
- Диаграмма последовательности для happy path и для отката: если оплата не прошла — профиль возвращается в пул, номер освобождается, заявка помечается как отменённая. Реализуйте это как сагу с компенсирующими транзакциями и опишите в тексте, почему двухфазный коммит здесь не подходит.
- Схема развёртывания: сервисы в контейнерах, очередь событий, шлюз API с ограничением частоты запросов. Обязательно покажите, где живут персональные данные и как ограничен к ним доступ.
Идемпотентность — обязательный пункт. В промо-период клиенты жмут кнопку «Подключить» по три раза, и без ключа идемпотентности вы получите три списания и три профиля. Фрагмент контракта, который стоит показать в приложении к диплому:
POST /v1/activations
Idempotency-Key: 8f2c-...-a41d
{
"msisdn": "+7XXXXXXXXXX",
"tariffCode": "VISIBLE_PLUS_PROMO",
"esim": { "profileType": "consumer", "rspVersion": "SGP.22" }
}
# 201 Created — первая обработка
# 200 OK — повторный запрос, возвращается исходный результат
Тестирование и метрики: чем доказать, что решение работает
Раздел испытаний — то место, где комиссия задаёт неудобные вопросы. Готовьте цифры заранее. Нагрузочный профиль стройте по мотивам новости: пик регистраций в первые часы после объявления, затем длинный хвост.
| Показатель | Целевое значение | Инструмент |
|---|---|---|
| Успешность активаций | ≥ 99,5 % | Счётчики бизнес-событий |
| Время до первой услуги, p95 | ≤ 180 с | Трассировка OpenTelemetry |
| Задержка API оформления, p95 | ≤ 400 мс | k6 / Locust |
| RTO / RPO биллинговых транзакций | 15 мин / 1 мин | Репетиция отказа СУБД |
| Частота успешных релизов | ≥ 1 в неделю | Данные CI/CD-пайплайна |
Отдельно опишите chaos-эксперимент: погасите сервис профилирования eSIM и покажите, что заявки не теряются, а накапливаются в очереди и обрабатываются после восстановления. Такой сюжет в третьей главе читается как инженерный результат, а не как отчёт о запуске тестов.
Чему вы научитесь на этой теме
- разбирать продуктовый кейс до набора интеграций, рисков и метрик;
- обосновывать архитектурный выбор через критерии и веса, а не через «популярность технологии»;
- проектировать процессы с повторной обработкой и компенсациями;
- строить наблюдаемость и связывать её с SLO, а не только с графиками загрузки процессора;
- оформлять результаты по ГОСТ 34.602-89 и ГОСТ 19.701-90 так, чтобы к тексту не было претензий у нормоконтроля.
Типичные ошибки на защите
1. Смешение моделей сервисов. В тексте одновременно фигурируют IaaS, PaaS и «облако» без разграничения. Лечится таблицей ответственности: что берёт на себя провайдер, что вы. Одна страница — и вопрос снимается.
2. Ноль измеримых показателей. «Система работает быстро» — не результат. Введите базовую линию (до внедрения) и целевое значение, укажите методику замера и число прогонов.
3. Забытые требования ГОСТ при оформлении ТЗ. ГОСТ 34.602-89 задаёт состав технического задания. Если в дипломе есть ТЗ без разделов о требованиях к системе и к видам обеспечения, нормоконтроль вернёт работу. Загляните в стандарт до того, как верстать приложения.
Чек-лист перед сдачей
- источник процитирован корректно: дата, автор, ссылка, и указано, что именно вы взяли из новости;
- каждая задача из введения закрыта конкретным разделом и выводом;
- архитектурные схемы подписаны, легенды читаемы, обозначения соответствуют ГОСТ 19.701-90;
- все метрики приведены с методикой измерения и единицами;
- список литературы содержит стандарты с полными реквизитами, а не только ссылки на блоги;
- объём приложений не съел основную часть: код — в приложение, выжимка логики — в главу;
- проверена согласованность терминов: одно понятие — один термин во всём тексте.
Частые вопросы студентов
Насколько сложно реализовать такой проект в одиночку за семестр?
Вопрос решает масштаб. Возьмите не полноценный операторский биллинг, а прототип одного потока: подключение с электронной SIM на заглушках внешних систем. Реально уложиться в 8–10 недель, если интеграции эмулируются контейнерами с фиксированными ответами. Сложность честно описана в разделе ограничений — комиссия это ценит.
Обязательно ли писать код для дипломной работы?
Формально не всегда, фактически — для архитектурной темы лучше иметь работающий прототип хотя бы по ключевому сценарию. Он даёт вам цифры производительности и надёжности, без которых защита превращается в пересказ литературы. Если код небольшой, усильте проектную часть: подробные диаграммы, спецификации API, расчёт экономики.
Как оформлять диаграммы: UML или ГОСТ?
Практика вузов разная. Чаще всего нормоконтроль требует схемы по ГОСТ 19.701-90, а логику взаимодействия допускает показывать в нотации UML. Уточните на кафедре до того, как что-то рисовать. Компромиссный вариант: структурные схемы — по ГОСТ, диаграммы последовательности — UML с расшифровкой обозначений в тексте.
Где взять данные для расчётов и тестов?
Реальные абонентские базы использовать нельзя — это персональные данные. Генерируйте синтетический набор: профиль нагрузки, распределение по тарифам, доля отказов оплаты. Источники для калибровки — открытая статистика регулятора, годовые отчёты операторов, технические статьи. Все допущения фиксируйте в тексте отдельным абзацем.
Если тема уже выбрана, но не хватает времени на расчёты, диаграммы и оформление — вы можете заказать диплом по вашему техническому заданию. Мы выделяем на работу до 120 часов, консультация по структуре бесплатная, тема может быть любой — от архитектуры микросервисов до экономики внедрения.
Источник: You can get a free iPhone 17e at Visible for a limited time - no trade-in required (опубликовано 2026-03-28)