Innowacje z systemami krytycznymi dla życia

Każde przedsiębiorstwo ma „krytyczną” infrastrukturę. Ogólnie rzecz biorąc, oznacza to, że jeśli system przejdzie w tryb offline, części (lub całość) firmy zatrzymają się, dopóki technicy nie będą mogli go ponownie uruchomić. Dzieje się tak często, gdy wymagane są duże aktualizacje oprogramowania, sprzętu lub sieci: nowo wdrożone systemy zawierają nieoczekiwane błędy, które powodują awarię systemu lub użytkownicy popełniają błędy w nowym systemie, ponieważ go nie znają, a produktywność zatrzymuje się, dopóki technicy nie będą mogli przepracować błędy wdrażania lub przeszkolić użytkowników. W większości przypadków okres przestoju lub obniżona produktywność jest akceptowalnym ryzykiem w zamian za obietnicę poprawy wydajności i efektywności nowej technologii, ale nie jest to uniwersalne. Większość firm może sobie pozwolić na pewien okres przestoju bez narażania dużych przychodów lub antagonizowania swoich klientów.

Ale co się dzieje, gdy systemy, które trzeba zmodyfikować, są systemami krytycznymi dla życia, w których bezpieczeństwo życia zależy od niezawodnego korzystania z systemu?

Ten artykuł odchodzi od bardziej tradycyjnego tworzenia oprogramowania, nad którym spędzamy większość czasu, i zamiast tego przyglądamy się elementowi ludzkiemu w systemach krytycznych dla życia. Moje przemyślenia na ten temat wynikają z mojego doświadczenia jako dyrektora ds. technologii informacyjnej dla pogotowia ratunkowego 911, jako specjalisty ds. technologii w międzynarodowej organizacji humanitarnej reagowania na katastrofy oraz z mojego doktoratu. Doktorat z Integracji Systemów Ludzkich ukończony w Massachusetts Institute of Technology.

Zanim zaczniemy, chciałbym wyjaśnić, dlaczego może to być dla Ciebie istotne. Chociaż może nie być oczywiste, że twój projekt faktycznie obejmuje system krytyczny dla życia, jest to znacznie bardziej prawdopodobne, niż mogłoby się wydawać. Wszystkie poniższe kwalifikują się, a także niezliczone inne tematy:

• Automobilowy. Pracujesz nad projektem z producentem pojazdów lub którymkolwiek z jego dostawców? Zwerbowany z uczelni przez startup zajmujący się autonomicznymi samochodami? Automatyczne hamowanie, tempomat, kontrola pasa ruchu, wizja komputerowa, rozpoznawanie przeszkód, elektroniczne moduły sterowania silnikiem itp. Każdy z nich to system krytyczny dla życia, w którym awaria może być śmiertelna.
• Lotnictwo. Kiedy jesteś 30 000' w powietrzu, prawie każda awaria systemu może być krytyczna dla życia. Biorąc pod uwagę ostatnie wydarzenia związane z Boeingiem 737 MAX, istnieją oczywiste krytyczne dla życia systemy autopilota i skomputeryzowanej kontroli lotu, ale jest też wiele rzeczy, o których możesz nie myśleć. W domu, jeśli wentylator w twoim systemie HVAC ulegnie awarii i zacznie wytwarzać trochę dymu, otwierasz okno lub wychodzisz na zewnątrz, aby zaczerpnąć świeżego powietrza. Czy kiedykolwiek próbowałeś otworzyć okno i wyjść na zewnątrz podczas lotu transatlantyckiego? Nawet najbardziej podstawowe systemy, od gniazdek w kuchni po hamulce na kołach wózka z napojami, mogą mieć krytyczne znaczenie dla życia w samolocie.
• Komunikacja. Większość programistów lub inżynierów będzie w pewnym momencie swojej kariery pracować nad projektem systemu komunikacyjnego w takim czy innym charakterze. Dla wielu ludzi telekomunikacja początkowo nie wydaje się krytyczna dla życia; w końcu cywilizacja radziła sobie dobrze przed telefonami i internetem. Jako osoba, która została rozmieszczona w strefach katastrofy, w których infrastruktura telekomunikacyjna została zniszczona, powiem ci, co się właściwie dzieje: ludzie bardzo chorują lub są ranni i nie mogą zadzwonić pod numer 911; starsi mieszkańcy nie mogą dzwonić do swoich dzieci, aby poprosić je o odbiór recept w aptece; ratownicy nie mogą komunikować się ze swoimi dyspozytorami ani między sobą; a ludzie, którzy nie mogą skontaktować się z członkami swojej rodziny, stają się zaniepokojeni i stawiają się w niezwykle niebezpiecznych sytuacjach, próbując ich znaleźć. Systemy komunikacji są absolutnie krytyczne dla życia.

