A szép júniusi napon a 61 éves asszony belépett a Mariettában (Georgia állam) álló Kenneston kórház ajtaján. Mellrákjának eltávolítása után 10 MeV (mega-elektronvolt) energiájú elektronsugár-kezelést írtak fel neki, így ezen a napon a kórház új terápiás röntgengépével, a mindössze fél éve vásárolt Therac-25-ös géppel volt randevúja.

Ez a röntgengép-típus az eset idején, 1985-ben már bő két éve üzemelt más kórházakban, és a Kenneston is elégedett volt vele. Már az elődje, a Therac-20 is nagyon megbízható eszközként volt ismert, de az ugyanazzal a szoftverrel vezérelt, ám sokkal kompaktabb és erősebb Therac-25-tel sem voltak problémák. Egészen eddig.

Az asszony felsikoltott fájdalmában, mikor a gép üzemelni kezdett. Hatalmas forróságot érzett, amely megperzselte a testét. Ugyan panaszkodott a kezelő személyzetnek, de nem volt látható égési sérülése, így az esetet nem vették túl komolyan. Azért a biztonság kedvéért felhívták a gyártót, az AECL-t, hogy lehetséges-e, hogy a gép összeégesse a pácienst, de két nappal később azt a választ kapták, hogy ez kizárt. A későbbi periratokból kiderül, hogy gyártó alkalmazottja minden vizsgálat nélkül lerázta a kórházi dolgozókat, érdemben nem foglalkozott senki az esettel és nem is jelentették tovább a főnökeiknek.

A hölgy fájdalmai fokozódtak, a háta lemerevedett, a bőre foszlani kezdett. A kezei is lebénultak. Végül a súlyos sugárártalom miatt a melleit is le kellett venni. A szakértők szerint 15-20 ezer rad dózist kapott, ami jelentősen több, mint kellett volna. Az esetet jelentették, ennek ellenére a gyártó továbbra sem tett semmit, mert kizártnak tartotta, hogy a Therac-25 legyen a bűnös.

Hét héttel később, Kanadában, Ontartioban csapott le újra a röntgengép. Egy negyvenes nő jött a rákközpontba a huszonnegyedik sugárkezelésére, de ezúttal nem ment simán a dolog. Az operátor aktiválta a gépet, de az leállt öt másodperc múlva egy fura hibaüzenettel. Ám mivel úgy tűnt, hogy csak valami átmeneti probléma van, az operátor ezt felülbírálta, és folytatásra utasította a gépet. Ez bevett gyakorlat volt; a röntgengép szoftvere nem volt nagyon megbízható, rendszeresen leállt adatbevitel közben különféle hibaüzenetekkel. Ezúttal viszont a P-gomb lenyomása (Proceed) után a gép megint leállt ugyanezzel a hibajelzéssel. Gyorsan átnézték a gépet, de mindent rendben találtak, ami szintén nem volt szokatlan.

A kezelés során ez a nő is égési sérüléseket szenvedett. Kórházba került, de végül november 3-án meghalt rákban. A halottkém szerint ez a páciens sem az örömtől sugárzott: 13-17 ezer rad sugárdózist kapott.

A gyártó ekkor már vizsgálódni kezdett, és úgy találta, hogy csak egy mikrokapcsoló döglött be; igazából még mindig nem vették komolyan az esetet. De a gép, melyből 11 üzemelt az USA-ban és Kanadában, hat hónap múlva, 1986 márciusában ismét hallatott magáról. Ekkor egy bizonyos Ray Cox kapott az előírtnál 125-ször erősebb dózist. Ráadásul ennél az esetnél a kezelő helyiségben nem működött az audio-videó rendszer és a vészhívó sem, így a röntgengéppel szenvedő technikus nem is tudott róla, hogy odabent épp eltesz valakit láb alól. Végülis praktikus: így legalább a beteg ordítása nem zavarta az operátort a koncentrációban.

Aztán 10 nap múlva az eset ugyanitt ismét megismétlődött, majd 1987. január 17-én a Yakima Valley kórházban is megsütöttek valakit. Összesen hat embernek kellett meghalnia, mire végre ténylegesen nekiálltak kideríteni, hogy mi történt.

A röntgengépet egy PDP-11-es számítógép vezérelte, melyen egy assemblyben írt program futott. Egy standard szöveges terminálon át lehetett vele kapcsolatot létesíteni. 

