5.4 – Biztonságos kudarc a kudarc megelőzése helyett – Sicher scheitern statt Scheitern verhindern

1. 2019. december 5-én a NASA Marshall Űrrepülési Központjának mérnökei előkészítettek egy hidrogéntartályt a töréshez.

2. A tartály a 4693-as tesztállványon állt, nem pedig egy indítóállványon.

3. Szerkezete megegyezett a Space Launch System számára tervezett folyékony hidrogéntartállyal, de nem repülésre, hanem tesztelésre készült, így a tervezett törés egy mintadarabot semmisített volna meg anélkül, hogy egy küldetéshez szükséges alkatrészt tönkretett volna.

4. Korábbi kísérletek során a tartályt a kilövés és a felszállás során várható erőknek tették ki, és megállapították, hogy a tervezés megfelel a tervezett repülési terheléseknek.

5. A tartály repedés és deformálódás nélkül vészelte át ezeket a kísérleteket.

6. Ez a sikeres tesztelés elengedhetetlen bizonyíték volt a repüléshez, de a tartály fennmaradó biztonsági tartalékának mértékét és jellegét továbbra is nyitott kérdésként hagyta.

7. Mennyire lehetett még terhelni a szerkezetet, mielőtt alakja megadta volna magát, és vajon a meghibásodás a mérnöki modellek által jósolt helyen következett volna be, vagy inkább egy váratlan gyenge ponton?

8. Hidraulikus dugattyúk nyomták, húzták és hajlították a tartályt, miközben gázhalmazállapotú nitrogén biztosította a belső nyomást, így reprodukálva azokat az erőkombinációkat, amelyek hatásait ezután össze lehetett hasonlítani a mérnökök számításaival.

9. Több ezer érzékelő rögzítette a feszültséget, a nyomást és a hőmérsékletet, miközben a ránehezedő terhelés a szerkezeti határérték felé emelkedett.

10. Nagysebességű kamerák és mikrofonok figyelték a meggörbülés első jeleit, így a mérnökök nem csupán a végső károsodásról kaptak képet, hanem arról is, hogyan kezdett meghibásodni a tartály.

11. A mérnökök folyamatosan növelték a terhelést.

12. Több mint öt óra elteltével a tartály a repülés során várható erők 260 százalékát meghaladó erőhatásokat állt ki, mielőtt meggörbült és megrepedt – ez volt a megfigyelt töréspont ennek a konkrét kialakításnak és terhelési sorrendnek az esetében.

13. A NASA jelentése szerint az első meggörbülés a teszt előtt az elemzők által előre jelzett hely közelében kezdődött.

14. Az adott ponton mért terhelés a számított törési terhelés körülbelül három százalékán belül volt.

15. A százalékos értékek inkább ezt a kontrollált kísérletet írták le – a kiválasztott erőkkel és a mért sorrenddel –, nem pedig azt az ígéretet, hogy minden repülési tartály képes lenne ellenállni az űrben előforduló minden igénybevétel 2,6-szorosának.

16. Az ebből eredő repedés a számított küszöbértéket a modell és a fizikai szerkezet közötti mért összehasonlításává tette.

17. A tartály meghibásodott, a teszt azonban sikeres volt.

18. Ez a fordulat csak azért értelmezhető, mert a meghibásodott tárgy elkülönült az embereket és a hajtóanyagot szállító berendezéstől, és mert a mérnökök a törést bizonyítékként tervezték.

19. Egy olyan repülési tartály, amely a felszállás során szakadna meg, túl későn szolgáltatna információt ahhoz, hogy megvédje a legénységet.

20. Ebben az esetben a meghibásodás egy kijelölt helyen, megfigyelés alatt következett be, miután a terv már megfelelt a minősítési terheléseknek, így a kísérlet a tartalék szilárdságot vizsgálhatta anélkül, hogy helyettesítette volna a repülési tanúsítást.

21. A különbség elsősorban fizikai, és csak másodsorban filozófiai jellegű.

22. Egy állvány tartotta a tárgyat, miközben a tesztberendezések olyan terheléseket alkalmaztak, amelyeket a mérnökök előre megtervezhettek és mérhettek, lehetővé téve, hogy a várható következmények figyelembevételével kialakított körülmények között megközelítsék a veszélyes szerkezeti határt.

23. Az érzékelők világossá tették a meghibásodás kezdetét és lefolyását, ahelyett, hogy a mérnököknek kizárólag a roncsokból kellett volna következtetniük az okokra.

24. Az ép repülési program az állványon kívül maradt.

25. Ez az elrendezés nem tette a törött fémet abszolút értelemben ártalmatlanná; a lehetséges károkat egy erre a célra kialakított tesztkörnyezetre korlátozta, amelynek műszerei és eljárásai meghatározott szerepet szántak a törésnek.

26. Ezt biztonságos meghibásodásnak is nevezhetnénk.

27. A kifejezés nem azt jelenti, hogy a meghibásodás kívánatos lenne, bárhol is történjen, vagy hogy az annak kitett embereket figyelmen kívül lehetne hagyni.

28. Azt jelenti, hogy a rendszert úgy alakították ki, hogy egy adott hiba hasznos információt nyújthasson anélkül, hogy magával rántaná az egész rendszert, még ha a teljes védelmet soha nem is lehet pusztán a címkéből levezetni.

29. Ahhoz, hogy ez működjön, a határnak állnia kell.

30. A tesztelt objektumot meg kell különböztetni attól a szolgáltatástól vagy struktúrától, amelyre az emberek már támaszkodnak, és elvesztése esetén is működőképes útvonalat kell hagynia azoknak a tevékenységeknek, amelyeket a kísérlet javítani kívánt.

