Опубликовано: 11.10.2026 | Источник: CNews (новости)

Анализ пользовательской активности hh.ru для ВКР: от обеденного пика до метрик SLO

27 марта 2026 года площадка онлайн-рекрутинга hh.ru опубликовала любопытную статистику: чаще всего россияне ищут новую работу в обеденный перерыв. С начала 2026 года число откликов на вакансии превысило сотни тысяч в сутки, и распределены они по дню крайне неравномерно — основной всплеск приходится на интервал между 12:00 и 14:00 по московскому времени. Для выпускника ИТ-направления это не курьёз из новостной ленты, а готовый сценарий для дипломной работы: суточная неравномерность нагрузки — классическая задача проектирования отказоустойчивых систем, потоковой аналитики и прогнозирования ресурсов.

Три темы ВКР, которые вырастают из этой новости

Тема 1. Прогнозирование пиковой нагрузки сервиса откликов на основе временных рядов

Актуальность. Данные hh.ru прямо показывают концентрацию пользовательской активности в узком временном окне. Если сервис не готов к такому профилю, растёт время отклика, падает конверсия и появляются отказы в обслуживании.

• Цель: разработать модель прогнозирования часовых пиков и механизм превентивного масштабирования.
• Задачи: собрать и очистить исторические данные об откликах; выполнить сезонную декомпозицию ряда (сутки/неделя); обучить и сравнить модели прогноза; реализовать автомасштабирование по прогнозу.
• Структура: Глава 1 — анализ предметной области и методов прогнозирования; Глава 2 — архитектура сервиса и алгоритм масштабирования; Глава 3 — эксперименты, метрики MAPE/MAE, оценка экономии ресурсов.

Тема 2. Сервис потоковой аналитики событий HR-платформы

Актуальность. Новость опирается на событийные данные: каждый отклик — это запись с меткой времени, регионом и вакансией. Значит, нужна шина событий и хранилище, пригодное для аналитических срезов в реальном времени.

• Цель: спроектировать и реализовать конвейер обработки событий с задержкой не более нескольких секунд.
• Задачи: обосновать выбор брокера сообщений; спроектировать схему топиков и партиционирование; реализовать запись в колоночное хранилище; построить дашборд распределения активности по часам.
• Структура: Глава 1 — обзор архитектурных стилей и стандарта ISO/IEC 25010; Глава 2 — проектирование компонентов и диаграммы по ГОСТ; Глава 3 — нагрузочные испытания и оценка пропускной способности.

Тема 3. Оптимизация отклика API под неравномерный трафик

Актуальность. Обеденный пик — это проверка API на прочность. Работа, где вы измеряете деградацию эндпоинта и предлагаете кэширование или очередь, звучит прикладнее, чем абстрактное «исследование технологий».

• Цель: снизить время отклика наиболее нагруженных эндпоинтов при пиковом профиле трафика.
• Задачи: собрать базовый профиль нагрузки; воспроизвести пик в нагрузочном тесте; применить кэширование и асинхронную обработку; сравнить метрики до и после.
• Структура: Глава 1 — анализ узких мест и обзор практик; Глава 2 — проектные решения и схемы; Глава 3 — методика тестирования и расчёт эффективности.

Как использовать статью в аналитической главе

Первая глава — это не пересказ новостей. Новость здесь становится источником исходных данных и постановкой задачи. Зафиксируйте факт: активность пользователей концентрируется в обеденное окно, следовательно, система должна проектироваться под пиковый, а не под средний сценарий. Дальше — сравнение подходов.

Обоснование выбора стека удобно свести к критериям качества из ISO/IEC 25010: функциональная полнота, производительность, удобство сопровождения, переносимость. Не пишите «выбрали Kafka, потому что популярна» — это самый частый провал на защите. Пишите: «выбран брокер с гарантией доставки at-least-once и горизонтальным партиционированием, что соответствует требованию обработки пикового потока событий».

Проектная часть: от схемы до алгоритма

Логика конвейера для темы с активностью пользователей выглядит так:

Клиент → API Gateway → брокер событий → обработчик потока → хранилище → BI-дашборд
                              ↓
                    сервис прогноза пиков (cron: каждый час)

Ключевая проектная деталь — партиционирование по идентификатору пользователя или по региону. Это даёт равномерную загрузку потребителей и позволяет масштабировать обработку горизонтально, не переписывая логику.

Алгоритм выделения пиковых интервалов

def peak_windows(events, threshold=1.5):
    hourly = group_by_hour(events)          # агрегация по часам
    baseline = median(hourly)               # медиана как устойчивая база
    return [h for h, v in hourly.items()
            if v > baseline * threshold]    # часы выше порога

Такой приём легко защищается: он прост, воспроизводим и опирается на статистику, а не на интуицию. В тексте работы обязательно поясните, почему медиана, а не среднее — среднее чувствительно к выбросам, которых в событийных данных много.

Тестирование, метрики и мониторинг

Раздел испытаний — то место, где дипломная работа превращается в инженерный документ. Профиль нагрузки в нагрузочном тесте должен повторять суточный ритм из статьи: плавный рост с утра, резкий пик в обед, спад к вечеру. Тогда результаты будут реалистичными.

Трассировку удобно построить на OpenTelemetry, а метрики снять через экспортёр в Prometheus. В работе опишите не только инструменты, но и то, какие решения вы примете по результатам: например, «при превышении p95 порога 300 мс включается превентивное добавление реплик обработчика».

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

• Проектировать событийные архитектуры и обосновывать границы сервисов.
• Работать с временными рядами и отделять сезонность от случайного шума.
• Строить нагрузочные профили, приближенные к реальному поведению пользователей.
• Формулировать SLO и доказывать их достижение цифрами, а не словами.
• Оформлять техническую документацию по ГОСТ 34.602-89 и схемы по ГОСТ 19.701-90.

Вопросы, которые задают чаще всего

Где взять реальные данные об активности пользователей?

Публичные агрегаты рекрутинговых платформ, открытые датасеты по веб-логам, а также собственный синтетический генератор, воспроизводящий суточный профиль из статьи. Второй вариант даже предпочтительнее: вы контролируете параметры и можете воспроизвести эксперимент.

Обязательно ли писать код?

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

Как оформить диаграммы компонентов и последовательностей?

Строгих требований к нотации UML в ГОСТ нет, поэтому ориентируйтесь на методические указания кафедры. Обычно достаточно единообразного стиля, подписей и ссылок на диаграммы в тексте.

Насколько сложна такая работа для студента-бакалавра?

Средний уровень. Основная сложность — не код, а корректная постановка эксперимента и умение объяснить, почему выбранные метрики доказывают гипотезу.

Источник: Чаще всего россияне ищут новую работу в обеденный перерыв (опубликовано 2026-03-27)