A gép kétféle üzemmóddal rendelkezett: elektronsugár móddal és röntgen-móddal. Az eszköz lelke egy változtatható erősségű elektronsugár-forrás volt, ami akár 25 MeV energiájú sugárnyalábot is képes volt kibocsájtani. Ez önállóan igen veszélyes, ezért amikor a gépet elektronsugár-kezelésre használták, akkor különféle mágnesekkel szétszórták és gyengítették a sugarat a megfelelő felületű és erősségű kezeléshez. De a szétszórás és a gyengítés mellett sem használták kis a teljes elektronágyú-kapacitást, mivel arra csak a másik üzemmódban volt szükség. Röntgen-módban ugyanis a sugár útjába egy fluorescent lemezt tettek, mely az elektronsugarat röntgen-fotonokká alakította. Ez igen tetemes veszteséggel járt, ezért kellett a nagy kiindulási energia.

A kétféle üzemmód között tehát cserélni kellett a sugár útjába kerülő elemeket, amit mechanikusan, egy forgótányér segítségével végeztek el (a tányért is a PDP-11 vezérelte). Kritikus volt tehát, hogy a forgótányér a megfelelő állásban legyen. Ezért a korábbi modelleknél a tányér helyzetét mechanikus módszerekkel is ellenőrizték: ha nem volt jó helyen a forgótányér, nem indult el a kezelés. Ezt a mechanikus zárolást a Therac-25 esetében elhagyták, és teljes egészében a szoftverre bízták a pozíció-ellenőrzését.

A szoftvert pedig lényegében változtatás nélkül vették át a korábbi gépekből, és nem is nagyon nyúltak hozzá, mivel addig nagyon megbízhatóan működött (értsd: nem halt meg addig senki). Csak egy extra pozíció-ellenőrző programrésszel egészítették ki, de még azt sem próbálták ki a gép éles üzembe helyezése előtt.

Ám az örökölt szoftver közel sem volt olyan jó minőségű. Már az alapstruktúrája is el volt fuserálva, amit aztán gyalázatos minőségű programkóddal töltöttek meg. Az is csoda volt, hogy egyáltalán működött. A kezelői felülete sem volt igazán kényelmes, de még csak informatív sem. Rendszeresek voltak a programhiba-üzenetek, melyeket általában csak kóddal azonosítottak a képernyőn („Malfunction 54”). Hogy melyik kód mit jelent, az nem volt leírva sehol. De a fő baj az volt, hogy a mechanikát kezelő programrészek párhuzamosan futottak az adatbeviteli részekkel, így ha a kezelő túl gyorsan vitte be az adatokat (kellően nagy gyakorlatra tett szert), akkor egyes esetekben előfordulhatott, hogy a forgótányér hibásan lett beállítva. Ez jellemzően akkor fordult elő, amikor a technikus rutinból X gombot nyomott (X-ray mód) kezelési üzemmódnak, majd villám gyorsan rájött a hibára, visszalépett, és korrigált E (Electron) módra; ekkor a gép fele X, a másik fele E módot állított be: a forgótányér visszament E üzemmódba, a sugárforrás pedig maradt teljesen energián.

Ahhoz, hogy ez előálljon, kellett még pár további elfuserált ötlet a kezelői felülettel kapcsolatban: például, hogy az operátornak sok Entert kellett nyomnia egymás után az adatbevitel során, de ha a sok Enter közben hibaüzenet jelent meg (például, hogy az energiaszint és a mód beállítása nem egyeznek), akkor mindjárt azt is lekezelte a sok lendületes Enter gomb… 

A kritikus forgótányér-hibát persze észre kellett volna vennie a szép új ellenőrző modulnak, hiszen pont ezért volt ott. Csakhogy a pocsék minőségű kód itt is visszaütött: egy sima aritmetikai hiba (túlcsordulás) miatt az ellenőrző programrészek egyszerűen le sem futottak. Ez a korábbi modelleknél sem volt nagyon máshogy, de ott még megvolt a mechanikus védelem, mint utolsó védőbástya.