31. Az alkalmazott erőknek egy meghatározott kérdésre kell választ adniuk a rendszer szilárdságával, viselkedésével vagy egy meglévő modell pontosságával kapcsolatban.

32. A méréseknek rögzíteniük kell azt a pontot, amelyen a rendszer elkezdi eltérni a várt viselkedéstől, mivel a végső roncsok dokumentálása önmagában nem feltétlenül magyarázza meg a hiba okát.

33. A kísérleten kívüli személyeket és berendezéseket meg kell védeni a teszt lehetséges következményeitől.

34. A szervezetnek a tesztalany eltűnése után is rendelkeznie kell egy működőképes alternatívával, függetlenül attól, hogy ez az alternatíva egy sértetlen repülési tartály, egy változatlan szoftververzió vagy egy továbbra is elérhető szolgáltatás.

35. Egy megsemmisült példány értékes lehet, mivel veszteségét előre figyelembe vették.

36. A számítás más lenne, ha ugyanaz a példány lenne az egyetlen működőképes alkatrész.

37. A mérnököknek azt is tudniuk kell, hogy milyen megfigyelés késztetné őket egy modell, terv vagy eljárás felülvizsgálatára, mivel azok az adatok, amelyek nem befolyásolják a döntést, alig többet tesznek, mint hogy dokumentálják a károkat.

38. Egy teszt lehet határolt és mérhető, mégis lehet, hogy nem nyújt tanulságot, ha eredményei soha nem változtatnak a döntésen.

39. A NASA eredménye különösen éles összehasonlítást nyújtott az előrejelzés és a megfigyelés között.

40. A meghibásodás helyének egyezése és a kezdeti alakváltozási terhelés pontos becslése alátámasztotta a szerkezeti modell megbízhatóságát a tesztelt feltételek között, ahol a modell elég pontos előrejelzést adott ahhoz, hogy szembesülhessenek vele.

41. Egyik megfigyelés sem bizonyította, hogy a modell leírta volna minden olyan terheléskombinációt, amellyel a rakéta a tesztben szereplőn túl szembesülhet.

42. A tesztelésnek megvan a maga határai.

43. Ezen a területen belül a meghibásodásig történő terhelés olyan tartalékot tár fel, amelyet a szokásos minősítési tesztek nem tárnak fel.

44. Ezen a területen túl a mérnököknek továbbra is fel kell tenniük a kérdést, hogy az anyagok, a gyártás vagy a feszültségkombinációk közötti különbségek megváltoztathatják-e az eredményt, mivel egy teszt keretében elért sikeres előrejelzés nem zárhat ki minden meghibásodási módot.

45. A tesztállvány célja az volt, hogy felfedezzék a határt anélkül, hogy azt repülés közben kellene felfedezni.

46. Ez az elv túlmutat a hardveren, bár a korlátozás mechanizmusai változnak.

47. A szoftveres sandbox elszigeteli a program műveleteit a gép többi részétől azáltal, hogy korlátozza, mire férhet hozzá a program.

48. Egy korlátozott szolgáltatási kiadás a szélesebb körű bevezetés előtt csak néhány felhasználó számára teszi elérhetővé a változást, így a rendszergazdáknak lehetőségük nyílik a valós viselkedés megfigyelésére, miközben a legtöbb felhasználó a meglévő verziót használja.

49. Egyik elhatárolás sem teljes automatikusan.

50. Egy homokozó még mindig hozzáférhet a megosztott adatokhoz, és egy kis kiadás is függhet a mindenki által használt infrastruktúrától, így a kísérlet látszólagos mérete alábecsülheti annak tényleges hatókörét.

51. A releváns kérdés az, hogy mely kapcsolatok juttathatnak hibát a tervezett határon túlra.

52. Ez a kérdés a rendszer felépítését érinti, nem a csapat magabiztosságát.

53. Egy üzemeltető őszintén remélheti a sikert, és mégis a hibára készülve tervezhet.

54. Egy teszt akkor lesz informatívabb, ha a tervezői előre meghatározzák, mi minősülne kudarcnak, mely mérési eredmények tárnák fel azt, és milyen gyorsan kell a szervezetnek reagálnia erre a jelre.

55. Ezután mérőeszközöket helyezhetnek el a küszöbérték közelében, és eldönthetik, kinek van jogosultsága a kísérlet leállítására.

56. A tartalék komponens csak akkor segít, ha ugyanaz a hiba nem képes egyszerre kikapcsolni mind azt, mind pedig azt a komponenst, amelyet helyettesítenie kell.

57. Egy hibás függőség megkettőzése csupán egy második útvonalat biztosít a hibának.

58. A határoláshoz ezért a tesztelt alkatrész ismerete mellett a közös alkatrészek ismerete is szükséges, mert egyetlen közös függőség is semmissé teheti a különálló komponensek által ígért védelmet.

59. A NASA tartálya szokatlanul jól láthatóvá tette a határait.

60. Egy szoftverfrissítés perceken belül átlépheti a határait.

61. 2024. július 19-én a CrowdStrike 04:09 UTC-kor kiadott egy Rapid Response Content frissítést a Windows-érzékelőihez.

62. A tartalom célja az volt, hogy segítse a biztonsági terméket a fenyegetések felismerésében azok megjelenésekor, így a gyorsaságnak operatív célja volt.

63. A vállalat incidens-elemzése szerint egy érvényesítési hiba miatt problémás adatok jutottak át a frissítésre alkalmazott ellenőrzéseken, annak ellenére, hogy korábban már sikeresen telepítettek kapcsolódó tartalmakat, amelyek látszólag igazolták a folyamatba vetett bizalmat.

