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

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

Що насправді означає «перевірено в бою»

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

Це кумулятивна якість. Програмна система накопичує оперативний досвід, будучи розгорнутою, відмовляючи, маючи ці відмови діагностованими та усуненими, розгортаючись знову та повторюючи цей цикл. Результатом є система, граничні випадки якої були знайдені та оброблені — не тому, що розробники їх передбачили, а тому, що оперативна реальність їх виявила. Жодна кількість аналізу вимог або планування тестування надійно не виявляє всі граничні випадки, які продукують реальні операції.

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

Україна: найактивніше у світі середовище для тестування оборонних технологій

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

Конкретні уроки з цього середовища є предметними. Програмне забезпечення управління та контролю, що надійно працювало на навчаннях бригадного рівня, відмовляло при використанні батальйонами під вогнем, оскільки користувачі під оперативним стресом взаємодіють з ПЗ інакше, ніж навчені оператори в умовах навчань. Логістичні застосунки, що добре працювали в умовах гарантованого зв'язку, відмовляли одразу, коли російська РЕБ порушувала зв'язок у зонах зіткнення. ПЗ управління дронами, що бездоганно працювало з малолатентними зв'язками, відмовляло при роботі через деградовані з'єднання — виявляючи, що ПЗ неявно передбачало рівень надійного зв'язку, який специфікація не вимагала, але розробники покладалися на нього.

Режими відмов, що виникають лише в реальних операціях

Обробка деградації мережі. Найбільш послідовним висновком з оперативних розгортань є те, що ПЗ, розроблене за припущення достатнього зв'язку, відмовляє коректно в симуляціях та катастрофічно в операціях. Реальні тактичні мережі працюють на рівні 10–30% від пропускної здатності, доступної в гарнізонному або навчальному контексті. Застосунки, що виконують десятки API-викликів на взаємодію користувача для оновлення одного екрана — стандарт у комерційній веб-розробці — стають непридатними у перевантаженій тактичній радіомережі. Цей режим відмови майже ніколи не виявляється при тестуванні, оскільки тестові середовища незмінно мають кращий зв'язок, ніж оперативні.

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

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

Чому лабораторні демонстрації можуть вводити в оману

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

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

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

Що слід запитувати офіцерам із закупівель про оперативну історію

Кілька конкретних питань відокремлюють постачальників, перевірених у бою, від лабораторних. По-перше: назвіть оперативні розгортання — не пілоти, не ознайомчі залучення, а фактичні оперативні розгортання до підрозділів, що виконують реальні місії. Як довго ці розгортання тривають? Які проблеми повідомляли оперативні користувачі (не керівник програми, а фактичні користувачі)? Які зміни були внесені у відповідь?

По-друге: яка поведінка системи, коли мережа недоступна протягом 30 хвилин? Протягом 8 годин? Що бачить користувач? Які дані зберігаються? Це питання, поставлене технічному керівнику, а не команді продажів, швидко виявляє, чи оперативна стійкість була продумана чи передбачена.

По-третє: опишіть конкретну оперативну відмову та що ви з нею зробили. Постачальник, який не може описати конкретну відмову, або не мав своєї системи у реальному оперативному використанні, або не є відвертим. Оперативне розгортання виробляє відмови. Досвідчені постачальники мають репозиторій конкретних діагнозів відмов та інженерних робіт, виконаних для їх усунення. Цей репозиторій є фактичним свідченням перевірки в бою — не список функцій, не демонстрація, не сертифікат.