A programot a gyártó egyáltalán nem tesztelte a Therac-25-ben. Egy-az-egyben átvették a korábbi gépről, beszerelték az új röntgengépbe, és kiszállították a kórházba. Ott futott életében először ezen a hardveren (a Therac-25 prototípusa nem számítógép-vezérelt volt). Végeztek ugyan biztonsági számításokat, hogy például mennyi a valószínűsége, hogy rossz tányér-helyzettel indul a kezelés, de ezeknél egyáltalán nem vették figyelembe a szoftver lehetséges hibáit. Tehát az AECL gyönyörűen bemutatta annak az iskolapéldáját, hogy hogyan NE tervezzünk és supportáljunk biztonságkritikus, szoftver-vezérelt rendszert.

Végül 1987-ben az összes Therac-25-öt visszahívták, és korrektül orvosolták az összes feltárt problémaforrást. De akkor már mindegy volt: a Therac-25 név addigra már a felelőtlenség és az impotens programkészítés szinonimájává vált. [Forrás]

A gyenge minőségre nincs mentség, és a tesztelés hiánya sem elfogadható. De azért a tisztánlátás miatt érdemes pár szót szólni a szoftverek teszteléséről vagy éppenséggel teszteletlenségéről, mivel ezzel más alkalmazási területeken is gyakran találkozhatunk.

Miért nem lehet minden hibát megtalálni és idejében kijavítani a program kellően alapos kipróbálásával? Vagy ha nem is mindet, legalább a biztonság szempontjából aggályosokat?

A válasz a szoftverek komplexitásában rejtőzik. Ha egy programot simán csak ´próbálgatunk´, akkor az elképesztően nagy komplexitás miatt legfeljebb a benne lévő hibák 10%-át fogjuk tudni megtalálni. Rengeteg állapot, eshetőség, egybeesés és használati módszer ugyanis eszünkbe sem fog jutni.

Ha mindent módszeresen, alaposan végigveszünk és kipróbálunk, akkor sokkal jobb eredményt kaphatunk: szisztematikus teszteléssel akár a hibák 30-40%-át is megtalálhatjuk; igaz, ilyenkor a tesztelés önállóan jóval-jóval több időt és pénzt emészt fel, mint magának a programnak a megírása.

Persze meg lehet próbálni a vizsgálandó program minden lehetséges állapotát minden lehetséges esetre átnézetni egy számítógéppel, de mivel az ilyen teszt csak pár ezer év alatt futna le, túl lassú lenne a piacra dobás. 

És ha sikerül is megtalálni és kijavítani egy-két hibát, akkor is gyakori, hogy a javítással újabb hiba kerül a rendszerbe. Előfordult ilyen többször is, például az űrsikló program kezdetén is harcolt egy ilyen hibával a NASA.

Jól mutatja a hibakeresés és hibajavítás reménytelenségét az alábbi eset is.

Aranylövés

1995-ben a Gish Biomedical Inc, egy kis cég számára úgy tűnt, hogy az orvosi eszközök gyártása lesz a jövő nagy dobása, mivel ez a terület akkor kezdett felfutni. A piacra lépésükhöz viszont szükség volt egy jó termékre, mégpedig gyorsan. Így hát a lassú fejlesztés helyett inkább gyorsan megvásároltak egy mások által tervezett, már létező terméket; a nevadai Creative Medical Development Inc. adta el nekik 2,6 millió USD-ért a saját tervezésű Creative's EZ Flow injekciós adagolókészülékét, a benne lévő szoftverrel és annak rejtett hibáival együtt.

A kis kütyüt egy mikrokontroller irányította, kicsi volt, könnyű, praktikus és egyszerűen kezelhető. A kb. 2000 USD-be kerülő készülék ráadásul többfeladatos volt: inzulin, infúzió, és bizonyos gyógyszerek adagolása és beadása mellett fájdalomcsillapításra is alkalmas volt – ekkor morfiumot adagolt a páciensnek.

Sajnos a készülékkel elég hamar konstrukciós gondok adódtak. A beragadó gombok és a bizonytalan működés miatt már az újratervezését fontolgatták, aminek külön lendületet adott, amikor 1996-ban a kütyü túladagolta a gyógyszert egy betegnek. Az illetőnek nem lett baja, de a cég nem akart kockáztatni, így az egész szériát azonnal visszahívták átdolgozásra.

