Boju vs laboratorium: doświadczenie operacyjne w obronności

Zdecydowana większość technologii obronnych oferowanych obecnie armiom państw członkowskich NATO nigdy nie była wdrożona w rzeczywistych operacjach bojowych. Była rozwijana, testowana w środowiskach kontrolowanych, demonstrowana komisjom oceniającym i certyfikowana jako spełniająca specyfikację. To nie to samo, co bycie przetestowanym bojowo — a ta różnica ma znaczenie w sposób trudny do skwantyfikowania z góry, lecz boleśnie oczywisty po wdrożeniu.

Od 2022 roku Ukraina stała się najbardziej aktywnym na świecie środowiskiem testowania technologii obronnych. Intensywność, czas trwania i charakter konfliktu z równorzędnym przeciwnikiem ujawnił tryby awarii oprogramowania wojskowego, których lata ćwiczeń i demonstracji nie odkryły. Systemy, które przetrwały i okazały się użyteczne, to jakościowo inna kategoria niż te, które nie sprostały wyzwaniu.

Co naprawdę oznacza „przetestowane bojowo"

Przetestowane bojowo nie oznacza doświadczenia bojowego w rozumieniu uczestnictwa w starciach kinetycznych. Oznacza to, że oprogramowanie było obsługiwane przez prawdziwych użytkowników wojskowych, w rzeczywistych warunkach operacyjnych, pod rzeczywistą presją operacyjną, przez dłuższy czas — a tryby awarii, które się pojawiły, zostały zidentyfikowane, naprawione, a poprawki ponownie przetestowane w tych samych warunkach.

Jest to jakość kumulatywna. System oprogramowania gromadzi doświadczenie operacyjne przez wdrożenie, awarię, diagnozowanie i usuwanie tych awarii, ponowne wdrożenie i powtarzanie tego cyklu. Efektem jest system, którego przypadki brzegowe zostały znalezione i obsłużone — nie dlatego, że programiści je przewidzieli, lecz dlatego, że rzeczywistość operacyjna je ujawniła. Żadna ilość analizy wymagań ani planowania testów nie ujawnia niezawodnie wszystkich przypadków brzegowych, które produkują rzeczywiste operacje.

System przetestowany laboratoryjnie, dla kontrastu, był testowany pod kątem specyfikacji wymagań i uznany za je spełniający. Specyfikacja była pisana przez ludzi, którzy przewidywali, jak system będzie używany i z jakimi warunkami się zetknie. Luka między tym przewidywaniem a rzeczywistością operacyjną jest źródłem większości rzeczywistych awarii oprogramowania obronnego.

Ukraina: najbardziej aktywne środowisko testowania technologii obronnych na świecie

Kilka cech sprawia, że konflikt ukraiński jest wyjątkowo cennym środowiskiem testowania technologii. Po pierwsze, tempo: konflikt charakteryzuje się utrzymywanymi operacjami wysokiej intensywności w tempie, którego ćwiczenia nie mogą odtworzyć, generując lata operacyjnego użytkowania w ciągu miesięcy. Po drugie, zaawansowanie adversaryjne: rosyjska walka elektroniczna, operacje cybernetyczne i zdolności przeciwdronowe testowały technologie obronne przeciwko równorzędnemu przeciwnikowi — nie podmiotowi zastępczemu ani zagrożeniu asymetrycznemu. Po trzecie, szybkość pętli informacji zwrotnej: organizacje działające w konflikcie były niezwykle skłonne do udzielania bezpośrednich informacji zwrotnych technicznych, umożliwiając szybką iterację.

Konkretne lekcje z tego środowiska są namacalne. Oprogramowanie dowodzenia i kontroli, które działało niezawodnie na ćwiczeniach szczebla brygady, zawodziło przy użyciu przez bataliony pod ostrzałem, ponieważ populacja użytkowników pod operacyjnym stresem wchodzi w interakcję z oprogramowaniem inaczej niż wyszkoleni operatorzy w kontekście ćwiczeń. Aplikacje logistyczne, które działały dobrze w środowiskach z zapewnionym połączeniem, zawodziły natychmiast, gdy rosyjska walka elektroniczna zakłócała komunikację na spornych obszarach. Oprogramowanie sterowania dronem, które działało bezbłędnie przy połączeniach o niskich opóźnieniach, zawodziło przy pracy przez zdegradowane połączenia — ujawniając, że oprogramowanie niejawnie zakładało poziom niezawodnego połączenia, którego specyfikacja nie wymagała, ale na którym programiści polegali.

Tryby awarii, które pojawiają się tylko w rzeczywistych operacjach