64. Amikor az érintett érzékelők feldolgozták az adatokat, egy határon kívüli memóriololvasás a Windows összeomlásához vezetett.

65. A CrowdStrike 05:27 UTC-kor visszavonta a hibás tartalmat, ezzel lezárva azt az időintervallumot, amely alatt az újonnan csatlakozó rendszerek megkaphatták volna azt.

66. Azonban a már összeomlott számítógépek helyreállítása továbbra is szükséges lehetett, ami jól mutatja, miért külön feladat a terjesztés leállítása és a következmények kijavítása.

67. A terjesztési időtartam kevesebb mint másfél óra volt.

68. Ez a rövid időtartam elegendő volt ahhoz, hogy a változás számos szervezet Windows-gépeire eljusson, mivel az automatizált terjesztés sokkal gyorsabban terjesztheti a hibás konfigurációt, mint amennyire az operátorok diagnosztizálni tudják annak hatását.

69. A hibának nem volt kijelölt tesztkörnyezete.

70. A hiba egy széles körben elterjedt termék terjesztési útvonalán terjedt tovább, és eljutott a kiadási csapattól távol eső gépekig is.

71. A CrowdStrike jelentése fontos különbséget tesz kétféle frissítés között.

72. A szokásos érzékelő kód már átesett egy fokozatos kiadási folyamaton, amely belső tesztelést és korai felhasználókat is magában foglalt – ez az út több lehetőséget biztosított a hibák feltárására, mielőtt a változás eljutott volna a szélesebb ügyfélkörhöz.

73. Ennek a gyorsabb tartalomterjesztési útvonalnak hiányzott a hiba hatékony korlátozása.

74. Ha az eseményt egyszerűen szoftverhibának nevezzük, akkor figyelmen kívül hagyjuk azt az útvonalat, amelyen keresztül a hiba széles körű leállássá vált – a nem megfelelő érvényesítéstől kezdve a kezelhetetlen összeomlásig és a széles körű terjesztési folyamatig.

75. A tartalmi hiba fontos volt, akárcsak az, hogy az értelmező nem tudta megfelelően kezelni az ebből eredő kivételt.

76. Az érintett gépek a szervezetek mindennapi munkájának részét képezték, nem pedig feláldozható tesztpéldányok voltak.

77. Az érvényesítés, a zökkenőmentes hiba kezelés és a fokozatos terjesztés egymástól független védelmi mechanizmusok, amelyek önállóan is sikeresek vagy sikertelenek lehetnek.

78. A szigorúbb érvényesítés megakadályozhatja, hogy egy hibás frissítés elhagyja a kiadási folyamatot, mielőtt bármely ügyfél megkapná.

79. A jobb hiba kezelés megakadályozhatja, hogy egy hibás frissítés összeomlasztja az operációs rendszert, még akkor is, ha az érvényesítés nem veszi észre a hibát.

80. A fokozatos terjesztés korlátozhatja a veszélynek kitett gépek számát, miközben a mérnökök felismerik a hibát és leállítják a további terjesztést.

81. E védelmi intézkedések egyike sem menti fel a többi hiányát.

82. Az incidens után a CrowdStrike bejelentette, hogy további ellenőrzéseket vezet be, kiterjeszti a tesztelést, javítja a hiba kezelését, és elhalasztja a Rapid Response Content terjesztését, így kezelve mind a hiba validáción való áthaladását, mind annak későbbi elterjedését.

83. A bejelentett bevezetés egy „canary” telepítéssel kezdődne, és a terjesztés kiterjesztésével párhuzamosan monitorozást is magában foglalna.

84. Ezek a vállalat saját beszámolójában javasolt javító intézkedések, amelyek hasznos technikai időrendet nyújtanak, de a változtatások bejelentésével nem tudják garantálni, hogy minden későbbi frissítés biztonságos lesz.

85. A „canary” kifejezés egy kis, ideiglenes kiadásra utal, amelyet valós üzemeltetési körülmények között hajtanak végre, mielőtt a változás szélesebb körben elérhetővé válna.

86. A Google webhelymegbízhatósági útmutatója a szolgáltatás megváltozott részét egy változatlan kontrollrésszel együtt írja le, hogy az üzemeltetők valós terhelés mellett összehasonlíthassák a kettőt, mielőtt eldöntenék, hogy több felhasználó számára is elérhetővé teszik-e a változtatást.

87. A kiadási döntést az összehasonlításnak kell megelőznie.

88. Ez az összehasonlítás olyan hibákat is feltárhat, amelyeket a tesztkörnyezet nem vesz észre, mivel a valós forgalom, az időzítés és a függőségek eltérnek a szimulációktól, de értéke attól függ, hogy olyan mintát válasszanak-e, amelyben a feltételezett hiba előfordulhat.

89. Egy kis léptékű első kiadás megakadályozhatja azt is, hogy egy hiba egyszerre érje el az összes felhasználót.

90. Az első kiadásnak mégis elég nagynak kell lennie ahhoz, hogy olyan körülményekkel találkozzon, amelyek mellett a feltételezett hiba megjelenhet.

91. Ha egy hiba csak nagy terhelés mellett jelentkezik, egy alacsony forgalmú minta sikert jelezhet, miközben a teljes szolgáltatás meghibásodna, így a forgalom mennyisége és a napszak is a kísérlet tervezésének részévé válik.

92. Ha egy hiba csak több óra elteltével vagy egy hosszú futásidejű feladat befejezése után jelentkezik, egy rövid megfigyelési időszak véget ér, mielőtt a bizonyíték megérkezne, még akkor is, ha minden rendelkezésre álló mutatót gondosan ellenőriznek.

