Tämä kirjoitus on toinen osa sarjasta, jossa käsittelen ICT-varautumista.
Löydät edellisen kirjoituksen täältä.
Ensimmäisen osan jälkeen varautuminen on edennyt siihen, että johto on sitoutettu hankkeeseen ja sovellusten kriittisyys on selvitetty.
Näiden vaiheiden jälkeen on päästy sopimaan varautumishankkeen tavoitteista.
Käytännössä tämä tarkoittaa sitä, että tiedetään miten tärkeänä yrityksen johto pitää varautumista, mitkä riskit ovat johdon mielestä suurimpia, ja kuinka kauan eri järjestelmät saavat olla pois käytöstä.
Tässä vaiheessa päästään tekemään arkkitehtuuritason suunnitelmaa, jonka avulla tavoitteisiin voidaan päästä.
Aloita suunnittelu riskianalyysin tekemisellä
Mikäli uhkakartoitusta tai riskianalyysiä ei vielä ole tehty, viimeistään nyt on sen aika. Tämä onnistuu listaamalla toimintaan, prosesseihin ja järjestelmiin kohdistuvia uhkia. Kunkin uhkan kohdalla arvioidaan niiden toteutumisen todennäköisyyttä sekä seurauksia.
Riskianalyysin tuloksena saadaan riskit, jotka vaativat eniten reagointia. Harjoitus on kiinnostava, koska se konkretisoi teknisten ratkaisuiden rajoitteita, ja auttaa ymmärtämään sitä, että läheskään kaikkia riskejä ei voida poistaa teknisillä ratkaisuilla. Nyt uhkaskenaariot voidaan jakaa seuraaviin luokkiin:
- Uhkaskenaariot tai vikatilanteet, joita vastaan suojaudutaan korkean käytettävyyden eli High Availability (HA) -ratkaisulla.
- Uhkaskenaariot tai vikatilanteet, joita vastaan suojaudutaan toipumissuunnittelun keinoin eli Disaster Recovery (DR) -ratkaisulla.
- Uhkaskenaariot tai vikatilanteet, joita vastaan ei suojauduta.
Tyypillisesti ihmisten on vaikea sisäistää HA- ja DR -ratkaisuiden eroja. HA-ratkaisuilla pyritään estämään pitkien käyttökatkojen syntyminen pitkälle viedyn automatiikan avulla. Disaster recovery -ratkaisuissa puolestaan ihminen tekee päätöksen varajärjestelyyn siirtymisestä.
Rajaa suunnittelun kohteet
Koska ICT-varautuminen on laaja kokonaisuus, on suunnitelman kohdetta hyvä rajata. Seuraava kuva esittää kokonaisuutta, josta IT-palvelun käytettävyys koostuu. Kuvasta nähdään, että varautuminen on paljon enemmän kuin pelkkää järjestelmien kahdentamista. Järjestelmät koostuvat tiloista, laitteista ja ohjelmistoista. IT-palvelu tuo mukanaan prosessit ja IT-henkilökunnan. Varautumiseen liittyy tämän lisäksi käyttäjät, jotka viime kädessä käyttävät palvelua. Jos palvelun tuottamiseen käytetään ulkopuolisia palveluntuottajia ja kenties alihankintaa, on syntyvä kokonaisuus huomattavan monimutkainen.
Arkkitehtuurisuunnitelman laatiminen
Arkkitehtuurisuunnitteluvaiheessa pyritään aluksi kuvaamaan ratkaisu siten, että ymmärretään ratkaisun toimintaperiaate.
Suunnittelukohteita on paljon, ja tämä tekeekin suunnittelun haastavaksi. Vaihtoehtoisia tapoja toteuttaa toiminnollisuuksia on runsaasti.
Suunnittelussa otetaan kantaa mm. seuraaviin asioihin:
- Konesalien lukumäärä, rooli ja taso (esim. TIER-luokitus). Tähän liittyviä asioita ovat mm.
- Sähkön syöttö
- Varavoimajärjestelyt
- UPS
- Jäähdytys
- Fyysinen suojaus, kulunvalvonta
- Palosuojaus
- Suojautuminen esim. vesivahinkoja vastaan
- Tietoliikenneyhteydet konesalien ja käyttöpaikkojen välillä
- Konesalien sisäinen tietoliikenneverkko
- Palvelinlaitteistot
- Virtualisointiteknologioiden rooli (esim. VMware vs. Hyper-V)
- Mitä tehdään rautapalvelimille
- Mikä on pilvipalveluiden rooli varautumishankkeessa
- Levyjärjestelmät
- SAN-verkot
- Backup-järjestelyt
- Klustereiden rakentaminen
Yllä oleva lista on vain esimerkki asioista, joita joudutaan miettimään. Suunnittelua tarkennetaan niin pitkälle kuin on tarpeen.
Tässä vaiheessa haasteeksi muodostuu tyypillisesti teknisten ratkaisuiden ominaisuuksien ymmärtäminen ja ihmisten eri mieltymykset.
Kuvausten laatiminen ei ole triviaalia, koska reaalimaailmassa ratkaisuihin liittyy hyvin paljon yksityiskohtia. On hyvin haastavaa päättää, millä tasolla kuvauksien on syytä olla.
Hyvin yksityiskohtaiset kuvaukset saattavat ohjata huomion pois tärkeistä periaatteista, jotka on syytä ymmärtää. Toisaalta liian ylätasolla olevat kuvaukset eivät välttämättä paljasta suunnittelun ongelmakohtia.
Kun ICT-varautumishankkeessa ollaan edetty ratkaisusuunnitteluun, on vielä hyvä arvioida suunniteltua ratkaisua.
Tämä tapahtuu arvioimalla sitä, miten hyvin suunniteltu ratkaisu toimii eri uhkaskenaarioiden toteutuessa. Tässä tarvitaan aiemmin tehtyä sovellusten kriittisyysanalyysia ja Recovery Time Objective (RTO) ja Recovery Point Objective (RPO) -arvoja.
Jos muistisi kaipaa virkistämistä termien suhteen, voit tutustua tähän kirjoitukseen. Ratkaisuiden tulisi mahdollistaa tavoitteisiin pääseminen. On kuitenkin täysin mahdollista, että tavoitteet on asetettu niin koviksi, että niihin pääseminen ei nykyisillä ratkaisuilla tai käytettävissä olevilla resursseilla ole mahdollista.
Tällöin pitää miettiä teknologia- ja palveluvaihtoehtoja sekä mahdollisesti tavoitteiden muuttamista. Mikäli ratkaisuun ollaan edelleen tyytyväisiä, voidaan edetä hankintaan, yksityiskohtaiseen suunnitteluun ja käyttöönottoon.
Jatkotoimenpiteet
ICT-varautuminen ei pääty siihen, että tekninen järjestelmä on uusittu ja käytössä. Tämän jälkeen on syytä pyrkiä parantamaan ylläpitoprosesseja ja kouluttamaan henkilökuntaa.
Erityisen tärkeää on tehdä selvät suunnitelmat sen varalle, miten toimintaa jatketaan erilaisissa poikkeusoloissa. ICT-varautumiseen liittyy paljon näkökohtia, ja käsittelenkin tulevissa kirjoituksissa lisää tätä tärkeää aihetta.