Побудова системи C2 з нуля, частина 1: основи й архітектура

Література з командування та управління переповнена закупівлями, доктриною та абревіатурами; і вкрай скупа на питання, на яке інженер насправді хоче отримати відповідь: як це побудувати? Ця серія з чотирьох частин крок за кроком веде через створення оборонної системи C2 — від порожнього репозиторію до операційного розгортання. Частина 1 закладає основи: скоуп, архітектуру, схеми та тех-стек. Частини 2–4 проводять через злиття, відображення, а також роботу зі сумісністю та безпекою, що виводить платформу в експлуатацію.

Серія доповнює архітектурний Повний посібник із систем командування та управління (C2), який оглядає галузь у цілому. Серія йде вужче й глибше: одна прикладна платформа, з ухваленими рішеннями, поясненими компромісами та винесеною на поверхню інженерною логікою. Приклад достатньо загальний, щоб застосовуватись на різних ешелонах; принципи переносяться.

Крок 1. Виберіть скоуп і дотримуйтеся його

Перше рішення — те, яке найчастіше пропускають, і саме воно визначає, чи дійде платформа до експлуатації. Система C2, спроєктована для обслуговування всіх ешелонів — тактичного, оперативного, стратегічного — зазвичай жоден з них не обслуговує добре. Виберіть один.

Визначальні питання:

Ешелон. Бригада і нижче означає бюджет затримок у секундах, плоску модель даних та UI для виснажених операторів у рукавичках на сонячному планшеті. Дивізія — корпус означає більші затримки, багатші інструменти планування та штабних офіцерів на робочих станціях. Об'єднаний і національний рівень означає ієрархічні моделі, компартментовану розвідку та аналітичний досвід desktop-класу. Повний розбір того, як ешелон формує архітектуру, — у статті Що таке система C2?.

Домен. Сухопутний, морський, повітряний або об'єднаний (joint-domain). Кожен має різні сімейства датчиків, стандарти повідомлень та робочі процеси операторів. Мультидоменна платформа — це значно важчий інженерний виклик, ніж однодоменна, і для першої збірки рідко виправдана.

Коаліційний vs національний рівень. Коаліційне розгортання означає, що сумісність з НАТО — це закупівельний gate з першого дня. Виключно національне розгортання дозволяє суверенну модель даних з мостом до НАТО, побудованим пізніше. Компроміси з боку сумісності — у статті Повний посібник із сумісності з НАТО.

Стеля класифікації. Найвища класифікація, з якою працюватиме платформа, визначає обсяг акредитаційних робіт, топологію мережі та вибір інструментів. Платформу рівня NATO RESTRICTED приблизно на порядок легше побудувати, ніж рівня NATO SECRET.

Запишіть рішення зі скоупу. Тегайте кожен архітектурний тикет тим, якому рішенню зі скоупу він служить. Розповзання скоупу — поступове додавання ешелонів, доменів чи рівнів класифікації під час розробки — є найбільшою одиничною причиною провалу програм.

Для прикладу, що проходить через усю серію, ми обираємо: тактичний C2 рівня бригади, мультидоменний (ситуаційна обізнаність по землі + повітрю), сумісний із НАТО, стеля класифікації NATO SECRET. Інші вибори зрушили б конкретні рішення впродовж серії, але не загальну архітектуру.

Крок 2. Зафіксуйте чотиришарову архітектуру

Кожна операційна C2-платформа сходиться до однієї й тієї самої чотиришарової архітектури. Сенсорний, обробки, відображення, комунікацій. Назви варіюються; відповідальності — ні. Архітектурне правило просте: кожен шар має одну відповідальність, інтерфейси між шарами явні, і жодна сутність не просочується через межі шарів.

Сенсорний шар. Адаптери, що переводять нативні для датчиків формати (ASTERIX, STANAG 4586, CoT, AIS NMEA, ADS-B) у внутрішній канонічний трек платформи. Адаптери — це односпрямовані конвертери даних; вони ніколи не ухвалюють рішень щодо треків.