93. Egy ritka hiba elkerülheti a kis mintát akkor is, ha a felügyelet tökéletesen működik, és a minta a tervezett időtartamig fut.

94. A jó méréseknek nem csupán azt kell nyomon követniük, hogy egy gép technikailag működik-e.

95. Egy olyan szolgáltatás, amely lassan válaszol a kérésekre vagy hibás eredményeket ad, egészségesnek tűnhet egy olyan irányítópulton, amely csak az összeomlásokat rögzíti; ezért a „kanári” számára kiválasztott mérőszámoknak tükrözniük kell a felhasználók tényleges igényeit.

96. A változatlan rész összehasonlítási alapot nyújt, de a közös infrastruktúra elmoshatja ezt a különbséget.

97. Mindkét rész ugyanazt az adatbázist, hálózatot vagy külső szolgáltatót használhatja, ami miatt elválasztásuk kevésbé teljes, mint amilyennek látszik.

98. Egy rossz változtatás a „kanári” rendszerben túlterhelheti ezt a közös függőséget, és a kontrollcsoport felhasználóinak is kárt okozhat, megcáfolva azt a feltételezést, hogy a változatlan rész el van szigetelve a kísérlettől.

99. Ezzel szemben egy független probléma a megosztott rendszerben úgy tűnhet, mintha a „kanári” lenne a hibás.

100. A mérnököknek szükségük van a szolgáltatás általános állapotának mérésére, valamint a két csoport közötti különbségek mérésére is, mivel a közös hiba mindkét adatsort egy irányba mozdíthatja el, és elrejtheti a problémát az összehasonlításban.

101. A leállítási szabály csak akkor bír jelentőséggel, ha valaki vagy valami azonnal reagálhat rá, mielőtt egy kedvezőtlen jel szélesebb körű meghibásodássá válna.

102. A kiadási folyamatnak képesnek kell lennie a terjesztés leállítására és a használható állapot helyreállítására.

103. A visszavonás nehezebb, ha egy változtatás olyan adatokat módosít, amelyeket az előző verzió nem tud olvasni, vagy ha a felhasználók már a hibás kimenet alapján cselekedtek, mert a szoftver visszaállítása nem fordítja vissza a használatának minden következményét.

104. A hiba hatóköre magában foglalja a késleltetett és visszafordíthatatlan hatásokat is, nem csupán a kezdetben frissített eszközök számát, így egy kis léptékű telepítés is jelentős veszteséget okozhat a közös függőségek vagy a tartós döntések miatt.

105. A kockázat mértéke is idővel növekszik.

106. Éppen ezért a „kis” kifejezésnek a kockázat mértékét és a következményeket kell leírnia, nem csupán a telepítések számát.

107. Néha a helyes első lépés egy olyan laboratóriumi teszt, amelyben egyáltalán nincsenek felhasználók, különösen akkor, ha a lehetséges kár visszavonhatatlan.

108. Néha valódi forgalomra van szükség ahhoz, hogy megtudjuk, mit nem tud a laboratórium reprodukálni a tényleges igény és a kapcsolódó rendszerek tekintetében.

109. A választás attól függ, mi romolhat el, milyen gyorsan válik láthatóvá a hiba, és ki viselné a veszteséget, mivel ugyanaz a kitettség elfogadható lehet egy eldobható tesztalany esetében, de elfogadhatatlan egy ember számára.

110. Egy sikertelen teszt nem azért biztonságos, mert a végrehajtó szervezet meg tudja fizetni a költségeket.

111. Ha a lakosok, a munkavállalók vagy a kiszolgáltatott felhasználók visszafordíthatatlan kárt szenvednek el, a kísérlet a kockázatot nem szűkítette le, hanem áthárította, még akkor is, ha a kísérletet végző szervezet csupán csekély pénzügyi veszteséggel szembesül.

112. Egy acéltartály szándékos megsemmisítése nem jogosíthat fel hasonló bánásmódra olyan emberekkel szemben, akiknek veszteségei tartósak vagy önkéntelenek lennének.

113. Egy tartálynak nincs joga hozzájáruláshoz, gondoskodáshoz vagy jogorvoslathoz.

114. Az etikai határ a műszaki határ része, mivel a kudarc költségeit azoknak kell viselniük, akik ténylegesen viselik azokat, beleértve azokat is, akik soha nem döntöttek úgy, hogy részt vesznek a kísérletben.

115. Vannak olyan helyzetek, amikor egyetlen elfogadható kis léptékű kísérlet sem képes reprodukálni egy lehetséges katasztrófa körülményeit, így a döntéshozóknak modellekre, kevésbé közvetlen tesztekre és védelmi határértékekre kell támaszkodniuk.

116. Ez a korlát másfajta bizonyítékokat és szigorúbb önmérsékletet igényel, nem pedig azt, hogy úgy tegyünk, mintha egy „kanári” garantálná a biztonságot.

117. Marshallban a tartály megsemmisítésének kijelöltek egy helyet és egy célt.

118. A tartály repedése helyszínt, terhelést és összehasonlítási alapot biztosított a mérnököknek a modelljükhöz képest.

119. A tesztállványon kívül a repülési berendezések sértetlenek maradtak.

120. Hasznosnak az a repedés bizonyult, amelynek terjedését még a fém megadása előtt korlátozták.

1. Am 5. Dezember 2019 bereiteten Ingenieure am Marshall Space Flight Center der NASA einen Wasserstofftank für einen Bruch vor.

2. Der Tank stand im Teststand 4693, nicht auf einer Startrampe.