A hibát kijavították, a gépet újra forgalmazni kezdték, és úgy tűnt, minden rendben van. De 1997 szeptemberében a helyzet egy csapásra megváltozott, és rémálommá vált a cég számára. Az újonnan átdolgozott-kijavított készülék ugyanis simán túladagolta egy végstádiumos rákbetegnek a morfiumot – aki emiatt meghalt. (Lehet, hogy így járt jobban…)

A hibát egy szoftver hiba okozta, így a cég kénytelen volt újra visszahívni az összes egységet. Megpróbálták újra megtalálni és kijavítani a szoftver hibát, de egy évnyi szenvedés és rengeteg beleölt pénz után sem voltak képesek ezt megtenni. Hiába, no: ha egy programot egyszer rosszul kezdenek el, később már reménytelen javítani. Ezért a Gish végső elkeseredésében inkább a szoftver teljes újraírása mellett döntött, mert így legalább volt remény (kellően) hibátlanná tenni.

A Gish Biomedical Inc közben kis híján csődbe ment az eset miatt, utólag már bánják, hogy egyáltalán beléptek az orvosi eszközök piacára. És mielőtt bárki is azt gondolná, hogy ez egy egyedi eset volt: abban az időben több más cég is hasonló problémákkal küzdött, tucatjával lelhetők fel beszámolók a különféle orvosi eszközök problémáiról. Sok esetben a szoftver volt a bűnös, melyekben a nagyon ritkán előforduló hibák megtalálására szinte semmilyen remény nem volt.

A nagyon ritkán előforduló programhibák hátterében gyakran egy egészen egyszerű probléma lapul: a szoftver olyan szituációba kerül, amire egészen egyszerűen senki sem gondolt. Így nem is gondolták át, hogy ilyenkor mit kellene a programnak csinálnia, nem is programozták le a viselkedést, és persze nem is tesztelhették azt le. Aztán jön az Élet, és megmutatja: előbb-utóbb a legváratlanabb helyzet is előáll. Ráadásul mindig ott a legnagyobb bizonytalanság: a kezelő ember, és az ő remek ötletei. 

Már a Therac-25-nél is láthattuk, hogy kezelő gyakorlottsága és a kezelő parancsai milyen komoly szerepet játszottak az eseményekben. Még szerencse, hogy sokat tanultunk abból az esetből, így a korszerű módszerekkel készült modern szoftvereknél ilyesmi már nem fordulhat elő!

Panama

2000 novemberében járunk, mikor Victor Garcia belépett a Panamai Nemzeti Rákintézetbe. Sugárkezelésre érkezett. Ekkorra a Therac-25 emlékei már a múlt homályába vesztek, annak kezdetleges adatbeviteli módszereit is korszerűbbre cserélték már: a Nemzeti Rákintézet terápiás röntgengépe, a Cobalt-60 számára már grafikusan kellett bevinni az adatokat. Az amerikai gyártmányú, a (mindössze 15 főt foglalkoztató) Multidata Systems International által fejlesztett kezelés-tervező rendszerben egy 3D grafikus ábrán kellett megadni a kezelendő területet, mégpedig úgy, hogy virtuális pajzsokat kellett definiálni a sugárzástól megvédendő területek lefedésére. A kezelés összes többi paraméterét a szoftver már önállóan számolta. 

Összesen csak négy ilyen „pajzsot” lehetett megadni, de az alakjuk tetszőleges lehetett.

A virtuális pajzsok által le nem fedett területre ezután a program kiszámolta a szükséges dózist és a kezelési időzítéseket, majd elindulhatott a gamma-sugárzás.

Sajnos a négy megadható sokszög sok esetben bizony fájóan kevés volt, gyakran legalább ötre lett volna szükség. Ám a fejlesztő nem tett semmit.

Szerencsére a kezelést irányító fizikus, Olivia Saldaña  (alul a képen) kreatív nő volt, és a kezelői kézikönyv elolvasása után gyorsan rájött, hogyan lehet korrekten megkerülni a problémát. Ehhez a szokásos konvex sokszögek helyett a védendő területet egyetlen nagy, összetett alakzatként definiálta, egy megfelelő alakú lyukkal a közepén. Ezzel az unortodox megoldással a probléma simán megkerülhető volt, a gép nem tiltakozott. 

Saldaña gondosan járt el. A sokszögek definiálása után leellenőrizte az alakzatok feldolgozásából generált kezelési görbéket és időzítéseket, és mivel ezek teljesen hihetőek voltak, minden úgy festett, hogy a dolog működik. Saldaña lelkes volt; ugyan minden kezelésnél ellenőrizte a görbéket, de mikor már a sokadikat is rendben találta, már nem ment bele olyan mélyen az adatok ellenőrzésébe.