W dzisiejszym świecie, w którym technologia opiera się na dużej mierze, projekty, których nigdy nie uważałeś za nawet w połowie ważne, mogą stać się istotnym elementem systemu o znaczeniu krytycznym dla życia.

Ale jeśli to nie jest zepsute, nie naprawiaj tego

Czy kiedykolwiek słyszałeś lub używałeś słowa „dziedzictwo” w odniesieniu do systemu technologicznego? To mocne słowo, przywołujące myśli o długich tradycjach, rodowodach i trudnych czasach dawnych czasów. W świecie inżynierii jest używany do oznaczania projektów, które istnieją od dłuższego czasu i okazały się działać niezawodnie i często jest postrzegane jako pożądana cecha zmniejszająca ryzyko. W rzeczywistości jest to eufemizm archaicznej technologii, która nigdy nie została zaktualizowana ze względu na awersję do ryzyka i jest wszechobecna w branżach, w których awarie systemu mogą prowadzić do tragicznych konsekwencji.

Istnieje dobry powód tego pokrewieństwa z oprogramowaniem i sprzętem odziedziczonym. Wiadomo, że działa, jest mało prawdopodobne, że pojawią się nieznane błędy, a jego koszty są stabilne i przewidywalne. Doskonałym przykładem jest przemysł lotów kosmicznych: rosyjski statek kosmiczny Sojuz od ponad 50 lat wystrzeliwuje astronautów w kosmos z niewielkimi zmianami w tym czasie i nadal jest używany, ponieważ jest niezawodny i bezpieczny. Niestety oznacza to, że jest on również wyjątkowo nieefektywny w porównaniu z nowoczesnymi projektami: podczas gdy Sojuz kosztuje NASA 81 mln USD za miejsce, aby przelecieć astronautów na stację kosmiczną przy użyciu jego tradycyjnego sprzętu, SpaceX i Boeing mają oferować miejsca po 58 mln USD za każde miejsce. używając ich nowoczesnych projektów rakietowych.

Zrozumiałe jest, że niewiele osób chce aktualizować stare systemy, które nadal działają; kadra kierownicza nie chce ryzykować, technicy nie chcą mieć do czynienia z tajemniczym serwerem w szafie z 12-letnim czasem pracy, a klienci nie chcą uczyć się nowych projektów. Niestety, istnieje punkt zwrotny między minimalizacją ryzyka a oszczędnościami: projekty zabytkowe będą musiały w końcu zostać zmodernizowane, nawet w środowiskach wysokiego ryzyka .

Pozostała część tego artykułu obejmuje niektóre z ważniejszych kroków w procesie wykonywania tego, gdy twoje systemy mają krytyczne znaczenie dla życia, na przykład te używane przez ratowników, jednostki wojskowe lub samoloty.

Przekonywanie Mosiądz

Z mojego doświadczenia wynika, że ​​prawdopodobnie najtrudniejszym etapem procesu jest przekonanie decydentów i interesariuszy, że potrzebne są ulepszenia. Systemy działające w środowiskach krytycznych dla życia często podlegają obszernym regulacjom prawnym i polityce organizacji, co oznacza, że ​​trzeba ich przekonać, że powinni nie tylko podejmować ryzyko i wydawać pieniądze, ale także angażować się w to, co z łatwością może być kilka. lata biurokratycznego cięcia taśm. Najsilniejszy sprzeciw, z jakim będziesz musiał się zmierzyć, będzie prawdopodobnie pochodził z zespołu prawnego, który szczegółowo określi potencjalną odpowiedzialność , na jaką otworzysz organizację, wprowadzając nową technologię. Mają rację: odpowiedzialność jest poważnym problemem , a jeśli coś się zepsuje i ktoś odniesie obrażenia lub umrze, może to być ogromnym obciążeniem etycznym, wizerunkowym i finansowym.