3. Seine Struktur entsprach dem für das Space Launch System konzipierten Flüssigwasserstofftank, doch er war für Testzwecke und nicht für den Flug gebaut worden, sodass der geplante Bruch ein Testexemplar zerstören würde, ohne eine Missionskomponente zu beschädigen.

4. Bei früheren Versuchen war der Tank den beim Start und Aufstieg zu erwartenden Kräften ausgesetzt worden, wodurch nachgewiesen wurde, dass die Konstruktion den vorgesehenen Flugbelastungen standhielt.

5. Er hatte diese Versuche ohne Risse oder Verformungen überstanden.

6. Diese Belastbarkeit war ein notwendiger Nachweis für den Flug, ließ jedoch die Frage nach der Größe und Art der verbleibenden Sicherheitsreserve des Tanks offen.

7. Wie weit konnte die Struktur noch beansprucht werden, bevor ihre Form nachgab, und würde das Versagen an der Stelle auftreten, die die technischen Modelle vorhersagten, oder an einer unerwarteten Schwachstelle?

8. Hydraulikkolben drückten, zogen und bogen den Tank, während gasförmiger Stickstoff für den Innendruck sorgte; so wurden Kraftkombinationen nachgebildet, deren Auswirkungen dann mit den Berechnungen der Ingenieure verglichen werden konnten.

9. Tausende von Sensoren zeichneten Spannungen, Druck und Temperatur auf, während die aufgebrachten Lasten bis an die strukturelle Grenze stiegen.

10. Hochgeschwindigkeitskameras und Mikrofone hielten Ausschau nach den ersten Anzeichen eines Knickens und lieferten den Ingenieuren so eine Aufzeichnung darüber, wie der Tank zu versagen begann, anstatt nur einen Blick auf den endgültigen Schaden zu gewähren.

11. Die Ingenieure erhöhten die Belastung kontinuierlich weiter.

12. Nach mehr als fünf Stunden hatte der Tank Kräfte von über 260 Prozent der im Flug zu erwartenden Belastungen ausgehalten, bevor er knickte und brach – ein beobachteter Bruchpunkt für diese spezielle Konfiguration und Belastungssequenz.

13. Die NASA berichtete, dass das erste Knicken nahe der Stelle einsetzte, die ihre Analysten vor dem Test vorhergesagt hatten.

14. Die Belastung an dieser Stelle lag innerhalb von etwa drei Prozent der berechneten Bruchlast.

15. Die Prozentangaben beschrieben diesen kontrollierten Test mit seinen festgelegten Kräften und der gemessenen Abfolge und stellten keine Zusicherung dar, dass jeder Flugtank dem 2,6-Fachen jeder Belastung standhalten könnte, der er im Weltraum ausgesetzt sein könnte.

16. Der entstandene Riss verwandelte einen berechneten Schwellenwert in einen gemessenen Vergleich zwischen einem Modell und einer physischen Struktur.

17. Der Tank versagte, doch der Test war erfolgreich.

18. Diese Umkehrung ergibt nur deshalb Sinn, weil das Objekt, das brach, von der Hardware getrennt war, die für den Transport von Menschen und Treibstoff vorgesehen war, und weil die Ingenieure den Bruch als Beweisquelle konzipiert hatten.

19. Ein Flugtank, der während des Aufstiegs reißen würde, würde Informationen liefern, die zu spät kämen, um die Besatzung zu schützen.

20. Hier trat der Versagen an einer festgelegten Stelle unter Beobachtung auf, nachdem die Konstruktion bereits ihre Qualifikationsbelastungen bestanden hatte, sodass das Experiment Aufschluss über die Reservestärke geben konnte, ohne an die Stelle der Flugzulassung zu treten.

21. Der Unterschied ist eher physikalischer als philosophischer Natur.

22. Ein Prüfstand hielt das Bauteil fest, während Testgeräte Belastungen aufbrachten, die die Ingenieure planen und messen konnten, sodass eine gefährliche strukturelle Grenze unter Bedingungen angegangen werden konnte, die auf die erwarteten Folgen abgestimmt waren.

23. Sensoren machten den Beginn und den Verlauf des Versagens nachvollziehbar, anstatt es den Ingenieuren zu überlassen, Ursachen allein aus den Trümmern abzuleiten.

24. Das intakte Flugprogramm blieb außerhalb des Prüfstands.

25. Diese Anordnung machte das zerbrochene Metall nicht im absoluten Sinne harmlos; sie begrenzte den möglichen Schaden auf eine eigens dafür geschaffene Testumgebung, deren Instrumente und Verfahren dem Bruch eine definierte Rolle zuwiesen.

26. Man könnte dies als „sicheren Ausfall“ bezeichnen.

27. Der Ausdruck bedeutet nicht, dass ein Ausfall wünschenswert ist, wo immer er auftritt, oder dass die ihm ausgesetzten Menschen ignoriert werden können.

28. Es bedeutet, dass ein System so ausgelegt wurde, dass ein bestimmtes Versagen nützliche Erkenntnisse liefern kann, ohne das gesamte System mit sich zu reißen – auch wenn aus dieser Bezeichnung allein niemals ein vollständiger Schutz abgeleitet werden kann.

29. Damit dies funktioniert, muss die Abgrenzung bestehen bleiben.

30. Das zu testende Objekt muss von dem Dienst oder der Struktur unterscheidbar sein, auf die sich Menschen bereits verlassen, und sein Verlust muss einen funktionierenden Weg für die Aktivitäten offenlassen, die durch das Experiment verbessert werden sollten.

31. Die ausgeübten Kräfte müssen eine definierte Frage zur Festigkeit, zum Verhalten oder zur Genauigkeit eines bestehenden Modells beantworten.