Pedig nem ártott volna…

Saldaña megoldását ugyan a kezelői utasítás sehol sem tiltotta, ám a szoftver fejlesztők mégsem gondoltak erre a zseniális megoldásra a program írása során. Így aztán nem is készítették fel rá kellően a gépet, és persze nem is tesztelték a helyes működést ilyen hülye alakú sokszögekre. Ennek ellenére a módszer látszólag teljesen jól működött, ugyanis minden probléma nélkül definiálni lehetett a lyukas sokszög külső peremét és a belsőt is, létre is jött a szokatlan alakzat, és a program nem is jelzett hibát.

Volt viszont egy kis bökkenő, ami eleinte nem szúrt szemet senkinek. Nem volt ugyanis mindegy, hogy a komplex alakzat határainak definiálása során az óramutató járásának megfelelően, vagy éppen ellenkezőleg haladt a kezelő az adatbevitellel. Ha a belső lyukat és a külső határvonalat ellentétes irányban definiálták, akkor minden jól működött. Ha viszont ugyanarra haladva, akkor az alakzatot értelmező szoftverben a két határvonal összekeveredett, és a program nem volt képes normálisan kiszámolni a területeket – így a szükséges sugárdózist sem. Az időzítések és sugáreloszlási ábrák ilyenkor is jónak tűntek, de a dózis 20%-100%-kal több volt, mint a szükséges. Ennek viszont nem volt nyilvánvaló jele, csak a részletekben elmélyedve lehetett volna kiszúrni, hogy a dózisbeállítás duplája a szükségesnek.

A gépen naponta nagyjából 100 kezelést végeztek el, köztük Viktor Garciaét is, aki bizony szerencsésnek nevezheti magát, hogy egyáltalán túlélte az esetet. A szoftver hiba csak akkor vált látványossá, mikor elkezdtek a betegek meghalni, és a statisztikák kimutatták a szokatlan halálozási arányt. Addigra a gép miatt már  legalább  nyolc ember nem érhette meg a halála napját, mert ők előbb meghaltak a túldozírozás miatt. Emellett további 28 páciens szenvedett súlyos sérüléseket.

A vizsgálat során a gyanú elsőként Saldañara terelődött, ő volt ugyanis a felelős a gép beállításáért. Meggyanúsították azzal, hogy rosszul vitte be az adatokat, nem ellenőrizte a beállításokat, így ő okozta a túldozírozást. Gyilkossággal vádolták, és alaposan meghurcolták. Mikor végre kiderült, hogy a Multidata szoftvere a hibás, akkor visszahelyezték az állásába, és ma is ott dolgozik – de annak ellenére, hogy igazából nem ő hibázott, állandó lelkiismeret-furdalása van.

A Cobalt-60 ma is működik, de már nem számítógépes terápiatervezéssel, hanem kézi módszerrel. Ez csak fele annyi beteget tud kiszolgálni naponta, mint annak idején a számítógépes módszer; igaz, ezek legalább életben maradnak. A Multidata is köszöni szépen, és jól van, de a 28 sérültnek fejenként fél-egy millió USD-t kellett kifizetniük fájdalomdíjként. [Forrás]

Tényleg: ki a felelős, ha egy szoftver gyilkol? 
A programozó? Neki esélye sincs hibátlan programot írni.
A kezelő? Ő nem tehet semmiről.
Akkor ki?

Habár ezt az esetet én inkább a Szoftverkrízis utolsó rúgásaként értelmezem, azért jól mutatja: a program a valóságban nagyon más körülmények közé fog kerülni, mint amit a laborban valaha is kipróbálhatnak a fejlesztők. Ezért nem mindegy az sem, hogy miként zajlik le egy szoftver bevezetése, betanítása és használatba vétele. 

Ezt illusztrálandó emlékezzünk most meg a londoni mentőszolgálat legismertebb szoftveres kalandjáról.

Mentőfrász