Niezależnie od tego, czy pracujesz z korporacją z listy Fortune 500, czy z lokalną ochotniczą strażą pożarną, zawsze sprowadza się to do tego samego: pieniędzy. Korporacje nie chcą go stracić, a organizacje non-profit nie mają z czym pracować. Jedynym wiarygodnym sposobem, jaki znalazłem, aby przekonać kierownictwo organizacji do podjęcia ryzyka zmiany systemu krytycznego dla życia, jest wykazanie, że prawdopodobnie jest bardziej prawdopodobne, że zarobią/zaoszczędzą pieniądze niż je stracą, albo że mogą zmniejszyć swoją odpowiedzialność poprzez modernizację technologii i poprawę bezpieczeństwa.

Oznacza to, że musisz policzyć. Jakie jest prawdopodobieństwo, że z powodu błędów wystąpią dłuższe przestoje lub przyszłe awarie (na podstawie poprzednich wdrożeń w Twojej organizacji lub danych z innych organizacji)? Jaki jest oczekiwany wpływ w przypadku niepowodzenia i ile by to kosztowało? I odwrotnie, jaki jest oczekiwany wzrost wydajności lub niezawodności i ile byłyby warte? Jeśli możesz pokazać, że istnieje duże prawdopodobieństwo, że wyjdziesz na prowadzenie, jest duża szansa, że ​​dostaniesz zielone światło.

Nie chodzi o Ciebie

Być może znasz zwrot „przez inżynierów dla inżynierów”, idiom sugerujący, że inżynierowie zbudowali coś, z czego mogą korzystać osoby o kwalifikacjach podobnych do ich własnych. Jest to niezwykle częste zjawisko i było jednym z głównych czynników przyspieszających rozwój badań użyteczności komputerów na początku lat 90. XX wieku. Jako inżynierowie często mamy inne mentalne modele działania systemów technologicznych niż przeciętny użytkownik końcowy, co prowadzi do tendencji do projektowania systemów z założeniem, że użytkownik końcowy już wie, jak to działa. W konwencjonalnych systemach prowadzi to do błędów i niezadowolonych klientów; w systemach krytycznych dla życia może prowadzić do śmierci.

Rozważmy przypadek lotu Air France 447. 1 czerwca 2009 r. Airbus A330 był nad Oceanem Atlantyckim w drodze z Rio de Janeiro do Paryża. Kryształki lodu blokowały rurki Pitota, powodując niespójności w pomiarach prędkości powietrza. Komputer pokładowy wyłączył autopilota, uznając, że nie może on niezawodnie latać samym samolotem z nieprawidłowymi danymi o prędkości lotu. Następnie przestawił się w tryb „rozszerzonej obwiedni lotu” , co pozwoliło pilotom wykonywać manewry, na które komputer normalnie nie pozwala. Można sobie wyobrazić inżynierów, którzy zbudowali system, myśląc „jeśli autopilot sam się wyłączy, to prawdopodobnie dlatego, że zaistniała sytuacja, w której piloci mogą potrzebować dodatkowej kontroli! ”

To naturalny tok myślenia inżynierów, którzy rozumieją, jakie rzeczy mogą spowodować wyłączenie się autopilota. Dla pilotów tak nie było. Zmusili samolot do stromego wznoszenia się w górę, ignorując ostrzeżenia „STALL”, aż stracił całą prędkość i spadł do oceanu. Zginęło wszystkich 228 pasażerów i załogi. Chociaż istnieje wiele pomysłów co do dokładnej motywacji ich działań, dominującą teorią jest to, że piloci zakładali, że komputer pokładowy zapobiegnie wprowadzaniu sygnałów sterujących, które zatrzymałyby samolot (co jest prawdą w przypadku normalnej obwiedni lotu) i nie zdawali sobie z tego sprawy przełączył się na tryb rozszerzonej obwiedni, ponieważ nie podzielali oni mentalnego modelu logiki inżynierów, który kierował decyzjami komputera.