32. Messungen müssen den Zeitpunkt erfassen, an dem das System beginnt, von seinem erwarteten Verhalten abzuweichen, da eine Aufzeichnung des endgültigen Schadens allein möglicherweise nicht erklärt, warum der Ausfall aufgetreten ist.

33. Personen und Ausrüstung außerhalb des Experiments müssen vor den möglichen Folgen des Tests geschützt werden.

34. Die Organisation muss auch nach dem Verlust des Testobjekts über eine funktionsfähige Alternative verfügen, sei es ein intakter Flugtank, eine unveränderte Softwareversion oder ein weiterhin verfügbarer Dienst.

35. Ein zerstörtes Testobjekt kann wertvoll sein, da sein Verlust im Voraus einkalkuliert wurde.

36. Die Berechnung würde sich ändern, wenn dasselbe Testobjekt die einzige funktionsfähige Komponente wäre.

37. Ingenieure müssen außerdem wissen, welche Beobachtung sie dazu veranlassen würde, ein Modell, einen Entwurf oder ein Verfahren zu überarbeiten, denn Daten, die keinen Einfluss auf eine Entscheidung haben, dienen kaum mehr als der Dokumentation von Schäden.

38. Ein Test kann zwar abgegrenzt und gemessen werden, aber dennoch keinen Aufschluss geben, wenn seine Ergebnisse niemals eine Entscheidung beeinflussen.

39. Das Ergebnis der NASA lieferte einen besonders anschaulichen Vergleich zwischen Vorhersage und Beobachtung.

40. Eine Übereinstimmung der Versagensstelle und eine genaue Schätzung der anfänglichen Knicklast stärkten das Vertrauen in das Strukturmodell unter den getesteten Bedingungen, unter denen das Modell eine Vorhersage getroffen hatte, die präzise genug war, um einer Überprüfung standzuhalten.

41. Keine der beiden Beobachtungen bewies, dass das Modell jede Lastkombination beschrieb, der eine Rakete über die im Test dargestellten hinaus ausgesetzt sein könnte.

42. Tests haben einen bestimmten Anwendungsbereich.

43. Innerhalb dieses Bereichs deckt das Testen bis zum Versagen eine Sicherheitsmarge auf, die bei gewöhnlichen Qualifizierungstests verborgen bleibt.

44. Außerhalb dieses Bereichs müssen Ingenieure sich dennoch fragen, ob Unterschiede bei Materialien, in der Fertigung oder bei Belastungskombinationen das Ergebnis verändern könnten, da eine erfolgreiche Vorhersage unter einer Testbedingung nicht jeden Versagensmodus abdecken kann.

45. Der Sinn des Prüfstands bestand darin, eine Grenze zu ermitteln, ohne sie im Flug zu entdecken.

46. Dieses Prinzip gilt über die Hardware hinaus, auch wenn sich die Mechanismen der Begrenzung ändern.

47. Eine Software-Sandbox isoliert die Aktionen eines Programms vom Rest des Systems, indem sie den Zugriffsbereich des Programms einschränkt.

48. Eine begrenzte Service-Version macht eine Änderung vor einer breiteren Einführung nur einigen Nutzern zugänglich und gibt den Betreibern so die Möglichkeit, das tatsächliche Verhalten zu beobachten, während die meisten Nutzer weiterhin die bestehende Version verwenden.

49. Keine der beiden Begrenzungen ist automatisch vollständig.

50. Eine Sandbox kann dennoch auf gemeinsam genutzte Daten zugreifen, und eine kleine Version kann von einer Infrastruktur abhängen, die von allen genutzt wird; daher kann der sichtbare Umfang eines Tests dessen tatsächliche Reichweite unterschätzen.

51. Die relevante Frage ist, welche Verbindungen einen Fehler über die beabsichtigte Grenze hinaus tragen können.

52. Diese Frage betrifft die Struktur des Systems, nicht das Vertrauen des Teams.

53. Ein Betreiber kann aufrichtig mit Erfolg rechnen und dennoch für den Fall eines Fehlers planen.

54. Ein Test wird aussagekräftiger, wenn seine Entwickler im Voraus festlegen, was als Fehler gilt, welche Messwerte diesen aufdecken würden und wie schnell die Organisation auf dieses Signal reagieren muss.

55. Sie können dann Messinstrumente in der Nähe dieser Schwelle platzieren und festlegen, wer befugt ist, den Test abzubrechen.

56. Eine Reservekomponente hilft nur, wenn derselbe Fehler nicht sowohl sie als auch die Komponente, die sie ersetzen soll, außer Betrieb setzen kann.

57. Das Duplizieren einer fehlerhaften Abhängigkeit verschafft dem Fehler lediglich einen zweiten Weg.

58. Die Eindämmung erfordert daher ebenso viel Wissen über gemeinsame Teile wie über das zu testende Teil, da eine einzige gemeinsame Abhängigkeit den durch separate Komponenten versprochenen Schutz zunichte machen kann.

59. Der NASA-Tank machte seine Grenze ungewöhnlich sichtbar.

60. Ein Software-Update kann diese Grenze innerhalb von Minuten überschreiten.

61. Am 19. Juli 2024 veröffentlichte CrowdStrike um 04:09 Uhr UTC ein „Rapid Response Content“-Update für seine Windows-Sensoren.

62. Der Inhalt sollte dem Sicherheitsprodukt helfen, Bedrohungen sofort nach ihrem Auftreten zu erkennen, sodass die Geschwindigkeit einem operativen Zweck diente.

63. Laut der Vorfallanalyse des Unternehmens ermöglichte ein Validierungsfehler, dass problematische Daten die für dieses Update durchgeführten Prüfungen passierten, obwohl frühere erfolgreiche Bereitstellungen verwandter Inhalte das Vertrauen in den Prozess zu rechtfertigen schienen.

