В материале от 30 марта 2026 года описан показательный сбой: порт Виго после визита хакеров вернулся к ручным бланкам, и судьба грузов снова зависит от аккуратности персонала. Для ИТ-специальностей это не курьёзная новость, а готовый кейс для дипломного исследования. Цифровой процесс без проверенного резервного контура ломается не только технически, но и организационно: люди, регламенты, журналы, права доступа и бумажная процедура становятся частью архитектуры.
В ВКР такой инцидент помогает обосновать требования к отказоустойчивости, мониторингу, резервному копированию и ручным сценариям. Главное — не пересказывать новость, а превратить её в измеримую задачу: какие метрики RTO/RPO выбрать, как проверить переключение, какие стандарты применить и где заканчивается техническое решение. Ниже — темы, структура глав и практические заготовки, которые можно защищать перед комиссией без ощущения «натянутой актуальности».
Актуальность. В статье цифровой обмен грузовыми данными заменяется бумагой после атаки. Это прямой аргумент для проектирования контуров: основной, резервный и ручной. Тема хорошо ложится на специальности, связанные с информационными системами, безопасностью и логистикой.
Цель: разработать архитектуру портовой информационной системы, которая сохраняет управляемость грузопотоком при отказе цифровых сервисов.
Задачи:
Возможная структура: глава 1 — анализ угроз, стандартов и инцидентов; глава 2 — архитектура, схемы, алгоритмы и требования по ГОСТ 34.602-89; глава 3 — прототип, сценарии отказа, метрики и экономическое обоснование.
Актуальность. Если порт узнаёт об атаке слишком поздно, остаётся только ручной режим. ВКР может быть посвящена раннему обнаружению: сбору логов, метрик и событий безопасности из ключевых сервисов.
Цель: спроектировать контур наблюдаемости для портовой ИС, который сокращает время обнаружения и локализации инцидента.
Задачи:
Возможная структура: глава 1 — обзор SIEM, OpenTelemetry и требований ISO/IEC 25010; глава 2 — архитектура сбора телеметрии и правила алертов; глава 3 — тестовые сценарии, ложные срабатывания и оценка эффективности.
Актуальность. После инцидента в Виго особенно заметно: «просто облако» или «просто локальный сервер» — не аргумент. Нужно сравнение вариантов по доступности, безопасности, стоимости и сложности эксплуатации.
Цель: обосновать гибридную архитектуру портовой ИС с воспроизводимым развёртыванием и проверенным резервным контуром.
Задачи:
Возможная структура: глава 1 — анализ вариантов и стандартов; глава 2 — целевая архитектура, Kubernetes-кластер или его учебная модель, схемы интеграции; глава 3 — нагрузочные проверки, оценка рисков и TCO.
В первой главе не стоит ограничиваться фразой «атаки участились». Ссылку на материал о порте Виго лучше превратить в таблицу сравнения архитектурных вариантов. Тогда новость работает как триггер для обоснования требований, а не как декоративная вставка. Заодно проверьте, не смешиваете ли вы SaaS, PaaS и локальную инфраструктуру: комиссия такие подмены замечает быстро.
| Вариант | Сильная сторона | Где риск | Что писать в ВКР |
|---|---|---|---|
| Полностью облачный / PaaS | Быстрое развёртывание, меньше администрирования | Зависимость от внешнего провайдера и каналов связи | Критерии доступности, SLA, ограничения для критичных грузовых операций |
| Локальный ЦОД | Контроль над данными и сетевым периметром | Выше стоимость эксплуатации и сложнее резервирование | Схема резервного копирования, RTO/RPO, требования ГОСТ 34.602-89 |
| Гибрид с изолированным контуром | Можно разделить критичные и вспомогательные сервисы | Сложнее синхронизация, мониторинг и разграничение доступа | Обоснование границ доверия, CI/CD-пайплайн, сценарии переключения |
Во второй главе статья даёт естественный набор схем: основной цифровой контур, резервный контур и ручной режим. Не нужно рисовать «просто диаграмму сети». Лучше показать, какие данные передаются между контурами, где стоят шлюзы, кто имеет право включить бумажный процесс и как фиксируются действия операторов.
На схеме отметьте три зоны: портовые сервисы, интеграционная шина и резервный контур. Отдельно покажите, что происходит при недоступности ERP или внешнего API. Если в работе используется Kubernetes, достаточно учебной схемы развёртывания: пространства имён, секреты, резервные копии, политики сетевого доступа. Не обязательно строить промышленный кластер — важнее показать логику изоляции и восстановления.
Фрагмент алгоритма можно вынести в раздел проектирования и затем проверить в третьей главе. Пример псевдокода для диплома:
if siem.alert == critical and core_erp.available == false:
freeze_external_api()
enable_manual_cargo_mode()
open_offline_journal()
notify_shift_manager()
schedule_recovery_check()
Здесь важны не имена переменных, а проверяемые условия: кто принимает решение, какие данные блокируются, куда пишется офлайн-журнал и когда запускается обратная синхронизация. Именно этот переход в статье о Виго и стал узким местом: цифровой процесс не имел отработанной ручной ветки.
Если тема связана с развёртыванием, покажите, как изменения попадают в контур: репозиторий, проверка, сборка, тест, развёртывание, откат. CI/CD-пайплайн в ВКР — это не «модный список инструментов», а способ доказать воспроизводимость. OpenTelemetry пригодится для сбора метрик и трассировки: по ним видно, где именно деградировал процесс до ручного режима.
Третья глава выигрывает, если в ней есть сценарии отказа и замеры. Недостаточно написать «система устойчива к атакам». Нужны метрики, привязанные к ISO/IEC 25010 и бизнес-процессу порта. Ниже — минимальный набор, который можно адаптировать под любую из трёх тем.
| Метрика | Как измерить | Что писать в выводах |
|---|---|---|
| RTO | Замер времени от сбоя до восстановления цифрового или ручного процесса | Укладывается ли система в целевой норматив для критичных грузов |
| RPO | Сравнение последней резервной копии и момента сбоя | Сколько данных допустимо потерять и как это влияет на документы |
| MTTR | Среднее время локализации и устранения инцидента по журналам | Сокращается ли простой за счёт мониторинга и регламента |
| Доля ручных операций | Количество операций в ручном режиме на тестовом сценарии | Насколько бумажный резерв реален, а не только описан |
| Ложные срабатывания | Сравнение алертов SIEM с подтверждёнными инцидентами | Не утонет ли дежурная смена в шуме оповещений |
Для защиты достаточно одного-двух продуманных сценариев: например, «недоступен основной API» и «SIEM фиксирует подозрительную активность». Фиксируйте время, действия оператора, результат и ограничения. Если реальные данные порта закрыты, используйте синтетические логи и явно укажите это в ограничениях исследования.
1. «Система надёжная» без метрик. Комиссия не увидит проверки. Исправление: добавьте таблицу RTO/RPO, сценарии отказа и замеры времени переключения.
2. Kubernetes или облако без сравнения альтернатив. Выглядит как выбор инструмента ради инструмента. Исправление: сравните on-prem, PaaS и гибридный вариант по доступности, стоимости и рискам.
3. ТЗ и схемы без привязки к ГОСТ 34.602-89. Работа теряет инженерную строгость. Исправление: проверьте состав требований, обозначения и структуру документации до финальной вёрстки.
Сложность зависит от глубины. Для ВКР достаточно учебного прототипа, схем контуров и проверенных сценариев переключения. Полноценный портовый комплекс не нужен: важнее показать логику, ограничения и измеримый результат.
Не всегда. В ряде тем достаточно архитектуры, алгоритмов и тестовых сценариев. Но если вы заявляете прототип, он должен запускаться или хотя бы воспроизводиться по инструкции. Комиссия любит проверяемые артефакты, а не скриншоты без объяснения.
Используйте единую нотацию и подписи на русском. Для бизнес-процесса подойдёт BPMN, для структуры классов или компонентов — UML. В тексте поясните, что именно показывает диаграмма и какие требования из неё следуют.
Берите синтетические данные, обезличенные логи, генераторы событий или открытые наборы транспортной телеметрии. Обязательно опишите происхождение данных и ограничения: это честнее, чем выдавать случайные строки за реальный грузопоток.
Источник: Добро пожаловать в прошлый век. Порт Виго перешёл на бумагу после визита хакеров (опубликовано 2026-03-30)
```