Единый контур мониторинга распределённых устройств в ВКР: от анализа стека до метрик отказоустойчивости
В марте 2026 года компания «Диагностика-М», выпускающая инспекционно-досмотровое оборудование под маркой ТСНК, сообщила о переводе сотен своих устройств в единый контур наблюдения на платформе «Астра Мониторинг». Суть события проста и потому полезна для диплома: разрозненные установки, разбросанные по объектам заказчика, начали отдавать телеметрию в одно место — с общей моделью событий, едиными правилами оповещений и одним журналом. Для выпускника ИТ-направления это готовый сценарий ВКР. Во-первых, он про распределённые системы, а не про учебный CRUD. Во-вторых, он опирается на отечественный стек, что снимает вопросы импортозамещения на защите. В-третьих, здесь есть что измерять: задержки сбора метрик, потери сообщений, время восстановления после сбоя узла.
Три темы ВКР, которые вырастают из этого кейса
Тема 1. Проектирование отказоустойчивого контура сбора телеметрии промышленного оборудования
- Актуальность: в статье описан переход от наблюдения «по каждому объекту отдельно» к общему контуру на сотни устройств. Масштабирование такого контура — типичная инженерная задача, а не абстрактная теория.
- Цель: разработать архитектуру сбора и хранения метрик, устойчивую к отказу одного узла и к разрыву канала связи с объектом.
- Задачи: проанализировать протоколы передачи телеметрии; выбрать схему буферизации на стороне устройства; спроектировать отказоустойчивый приёмник; рассчитать параметры хранения и ретенции.
- Структура: Глава 1 — обзор подходов к мониторингу распределённых систем; Глава 2 — проектирование архитектуры, схемы потоков, выбор стека; Глава 3 — нагрузочное тестирование, оценка экономики внедрения.
Тема 2. Разработка модуля агрегации и визуализации состояния парка оборудования
- Актуальность: объединение сотен устройств в один контур требует дашбордов и правил оповещений, иначе данные есть, а решений на их основе нет.
- Цель: реализовать модуль, который превращает сырые метрики в набор показателей состояния парка и в события для службы эксплуатации.
- Задачи: формализовать модель показателей по ISO/IEC 25010; реализовать правила вычисления агрегатов; настроить пороги и дедупликацию оповещений; оценить точность детектирования отказов.
- Структура: Глава 1 — метрики и модели качества ПО; Глава 2 — проектирование модуля, схема данных, алгоритмы агрегации; Глава 3 — испытания на имитационной модели парка устройств.
Тема 3. Оценка эффективности внедрения отечественной платформы мониторинга на предприятии
- Актуальность: выбор между самописным решением, свободным и отечественным проприетарным продуктом — реальная развилка, с которой столкнулась «Диагностика-М».
- Цель: построить методику сравнения платформ мониторинга по техническим и стоимостным критериям и применить её к конкретному предприятию.
- Задачи: сформировать критерии и веса; собрать данные по кандидатам; рассчитать совокупную стоимость владения; проверить результат методом анализа чувствительности.
- Структура: Глава 1 — анализ рынка и требований; Глава 2 — методика многокритериальной оценки; Глава 3 — расчёт TCO, риски, рекомендации.
Аналитическая глава: как превратить новость в обоснование выбора
Самая частая претензия комиссии к первой главе — «переписанный обзор». Лечится это таблицей сравнения, где у каждого критерия есть источник данных и вес. Для кейса с единым контуром такая таблица выглядит примерно так:
| Критерий | Самописный сборщик | Свободный стек (Prometheus + Grafana + агент) | Отечественная платформа (кейс «Астра Мониторинг») |
|---|---|---|---|
| Скорость ввода в эксплуатацию | Низкая, весь цикл на своей команде | Средняя, нужна интеграция и сопровождение | Высокая за счёт готовых коннекторов |
| Требования к реестру отечественного ПО | Не закрывает | Закрывает частично | Закрывает полностью |
| Гибкость модели метрик | Максимальная | Высокая | Ограничена вендором |
| Стоимость владения за 3 года | Растёт с числом устройств | Лицензии 0, но трудозатраты высоки | Лицензия + поддержка вендора |
Важно не просто заполнить ячейки, а объяснить, почему веса именно такие. Если в организации действует требование использовать ПО из реестра, критерий «импортозамещение» получает вес выше среднего — и это честное обоснование, а не подгонка ответа. Опирайтесь на ГОСТ 34.602-89 при оформлении требований и на ISO/IEC 25010 при описании атрибутов качества: комиссия такие ссылки любит, потому что они проверяемы.
Проектная часть: схемы, потоки данных, интеграция устройств
Схема потоков телеметрии
Возьмите три уровня: устройство (агент сбора), транспорт (брокер или шлюз), ядро платформы (хранилище и правила). На диаграмме в нотации UML или по ГОСТ 19.701-90 покажите, где возникает буфер, что происходит при обрыве канала и как сообщения попадают в долговременное хранилище. Именно буфер на стороне устройства делает контур устойчивым: единичный сбой сети не должен превращаться в дыру в истории наблюдений.
Модель данных и журналирование
Распишите сущности: устройство, модель, объект размещения, метрика, событие, инцидент. Отдельно опишите формат записи журнала — с обязательными полями времени, идентификатора устройства и кода события. Здесь уместно упомянуть OpenTelemetry как способ не изобретать свой формат и сохранить совместимость с внешними системами анализа.
Тестирование и метрики: чем доказывать работоспособность
Раздел испытаний — то место, где диплом перестаёт быть текстом. Вам нужны измеримые показатели, а не фраза «система работает стабильно».
| Показатель | Как измерять | Ориентир для защиты |
|---|---|---|
| Задержка доставки метрики | Метка времени на устройстве минус метка записи в хранилище | секунды, а не десятки секунд |
| Доля потерянных сообщений | Счётчики отправленных и принятых пакетов при искусственном обрыве канала | стремление к нулю при буферизации |
| RTO контура | Принудительное отключение узла приёма | минуты, зафиксировать в отчёте |
| RPO | Объём данных, не дошедших до хранилища за время сбоя | не больше окна буфера |
| Нагрузка при росте парка | Эмуляция 100, 500, 1000 устройств | линейный рост потребления ресурсов |
Тестовые данные удобно генерировать скриптом-эмулятором: он подменяет реальные инспекционные комплексы и позволяет прогнать сценарии отказа без выезда на объект. Такой эмулятор — самостоятельный результат работы, его стоит вынести в приложение к ВКР.
Чему вы научитесь на такой теме
- Обосновывать выбор стека через критерии, а не через «мне нравится этот инструмент».
- Проектировать отказоустойчивые схемы сбора данных и описывать их в нотациях, понятных комиссии.
- Строить методику испытаний и получать числовые метрики вместо оценочных суждений.
- Оформлять техническую документацию по ГОСТ 34 и ГОСТ 19, включая ТЗ и схемы алгоритмов.
- Считать совокупную стоимость владения и защищать экономическую часть проекта.
Три ошибки, которые чаще всего топят такие работы
- Путаница SaaS, PaaS и локального развёртывания. Студент пишет «облачная платформа», а в проектной части разворачивает всё на одном сервере. Как избежать: зафиксируйте модель развёртывания в первом же разделе проектирования и держите её до конца текста.
- Отсутствие метрик эффективности. Внедрение описано, выгода — нет. Как избежать: заранее выберите 3–5 измеримых показателей из таблицы выше и вернитесь к ним в выводах.
- Игнорирование ГОСТ 34.602-89 при оформлении ТЗ. Комиссия проверяет состав разделов документа. Как избежать: сверьте структуру ТЗ с перечнем разделов стандарта до того, как начнёте писать третью главу.
Вопросы, которые задают чаще всего
Обязательно ли писать работающий код для такой темы?
Нет, если тема проектная или аналитическая. Но должен быть артефакт: прототип сборщика метрик, конфигурация платформы, эмулятор устройств или скрипты расчёта. Комиссия оценивает проверяемость результата, а не объём кода.
Где взять данные, если реального парка устройств нет?
Синтетическая нагрузка. Сгенерируйте поток метрик по расписанию, задайте вероятность отказов и обрывов канала — этого достаточно для проверки архитектуры. В тексте честно укажите, что модель имитационная, и опишите её допущения.
Можно ли использовать зарубежные инструменты мониторинга?
Технически да, но при требовании импортозамещения сравнение должно включать хотя бы одно отечественное решение из реестра и оценку по критерию соответствия требованиям заказчика.
Как оформить диаграммы, чтобы их приняли?
Единая нотация по всей работе: либо UML, либо схемы по ГОСТ 19.701-90. Каждая диаграмма — с подписью, ссылкой в тексте и кратким пояснением, что именно на ней видно.
Чек-лист перед сдачей
- Ссылка на источник события оформлена корректно, дата публикации указана.
- Каждая задача из введения отражена в заключении конкретным результатом.
- Есть минимум одна схема архитектуры и одна схема алгоритма или потока данных.
- Метрики в главе испытаний совпадают с метриками в выводах и в экономической части.
- ТЗ и структурная схема оформлены по ГОСТ 34.602-89 и ГОСТ 19.701-90.
- Термины употребляются единообразно: одна и та же сущность не называется тремя словами.
- Список литературы содержит стандарты и актуальные технические публикации, не только веб-статьи.
Застряли на выборе темы или не сходится экономическая часть? Оставьте заявку на бесплатную консультацию: разберём ваш случай за 20–30 минут, покажем, каких данных не хватает, и предложим план работы. Возьмём тему в проработку — от постановки задачи до защиты. Обычный срок работы над проектом — около 120 часов трудозатрат специалиста.
Источник: С платформой «Астра Мониторинг» компания «Диагностика-М» объединила сотни устройств в общем контуре (опубликовано 2026-03-25)