64. Als betroffene Sensoren die Daten auswerteten, führte ein Speicherzugriff außerhalb des zulässigen Bereichs zu einem Windows-Absturz.

65. CrowdStrike machte den fehlerhaften Inhalt um 05:27 Uhr UTC rückgängig und beendete damit das Zeitfenster, in dem neu verbundene Systeme ihn noch empfangen konnten.

66. Dennoch mussten Computer, die bereits abgestürzt waren, möglicherweise noch wiederhergestellt werden, was verdeutlicht, warum das Stoppen der Verteilung und die Behebung ihrer Folgen getrennte Aufgaben sind.

67. Das Verteilungsfenster dauerte weniger als eineinhalb Stunden.

68. Dieses kurze Intervall reichte aus, damit die Änderung Windows-Rechner in vielen Organisationen erreichte, da die automatisierte Bereitstellung eine fehlerhafte Konfiguration viel schneller verbreiten kann, als Betreiber deren Auswirkungen diagnostizieren können.

69. Für den Fehler war kein Teststand vorgesehen.

70. Der Fehler verbreitete sich über den Verteilungspfad eines weit verbreiteten Produkts und erreichte Rechner, die weit vom Release-Team entfernt waren.

71. Der Bericht von CrowdStrike unterscheidet deutlich zwischen zwei Arten von Updates.

72. Der reguläre Sensorkode durchlief bereits einen stufenweisen Release-Prozess mit internen Tests und Early Adopters – ein Weg, der Fehlern mehr Möglichkeiten bot, aufzutreten, bevor die Änderung die breitere Kundenbasis erreichte.

73. Diesem schnelleren Verteilungsweg fehlte eine wirksame Begrenzung für den Fehler.

74. Das Ereignis einfach als Softwarefehler zu bezeichnen, lässt den Weg außer Acht, auf dem der Fehler zu einem großflächigen Ausfall führte – von unzureichender Validierung über einen nicht beherrschbaren Absturz bis hin zu einem Verteilungsprozess mit großer Reichweite.

75. Der Fehler im Code spielte eine Rolle, ebenso wie die Unfähigkeit des Interpreters, die daraus resultierende Ausnahme elegant zu behandeln.

76. Die betroffenen Rechner waren Teil des regulären Betriebs der Organisationen und keine entbehrlichen Testobjekte.

77. Validierung, elegante Fehlerbehandlung und gestaffelte Verteilung sind eigenständige Schutzmaßnahmen, die unabhängig voneinander versagen oder erfolgreich sein können.

78. Eine strengere Validierung kann verhindern, dass ein fehlerhaftes Update die Release-Pipeline verlässt, bevor es bei einem Kunden ankommt.

79. Eine bessere Fehlerbehandlung kann verhindern, dass ein fehlerhaftes Update das Betriebssystem zum Absturz bringt, selbst wenn die Validierung es übersieht.

80. Eine stufenweise Verteilung kann die Anzahl der betroffenen Rechner begrenzen, während Ingenieure einen Fehler erkennen und die weitere Bereitstellung stoppen.

81. Keine dieser Schutzmaßnahmen entschuldigt das Fehlen einer anderen.

82. Nach dem Vorfall kündigte CrowdStrike an, zusätzliche Prüfungen einzuführen, die Tests auszuweiten, die Fehlerbehandlung zu verbessern und die Bereitstellung von „Rapid Response Content“ zu staffeln, um sowohl das Durchrutschen des Fehlers durch die Validierung als auch dessen anschließende Ausbreitung anzugehen.

83. Die angekündigte Einführung solle mit einem „Canary“-Deployment beginnen und eine Überwachung im Zuge der Ausweitung der Verteilung umfassen.

84. Dies waren die im eigenen Bericht des Unternehmens vorgeschlagenen Abhilfemaßnahmen, der zwar eine nützliche technische Chronologie liefert, aber durch die Ankündigung von Änderungen nicht gewährleisten kann, dass jedes spätere Update sicher sein wird.

85. Der Begriff „Canary“ bezieht sich auf eine kleine, vorübergehende Veröffentlichung unter realen Betriebsbedingungen, bevor die Änderung eine breitere Nutzergruppe erreicht.

86. Die Leitlinien von Google zur Site Reliability beschreiben einen geänderten Teil eines Dienstes neben einem unveränderten Kontrollteil, sodass Betreiber beide unter realer Auslastung vergleichen können, bevor sie entscheiden, ob sie weitere Nutzer einbeziehen.

87. Eine Entscheidung über die Freigabe muss auf diesem Vergleich basieren.

88. Dieser Vergleich kann Fehler aufdecken, die in einer Testumgebung übersehen werden, da sich der tatsächliche Datenverkehr, das Timing und die Abhängigkeiten von Simulationen unterscheiden; sein Wert hängt jedoch von der Auswahl einer Stichprobe ab, bei der der vermutete Fehler auftreten kann.

89. Eine kleine erste Freigabe kann zudem verhindern, dass ein Fehler alle Nutzer auf einmal betrifft.

90. Die erste Freigabe muss dennoch groß genug sein, um die Bedingungen abzudecken, unter denen der vermutete Fehler auftreten könnte.

91. Tritt ein Fehler nur unter hoher Auslastung auf, kann eine „ruhige“ Stichprobe einen Erfolg melden, während der gesamte Dienst ausfallen würde; daher sind Datenverkehrsvolumen und Tageszeit Teil des Versuchsdesigns.

