Платформа онлайн-отбора в дипломе: архитектура видеоприёма и метрики нагрузки
МТС вместе с ГИТИС открыли регистрацию на удалённый отбор абитуриентов из Пермского края. За этой новостью легко не заметить главного: под капотом работает полноценная распределённая система — приём видеовизиток, потоковая доставка, автоматизированная проверка заявок, интеграция с личным кабинетом и расписанием прослушиваний. Для выпускника ИТ-направления это не просто инфоповод, а готовый прототип реальной задачи. Те же паттерны встречаются в EdTech, телемедицине, сервисах видеоарбитража и записи на приём.
Почему это важно именно сейчас? Приёмная кампания даёт предсказуемый, но очень резкий пик нагрузки: за две-три недели количество загрузок видео вырастает в десятки раз, а требования к доступности остаются жёсткими. Такой профиль трафика плохо ложится на классический монолит и хорошо — на микросервисы с автоскейлингом, объектным хранилищем и CDN. Всё это отлично защищается в ВКР, потому что поддаётся измерению: задержка, пропускная способность, стоимость обработки одной визитки.
Три темы ВКР, которые вытекают из кейса напрямую
Тема 1. Отказоустойчивая платформа приёма видеовизиток на микросервисах и Kubernetes
Актуальность. Онлайн-отбор в ГИТИС для абитуриентов Прикамья показывает типовой сценарий: географически распределённые пользователи, разное качество канала, пиковая нагрузка в коротком окне. Классическая монолитная архитектура в такой ситуации требует ручного масштабирования и быстро упирается в лимиты.
Цель: спроектировать архитектуру сервиса приёма и обработки видеовизиток, выдерживающую пиковый рост запросов без деградации качества обслуживания.
Задачи:
- проанализировать аналоги и обосновать переход к сервисной архитектуре;
- спроектировать схему взаимодействия сервисов загрузки, транскодирования, каталога и уведомлений;
- настроить горизонтальное автомасштабирование и описать политики HPA;
- провести нагрузочное тестирование и оценить стоимость инфраструктуры.
Структура: глава 1 — анализ предметной области, обзор платформ дистанционного отбора, выбор архитектурного стиля; глава 2 — проектирование сервисов, схемы взаимодействия, описание API, диаграммы развёртывания; глава 3 — тестирование, метрики, расчёт экономики внедрения и сравнение с базовым вариантом.
Тема 2. Сравнительный анализ протоколов доставки видео для сервиса дистанционного отбора
Актуальность. Абитуриент может загружать визитку из города, где канал нестабилен. Выбор между WebRTC, HLS и DASH напрямую влияет на время до первого кадра и на затраты на транскодирование. Кейс МТС и ГИТИС даёт естественный контекст для обоснования.
Цель: определить оптимальный протокол и параметры адаптивного битрейта для просмотра записей приёмной комиссией.
Задачи: обзор протоколов и их ограничений; построение стенда с лестницей качества; замер задержки и доли буферизации; расчёт стоимости хранения и раздачи.
Структура: теория потоковой передачи и адаптивного битрейта → проектирование стенда и пайплайна транскодирования → эксперименты, таблицы замеров, выводы по применимости.
Тема 3. Оценка качества сервиса онлайн-отбора по ISO/IEC 25010: SLO, мониторинг, RTO/RPO
Актуальность. Приёмная кампания — это жёсткие сроки: два часа недоступности сервиса означают тысячи потерянных заявок. Формализовать требования через атрибуты качества и подтвердить их измерениями — сильный ход для защиты.
Цель: разработать систему метрик и мониторинга, подтверждающую соответствие сервиса заданным SLO.
Задачи: выделить атрибуты качества по ISO/IEC 25010; определить SLO и бюджет ошибок; настроить сбор телеметрии (OpenTelemetry + Prometheus + Grafana); провести учения по восстановлению и зафиксировать RTO/RPO.
Структура: анализ стандартов и модели качества → проектирование контуров мониторинга и алертинга → эксперименты, отчёты, план реагирования на инциденты.
Аналитическая глава: как обосновать стек, а не просто перечислить технологии
Самая частая слабость первого раздела — список «мы выбрали Kubernetes, потому что он современный». Комиссия это читает одинаково во всех работах. Работает другой приём: сформулировать критерии выбора до того, как появятся названия технологий.
Для сервиса дистанционного отбора критерии выглядят так: способность выдерживать пик в 20–30 раз выше среднего, стоимость хранения часа видео, сложность эксплуатации силами команды из трёх человек, требования к задержке при просмотре комиссией, наличие готовых SDK для веб-клиента. Только после этого появляется таблица сравнения — и она уже не выглядит притянутой за уши.
| Критерий | Монолит на ВМ | Микросервисы + Kubernetes | Serverless-функции |
|---|---|---|---|
| Масштабирование под пик | Ручное, простой при перегрузке | Автоматическое по метрикам | Автоматическое, но с холодным стартом |
| Стоимость в межсезонье | Постоянная, избыточная | Средняя, зависит от политик HPA | Близка к нулю при простое |
| Обработка длинного видео | Ограничена лимитами процесса | Отдельные воркеры транскодирования | Лимит времени выполнения |
| Порог входа для команды | Низкий | Высокий | Средний |
| Пригодность для ВКР | Просто описать, сложно защитить | Богатая доказательная база | Хорошо для подсистемы уведомлений |
Обратите внимание на последнюю строку таблицы. Это не украшение, а рабочий инструмент: вы заранее объясняете комиссии, почему выбрали более сложный вариант и что именно планируете измерять. Отсылка к новости об онлайн-отборе в ГИТИС здесь уместна как подтверждение того, что сценарий не выдуман.
Проектная часть: схемы, алгоритмы, интеграция
Здесь важно не уйти в пересказ документации. Проектная глава ценна конкретикой: кто с кем общается, по какому протоколу, что происходит при сбое.
Поток загрузки и обработки визитки
- Клиент получает预 presigned-ссылку на объектное хранилище и загружает файл напрямую, минуя прикладной сервер — это снимает нагрузку с API.
- Сервис-оркестратор публикует событие в очередь; воркеры транскодирования строят лестницу качества.
- Сервис каталога фиксирует метаданные, проверяет длительность и формат, ставит заявку в очередь на рассмотрение.
- Комиссия получает ссылку на поток через CDN с адаптивным битрейтом.
Такой конвейер хорошо ложится на диаграмму последовательности и на схему развёртывания — оба артефакта обязательны и выполняются по правилам ГОСТ 19.701-90.
# Пример лестницы качества для визитки длительностью до 3 минут
ffmpeg -i vizitka.mp4 \
-filter_complex "[0:v]split=3[v1][v2][v3]; \
[v1]scale=w=1920:h=1080[v1out]; \
[v2]scale=w=1280:h=720[v2out]; \
[v3]scale=w=854:h=480[v3out]" \
-map "[v1out]" -c:v libx264 -b:v 4500k -preset veryfast \
-map "[v2out]" -c:v libx264 -b:v 2500k -preset veryfast \
-map "[v3out]" -c:v libx264 -b:v 1000k -preset veryfast \
-f hls -hls_time 6 -hls_playlist_type vod -var_stream_map "v:0 v:1 v:2" \
stream_%v.m3u8
Комментарий к фрагменту в тексте ВКР обязателен: объясните, почему выбран именно такой шаг сегмента, как он влияет на время до первого кадра и сколько места занимает час исходного видео в каждом варианте.
Устойчивость к сбоям
Опишите, что произойдёт при падении воркера во время транскодирования, как организована идемпотентность повторной обработки и где хранится состояние задания. Именно эти абзацы отличают проект от реферата.
Тестирование и метрики: чем доказать работоспособность
Раздел с экспериментами — самый весомый на защите. Набор метрик стоит зафиксировать заранее, чтобы потом не искать данные задним числом.
| Группа | Метрика | Как снимать | Ориентир |
|---|---|---|---|
| Производительность | p95 времени ответа API | Нагрузочный тест, отчёт с перцентилями | до 300 мс при пике |
| Потоковая передача | Время до первого кадра, доля буферизации | Клиентские замеры на трёх профилях сети | TTFF до 2 с, буферизация < 1% |
| Надёжность | Доступность за период, RTO, RPO | Учения по восстановлению | 99,9%, RTO 15 мин, RPO 5 мин |
| Экономика | Стоимость обработки 1000 визиток | Расчёт по тарифам облака | Снижение против базового варианта |
Телеметрию удобно собирать через OpenTelemetry: единый формат трейсов, метрик и логов избавляет от зоопарка агентов. Дальше Prometheus хранит временные ряды, Grafana строит дашборд, а правила алертинга выносятся в отдельный раздел приложения. Скриншот дашборда с реального прогона — сильный визуальный аргумент, который редко встречается в студенческих работах.
- Каждая задача из введения отражена в выводах по главам и в заключении.
- Ссылка на источник по теме вставлена в аналитическую главу, а не в приложение.
- Есть минимум три схемы: архитектурная, последовательности, развёртывания.
- ТЗ оформлено по ГОСТ 34.602-89, схемы — по ГОСТ 19.701-90.
- Все числовые результаты получены на стенде, а не взяты «из головы».
- Единицы измерения и названия метрик совпадают в тексте, таблицах и подписях к рисункам.
- Список литературы содержит стандарты и документацию технологий с датами обращения.
Чему вы научитесь на такой теме
- Обосновывать архитектурный выбор через критерии, а не через популярность технологии.
- Строить конвейеры обработки медиаданных и считать их стоимость.
- Снимать метрики производительности и превращать их в защищаемые выводы.
- Оформлять техническую документацию так, чтобы она проходила нормоконтроль с первого раза.
- Связывать отраслевую новость с инженерной задачей — навык, который пригодится и в резюме.
- Подмена терминов SaaS, PaaS и IaaS без обоснования. Пишут «облачная платформа» и не уточняют уровень абстракции. Как избежать: заведите в первой главе короткий глоссарий и придерживайтесь его до конца работы.
- Отсутствие измеримых метрик эффективности. Формулировка «система стала быстрее» не защищается. Как избежать: определите базовый вариант, проведите замеры до и после, приведите разницу в процентах с указанием методики.
- Игнорирование требований ГОСТ 34.602-89 при оформлении ТЗ. Комиссия проверяет наличие обязательных разделов. Как избежать: сверьте структуру ТЗ с перечнем разделов стандарта до, а не после написания текста.
Вопросы, которые задают чаще всего
Обязательно ли писать работающий код для такой темы?
Не обязательно в полном объёме, но нужен подтверждённый эксперимент. Достаточно прототипа из трёх-четырёх сервисов, стенда для нагрузочного тестирования и воспроизводимых замеров. Если код написать не получается, замените его формализованными расчётами и имитационной моделью — но тогда обоснуйте, почему модель адекватна.
Как измерить производительность, если нет доступа к промышленной инфраструктуре?
Разворачивайте стенд локально или в облаке на минимальных тарифах. Важна не абсолютная мощность железа, а сопоставимость условий: одинаковое число виртуальных пользователей, одинаковый профиль загрузки, одинаковые сценарии. Все параметры стенда выносятся в приложение.
Где брать тестовые данные, если реальные визитки абитуриентов закрыты?
Используйте генераторы синтетических видео разной длительности и битрейта, а также открытые датасеты. Ограничение по персональным данным стоит отдельно проговорить в разделе о защите информации — это добавит работе веса.
Сколько UML-диаграмм достаточно?
Три-четыре осмысленных лучше десяти декоративных. Оптимально: компонентная схема, диаграмма последовательности для ключевого сценария, схема развёртывания и диаграмма состояний обработки задания.
Не хватает времени на эксперименты и расчёты? Мы берём на себя темы любой сложности: 120 часов работы эксперта, бесплатная консультация на старте и сопровождение до защиты. Опишите свою тему — предложим план и скажем, где могут возникнуть вопросы у комиссии.
Источник: Абитуриенты Прикамья могут принять участие в онлайн-отборе в ГИТИС (опубликовано 2026-03-24)