Chociaż jest to nieco okrężna droga, prowadzi nas to do mojego głównego punktu: działania, które użytkownicy mają wykonać w określonych warunkach, muszą być działaniami, które są dla nich naturalne .

Użytkowników można poinstruować, aby postępowali zgodnie z określonymi procedurami, ale po prostu nie zawsze będą pamiętać, co należy zrobić, lub zrozumieć, co dzieje się w warunkach dużego stresu. Twoim obowiązkiem jest zaprojektowanie oprogramowania, elementów sterujących i interfejsów w intuicyjny sposób, który sprawi, że użytkownicy z natury chcą robić to, co powinni.

Oznacza to, że absolutnie kluczowe jest, aby użytkownicy końcowi byli zaangażowani na każdym etapie procesu projektowania i rozwoju. Nie można poczynić żadnych założeń dotyczących tego, co prawdopodobnie zrobią użytkownicy; wszystko musi być oparte na dowodach. Projektując interfejsy, musisz przeprowadzić badania, aby określić wzorce myślowe, które wywołują w użytkownikach i dostosować je w razie potrzeby. Kiedy testujesz swoje nowe systemy, musisz je przetestować z prawdziwymi użytkownikami w rzeczywistych warunkach w realistycznych warunkach. I niestety, kiedy zmieniasz swoje projekty, musisz wykonać te kroki od nowa.

Chociaż każdy złożony system jest wyjątkowy, chciałbym wspomnieć w szczególności o trzech względach projektowych, które powinny być stosowane uniwersalnie:

• Kontrole powinny być reprezentatywne dla akcji, które wywołują. Na szczęście ten jest dość powszechny, ogólnie widziany w postaci wybierania odpowiednich ikon dla przycisków GUI lub odpowiednich kształtów dla kontrolek fizycznych. Przyciski „Nowy plik” wykorzystują ikonę pustej kartki papieru, a manetki podwozia w samolotach mają pokrętło w kształcie koła. Jednak łatwo jest popaść w samozadowolenie. Dlaczego nadal widzimy ikony dyskietek 3,5” dla przycisków „Zapisz”? Czy ktoś w wieku poniżej 25 lat w ogóle wie, co to jest dyskietka? Nadal go używamy, ponieważ uważamy, że jest reprezentatywny, ale tak naprawdę już nie jest. Wymaga to nieustannego wysiłku, aby zapewnić, że reprezentacje kontrolek mają znaczenie dla użytkowników, ale konieczne i trudne jest również zrównoważenie tego ciągłością.
• Jeśli system ostrzegawczy się zepsuje, musi być wykrywalny. Często używamy lampek ostrzegawczych, które włączają się, gdy pojawia się problem, takich jak migający czerwony wskaźnik. Świetnie nadaje się do przyciągnięcia uwagi użytkownika, ale co się stanie, jeśli lampka się wypali? Statek kosmiczny używany w misjach księżycowych Apollo miał dziesiątki świateł ostrzegawczych dla wszelkiego rodzaju systemów, ale nie działały one w konwencjonalny sposób. Zamiast świecić, gdy był problem, świeciły się, gdy wszystko było w porządku i wyłączały się, gdy był problem. Gwarantowało to, że wypalona lampka ostrzegawcza nie spowoduje, że astronauci przeoczą potencjalnie krytyczny błąd systemu. Nie mówię, że powinieneś używać tego projektu, ponieważ żarówki przeszły długą drogę pod względem niezawodności od lat 60., ale daje to wyobrażenie o tym, jak dogłębne muszą być niektóre twoje plany. Ile razy system uległ awarii, ale nie wiedziałeś o tym, ponieważ logowanie lub powiadomienia nie działały poprawnie?
• Przejścia trybów muszą być oczywiste dla użytkownika. Co się stanie, jeśli Airbus A330 przejdzie z normalnego trybu sterowania do zaawansowanego trybu sterowania bez zauważenia przez użytkownika i nagle samolot zrobi rzeczy, o których użytkownik nie pomyślał, że może zrobić? Co się stanie, jeśli autonomiczny samochód wyłączy swojego autopilota, pozostawiając użytkownikowi nieoczekiwanie pełną kontrolę? Co się stanie, gdy nastąpi jakaś większa zmiana trybu lub funkcjonalności, która wymaga natychmiastowej zmiany działań użytkownika, ale zajmuje mu minutę lub dwie, zanim zorientuje się, co się właśnie stało? Chociaż różne tryby pracy mogą być konieczne w złożonym systemie, tryby nie mogą się zmieniać bez odpowiedniego powiadomienia, wyjaśnienia i interakcji z użytkownikiem.