A londoni mentőszolgálat a világ egyik legnagyobb ilyen szervezete. A National Health Service részeként működő szervezet a folyamatosan növekvő terhelés, és az ezzel párhuzamosan zajló költségcsökkentés miatt már az 1980-as évek elején úgy döntött, hogy automatizálja a hívások fogadását, az erőforrások allokálását és a mentőautók szervezését. Elkezdtek tehát tervezni egy olyan rendszert, mely a tervek szerint központi szerverekből, mobil egységekből, és járművekre szerelt készülékekből állt volna. A tervek szerint ezek az egységek rádiókapcsolatban lettek volna egymással. A bejövő hívások forrását a rendszer automatikus lokalizálta volna, hozzárendelt volna egy mentőautót, és leküldte volna neki az útvonalat. A mentőautó sofőr a helyszínen megadhatta volna, hogy hol van, és mi az állapota. Így a központ folyamatosan tudta volna, hogy a flotta hol van éppen és mit csinál. 

Szépen hangzó terv, de a hatékonyság növelése mellett a másik célja emberek elbocsátása és költségmegtakarítás volt, így nem örvendett osztatlan népszerűségnek.

A feladatot egy kis cég, az IAL kapta meg. Rendkívül szoros határidőket jelöltek meg nekik, és szűkös pénzügyi keretet. Ráadásul tapasztalatuk sem volt a területen. A mentősök 1990-ben akarták az új rendszert indítani, de már sokkal korábban kiderült: az elkészülőfélben lévő rendszer egyszerűen nem lesz képes a várható terhelést kiszolgálni, alkalmatlan lesz a feladatra.

Így gyorsan új pályázatot írtak ki, amit a CAD, egy kis cégekből álló konzorcium nyert meg. Az eredeti terv alapvetően megmaradt, csak a megvalósítást kezdték újra. 1991. februárra készült el végleges a specifikáció, júliusra a rendszerterv, a bevezetést pedig 1992. január 8-ra írták ki. Ez egy ekkora rendszer esetén teljesen tarthatatlan határidő, de a mentők nagyfőnöke ragaszkodott hozzá. Pedig már az első kísérletből tudhatta volna: egy kudarc sokkal többe fog kerülni, mint az esetlegesen megtakarított bérek. Végül a határidőt nem is lehetett betartani: csak 1992 júniusában tartották meg a szoftver első oktatását a leendő kezelőknek. Ez volt egyben az utolsó is, pedig a rákövetkező 6 hónapban sok dolog változott a szoftvereken, az emberek pedig csak felejtettek.

1992. október 26-án, hétfőn reggel álltak át a diszpécserek az új rendszer használatára. Igen, mindenféle előzetes próbaüzemek, párhuzamos működés, tesztek és kiképzések nélkül (láttunk már máshol is ilyet…?). Ekkor 81 hibáról tudtak a szoftverben, de ez csak a jéghegy csúcsa volt.

Az egyes részeket és egységeket külön-külön cégek fejlesztették, és addig sosem próbálták ki együtt valós körülmények között. Nem volt tartós futási teszt, és terhelési teszt sem. Emellett a program csak a normál, tökéletes ügymenetre volt felkészülve, így nem bírt el a tévesen beadott adatokkal (pl. ha a mentőautó-sofőr mellényomott vezetés közben a mobil kütyü idiótán elhelyezett gombjain) és a hardverhibákkal sem. Hibás volt a kezelőfelület, és nehezen használhatók a mentőkocsis egységek. 

A rendszer folyamatosan „ette” az erőforrásokat, ezért idővel egyre lassabb lett. Ennek ellenére az első pár órában jól helyt állt (mivel viszonylag kevés eset volt). Ám utána a lassulás miatt a rendszer elkezdte elveszíteni a bejövő hívásokat, és az állandó ismétlések miatt hamarosan már 30 perces várakozási időkkel néztek szembe a betelefonálók. Kezdett akadozni az adatcsere a mentőautókkal, ráadásul a leküldött útvonal is gyakran hibás volt; így útfelbontásokba, dugókba vezette a sofőröket. A sofőrök is nehezen boldogultak a kezelőfelületükkel, így nagyon sok volt a téves gombnyomás – amit nem lehetett javítani (!), így a központot elárasztották a téves adatok. Így egy idő után a diszpécsereknek már fogalma sem volt róla, hogy az autóik fele hol jár. 

