Модернизация инфраструктуры в ВКР: миграция без простоя и расчёт SLA
В апреле 2026 года экипаж 74-й экспедиции МКС получил партию HP ZBook Fury G9 — мобильные рабочие станции заменили устаревшие ноутбуки, а заодно обновили сетевые серверы станции. Для ИТ-выпускника это не просто новость про «железо в космосе», а готовый кейс для ВКР: как спланировать замену критической инфраструктуры без остановки сервисов, оценить риски и посчитать SLA. Разберём, как упаковать этот сценарий в диплом по DevOps/SRE-направлению.
Темы ВКР на базе кейса МКС
| Тема | Актуальность | Цель | Задачи | Структура |
|---|---|---|---|---|
| Проектирование стратегии миграции инфраструктуры с нулевым простоем | На МКС нельзя «просто выключить серверы» — аналогично в enterprise-среде. Кейс HP ZBook G9 демонстрирует поэтапную замену. | Разработать методологию миграции с SLA ≥ 99,95%. | 1) Анализ текущей архитектуры; 2) Выбор паттерна миграции (blue-green, canary); 3) Реализация пайплайна; 4) Оценка рисков. | Г1 — обзор подходов (SRE, PMBOK 7). Г2 — проектирование (C4, BPMN). Г3 — эксперимент на стенде + метрики. |
| Отказоустойчивая архитектура распределённой системы: опыт изолированных сред | МКС — пример среды с ограниченной связностью и высокими требованиями к надёжности (ISO/IEC 25010, атрибут reliability). | Спроектировать систему, устойчивую к потере узлов. | 1) Матрица отказов; 2) Паттерны circuit breaker, bulkhead; 3) Реализация на Kubernetes; 4) Chaos-тестирование. | Г1 — теория надёжности. Г2 — архитектура (UML deployment). Г3 — нагрузочные и хаос-тесты. |
| Мониторинг и observability при обновлении критических компонентов | Перед заменой ноутбуков астронавты проверили серверы — классический pre-flight check. В дипломе это метрики OpenTelemetry. | Построить наблюдаемость для контроля миграции. | 1) Выбор сигналов (RED/USE); 2) Настройка трейсинга; 3) Дашборды Grafana; 4) Алертинг по SLO. | Г1 — observability-стек. Г2 — внедрение OpenTelemetry. Г3 — валидация на синтетической нагрузке. |
Как интегрировать кейс МКС в главы диплома
Глава 1. Аналитика и выбор подхода
Начните с описания ограничений среды: на МКС каждый килограмм на орбите стоит ~$20 000, а задержка связи — до 2 секунд. Это прямая аналогия с edge-инфраструктурой и branch-офисами на Земле. Сравните три паттерна миграции:
- Big-bang — быстро, но высокий риск (как заменить все ноутбуки за один выходной).
- Strangler fig — постепенное вытеснение старых компонентов.
- Blue-green / canary — параллельная работа двух версий с переключением трафика.
Обоснуйте выбор через призму ISO/IEC 25010 (reliability, maintainability) и принципов SRE: error budget, toil reduction.
Глава 2. Проектирование и реализация
Постройте C4-модель (Context → Container → Component). Для миграции серверов МКС подойдёт такая схема:
# Пример Ansible-плейбука для canary-развёртывания
- name: Rollout new ZBook workstation image
hosts: iss_workstations_canary
serial: "20%"
tasks:
- name: Pre-flight health check
uri:
url: "https://iss-internal/healthz"
status_code: 200
register: health
- name: Deploy new image
command: /opt/iss/deploy.sh --version=g9-fury
when: health.status == 200
- name: Wait for SLO convergence
pause:
minutes: 5
- name: Validate SLO > 99.9%
shell: /opt/iss/check_slo.sh --window=5m
register: slo
failed_when: slo.rc != 0Добавьте BPMN-диаграмму процесса замены: «Получение оборудования → Проверка совместимости → Canary-развёртывание → Валидация SLO → Откат или продвижение». Это покажет комиссии, что вы мыслите процессами, а не только скриптами.
Глава 3. Тестирование и оценка эффективности
Ключевые метрики, которые нужно посчитать:
- MTTR (Mean Time To Recovery) — до и после миграции.
- Change failure rate — доля неудачных обновлений.
- SLI/SLO — latency p99, error rate, throughput.
- TCO — стоимость владения с учётом «стоимости простоя» (как на МКС, где час простоя эксперимента = потеря данных).
Используйте OpenTelemetry для сбора трейсов и Grafana для визуализации. Хаос-тестирование через LitmusChaos или Chaos Mesh покажет, как система ведёт себя при отказе узла во время миграции.
Чему вы научитесь
- Проектировать миграцию с учётом SLA и error budget по практикам SRE.
- Строить C4- и UML-диаграммы для инфраструктурных изменений.
- Настраивать observability-стек на OpenTelemetry + Prometheus + Grafana.
- Считать MTTR, change failure rate и TCO для обоснования проекта.
- Оформлять ТЗ и пояснительную записку по ГОСТ 34 и ГОСТ 19.
Типичные ошибки студентов
- «Мигрируем всё сразу в пятницу вечером». На МКС такой подход не прошёл бы — астронавты меняют серверы поэтапно, начиная с сетевых. В дипломе обязательно предусмотрите план отката и критерии успеха.
- Метрики «для галочки». Если вы пишете про SLA 99,99%, но не показываете, как его измеряли и какой был error budget — комиссия это заметит. Ссылайтесь на Google SRE Book.
- Игнорирование совместимости. HP ZBook G9 потребовал проверки с существующим ПО станции. В вашем проекте — аналогично: матрица совместимости версий обязательна.
FAQ
Какой стек выбрать для диплома по миграции инфраструктуры?
Оптимальный набор: Kubernetes (оркестрация), Ansible/Terraform (IaC), Prometheus + Grafana (мониторинг), OpenTelemetry (трейсинг), ArgoCD (GitOps). Если тема про «железо» — добавьте IPMI/BMC для управления физическими серверами.
Как обосновать актуальность, если кейс «про космос»?
Проведите параллель с изолированными средами на Земле: ЦОДы в Арктике, морские платформы, branch-офисы со слабой связностью. МКС — это extreme-кейс, но принципы те же. Ссылка на статью The Verge придаст работе «живой» контекст.
Сколько кода должно быть в ВКР по DevOps?
Не менее 30–40 страниц приложений: плейбуки Ansible, Helm-чарты, Terraform-модули, конфигурации Prometheus. В тексте — только ключевые фрагменты с пояснениями. Нормоконтроль требует, чтобы код соответствовал ГОСТ 19 и был оформлен единообразно.
Как считать эффективность миграции для защиты?
Снимите baseline-метрики ДО миграции (latency p99, error rate, MTTR), затем повторите ПОСЛЕ. Разница в процентах — ваш главный аргумент. Добавьте расчёт TCO: стоимость простоя × время миграции vs. стоимость нового решения.
Чек-лист «Что проверить перед сдачей»
- ☑ Все задачи из введения закрыты в выводах соответствующих глав.
- ☑ C4/UML/BPMN-диаграммы согласованы между собой и с текстом.
- ☑ Метрики (SLA, MTTR, TCO) посчитаны, а не «взяты с потолка».
- ☑ Код в приложениях соответствует ГОСТ 19, есть комментарии.
- ☑ Список литературы включает SRE Book, ISO/IEC 25010, PMBOK 7.
- ☑ Уникальность текста ≥ 70%, код — ≥ 80%.
- ☑ Презентация на 10–12 слайдов с акцентом на результаты, а не теорию.
Нужна помощь с ВКР? Разработка темы с нуля, помощь с кодом, оформление по ГОСТ или подготовка к защите — на всё про всё уходит около 120 часов кропотливой работы. Если вы хотите бесплатную консультацию по вашей теме или оценку сроков, наши эксперты на связи. Помогаем с любой сложностью — от курсовой до докторской.
Источник: ISS astronauts are getting new laptops (опубликовано 2026-04-21)