Шар обробки. Злиття треків, нормалізація, авторитетне сховище треків. Трек — це одиниця даних, з якою працює решта платформи. Цей шар — тема частини 2.

Шар відображення. Спільна оперативна картина та супутній інструментарій. Постановка завдань, обмін повідомленнями, планування. Веб-фронтенд, що споживає WebSocket- та REST-API від шару обробки. Тема частини 3.

Шар комунікацій. Шини повідомлень, store-and-forward реплікація, мости між анклавами, інтеграція з тактичними радіостанціями. Тема частини 4 поряд із сумісністю та безпекою.

Викладіть це як реальні репозиторії та сервіси з першого дня. Опирайтесь спокусі «почати з одного сервісу, а потім винести» — винесення ніколи не відбувається чисто, а межі шарів розмиваються так, що відновлення коштує року роботи.

Крок 3. Спроєктуйте канонічну схему треків

Трек — це центральна структура даних будь-якої C2-платформи. Кожен адаптер виробляє треки. Кожне рішення злиття оновлює треки. Кожна СОК рендерить треки. Кожен лог аудиту посилається на треки. Спроєктуйте схему правильно — і більша частина решти платформи стане прямою; помиліться — і вартість накопичуватиметься роками.

Мінімально життєздатна схема треків включає:

• ID треку. Стабільний, глобально унікальний, ніколи не використовується повторно. UUIDv7 або типізований префікс плюс UUID — безпечне дефолтне рішення.
• Ідентичність. Чим є трек. Таксономія типів (судно, повітряне судно, транспорт, особа, підрозділ) плюс підтип і бортовий номер / номер корпусу / позивний, де відомо. Ідентичність зливається з часом; не зашивайте її в ID.
• Позиція. Широта, довгота, висота. Система координат явна (WGS84 — безпечне дефолтне). Еліпс невизначеності — не одне число; матриця коваріації або велика/мала вісь з пеленгом.
• Кінематичний стан. Швидкість (вектор), кутова швидкість повороту, обчислені курс/швидкість. З міткою часу.
• Набір джерел. Які адаптери внесли вклад у цей трек. Класифікація джерела, releasability, впевненість.
• Мітки часу. Три різні моменти: час спостереження (коли датчик побачив об'єкт), час звіту (коли повідомлення залишило датчик), час прийому (коли платформа його отримала). Змішування цих понять — поширене джерело багів.
• Стан життєвого циклу. Попередній (tentative), підтверджений, зрілий, згасаючий, втрачений. Керується рушієм злиття; видимий у СОК.
• Конверт класифікації. Ефективна класифікація, обчислена з набору джерел. Теги releasability. Маркування компартменту, якщо застосовно.
• Впевненість і визначеність. Впевненість на рівні треку; визначеність на рівні атрибута там, де це важливо (наприклад, позиція має високу визначеність, а ідентичність — попередня).

Версіонуйте схему адитивно. Нові поля — необов'язкові; існуючі поля ніколи не змінюють значення. Breaking changes допускаються лише через мажорні релізи платформи з документованою міграцією. Детальний розбір, включно з патернами нормалізації ідентичностей та стратегіями еволюції схем, — у статті Виклики інтеграції оборонних даних.

Крок 4. Виберіть тех-стек

Стек технологій оборонної C2-платформи має балансувати чотири обмеження: операційну виживаність (20-річний життєвий цикл), доброзичливість до акредитації (національні переліки схвалених рішень), наявні навички команди та інженерну ергономіку, що визначає швидкість спринтів. Наведений нижче набір — один із захищабельних, не єдиний.

Бекенд-сервіси: типізована мова зі зрілою історією конкурентності. Go і Rust — два сильні варіанти для нових програм; Java залишається захищабельним incumbent-варіантом. Уникайте нішевих мов з одним мейнтейнером — платформа переживе мовну спільноту.

Шина повідомлень: Kafka або NATS JetStream як надійний журнал подій; вибір між ними — у статті Черги повідомлень для пайплайнів оборонних даних. Для малих розгортань NATS легший; для великих — Kafka операційно перевірена.

Геопросторова база даних: PostGIS поверх PostgreSQL — за замовчуванням. Зріла, доброзичлива до акредитації, масштабується до мільярдів точок за умови правильного індексування. Інженерні деталі — у статті PostGIS для оборонних геопросторових даних.

Часова база даних: TimescaleDB як розширення PostGIS або InfluxDB як окреме сховище. Історії датчиків і телеметрія належать сюди, а не в операційне сховище треків.

Фронтенд-стек: React або Vue, типізовані (TypeScript). Cesium для 3D і виду глобуса; Mapbox GL або MapLibre для 2D. Детальні компроміси рендерингу мап — у статті Рендеринг мап у реальному часі для військового C2.

Транспорт у реальному часі: WebSocket для браузера, MQTT для тактичного edge, gRPC для між-сервісної взаємодії всередині ЦОД. У кожного — чітке місце застосування, і вони співіснують.

Автентифікація й авторизація: OpenID Connect для людей-користувачів (з інтеграцією національної PKI, де це потрібно), mTLS між сервісами з короткоживучими сертифікатами. RBAC і класифікація, накладені через виділений engine політик — Open Policy Agent є захищабельним вибором. Детальний патерн — у статті Рольовий контроль доступу в оборонних C2-системах.

Розгортання: контейнери (OCI), оркестровані Kubernetes у хмарі або великому on-prem; systemd або k3s для тактичних edge-вузлів. Ті самі артефакти працюють у всьому спектрі; змінюється оркестрація.

Опирайтеся надмірному інжинірингу. Першій збірці не потрібні service mesh, абстракція мульти-хмари чи власноруч написаний фреймворк. Нудні рішення — добре підтримувані, широко розгорнуті, з зрілими акредитаційними доказами — це правильні рішення для оборони.

Крок 5. Налаштуйте структуру репозиторію

Вирішіть заздалегідь: монорепо vs мульти-репо. Для нової платформи з однією командою монорепо зазвичай правильне: спільні бібліотеки (схема, RBAC-клієнт, телеметрія) лежать поряд із сервісами, зміни потрапляють атомарно, а збірна система примушує консистентність. Мульти-репо стає привабливим лише тоді, коли межі команд розходяться.

Захищабельна структура верхнього рівня:

• schemas/ — канонічна схема треків, схеми повідомлень, API-контракти. Кодогенеровані прив'язки для кожної мови-споживача.
• adapters/ — сенсорні адаптери, по одному на тип джерела.
• services/ — рушій злиття, сховище треків, engine політик, сервіс аудиту.
• frontend/ — СОК і допоміжний UI.
• tools/ — операційні інструменти, тестові стенди, симулятори.
• deploy/ — Kubernetes-маніфести, Helm-чарти, Ansible-playbook для тактичних edge-вузлів.
• docs/ — архітектурні рішення (ADR), runbook'и, акредитаційні докази.

Поводьтеся з каталогом документації як із кодом: рев'ювати, версіонувати, обов'язково. ADR (Architecture Decision Records) рятують платформу від повторного «суду» над тими ж компромісами кожні півроку, коли приходить новий інженер.

Що далі

Частина 1 окреслила платформу. Скоуп вибрано, чотиришарова архітектура зафіксована, канонічну схему треків спроєктовано, тех-стек обрано, репозиторій структуровано. Скелет існує; ніщо ще не приймає даних від датчика і не рендерить трек.

Частина 2: рушій злиття бере схему і будує шар, що приймає звіти датчиків, корелює їх у треки та виставляє решті платформи. Це інженерне серце системи C2, і саме там архітектурні рішення частини 1 проходять перевірку реальністю.

Перш ніж переходити до частини 2, врегулюйте рішення зі скоупу та запишіть канонічну схему треків. Серія припускає, що і те, і інше у вас уже є.