Wycofywanie systemów krytycznych dla życia ze sklepu

Zgodnie z najlepszymi praktykami w branży faza beta ma kluczowe znaczenie dla wdrażania nowych systemów o krytycznym znaczeniu dla życia. Testy nowej technologii mogły pomóc w naprawieniu większości błędów i problemów z użytecznością, ale ukryte zagrożenia mogą się ujawnić, gdy będzie musiała być używana razem z innymi systemami w rzeczywistych środowiskach. W dyscyplinie inżynierii systemów jest to znane jako „wyłanianie się”. Właściwości pojawiające się to „nieoczekiwane zachowania, które wynikają z interakcji między składnikami aplikacji a ich środowiskiem” iz samej swojej natury są zasadniczo niemożliwe do wykrycia w warunkach laboratoryjnych. Zapraszając reprezentatywną grupę użytkowników końcowych do wypróbowania nowego systemu pod starannym nadzorem, wiele z tych właściwości można wykryć i ocenić pod kątem negatywnych konsekwencji, które mogą pojawić się przy wdrożeniu na pełną skalę.

Innym tematem, który często pojawia się w rozmowach o architekturze z moimi klientami, jest stopniowe wdrażanie. Jest to wybór między stopniową wymianą elementów istniejącego systemu na elementy nowego, aż w końcu wszystko zostanie wymienione, a zmianą wszystkiego na raz. Dla każdego są plusy i minusy: stopniowe wdrażanie pozwala na stopniową aklimatyzację użytkowników do nowego projektu, zapewniając, że zmiany przyjdą w rozsądnych ilościach, a użytkownicy nie będą przytłoczeni; z drugiej strony może przeciągać proces na dłuższe okresy i skutkować ciągłym stanem przejściowym. Natychmiastowe wdrożenia są korzystne, ponieważ „odrywają banderę” i przyspieszają działanie, ale nagłe drastyczne zmiany mogą przytłoczyć użytkowników.

Odkryłem, że w przypadku systemów krytycznych dla życia etapowe wdrażanie jest ogólnie bezpieczniejsze, ponieważ umożliwia stopniową ocenę poszczególnych komponentów w środowisku produkcyjnym i pozwala na mniejsze zmiany, jeśli coś musi zostać wycofane. Jest to jednak coś, co należy oceniać indywidualnie dla każdego przypadku.

Normalizacja dewiacji

OK, więc testy użytkowników pomogły Ci zaprojektować intuicyjny system, faza beta zidentyfikowała pojawiające się problemy, stopniowe wdrażanie pozwoliło użytkownikom zaznajomić się z projektem i wszystko działa płynnie. Skończyłeś, prawda? Niestety nie.

Nieuchronnie pojawią się problemy z twoim systemem, nie da się tego obejść. Gdy użytkownicy napotykają te problemy, często opracowują obejścia zamiast zgłaszać problem zespołowi technicznemu. Obejścia staną się standardową praktyką, udostępnianą jako „wskazówki” od weteranów po nowicjuszy. Socjolog Diane Vaughan ukuła frazę opisującą to zjawisko: „normalizacja dewiacji”. Użytkownicy tak przyzwyczajają się do dewiacyjnych zachowań, że nie pamiętają, że są one w rzeczywistości dewiacyjne.

Klasycznym przykładem jest Space Shuttle Challenger: regularnie obserwowano erozję elementu w dopalaczach rakiet na paliwo stałe podczas startu i chociaż wszyscy wiedzieli, że erodowanie elementów rakiety jest czymś złym, zdarzało się to tak często, że regularnie wydawano zwolnienia i było to rozważane normalna. 28 stycznia 1986 r. problem, o którym wszyscy wiedzieli, że nie powinien być dozwolony, ale który został znormalizowany, spowodował eksplozję Challengera i śmierć siedmiu astronautów.