92. Tritt ein Fehler erst nach mehreren Stunden oder nach Abschluss einer lang andauernden Aufgabe auf, endet ein kurzer Beobachtungszeitraum, bevor der Nachweis vorliegt – selbst wenn alle verfügbaren Metriken sorgfältig überprüft werden.

93. Ein seltener Ausfall kann einer winzigen Stichprobe entgehen, selbst wenn die Überwachung einwandfrei funktioniert und die Stichprobe über die geplante Dauer läuft.

94. Gute Messungen müssen mehr erfassen als nur, ob eine Maschine technisch läuft.

95. Ein Dienst, der Anfragen langsam beantwortet oder Ergebnisse verfälscht, kann auf einem Dashboard, das nur Abstürze erfasst, als fehlerfrei erscheinen; daher müssen die für einen „Canary“ gewählten Messgrößen die tatsächlichen Bedürfnisse der Nutzer widerspiegeln.

96. Der unveränderte Teil dient als Vergleichsgrundlage, doch eine gemeinsam genutzte Infrastruktur kann diesen Vergleich verwischen.

97. Beide Teile nutzen möglicherweise dieselbe Datenbank, dasselbe Netzwerk oder denselben externen Anbieter, wodurch ihre Trennung weniger vollständig ist, als es den Anschein hat.

98. Eine fehlerhafte Änderung im „Canary“ könnte diese gemeinsame Abhängigkeit überlasten und auch den Nutzern in der Kontrollgruppe schaden, was die Annahme widerlegt, dass der unveränderte Teil von dem Test isoliert ist.

99. Umgekehrt könnte ein unabhängiges Problem im gemeinsam genutzten System den „Canary“ als fehlerhaft erscheinen lassen.

100. Entwickler benötigen Kennzahlen zum allgemeinen Zustand des Dienstes sowie zu den Unterschieden zwischen den beiden Gruppen, da gemeinsame Probleme beide Messwerte in die gleiche Richtung verschieben und ein Problem im Vergleich verbergen können.

101. Eine Stoppregel ist nur dann von Bedeutung, wenn jemand oder etwas umgehend darauf reagieren kann, bevor ein negatives Signal zu einem umfassenderen Ausfall wird.

102. Der Release-Prozess muss in der Lage sein, die Verteilung zu stoppen und einen nutzbaren Zustand wiederherzustellen.

103. Ein Rollback ist schwieriger, wenn eine Änderung Daten verändert, die die vorherige Version nicht lesen kann, oder wenn Nutzer bereits auf fehlerhafte Ausgaben reagiert haben, da das Rückgängigmachen von Software nicht alle Folgen ihrer Nutzung rückgängig macht.

104. Die Reichweite eines Fehlers umfasst verzögerte und irreversible Auswirkungen, nicht nur die Anzahl der ursprünglich aktualisierten Geräte; daher kann eine kleine Bereitstellung durch gemeinsame Abhängigkeiten oder dauerhafte Entscheidungen dennoch einen großen Schaden verursachen.

105. Auch das Risiko summiert sich im Laufe der Zeit.

106. Deshalb muss „klein“ das Risiko und die Folgen beschreiben, nicht nur die Anzahl der Installationen.

107. Manchmal ist der richtige erste Schritt ein Labortest ganz ohne Nutzer, insbesondere wenn der mögliche Schaden nicht rückgängig gemacht werden kann.

108. Manchmal ist echter Datenverkehr notwendig, um Erkenntnisse über die tatsächliche Nachfrage und verbundene Systeme zu gewinnen, die im Labor nicht reproduziert werden können.

109. Die Entscheidung hängt davon ab, was ausfallen kann, wie schnell dies sichtbar wird und wer den Verlust tragen würde, da dieselbe Gefährdung für ein Wegwerf-Testobjekt tolerierbar, für eine Person jedoch inakzeptabel sein kann.

110. Ein fehlgeschlagener Test ist nicht sicher, nur weil sich die durchführende Organisation die Kosten leisten kann.

111. Wenn Anwohner, Arbeitnehmer oder schutzbedürftige Nutzer irreversiblen Schaden erleiden, hat das Experiment sein Risiko ausgelagert, anstatt es einzudämmen – selbst wenn die Organisation, die den Versuch durchführt, nur einen geringen finanziellen Verlust erleidet.

112. Die absichtliche Zerstörung eines Stahltanks kann keine vergleichbare Behandlung von Menschen rechtfertigen, deren Verluste dauerhaft oder unfreiwillig wären.

113. Ein Tank hat keinen Anspruch auf Einwilligung, Fürsorge oder Wiedergutmachung.

114. Die ethische Grenze ist Teil der technischen Grenze, denn die Kosten eines Versagens müssen auf diejenigen zurückgeführt werden, die sie tatsächlich tragen, einschließlich der Menschen, die sich nie für eine Teilnahme am Experiment entschieden haben.

115. Es gibt Situationen, in denen kein akzeptabler kleiner Versuch die Bedingungen einer möglichen Katastrophe nachbilden kann, sodass sich Entscheidungsträger stattdessen auf Modelle, weniger direkte Tests und Schutzgrenzen verlassen müssen.

116. Diese Grenze erfordert andere Nachweise und strengere Zurückhaltung, nicht die Vortäuschung, dass ein „Kanarienvogel“ Sicherheit garantiert.

117. In Marshall war der Zerstörung des Tanks ein Ort und ein Zweck zugewiesen worden.

118. Sein Bruch lieferte den Ingenieuren einen Ort, eine Belastung und einen Vergleich mit ihrem Modell.

119. Außerhalb des Versuchsstandes blieb die Flugausrüstung unversehrt.

120. Der nützliche Bruch war derjenige, dessen Ausmaß begrenzt worden war, bevor das Metall nachgab.