Jokaisella yrityksellä on 'kriittinen' infrastruktuuri. Yleensä tämä tarkoittaa, että jos järjestelmä menee offline-tilaan, yrityksen osat (tai kaikki) pysähtyvät, kunnes teknikko saa sen toimimaan uudelleen. Tämä tapahtuu usein, kun tarvitaan suuria ohjelmisto-, laitteisto- tai verkkopäivityksiä: uudet järjestelmät sisältävät odottamattomia virheitä, jotka aiheuttavat järjestelmän vian, tai käyttäjät tekevät virheitä uudessa järjestelmässä, koska he eivät tunne järjestelmää, ja tuottavuus pysähtyy, kunnes teknikko pystyy työskentele käyttöönottovirheiden kautta tai kouluta käyttäjiä. Suurimmaksi osaksi seisokkeja tai alentunutta tuottavuutta on hyväksyttävä riski vastineeksi lupauksesta parantaa uuden tekniikan suorituskykyä ja tehokkuutta, mutta se ei ole universaalia. Suurimmalla osalla yrityksiä on varaa tietty määrä seisokkeja vaarantamatta suuria tuloja tai vastustamatta asiakkaitaan.
Mutta mitä tapahtuu, kun muutettavat järjestelmät ovat elämän kriittiset järjestelmät , jossa elämän turvallisuus riippuu järjestelmän luotettavasta käytöstä?
Tämä artikkeli eroaa perinteisemmästä ohjelmistokehityksestä, johon vietämme suurimman osan ajastamme, ja sen sijaan tarkastellaan elämänkriittisten järjestelmien inhimillistä elementtiä. Ajatukseni tästä aiheesta johtuvat kokemuksestani 911-ambulanssin tietotekniikan johtajana, kansainvälisen humanitaarisen katastrofivalmiusjärjestön teknologiaspetsialistina ja Ph.D. in Human Systems Integration valmistui Massachusettsin teknillisessä instituutissa.
Ennen kuin aloitamme, haluaisin selittää, miksi tämä voi olla sinulle merkitystä. Vaikka ei ehkä ole ilmeistä, että projektissasi todella on elintärkeää järjestelmää, se on paljon todennäköisempää kuin luulet. Kaikki seuraavat ehdot täyttävät sekä lukemattomat muut aiheet:
Nykypäivän maailmassa, jossa teknologia on erittäin riippuvainen, projektit, joita et ole koskaan pitänyt edes puolitärkeinä, voivat päätyä elintärkeän osan elintärkeään järjestelmään.
Oletko koskaan kuullut tai käyttänyt sanaa 'perintö' suhteessa tekniseen järjestelmään? Se on vahva sana, joka herättää ajatuksia pitkäaikaisista perinteistä, sukulaisuudesta ja vaikeista aikakausista. Suunnittelumaailmassa sitä käytetään kuvaamaan malleja, jotka ovat olleet olemassa pitkään ja joiden on osoitettu toimivan luotettavasti, ja sitä pidetään usein toivottavana piirteenä riskien vähentämiseksi. Todellisuudessa se on eufemismi arkaaiselle tekniikalle, jota ei koskaan päivitetty riskien välttämisen takia, ja se on yleistä teollisuudessa, jossa järjestelmän viat voivat johtaa vakaviin seurauksiin.
Tämän suhde perintöohjelmistoihin ja -laitteistoihin on hyvä syy. Sen tiedetään toimivan, on epätodennäköistä, että tuntemattomia vikoja syntyy, ja sen kustannukset ovat vakaat ja ennakoitavissa. Erinomainen esimerkki on avaruuslentoteollisuus: venäläinen Sojuz-avaruusalus on lähettänyt astronautteja avaruuteen yli 50 vuoden ajan vain pienin muutoksin tuona aikana, ja sitä käytetään edelleen, koska se on luotettava ja turvallinen. Valitettavasti tämä tarkoittaa, että se on myös erittäin tehoton verrattuna moderneihin malleihin: kun Sojuz maksaa NASA: lle 81 miljoonaa dollaria per paikka, kun astronautit lentävät avaruusasemalle perintölaitteiston avulla, SpaceX: n ja Boeingin odotetaan tarjoavan paikkoja 58 miljoonaa dollaria kukin käyttää modernia rakettimalliaan.
On ymmärrettävää, että harvat ihmiset haluavat päivittää edelleen toimivia vanhoja järjestelmiä. johtajat eivät halua riskiä, teknikot eivät halua käsitellä salaperäistä palvelinta kaapissa 12 vuoden käyttöajalla, eivätkä asiakkaat halua joutua oppimaan uusia malleja. Valitettavasti riskien minimoinnin ja kustannussäästöjen välillä on käännekohta: kulttuuriperintösuunnitelmia on päivitettävä lopulta jopa korkean riskin ympäristöissä .
Tämän artikkelin loppuosa kattaa joitain tärkeimpiä vaiheita prosessin tekemisessä, kun järjestelmät ovat elämän kannalta kriittisiä, kuten ensiapujoukot, sotilasyksiköt tai lentokoneet.
Kokemukseni mukaan prosessin mahdollisesti vaikein vaihe on vakuuttaa päättäjät ja sidosryhmät päivitysten tarpeesta. Elinkriittisissä ympäristöissä toimiviin järjestelmiin sovelletaan usein laajaa lainsäädäntöä ja organisaatiopolitiikkaa, mikä tarkoittaa, että sinun on saatava heidät vakuuttamaan, että heidän ei tarvitse vain ottaa riskiä ja käyttää rahaa, vaan että heidän tulisi myös harjoittaa sellaista, mikä voi helposti olla useita vuosien byrokraattinen nauhanleikkaus. Vahvin vastustaja, jonka kohtaat, tulee todennäköisesti olemaan lakimieheltä, joka esittää sietämättömän yksityiskohtaisesti mahdollinen vastuu avaat organisaation ottamalla käyttöön uuden tekniikan. He ovat oikeassa: vastuu on tärkeä asia ja jos jokin rikkoutuu ja joku sattuu tai kuolee, se voi olla valtava eettinen, maineellinen ja taloudellinen taakka.
Riippumatta siitä, työskenteletkö Fortune 500 -yhtiön tai paikallisen vapaaehtoisen palokunnan kanssa, kyse on aina samasta asiasta: rahasta. Yritykset eivät halua menettää sitä, eikä voittoa tavoittelemattomilla organisaatioilla ole aluksi paljon työtä. Ainoa luotettava tapa, jolla olen saanut vakuuttamaan organisaation johtajan ottamaan riskin muuttaa elintärkeää järjestelmää, on osoittaa, että todennäköisemmin he joko ansaitsevat / säästävät rahaa kuin menettävät sen tai että he voivat vähentää vastuutaan modernisoimalla tekniikkaansa ja parantamalla turvallisuutta.
Se tarkoittaa, että sinun on tehtävä matematiikka. Mikä on todennäköisyys, että virhetilanteista johtuvia pidennettyjä seisokkeja tai tulevia kaatumisia jatketaan (organisaatiosi aiempien käyttöönottojen tai muiden organisaatioiden tietojen perusteella)? Mikä on odotettu vaikutus, jos se epäonnistuu, ja mitä se maksaisi? Vastaavasti mitkä ovat odotetut suorituskyvyn tai luotettavuuden lisäykset, ja mitä ne olisivat arvoisia? Jos pystyt osoittamaan, että olet todennäköisesti tulossa eteenpäin, on hyvät mahdollisuudet saada vihreä valo.
Saatat olla perehtynyt lauseeseen 'insinöörien insinööreille', idioomi, joka viittaa siihen, että insinöörit rakensivat jotain sellaisten ihmisten käyttöön, joilla on samanlainen pätevyys. Se on erittäin yleinen tapahtuma, ja se oli yksi tärkeimmistä tekijöistä tietokoneiden käytettävyystutkimusten nousulle 1990-luvun alku . Insinööreinä meillä on usein erilaiset henkiset mallit teknologisten järjestelmien toiminnasta kuin keskimääräisellä loppukäyttäjällä, mikä johtaa taipumukseen suunnitella järjestelmiä olettaen, että loppukäyttäjä tietää jo sen toiminnan. Tavanomaisissa järjestelmissä tämä johtaa virheisiin ja onnettoihin asiakkaisiin; elämän kriittisissä järjestelmissä se voi johtaa kuolemaan.
Harkitse tapausta Air Francen lento 447 . 1. kesäkuuta 2009 Airbus A330 oli Atlantin valtameren yli matkalla Rio de Janeirosta Pariisiin. Jääkiteet estivät pitot-putket , mikä aiheuttaa epäjohdonmukaisuuksia ilman nopeuden mittauksissa. Lentotietokone irrotti autopilotin ja huomasi, että se ei voinut luotettavasti lentää itse konetta virheellisillä ilmanopeustiedoilla. Sitten se sijoitti itsensä 'Pidennetty lennon kirjekuori' -tila, joka antoi lentäjille mahdollisuuden suorittaa liikkeitä, joita tietokone ei normaalisti salli. Voit kuvitella järjestelmän rakentaneet insinöörit ajattelemaan 'Jos autopilotti irtoaa itsestään, se johtuu todennäköisesti tilanteesta, jossa ohjaajat saattavat tarvita ylimääräistä hallintaa! '
Tämä on luonnollinen ajatusinsinööri insinööreille, jotka ymmärtävät, minkälaiset asiat voivat saada autopilotin irti. Lentäjille se ei ollut asia. He pakottivat koneen nousemaan jyrkästi ylöspäin, ohittamatta 'STALL' -varoituksia, kunnes se menetti kaiken nopeuden ja laskeutui merelle. Kaikki 228 matkustajaa ja miehistö kuoli. Vaikka on olemassa useita ajatuksia heidän toimintansa tarkasta motivaatiosta, vallitseva teoria on, että ohjaajat olettivat lentotietokoneen estävän ohjaustuloja, jotka pysäyttävät lentokoneen (mikä pätee normaaliin lennon kirjekuoreen), eivätkä tajunnut sitä se oli vaihtanut laajennetun kirjekuoren tilaan, koska he eivät jakaneet insinöörien henkistä mallia logiikasta, joka ohjasi tietokoneen päätöksiä.
Vaikka hieman kiertävä reitti, tämä johtaa meidät pääkohteeni: niiden toimintojen, jotka haluat käyttäjien tekevän tietyissä olosuhteissa tuntuu luonnolliselta käyttäjälle .
Käyttäjiä voidaan kehottaa noudattamaan tiettyjä menettelyjä, mutta he eivät aina muista aina oikeita toimia tai ymmärtävät, mitä tapahtuu korkean stressin olosuhteissa. Sinun vastuullasi on suunnitella ohjelmistot, ohjaimet ja käyttöliittymät intuitiivisella tavalla, joka tekee käyttäjistä luontaisen haluta tehdä asioita, joiden heidän pitäisi tehdä.
Tämä tarkoittaa sitä, että on ehdottoman tärkeää, että loppukäyttäjät ovat mukana suunnittelun ja kehitysprosessin jokaisessa yksittäisessä vaiheessa. Ei voida olettaa, mitä käyttäjät todennäköisesti tekevät; sen kaikkien on oltava näyttöön perustuvia. Kun suunnittelet rajapintoja, sinun on suoritettava tutkimuksia määrittääkseen ajattelutavat, jotka ne aiheuttavat käyttäjille, ja mukautettava tarvittaessa. Kun testaat uusia järjestelmiäsi, sinun on testattava ne todellisten käyttäjien kanssa todellisissa ympäristöissä realistisissa olosuhteissa. Ja valitettavasti, kun muutat mallejasi, sinun on tehtävä nämä vaiheet uudestaan.
Vaikka jokainen monimutkainen järjestelmä on ainutlaatuinen, haluaisin mainita erityisesti kolme suunnittelunäkökohtaa, joita tulisi soveltaa yleisesti:
Alan parhaiden käytäntöjen mukaisesti beeta-vaihe on ratkaisevan tärkeä uusien elintärkeiden järjestelmien käyttöönotossa. Uuden tekniikan testit ovat saattaneet auttaa sinua korjaamaan suurimman osan virheistä ja käytettävyyteen liittyvistä ongelmista, mutta piilotetut vaarat saattavat nousta esiin, kun sitä on käytettävä yhdessä muiden järjestelmien kanssa todellisessa ympäristössä. Systeemitekniikan kurissa tämä tunnetaan nimellä syntyminen . ” Esiintyviä ominaisuuksia ovat 'Odottamattomat käyttäytymiset, jotka johtuvat sovelluksen komponenttien ja niiden ympäristön välisestä vuorovaikutuksesta' ja luonteensa vuoksi niitä on käytännössä mahdotonta havaita laboratoriossa. Kutsumalla edustava loppukäyttäjäryhmä kokeilemaan uutta järjestelmääsi huolellisessa valvonnassa, monet näistä ominaisuuksista voidaan havaita ja arvioida negatiivisten seurausten suhteen, jotka saattavat ilmetä täysimittaisessa käyttöönotossa.
Toinen arkkitehtuurikeskusteluissa asiakkaiden kanssa usein esiin nouseva aihe on vaiheittainen käyttöönotto. Tämä on valinta, vaihdetaanko olemassa olevan järjestelmän elementit asteittain uuden elementteihin, kunnes lopulta kaikki korvataan tai vaihdetaan kaikki kerralla. Jokaiselle on hyvät ja huonot puolet: vaiheittainen käyttöönotto mahdollistaa käyttäjien asteittaisen sopeutumisen uuteen suunnitteluun varmistaen, että muutokset tulevat hallittavina määrinä ja että käyttäjiä ei hukuteta; toisaalta se voi vetää prosessin ulos pitkiä aikoja ja johtaa jatkuvaan siirtymätilaan. Välitön käyttöönotto on hyödyllistä siinä mielessä, että se 'repii nauhan irti' ja nopeuttaa asioita eteenpäin, mutta äkilliset rajut muutokset voivat hukuttaa käyttäjät.
Elinkriittisissä järjestelmissä olen havainnut, että vaiheittainen käyttöönotto on yleensä turvallisempaa, koska ne mahdollistavat yksittäisten komponenttien asteittaisen arvioinnin tuotantoympäristössä ja mahdollistavat pienemmät käännökset, jos jotain on palautettava. Tätä on kuitenkin arvioitava tapauskohtaisesti.
OK, joten käyttäjätestauksesi auttoi sinua suunnittelemaan intuitiivisen järjestelmän, beetavaiheesi tunnisti esiin nousevat ongelmat, vaiheittainen käyttöönotto antoi käyttäjille mahdollisuuden mukautua suunnitteluun ja kaikki toimii sujuvasti. Olet valmis, eikö? Valitettavasti ei.
Järjestelmääsi tulee väistämättä, eikä siitä ole kiertämistä. Kun käyttäjät kohtaavat nämä ongelmat, he kehittävät usein kiertotapoja sen sijaan, että ilmoittaisivat ongelmasta teknikkotiimille. Kiertotavoista tulee tavanomainen käytäntö, joka jaetaan 'vinkkeinä' veteraaneilta aloittelijoille. Sosiologi Diane Vaughan loi lauseen kuvaamaan tätä ilmiötä: “ poikkeaman normalisointi . ” Käyttäjät tottuvat niin poikkeavaan käyttäytymiseen, että eivät muista, että se on itse asiassa poikkeavaa.
Klassinen esimerkki on avaruussukkula Challenger: kiinteiden rakettien vahvistimien osan havaittiin säännöllisesti heikentyvän laukaisun aikana, ja vaikka kaikki tiesivät, että rakettikomponenttien syöpyminen oli huono asia, niin tapahtui niin usein, että poikkeuslupia annettiin säännöllisesti ja sitä pidettiin normaalia. 28. tammikuuta 1986 ongelmaa, jonka kaikki alun perin tiesivät, ei pitäisi sallia, mutta että he olivat normalisoituneet, johti Challengerin räjähdys ja seitsemän astronautin kuolema.
Elinkriittisen järjestelmän järjestelmänvalvojana sinun on estettävä tällaisten tapahtumien tapahtuminen. Tutki, miten käyttäjät ovat vuorovaikutuksessa järjestelmän kanssa. Varjota heitä muutaman päivän ajan ja katso, käyttävätkö he odottamattomia kiertotapoja. Lähetä ajoittain kyselyjä ehdotettujen muutosten ja parannusten pyytämiseksi. Omistaudu aikaa ja vaivaa järjestelmän parantamiseen, ennen kuin käyttäjät löytävät tapoja kiertää ongelmat ilman sinua.
Elinkriittisissä järjestelmissä esiintyy usein vikoja, kun käyttäjät kärsivät stressistä, adrenaliinin kohoamisesta ja tunnelinäköstä. Se tapahtui lentäjille Air France 447 -laitteessa, se tapahtui ensihoitajille, jotka eivät muista, miten sydämen näyttöä tulisi käyttää ensimmäisellä sydänpysähdyspotilaallaan, ja sattui sotilaita, jotka eivät pysty käyttämään radiota oikein tulipalon alla.
Joitakin tätä riskiä lievennetään käyttämällä intuitiivisia malleja, kuten aiemmin keskusteltiin, mutta se yksin ei riitä. Varsinkin ympäristöissä, joissa korkean stressin skenaarioita esiintyy, mutta esiintyy harvoin, on tärkeää kouluttaa käyttäjiä paitsi järjestelmän käyttämisestä myös ajattelemisesta selkeästi tällaisissa olosuhteissa. Jos käyttäjät muistavat laitteisiin liittyviä toimintoja, he eivät voi käsitellä odottamattomia vikoja, koska oppimansa toimet eivät ehkä enää ole sopivia. jos he kouluttavat ajattelemaan loogisesti ja selkeästi stressin alla, he voivat reagoida muuttuviin olosuhteisiin ja auttaa järjestelmääsi pysymään hengissä, kun jotain rikkoutuu.
Elinkriittisten ohjelmistojen kehittäminen, käyttöönotto ja ylläpito on tietysti helvetin paljon monimutkaisempi kuin mitä voidaan tarkentaa yhdessä artikkelissa. Nämä harkinta-alueet voivat kuitenkin auttaa sinua saamaan paremman käsityksen siitä, mitä odottaa, kun aiot työskennellä tällaisen projektin parissa. Yhteenvetona:
Lopuksi haluaisin huomata, että monimutkaisissa turvallisuuskriittisissä järjestelmissä asiat menevät pieleen jossain vaiheessa riippumatta siitä, kuinka paljon suunnittelua, testausta ja huoltoa teet. Kun nämä järjestelmät ovat elämänkriittisiä, on täysin mahdollista, että vika voi johtaa hengen menetykseen tai raajoihin.
Siinä tapauksessa, että tällainen tragedia tapahtuu jollakin vastuullasi, se on musertavaa painoa omalletunnollesi ja luulet todennäköisesti, että olisit voinut estää sen, jos olisit kiinnittänyt enemmän huomiota tai työskennellyt kovemmin. Ehkä se on totta, ehkä ei, mutta on mahdotonta ennakoida kaikkia mahdollisia tapahtumia.
Työskentele huolellisesti, älä nouse, ja teet maailmasta paremman paikan.
Elinkriittinen järjestelmä on järjestelmä, jonka vika tai toimintahäiriö voi johtaa kuolemaan tai vakavaan loukkaantumiseen. Se sisältää kaikki kriittisen toiminnon suorittamiseen tarvittavat ohjelmistot ja laitteistot.
Luotettavuus mittaa järjestelmän käytettävyyttä, luotettavuutta ja ylläpidettävyyttä. Yleensä se mittaa luottamusta siihen, että järjestelmä toimii odotetulla tavalla.
Turvallisuuden kannalta tärkeät elementit ovat järjestelmiä tai komponentteja, jotka on suunniteltu estämään, hallitsemaan, lieventämään tai reagoimaan järjestelmän toimintahäiriöihin tai onnettomuuksiin, jotka voivat johtaa loukkaantumiseen tai kuolemaan.
