Heinäkuun 19.päivänä 2024 koettiin yksi suurimmista IT-katkoista, mitä on koskaan nähty. Vaikka katko näkyi Suomessakin, vaikutukset olivat pienemmät verrattuna moneen muuhun maahan.
Katko sai minut pohtimaan, mitä IT:ssä voidaan oppia tapahtuneesta. Mitä IT-tiimit siis voisivat oppia tästä ongelmasta?
Käsittelen tässä kirjoituksessa joitakin oppeja, joita itselle tulee mieleen. Artikkelin innoittajana on McKinseyn julkaisema kirjoitus What should you be asking your team after the CrowdStrike outage?
Koska virhe johtui ohjelmistovirheestä, on selvää, että sellaisia tullaan näkemään vielä tulevaisuudessa. Katkoja voi kuitenkin tapahtua muistakin syistä.
Listaan seuraavassa 10 oppia tai asiaa, jotka auttavat tällaisista ongelmista toipumisessa ja jotka siksi olisi hyvä laittaa kuntoon jokaisessa IT-ympäristössä.
Oppi 1: Mieti millaisia katastrofeja meidän IT-ympäristössämme voisi tapahtua?
Kaiken tietoturva- ja varautumistyön pitäisi lähteä uhkien ja riskien kartoittamisesta. Siksi kannattaisi kirjoittaa auki erilaisia uhkaskenaarioita, mitä omassa IT-ympäristössä voisi tapahtua.
Todellinen arvo tästä harjoituksesta piilee siinä, että kun erilaisia uhkaskenaarioita on kirjoitettu auki, niistä voidaan keskustella. Todennäköisesti eri ihmiset tunnistavat erilaisia skenaarioita. Asiantuntijat ovat voineet koko ajan olla tietoisia jostain ongelmasta, mitä johto ei ole sisäistänyt. Tämä harjoitus auttaa ymmärryksen levittämisessä.
Oppi 2: Selvitä onko asset managementissa parannettavaa (todennäköisesti on)
Riskien hallinta ja varautumistoimenpiteet lähtevät yleensä siitä, että tunnistetaan kohteet, joita pitää suojata. Mutta kuinka monessa organisaatiossa on oikeasti tieto kaikista kohteista?
Väittäisin, että aika monessa varsinkin keskisuuressa organisaatiossa IT:n inventaariotieto ei ole ajan tasalla. Käsitys kaikista verkkolaitteista, palvelimista sovelluksista, PC:stä, mobiililaitteista, jne. on usein hieman hatara.
Toki suurin osa asseteista on IT:llä tiedossa, mutta jos asset management -käytännöissä on yhtään pehmeää, tieto siitä, missä mikäkin joskus hankittu laite tai softa on, voi olla yllättävän epävarmalla pohjalla.
Jos ei ole tietoa asseteista, joita suojataan, jää suojaus väkisinkin vajaaksi ja siten toipuminenkin on hankalampaa kuin, jos kaikki assetit ovat hyvin hallussa.
Erityinen riski ovat vanhentuneet käyttöjärjestelmät ja ohjemistot, joita on jäänyt käyttöön, koska laite itsessään toimii edelleen. Näihin ei saa päivityksiä ja ne voivat helposti saastua ja olla siten alkusysäys paljon isommalle katastrofille.
Oppi 3: Tunnista kriittisimmät järjestelmät
Onko sinulle selvää, mitkä järjestelmät ovat teille kaikkein kriittisimpiä? Todennäköisesti osaat. Osaatko sanoa, mitkä järjestelmät ovat vähemmän tärkeitä? Sekin on varmasti helppoa. Tämä on kuitenkin vasta sinun näkemyksesi.
Ajatteleeko IT-osasto samalla tavalla? Heijastavatko palveluiden SLA:t (Service Level Agreement) tätä kriittisyyttä? Usein ne eivät ole täysin linjassa.
Jotta liiketoiminnan näkemys järjestelmien kriittisyydestä saadaan näkymään IT-palvelutuotannossa, on tärkeää määritellä järjestelmien saatavuustavoitteet yhdessä liiketoiminnan kanssa.
Keskeisiä parametreja ovat esimerkiksi Recovery Time Objective (RTO), Recovery Point Objective (RPO) sekä Maximum Tolerable Period of Disruption (MTPD).
- RTO kuvaa tavoiteajan, jonka sisään järjestelmä pitäisi saada katkon jälkeen pystyyn.
- RPO taas kuvaa, paljonko data saa enimmillään hävitä.
- MTPD kuvaa aikaa, jonka liiketoiminta enintään kestää ilman kyseistä järjestelmää.
Olisi tärkeää määritellä nämä parametrit kaikkien järjestelmien osalta. Jos haluat lukea lisää asiasta, tutustu kirjoitukseeni Tunnetko nämä neljä (4) jatkuvuudenhallinnan termiä?
Oppi 4: Tunnista järjestelmien väliset riippuvuudet
Ei riitä, että yksittäisille sovelluksille tai järjestelmille määritellään toipumisen tavoiteajat. Yleensä sovellus tarvitsee monia muita järjestelmiä toimiakseen kunnolla. Kyse voi olla esimerkiksi integraatioista tai infrakomponenteista.
Sovellukselle riippuvuuksia ovat olla esimerkiksi virtuaalipalvelimet, jotka ovat puolestaan riippuvaisia alla olevista host-palvelimista, jotka ovat riippuvaisia sähköstä ja fyysisestä tilasta. Sovellus on usein riippuvainen Active Directoryn (AD) toiminnasta. Sovellus tarvitsee konesaliverkkoa ja palomuureja toimiakseen.
Kun määritellään riippuvuuksia päästä päähän, pitää ottaa huomioon, missä palvelun tai sovelluksen käyttäjä on, mitä hän tarvitsee (esim. PC, tietoliikenneyhteys jne.). Tästä kokonaisuudesta syntyy riippuvuuskartta, jonka jokaisen elementin pitää toimia, jotta järjestelmä on käytettävissä.
Kun tällaisen harjoituksen tekee, on helppo nähdä, että itse tuotetuissa konesalipalveluissa on paljon riippuvuuksia omalla vastuulla, ja jos taas sovellukset on hankittu SaaS-palveluna, suurin osa riippuvuuksista on sovellustoimittajan vastuulla.
On helppo nähdä, että itse tuotetuissa konesalipalveluissa on paljon riippuvuuksia omalla vastuulla, ja jos taas sovellukset on hankittu SaaS-palveluna, suurin osa riippuvuuksista on sovellustoimittajan vastuulla.
Oppi 5: Mieti etukäteen missä järjestyksessä sovelluksia ja järjestelmiä pitää palauttaa katastrofitilanteissa
Jos ympäristöt hajoavat, järjestelmien palauttaminen voi kestää pitkään. Silloin pitää päättää, missä järjestyksessä palauttamista toimintakuntoon tehdään.
Tässä auttaa järjestelmien kriittisyysluokittelu ja riippuvuusanalyysi, koska sieltä selviää, mitkä ovat kriittisimpiä järjestelmiä ja mitä tukijärjestelmiä pitää pystyttää ennen varsinaisen sovelluksen palauttamista.
Tällaiset asiat pitäisi määritellä Disaster Recovery -suunnitelmissa. Käydään siksi läpi sitä seuraavaksi.
Oppi 6: Varmista missä kunnossa Disaster Recovery (DR) -suunnitelmat ovat
Jos edustat liiketoimintajohtoa, kannattaa kysyä IT:ltä, onko tärkeimmille järjestelmille laadittu Disaster Recovery -suunnitelmat.
Jos suunnitelmia on, kannattaa kysyä, mitä skenaarioita niissä on huomioitu.
DR-suunnitelmissa tulisi olla kuvattuna, miten järjestelmä saatetaan toimintakuntoon, jos se joudutaan palauttamaan varmistuksista tai jopa asentamaan uudelleen DR-ympäristöön. Suunnitelma kuvaa, missä järjestyksessä asioita tehdään, mitä pitää muistaa tehdä, jne.
DR-suunnitelmat ovat hyvin usein IT:llä todo-listalla. Valitettavasti niitä ei ehditä tekemään, koska aina riittää muita päälle kaatuvia asioita, jotka ovat tärkeämpiä juuri silloin.
Lisäksi on hyvä muistaa, että pelkkä suunnitelma kantaa vain jonkin matkaa. Suunnitelmaa pitää koeponnistaa, ja palautumista pitää harjoitella. Kannattaa siksi kysyä, milloin ja missä laajuudessa asiaa on harjoiteltu.
Olen itse huomannut, että DR-harjoituksien pitäminen tuntuu monista vähän turhalta ja riskialttiilta. Siksi harjoitusten järjestäjänä saa kokea tunnetta, että haaskataanko tässä kaikkien kallista aikaa.
Itse olen saanut harjoitusten järjestämisestä mielenrauhaa, kun olen tiennyt, että ainakin tuo kohta ympäristöstä pystytään palauttamaan toimintakuntoon hyvin suoraviivaisesti.
Oppi 7: Selvitä mitä katkot maksaisivat liiketoiminnalle
Jos edustat itse liiketoimintajohtoa tai vastaat IT:stä johdolle, kannattaa selvittää, miten kauan palautuminen erilaisista uhkaskenaarioista todellisuudessa voisi viedä aikaa. Sitten on hyvä selvittää, miten liiketoiminta pystyy nilkuttamaan tämän ajan läpi.
Parasta on, jos pystytte laskemaan euromääräisiä kustannuksia katkoille. Se on hyödyllistä, koska vasta silloin selviää, minkä kokoisesta riskistä on kyse. Käytännössä kyse on Business Impact -analyysin (BIA) tekemisestä.
Jos aihe kiinnostaa, lue kirjoitukseni Mikä on Business Impact Analysis eli BIA ja mitä hyötyä sen tekemisestä on?
Jos haluat lukea case-esimerkin BIAn hyödyistä, lue ”Kybervakuutuksen hinta laski melkein puoleen”, jossa kerron, miten Oras Group hyötyi perusteellisesta BIA:sta.
Jos katkon kesto tuntuu kestämättömältä, on hyvä miettiä, miten nopeuttaa toipumista. Puhutaan siksi seuraavaksi siitä.
Oppi 8: Mieti miten nopeuttaa toipumista katastrofitilanteissa
Jos olette selvittäneet toipumisaikoja erilaisista skenaarioista, tulee varmasti mieleen, miten toipumista voisi nopeuttaa. Tämä onkin monimutkaisempi kysymys.
Olen tehnyt lukuisia projekteja asiakkaille, jotka ovat halunneet selvittää IT-ympäristöjensä tilaa, ja usein selvityksissä käy ilmi, että itse rakennettuihin ympäristöihin sisältyy riskiä, joka ei ole ylimmän johdon tiedossa.
Syynä on usein IT:n halu rakentaa ympäristö edullisesti. Käytännössä on säästetty rahaa. Vaikka ylin johto tietysti arvostaa, että rahaa ei tuhlata, joskus IT säästää rahaa johdon mielestä väärässä paikassa.
Usein toipumisen nopeuttaminen vaatii ympäristöön joko arkkitehtuurimuutoksia tai sitten palveluntuotantotapaa pitää muuttaa.
Jos mietit, mikä tilanne on juuri teidän ympäristössä ja haluaisit siihen ulkopuolisen arvion, tutustu palveluuni jossa arvioin IT-ympäristönne ja rakennan sille liiketoimintalähtöinen IT-roadmapin.
Oppi 9: Selvitä mikä on tasapaino uuden kehittämisen ja teknisen velan maksamisen välillä
Yleensä firmat panostavat uuden kehittämiseen. Jopa niin paljon, että olemassa olevaan tuotteeseen tai ympäristöön liittyvä tekninen velka jää huomioimatta.
On ymmärrettävää, että liiketoimintajohto haluaa uusia ratkaisuja ja mahdollisuuksia, koska juuri niiden avulla voidaan lisätä tuottavuutta, luoda uusia kyvykkyyksiä ja jopa kilpailuetuja.
Johto ei kuitenkaan usein ymmärrä, eikä ehkä voikaan ymmärtää, miten paljon teknistä velkaa olemassa olevaan IT-ympäristöön on pesiytynyt.
Tämä tekninen velka kumuloituu pikkuhiljaa. Aluksi se ei juuri haittaa, mutta jossain vaiheessa se voi tulla hyvinkin näkyväksi, kun riskit realisoituvat tai jokin kehitysaskel ei enää onnistukaan.
On IT:n asia tehdä tekninen velka näkyväksi muulle organisaatiolle ja löytää yhdessä liiketoiminnan kanssa tasapaino uuden kehittämisen ja teknisen velan maksamiseksi.
Katso tekemäni video Miksi IT:n tekninen velka kannattaa tehdä näkyväksi liiketoiminnalle?
Oppi 10: Selvitä onko muutoksen hallinta ja testaus riittävällä tasolla
Jokainen muutos aiheuttaa aina riskin IT-ympäristön hajoamiselle. Siksi on hyvä pohtia, miten muutoksia ylipäätään hallitaan, millä tasolla muutoksia dokumentoidaan ja niistä sovitaan yhdessä.
Pystytäänkö jälkikäteen selvittämään, millaisia muutoksia ympäristöön on tehty? Omaa muutoksenhallintaa kannattaa käydä läpi, koska asiantuntijoilla on taipumus oikaista kaikesta, joka hidastaa ja hankaloittaa tekemistä.
Crowdstrike-ongelman aiheutti testauskäytäntöjen pettäminen. Levitykseen päätyi päivitys, jota ei ollut testattu riittävästi.
Siksi kannattaa kysellä IT:ltä, miten päivityksiä tai muutoksia testataan.
Jos organisaatio kehittää itse softaa, on syytä kysyä, onko edes osaa testejä automatisoitu? Jos ei, mitä pitäisi tapahtua, että testausta saadaan automatisoitua?
Yhteenveto
Crowdstrike-ongelman tyyppisiä ohjelmistovirheen vuoksi hajoavia järjestelmiä ja laajalle leviäviä katkoja tullaan näkemään varmasti vielä lisää. Sitä mukaa, kun yhteiskunta digitalisoituu, kohtia, jotka voivat hajota ohjelmistovirheen vuoksi, syntyy lisää ja niiden kriittisyys yhteiskunnalle kasvaa.
Siksi liiketoimintajohdon ja riskeistä vastaavien johtajien tulisi ottaa IT-riskit vakavasti. Käsittelin tässä kymmentä asiaa, jotka kannattaa käydä yrityksissä läpi.
Käyn itse tällaisia asioita läpi, kun teen arvioita asiakkaiden IT-ympäristöistä ja kun rakennamme roadmapeja, joilla IT saadaan vastaamaan paremmin liiketoiminnan tarpeita.
Jos juuri tämä asia tuntuu ajankohtaiselta ja haluatte selvittää asiaa tarkemmin, tutustu IT-jatkuvuuden hallinnan palveluihini.
Toivottavasti tästä kirjoituksesta oli sinulle hyötyä. Jos haluat ilmoituksen, kun julkaisen uutta sisältöä, tilaa uutiskirjeeni.