Failover-testaus: harjoitukset ja katastrofipalautusharjoitukset

Katastrofipalautumissuunnitelma, jota ei ole koskaan testattu, on vain asiakirja – se luo vääränlaista luottamusta ilman todellista varmuutta. Todellisten katastrofien aikana mutta testaamattomissa suunnitelmissa yleisesti paljastuvia puutteita ovat esimerkiksi vanhentuneet yhteystietoluettelot (avainhenkilöt ovat vaihtaneet tehtävää tai lähteneet organisaatiosta), epäonnistuvat varmuuskopioiden palautukset ohjelmistoversioiden yhteensopimattomuuksien vuoksi, järjestelmät, joiden palauttaminen kestää 4 tuntia, vaikka suunnitelmassa oletettiin 30 minuuttia, sekä päätösvallan puutteet, joissa kukaan ei tiedä, kenellä on valtuudet julistaa katastrofi. Testaaminen paljastaa nämä puutteet hallitussa ympäristössä eikä kriisin aikana.

DR- ja BCP-testaus muodostaa jatkumon, jossa monimutkaisuus ja todentuntuisuus lisääntyvät. Asiakirjojen tarkistus – sen varmistaminen, että suunnitelmat ovat ajan tasalla ja täydelliset – on vähimmäistaso. Keskusteluharjoituksissa keskustellaan tilanteesta ilman järjestelmien aktivointia. Menettelyharjoituksissa osallistujat käyvät toimenpiteet suullisesti läpi. Toiminnallisissa harjoituksissa aktivoidaan tiettyjä osia, kuten puheluketjuja tai osittaisia järjestelmän vikasietoon siirtymisiä. Täyden mittakaavan testeissä siirrytään tosiasiassa DR-infrastruktuuriin ja liiketoimintaa jatketaan vaihtoehtoisesta toimipaikasta. Kukin taso lisää varmuutta, mutta myös kustannuksia ja häiriöitä.

Keskusteluharjoituksessa keskeiset sidosryhmät kokoontuvat käymään hypoteettisen katastrofitilanteen suullisesti läpi ilman todellisten järjestelmien aktivointia. Harjoituksen vetäjä esittää tilanteen: ”On maanantaiaamu, ja saatte hälytyksen, jonka mukaan kiristysohjelma on salannut ensisijaisen tietokantapalvelimen ja leviää verkossa. Mitä teette?” Osallistujat vastaavat reaaliajassa, jolloin päätösvallan, viestintäkäytäntöjen ja palautumismenettelyjen tuntemuksen puutteet tulevat esiin ilman toiminnan häiriintymistä.

Toiminnallisissa harjoituksissa testataan DR-suunnitelman tiettyjä osia ilman täydellistä aktivointia. Esimerkkejä ovat puheluketjun testi (kaikille hätäyhteyshenkilöille soitetaan oikeasti kello 2 yöllä, jotta numeroiden oikeellisuus ja henkilöstön vastaaminen tavoiteajassa voidaan varmistaa), varmuuskopion palautustesti (tietokanta palautetaan varmuuskopiosta testiympäristöön ja tietojen eheys varmistetaan), failover-testi (yksi ei-kriittinen sovellus siirretään DR-toimipaikkaan) sekä viestintäjärjestelmän testi (kaistan ulkopuolista viestintäkanavaa käytetään simuloidun häiriön koordinointiin). Kukin toiminnallinen harjoitus vahvistaa yhden suunnitelman osan toimivuuden.

Täyden mittakaavan DR-harjoituksessa tuotantotoiminta siirretään tosiasiassa DR-toimipaikkaan ja varmistetaan, että koko palautusketju toimii. Organisaatio aktivoi vaihtoehtoisen toimipaikan, lataa järjestelmät varmuuskopioista, ohjaa DNS:n DR-ympäristöön ja yrittää jatkaa varsinaista liiketoimintaa. Täyden mittakaavan testit vastaavat kriittisiin kysymyksiin: kuinka kauan täydellinen palautuminen todellisuudessa kestää? Toimivatko kaikki sovellukset DR-toimipaikassa? Ovatko kaikki verkkoasetukset oikein? Toimivatko valvonta- ja hälytystyökalut DR-ympäristössä? Nämä testit ovat kalliita ja häiritsevät toimintaa, mutta ne tarjoavat parhaan varmuuden tason.

DR-harjoituksissa on mitattava toteutunutta suorituskykyä RTO- ja RPO-tavoitteisiin verrattuna. Kirjatkaa harjoituksen aikana kunkin järjestelmän aktivointiaika DR-sivustolla, ajankohta, jolloin ensimmäinen käyttäjä pystyi onnistuneesti todentamaan henkilöllisyytensä ja käyttämään kutakin sovellusta, tietojen ikä järjestelmien tullessa käyttöön sekä kokonaisaika katastrofin julistamisesta toimintojen palauttamiseen. Verratkaa näitä RTO- ja RPO-tavoitteisiin. Jokainen tavoitteen ja toteutuneen suorituskyvyn välinen poikkeama osoittaa konkreettisen parannuskohteen ennen seuraavaa harjoitusta.