Jako administrator systemu krytycznego dla życia, do Ciebie należy zapobieganie takim zdarzeniom. Sprawdź, w jaki sposób Twoi użytkownicy wchodzą w interakcję z systemem. Przesłaniaj je przez kilka dni i sprawdź, czy nie używają nieoczekiwanych obejść. Okresowo wysyłaj ankiety z prośbą o sugerowane zmiany i ulepszenia. Poświęć czas i wysiłek na ulepszenie systemu, zanim użytkownicy znajdą sposoby na obejście problemów bez Ciebie.

Trening pod presją wydajności

Często zdarza się, że awarie systemów krytycznych dla życia pojawiają się, gdy użytkownicy cierpią z powodu stresu, skoków adrenaliny i widzenia tunelowego. Zdarzyło się to pilotom Air France 447, zdarzyło się to ratownikom medycznym, którzy nie pamiętają, jak obsługiwać monitor pracy serca przy pierwszym pacjencie z zatrzymaniem krążenia, i zdarzyło się żołnierzom, którzy nie mogą prawidłowo obsługiwać swoich radiotelefonów pod ostrzałem.

Niektóre z tego ryzyka są łagodzone przez stosowanie intuicyjnych projektów, jak omówiono wcześniej, ale samo to jest niewystarczające. Szczególnie w środowiskach, w których zdarzają się scenariusze o wysokim obciążeniu, ale zdarzają się one rzadko, konieczne jest przeszkolenie użytkowników nie tylko w zakresie obsługi systemu, ale także jasnego myślenia w takich warunkach. Jeśli użytkownicy zapamiętują czynności związane z obsługą sprzętu, nie mogą poradzić sobie z nieoczekiwanymi awariami, ponieważ czynności, których się nauczyli, mogą już nie być odpowiednie; jeśli uczą się logicznego i jasnego myślenia w stresie, mogą reagować na zmieniające się okoliczności i pomagać systemowi pozostać przy życiu, gdy coś się zepsuje.

Wniosek

Oczywiście opracowywanie, wdrażanie i konserwacja oprogramowania o znaczeniu krytycznym dla życia jest o wiele bardziej złożone, niż można to szczegółowo opisać w jednym artykule. Jednak te obszary do rozważenia mogą pomóc ci lepiej zrozumieć, czego się spodziewać, gdy myślisz o pracy nad takim projektem. W podsumowaniu:

• Innowacyjność jest konieczna, nawet gdy wszystko działa sprawnie
• Trudno przekonać menedżerów, że warto ryzykować, ale liczby nie kłamią
• Użytkownicy końcowi muszą być zaangażowani na każdym etapie procesu
• Testuj i ponownie testuj z prawdziwymi użytkownikami w rzeczywistych warunkach w realistycznych warunkach
• Nie zakładaj, że zrobiłeś to dobrze za pierwszym razem; nawet jeśli działa, mogą wystąpić niewykryte problemy, o których użytkownicy nie informują.
• Szkol swoich użytkowników nie tylko w zakresie korzystania z systemu, ale także jasnego myślenia i dostosowywania się w stresie.

Na zakończenie chciałbym zauważyć, że w złożonych systemach o krytycznym znaczeniu dla bezpieczeństwa, w pewnym momencie coś pójdzie nie tak, bez względu na to, ile planujesz, testujesz i konserwujesz. Kiedy te systemy są krytyczne dla życia, jest całkiem możliwe, że awaria może prowadzić do utraty życia lub kończyn.

Jeśli taka tragedia zdarzy się z czymś, za co jesteś odpowiedzialny, będzie to przygniatające twoje sumienie i prawdopodobnie pomyślisz, że mogłeś temu zapobiec, gdybyś poświęcił więcej uwagi lub pracował ciężej. Może to prawda, może nie, ale nie da się przewidzieć każdego możliwego zdarzenia.

Pracuj skrupulatnie, nie bądź zarozumiały, a zmienisz świat na lepsze.