Kesäkuussa 2017 NotPetya-haittaohjelma iski varustamojätti Maerskiin ja levisi nopeasti yhtiön maailmanlaajuiseen IT-ympäristöön. Tuhansia palvelimia ja kymmeniä tuhansia työasemia jouduttiin myöhemmin rakentamaan uudelleen.
Palautumisessa tuli kuitenkin vastaan vakava ongelma. Yksi koko ympäristön toiminnan kannalta kriittinen palvelinkerros oli tuhoutunut käytännössä kokonaan, eikä siitä löytynyt käyttökelpoista varmuuskopiota.
Sitten löytyi yksi puhdas palvelin Ghanasta.
Sen oli pelastanut sattuma: paikallinen sähkökatko oli irrottanut palvelimen verkosta ennen haittaohjelman leviämistä. Se sisälsi ainoan tunnetun ehjän kopion kriittisestä datasta, jota tarvittiin muun ympäristön palauttamiseen.
Yhden maailman suurimman logistiikkayhtiön palautumisessa ratkaisevan palasen pelasti siis lopulta sähkökatko.
Maersk joutui rakentamaan uudelleen noin 4 000 palvelinta ja 45 000 työasemaa. Yhtiö arvioi hyökkäyksen aiheuttaneen sille 250–300 miljoonan dollarin menetykset.
Tapaus kiteyttää jatkuvuuden hyvin: varmuuskopiot ovat välttämättömiä, mutta vasta toimiva palautuminen ratkaisee, kuinka nopeasti liiketoiminta saadaan takaisin käyntiin.
Kaikissa häiriötilanteissa panokset eivät tietenkään ole Maerskin mittaluokkaa. Perusajatus on silti sama.
Palvelin kaatuu. Verkkoyhteys katkeaa. Päivitys menee pieleen. Tiedosto poistetaan vahingossa. Pilvipalvelussa on häiriö.
Jossain vaiheessa jotain kuitenkin tapahtuu.
Siksi liiketoiminnan jatkuvuutta ei kannata rakentaa sen oletuksen varaan, että kaikki toimii aina. Paljon tärkeämpi kysymys on: mitä tapahtuu silloin, kun jokin ei toimi?
Juuri tästä jatkuvuuspalveluissa on kyse.
Varmuuskopio on tärkeä – mutta se ei vielä ole jatkuvuussuunnitelma
Kun puhutaan IT-jatkuvuudesta, ensimmäisenä mieleen tulee usein varmuuskopiointi.
Se on hyvä alku, mutta ei yksin riitä.
Varmuuskopiosta ei ole paljon iloa, jos vasta häiriötilanteessa huomataan, ettei sitä saada palautettua. Tai jos viimeisin käyttökelpoinen kopio on vuorokauden vanha, vaikka yritykselle jo tunnin tietojen menettäminen aiheuttaisi merkittävän ongelman.
Jatkuvuutta tarkasteltaessa pitääkin kysyä:
- Mitkä järjestelmät ovat liiketoiminnalle kriittisiä?
- Kuinka pitkän käyttökatkon yritys kestää?
- Kuinka paljon tietoa voidaan hyväksyttävästi menettää?
- Onko palautumista oikeasti testattu?
- Kuka toimii, kun häiriö tapahtuu?
Oleellista ei siis ole vain se, onko data tallessa, vaan kuinka nopeasti yritys pystyy palaamaan normaaliin toimintaan.
Tekninen häiriö muuttuu nopeasti liiketoiminnan häiriöksi
Joskus kyse on yhdestä palvelimesta. Joskus sähköpostista, toiminnanohjausjärjestelmästä, verkkokaupasta tai tiedostopalvelusta.
Vaikutukset alkavat kuitenkin nopeasti ketjuuntua.
Työntekijät eivät pääse järjestelmiin. Asiakaspalvelu ei näe tarvittavia tietoja. Tilauksia ei pystytä käsittelemään. Työt seisovat samalla, kun ongelmaa selvitetään.
Siksi jatkuvuuden suunnittelussa ei pitäisi aloittaa palvelimista vaan liiketoiminnasta:
Mitä yrityksessä lakkaa tapahtumasta, jos tämä järjestelmä katoaa käytöstä?
Vasta sen jälkeen voidaan määritellä, kuinka nopeasti palvelun pitää palautua ja millainen ratkaisu sen varmistamiseksi tarvitaan.
Kaikkea ei tarvitse varmistaa samalla tavalla
Yrityksen verkkosivuston tunnin käyttökatko voi olla harmillinen. Tuotantoa ohjaavan järjestelmän tunnin käyttökatko voi maksaa huomattavasti enemmän.
Siksi jatkuvuusratkaisujen pitää perustua priorisointiin.
Kriittisimmille järjestelmille voidaan rakentaa korkea käytettävyys, rinnakkainen varaympäristö tai automaattinen siirtyminen varajärjestelmään. Vähemmän kriittisissä palveluissa hyvin toteutettu varmuuskopiointi ja selkeä palautusprosessi voivat olla täysin riittäviä.
Tavoitteena ei ole mahdollisimman raskas tai kallis ympäristö, vaan riittävä toimintavarmuus oikeissa paikoissa.
Palautuminen ratkaisee
Jatkuvuuden todellinen testi tulee vasta häiriötilanteessa.
Jos tuotantopalvelin rikkoutuu tänään, kuinka nopeasti uusi ympäristö saadaan käyttöön?
Jos tärkeä tiedosto poistetaan, kuinka nopeasti se saadaan takaisin?
Jos organisaatio joutuu kiristyshaittaohjelman kohteeksi, löytyykö puhdas palautuspiste?
Näihin kysymyksiin tulisi olla olemassa vastaus, ennen kuin niitä joudutaan kysymään tositilanteessa.
Siksi jatkuvuus ei ole vain teknologiaa. Siihen kuuluvat myös vastuut, dokumentaatio, valvonta ja palautumisen testaaminen.
Palautussuunnitelma, jota ei ole koskaan testattu, on lopulta vasta oletus.
Jatkuvuus on kokonaisuus
Hyvä jatkuvuusratkaisu voi koostua varmuuskopioinnista, rinnakkaisista ympäristöistä, valvonnasta, tietoturvasta ja selkeästä toimintamallista häiriötilanteita varten.
Yksittäinen teknologia ei ratkaise kaikkea.
Pilvipalvelukaan ei automaattisesti tarkoita jatkuvuutta. Microsoft 365:n, Azure-ympäristön tai muun pilvipalvelun käytössä organisaation pitää edelleen miettiä, miten data, käyttöoikeudet ja liiketoiminnan kannalta kriittiset palvelut palautetaan häiriön jälkeen.
Ratkaisevaa on kokonaisuus.
Paras aika varautua on ennen häiriötä
IT-ympäristöissä tapahtuu virheitä ja häiriöitä riippumatta siitä, kuinka hyvin niitä ylläpidetään.
Jatkuvuuspalveluiden tarkoitus ei ole luvata, ettei mitään koskaan tapahdu. Niiden tarkoitus on varmistaa, ettei yksittäisestä ongelmasta synny katastrofia.
Kun kriittiset järjestelmät on tunnistettu, varmistukset toimivat, palautumisajat tunnetaan ja toimintamallit on testattu, häiriötilanteessa ei tarvitse alkaa improvisoida.
Silloin palvelin voi pysähtyä ilman, että liiketoiminta pysähtyy sen mukana.
Kuinka nopeasti teidän liiketoimintanne palautuisi, jos kriittinen IT-palvelu lakkaisi toimimasta juuri nyt?
Integral auttaa suunnittelemaan ja toteuttamaan jatkuvuusratkaisuja, joilla liiketoiminnan kannalta tärkeät palvelut ja tiedot saadaan pidettyä turvassa ja palautettua hallitusti myös silloin, kun kaikki ei mene suunnitelmien mukaan.