Hétfő estére a hívás-torlódás már odáig jutott, hogy teljes káosz kezdett kialakulni. Ekkor a központi szoftver észlelte, hogy vannak le nem kezelt hívások (naná, állt a káosz), és ezeket figyelemfelhívásul „Kivétel”-ként egy printerre is kinyomtatta. A dolog célja eredetileg az lett volna, hogy külön figyelmeztessék a kezelőket az elmaradásra. De amikor lényegében állandóan ömlött a printerből a kivétel-üzenet, akkor inkább kikapcsolták a nyomtatót. Ez nem segített, mert ezután már a képernyőn jelent meg ugyanez a folyam, azt is ellehetetlenítve. Elvileg lehetett volna törölni a kivétel-listát, de a gyakorlatban ez a funkció nem működött, a grafikus térképek pedig egyre lassabban, majd végül sehogy sem töltődtek be.

Az egész rendszer kezdett összeomlani. Nem lehetett rendesen mentőautót allokálni, emiatt megjelentek a nem kezelt hívások. Ezeket egy idő után ismételték, többször is, ami a sokszorosára növelte a bejövő hívásmennyiséget, pedig már kisebb volumennel sem bírt el a rendszer. Ez egy öngerjesztő folyamat volt, aminek teljes káosz lett a vége. Volt eset, ahol egy halott elszállításához két menőautó toppant be teljes harci díszben, de egy agyvérzéses beteghez csak 10 órával a hívás után ért ki a kocsi. 5 órával azután, hogy a beteg a saját lábán beért a kórházba.

Kedden az operátorok áttértek egy félig papír, félig számítógép-alapú nyilvántartásra. Ez nem sokat segített, mert még további késéseket vitt a rendszerbe – de legalább működgetett valahogy. Ez az állapot 7 napig, november 4-ig állt fent, amikor a program végképp „megette” a memóriát, és belassult, majd hajnali kettőkor összeomlott és leállt. Attól kezdve teljesen manuális lett az irányítás. 

Az új rendszer összesen 9 napot futott. A becslések szerint ezalatt 20-30 ember halt meg feleslegesen, mert nem jutottak időben mentőautóhoz; és akkor az egyéb okozott kárról még nem is beszéltünk. A CAD és az NHS vezetősége annak az iskolapéldáját mutatták be, hogyan NEM szabad egy kritikus szoftver kifejlesztését és bevezetését megszervezni. [Forrás]

Azt hiszem, hogy az itt elkövetett hibákat mind a mai napig előszeretettel ismétlik meg különböző szoftverek esetében, legutóbb például vállalatirányítási programnál láttam ilyet. Igaz, ekkor legalább csak a cég gazdasági működése állt le 4-5 napra a londonihoz hasonló hibák miatt – de legalább a pasziánsz-túladagoláson kívül senkit sem fenyegetett veszély.

Hibapozíció

Amúgy a US légierő is bemutatta 2010 januárjában, hogyan kell egy szoftvert „hatékonyan” és „profin” frissíteni. A cél a GPS rendszer képességeinek javítása volt, ami egyrészt a pontosság növelésében, másrészt a védettség erősítésében öltött testet. Ez a változtatás ugyan kis mértékben a polgári GPS vevőknél is érezteti hatását, de ebben az esetben a fő cél egyértelműen a katonai képességek javítása volt. A művelethez nem csak új műholdakra, hanem egy szoftver frissítésére is szükség volt, amit január 11-én szépen végre is hajtottak.

És azzal a lendülettel leállítottak jó pár ezer olyan harceszközt, melyekben a kaliforniai Trimble Navigation Limited által gyártott vevőegységek voltak. Ezek ugyanis nem voltak képesek az új típusú katonai jeleket értelmezni.

Innentől kezdve elkezdődött az egymásra mutogatás: a katonák szerint a Timble vevői nem voltak kompatíbilisek az új protokollokkal, mivel nem lettek eléggé tesztelve. A Timble szerint viszont ők igenis alaposan tesztelték a cuccot és mindent rendben is találtak; szerintük a hadsereg végül nem azt a programot telepítette, amit ők megkaptak a teszthez…. 

Megjegyzem: nem ez volt az első GPS-leállítós eset, és nyilván nem is az utolsó. A GPS számos konstrukciós problémával küzd, miközben a jelentősége még mindig óriási. A fennakadásmentes korszerűsítése tehát nem triviális feladat. Csak hát…

A következő részben a magasba emeljük a színvonalat.