Obsługa degradacji sieci. Najbardziej spójnym odkryciem z wdrożeń operacyjnych jest to, że oprogramowanie zaprojektowane przy założeniu odpowiedniej łączności zawodzi elegancko w symulacjach i katastrofalnie w operacjach. Rzeczywiste sieci taktyczne działają przy 10–30% przepustowości dostępnej w kontekście garnizonu lub ćwiczeń. Aplikacje wykonujące dziesiątki wywołań API na interakcję użytkownika w celu obsługi aktualizacji jednego ekranu — standard w komercyjnym tworzeniu stron internetowych — stają się bezużyteczne w zatłoczonej taktycznej sieci radiowej. Ten tryb awarii prawie nigdy nie jest wykrywany podczas testów, ponieważ środowiska testowe niezmiennie mają lepszą łączność niż środowiska operacyjne.

Stres operatora i tolerancja na błędy. Prawdziwi operatorzy pod stresem używają oprogramowania inaczej niż wyszkoleni operatorzy w warunkach kontrolowanych. Naciskają przyciski wielokrotnie, bo nie są pewni, czy pierwsze naciśnięcie zostało zarejestrowane. Przerywają długotrwałe operacje. Wybierają błędne opcje i muszą cofać działania. Robią rzeczy, których programista nigdy nie przewidział. Oprogramowanie pozbawione solidnej obsługi błędów i odtwarzania po przerwanych operacjach będzie zawodzić w sposób, którego test laboratoryjny nie wykryje, ponieważ tester laboratoryjny postępuje zgodnie z oczekiwanym przepływem pracy i zna system wystarczająco dobrze, by unikać większości pułapek.

Ingerencja adversaryjna. Przeciwnicy aktywnie próbują zakłócić systemy oprogramowania — poprzez zagłuszanie (wpływające na łączność i GPS), spoofing (wstrzykiwanie fałszywych danych) i ataki cybernetyczne (exploitowanie podatności). System, który nigdy nie był eksploatowany w środowisku zwalczanym przez przeciwnika, nigdy nie miał faktycznie przetestowanej odporności na te zagrożenia. Środowisko testowe zapewnia czysty sygnał; środowisko operacyjne — wrogi.

Dlaczego demonstracje laboratoryjne mogą być mylące

Demonstracja jest zaprojektowana tak, by pokazać system z jak najlepszej strony: poprawnie skonfigurowany, obsługiwany przez osoby dobrze go znające, działający na niezawodnej sieci, w oparciu o wstępnie wybrane scenariusze. Wszystkie warunki są sprzyjające. Demonstracja, która przebiega pomyślnie, jest dowodem na to, że system jest zdolny do prawidłowego działania w idealnych warunkach. Nie jest dowodem na to, że system działa prawidłowo w warunkach operacyjnych, które nie są idealne.

Kryteria oceny stosowane w większości procesów zamówień obronnych nagradzają wyniki demonstracji, a nie odporność operacyjną. Oceniane są funkcje; odtwarzanie po awariach — nie. Oceniana jest responsywność interfejsu użytkownika w kontrolowanym środowisku; zachowanie przy spornej komunikacji — nie. Rezultatem jest proces zamówień, który systematycznie preferuje systemy, które dobrze się demonstrują, nad systemami, które dobrze działają.

O co oficerowie zamówień powinni pytać w kwestii historii operacyjnej

Kilka konkretnych pytań oddziela dostawców przetestowanych bojowo od laboratoryjnych. Po pierwsze: podaj wdrożenia operacyjne — nie piloty, nie zaangażowania proof-of-concept, lecz rzeczywiste wdrożenia operacyjne do jednostek wykonujących prawdziwe misje. Jak długo trwają te wdrożenia? Jakie problemy zgłaszali użytkownicy operacyjni (nie kierownik programu, ale rzeczywiści użytkownicy)? Jakie zmiany zostały wprowadzone w odpowiedzi?

Po drugie: jakie jest zachowanie systemu, gdy sieć jest niedostępna przez 30 minut? Przez 8 godzin? Co widzi użytkownik? Jakie dane są zachowywane? To pytanie, zadane kierownikowi technicznemu, a nie zespołowi sprzedaży, szybko ujawnia, czy odporność operacyjna była przemyślana, czy zakładana.

Po trzecie: opisz konkretną awarię operacyjną i co z nią zrobiłeś. Dostawca, który nie potrafi opisać konkretnej awarii, albo nie miał swojego systemu używanego operacyjnie, albo nie jest szczery. Wdrożenie operacyjne produkuje awarie. Doświadczeni dostawcy mają repozytorium konkretnych diagnoz awarii i pracy inżynierskiej wykonanej w celu ich usunięcia. To repozytorium jest faktycznym dowodem testowania bojowego — nie lista funkcji, nie demonstracja, nie certyfikat.