Орбитальные ЦОД в дипломе: архитектура распределённых вычислений на примере Starcloud

30 марта 2026 года компания Starcloud объявила о привлечении $170 млн в раунде Series A на строительство центров обработки данных на орбите. Через 17 месяцев после демо-дня Y Combinator проект стал «единорогом» — самым быстрым в истории акселератора. Это не просто новость про космос: речь о том, что вычислительная инфраструктура выходит за пределы земных дата-центров, а значит — меняются требования к распределённым системам, отказоустойчивости, энергопотреблению и сетевым протоколам. Для выпускника ИТ-направления это готовый повод защитить ВКР на тему, которая через 2–3 года попадёт в вакансии. Ниже — как превратить кейс Starcloud в защищаемую работу, не скатываясь в фантастику и не выдумывая данные.

Семантический каркас: что искать и с чем сравнивать

Три темы ВКР, которые можно собрать из статьи

Тема 1. «Анализ архитектур распределённых вычислительных систем для работы в условиях ограниченной связности»

• Актуальность: кейс Starcloud показывает коммерциализацию орбитальных ЦОД — это тренд на «вычисления там, где рождаются данные». Классические земные ЦОД уже не единственный вариант.
• Цель: разработать модель распределённого кластера, устойчивого к задержкам 5–40 мс и разрывам канала.
• Задачи: обзор архитектур edge/space-computing; классификация паттернов репликации; проектирование схемы внутриспутниковой и межспутниковой коммутации; оценка отказоустойчивости по RTO/RPO.
• Структура: Гл. 1 — теория распределённых систем и космических платформ; Гл. 2 — архитектура кластера, диаграммы компонентов, спецификация API; Гл. 3 — имитационные тесты, расчёт экономии энергии и полосы связи.

Тема 2. «Проектирование системы мониторинга гетерогенной инфраструктуры с использованием OpenTelemetry»

• Актуальность: орбитальные узлы нельзя «перезагрузить по SSH» — метрики должны быть распределёнными и самодостаточными. Кейс Starcloud — пример отрасли, где observability становится критичной.
• Цель: спроектировать конвейер сбора метрик, логов и трейсов для территориально разнесённых узлов.
• Задачи: выбор стандарта сбора телеметрии; расчёт бюджета частоты сбора данных; проектирование буферизации при потере связи; тестирование нагрузки.
• Структура: Гл. 1 — обзор OpenTelemetry, Prometheus, ISO/IEC 25010; Гл. 2 — схема pipeline, диаграммы развёртывания; Гл. 3 — нагрузочные тесты, метрики точности и задержки.

Тема 3. «Обоснование стека контейнерной оркестрации для распределённого кластера с нестабильным каналом»

• Актуальность: Kubernetes заточен под «всегда онлайн», а орбитальный кластер живёт с периодическими окнами связи. Это реальный архитектурный пробел, который статья Starcloud подсвечивает.
• Цель: сравнить K3s, KubeEdge и Nomad для условий низкой связности и предложить критерии выбора.
• Задачи: анализ требований по времени сходимости; сравнение потребления ресурсов; проектирование отказоустойчивого scheduler; расчёт TCO.
• Структура: Гл. 1 — теория оркестрации и edge-развёртывания; Гл. 2 — сравнительная таблица и архитектура; Гл. 3 — бенчмарки и экономика.

Аналитическая глава: как не превратить обзор в реферат

В первой главе не нужно пересказывать пресс-релиз Starcloud. Задача другая — построить матрицу сравнения, из которой логически вытекает ваше решение. Возьмите 4–6 существующих подходов: централизованный ЦОД, AWS Ground Station, edge-узлы на базе 5G, орбитальные платформы Starcloud. Сравнивайте по столбцам: задержка, пропускная способность, энергопотребление, стоимость развёртывания, юридические ограничения.

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

Проектная часть: от схем к реализации

Здесь защищаются 70% оценок. Комиссия смотрит не на красоту кода, а на согласованность: задача → архитектура → диаграмма → артефакт. Минимальный набор:

• Диаграмма компонентов в нотации C4 (уровень Container) — узлы, каналы, зоны доверия.
• Диаграмма последовательности для сценария «потеря связи с центральным узлом».
• Спецификация API (OpenAPI/YAML) для сервисов синхронизации.
• Схема развёртывания с учётом радиационно-стойких компонентов.

Если пишете код — зафиксируйте commit hash и приложите CI/CD-пайплайн (GitLab CI или GitHub Actions). Даже имитационная модель на Python в 300 строк с воспроизводимыми тестами выглядит убедительнее, чем 5000 строк неподдерживаемого кода без метрик.

Тестирование и метрики: чем измерять «космическую» систему

Не пишите «система работает быстро». Пишите: «при нагрузке 200 RPS средняя задержка обработки — 43 мс, p95 — 78 мс, потери пакетов менее 0.5%». Метрики — то, что отличает ВКР от курсовой.

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

• Формализовывать нечёткое требование («работа в условиях космоса») в измеримые характеристики.
• Обосновывать выбор фреймворка через матрицу критериев, а не через «мне нравится Kubernetes».
• Проектировать отказоустойчивые системы с учётом RTO/RPO и оформлять это по ГОСТ 34.602-89.
• Строить observability-контур на OpenTelemetry — навык, который прямо сейчас ищут в вакансиях DevOps/SRE.
• Оформлять архитектурные схемы так, чтобы рецензент не задавал вопросов «а что значат эти стрелочки».

FAQ для защиты

Источник: Starcloud raises $170 million Series Ato build data centers in space (опубликовано 2026-03-30)