Jokaisen DR-harjoituksen — lopputuloksesta riippumatta — tulisi tuottaa toimien jälkeinen raportti (After-Action Report, AAR). AAR-raportissa dokumentoidaan, mitä skenaarioita testattiin, mikä toimi hyvin, mikä epäonnistui tai kesti suunniteltua kauemmin, tunnistetut konkreettiset puutteet sekä priorisoitu luettelo parannuksista ja niille nimetyt vastuuhenkilöt sekä tavoitevalmistumispäivät. Raportti jaetaan ylimmälle johdolle ohjelman kypsyyden osoittamiseksi ja tunnistettujen puutteiden korjaamiseen tarvittavien investointien perustelemiseksi. Jos AAR-raportin toimenpiteiden toteutumista ei dokumentoida, harjoituksissa paljastuu ongelmia, joita ei koskaan korjata.

Laajamittaisissa DR-testeissä käytetään jompaakumpaa kahdesta lähestymistavasta. Käyttöönottoon siirtymisen testauksessa tuotantoliikenne siirretään tosiasiallisesti DR-sivustolle — menetelmä on realistinen, mutta riskialtis, jos DR-sivusto vikaantuu ja aiheuttaa pitkittyneen käyttökatkon. Rinnakkaisessa testauksessa DR-ympäristö käynnistetään tuotantoympäristön rinnalle ja testiliikenne ohjataan DR-ympäristöön samalla, kun tuotanto palvelee edelleen oikeita käyttäjiä — näin DR-toiminnallisuus voidaan validoida vähäisellä riskillä, koska tuotanto jatkaa toimintaansa. Useimmat organisaatiot käyttävät rinnakkaista testausta kriittisissä järjestelmissä ja käyttöönottoon siirtymisen testausta vähemmän kriittisissä järjestelmissä tai suunniteltujen huoltoikkunoiden aikana.

Selkeä katastrofin julistamisprosessi on välttämätön — epäselvyys siitä, milloin DR on aktivoitava, aiheuttaa vaarallisia viiveitä. Suunnitelmissa on määriteltävä täsmälliset ja mitattavat kriteerit, jotka käynnistävät DR:n aktivoinnin automaattisesti: ”Jos ensisijaiseen datakeskukseen ei saada yhteyttä yli 2 tuntiin” tai ”Jos yli 50 % tuotantopalvelimista ei ole käytettävissä”. Suunnitelmassa on myös määriteltävä kuka on valtuutettu julistamaan katastrofin (tyypillisesti CIO tai CTO sekä nimetty varahenkilö hänen ollessaan estynyt), ympärivuorokautinen puhelinnumero, josta valtuutettu henkilö tavoitetaan, sekä selkeä eskalointipolku siltä varalta, ettei ensisijaista valtuutettua henkilöä tavoiteta.

Testaustiheyden tulisi vastata järjestelmien kriittisyyttä ja ympäristön muutosten nopeutta. Alan parhaat käytännöt ovat seuraavat: pöytäharjoitukset neljännesvuosittain (edullisia ja hyödyllisiä sekä pitävät taidot tuoreina), toiminnalliset harjoitukset puolivuosittain (testaavat tiettyjä komponentteja), laajamittaiset DR-harjoitukset vuosittain (koko suunnitelman kattava validointi) ja ennalta ilmoittamattomat testit vähintään kerran vuodessa (testaavat, pystyykö tiimi reagoimaan ilman ennakkovalmistautumista). Kaikkien merkittävien infrastruktuurimuutosten — kuten pilvisiirtymän, uuden sovelluksen käyttöönoton tai datakeskuksen siirron — tulisi käynnistää päivitetty DR-testi.

Monet sääntelykehykset edellyttävät DR-testausta tietyin väliajoin ja erityisiä dokumentointivaatimuksia noudattaen. HIPAA edellyttää, että sen piiriin kuuluvat toimijat testaavat valmiussuunnitelmansa säännöllisesti ja tarkistavat niitä. PCI-DSS Requirement 12.10 edellyttää, että incident response -suunnitelma testataan vähintään vuosittain ja merkittävien muutosten yhteydessä. FDIC:n ja OCC:n ohjeistus pankeille edellyttää BCP-testauksen suorittamista vuosittain ja raportointia hallitustasolla. SOC 2 Type II -auditoijat tarkastavat näyttöä BCP/DRP-testauksen tiheydestä, tuloksista ja tunnistettujen puutteiden korjaamisesta. Säilyttäkää dokumentoidut todisteet kaikista testeistä, tuloksista ja korjaavista toimenpiteistä auditoijien tarkastusta varten.

Tässä oppitunnissa opitte, että DR-testaus etenee pöytäkeskusteluista toiminnallisten harjoitusten kautta laajamittaisiin harjoituksiin realismin ja kustannusten kasvaessa, jokaisessa testissä on mitattava toteutunutta suorituskykyä RTO- ja RPO-tavoitteisiin verrattuna konkreettisten puutteiden tunnistamiseksi ja että toimien jälkeiset raportit ja nimetyt toimenpiteet varmistavat tunnistettujen heikkouksien korjaamisen ennen seuraavaa häiriötilannetta. Onnittelut Business Continuity and Disaster Recovery -moduulin suorittamisesta — olette valmiita siirtymään edistyneitä uhkia käsitteleviin aiheisiin.