Vaikka kyseessä olisi tulva, 1C:n pitäisi toimia! Olemme samaa mieltä yrityksen kanssa DR

Kuvittele: palvelet suuren kauppakeskuksen IT-infrastruktuuria. Kaupungissa alkaa sataa. Sadevirrat murtautuvat katon läpi, vesi täyttää kauppatilat nilkoihin asti. Toivomme, että palvelinhuoneesi ei ole kellarissa, muuten ongelmia ei voida välttää.  

Kuvattu tarina ei ole fantasiaa, vaan kollektiivinen kuvaus parista vuoden 2020 tapahtumasta. Suurissa yrityksissä katastrofipalautussuunnitelma tai DRP (Dasaster Recovery Plan) on aina käsillä tätä tapausta varten. Yrityksissä tämä on liiketoiminnan jatkuvuuden asiantuntijoiden vastuulla. Mutta keskisuurissa ja pienissä yrityksissä tällaisten ongelmien ratkaiseminen jää IT-palvelujen varaan. Sinun täytyy itse ymmärtää liiketoimintalogiikka, ymmärtää, mikä voi epäonnistua ja missä, keksiä suoja ja toteuttaa se. 

On hienoa, jos IT-asiantuntija pystyy neuvottelemaan yrityksen kanssa ja keskustelemaan suojan tarpeesta. Mutta olen nähnyt useammin kuin kerran, kuinka yritys säästeli DR-ratkaisua, koska se piti sitä tarpeettomana. Onnettomuuden sattuessa pitkä toipuminen uhkasi tappioita, eikä liiketoiminta ollut valmis. Voit toistaa niin paljon kuin haluat: "Sanoin sinulle niin", mutta IT-palvelun on silti palautettava palvelut.

Arkkitehdin asemasta kerron sinulle, kuinka voit välttää tämän tilanteen. Artikkelin ensimmäisessä osassa näytän valmistelutyön: kuinka keskustella asiakkaan kanssa kolmesta turvatyökalujen valinnan kysymyksestä: 

• Mitä suojelemme?
• Miltä suojelemme?
• Kuinka paljon suojelemme? 

Toisessa osassa puhumme vaihtoehdoista vastata kysymykseen: kuinka puolustaa itseäsi. Annan esimerkkejä tapauksista, joissa eri asiakkaat rakentavat suojauksensa.

Mitä suojaamme: kriittisten liiketoimintatoimintojen tunnistaminen 

Valmistautuminen kannattaa aloittaa keskustelemalla yritysasiakkaan kanssa hätätilanteen jälkeisestä toimintasuunnitelmasta. Suurin vaikeus tässä on löytää yhteinen kieli. Asiakas ei yleensä välitä siitä, miten IT-ratkaisu toimii. Hän välittää siitä, pystyykö palvelu hoitamaan liiketoimintoja ja tuomaan rahaa. Esimerkiksi: jos sivusto toimii, mutta maksujärjestelmä ei toimi, asiakkailta ei tule tuloja, ja "ääriainekset" ovat edelleen IT-asiantuntijoita. 

IT-ammattilaisella voi olla vaikeuksia tällaisissa neuvotteluissa useista syistä:

• IT-palvelu ei täysin ymmärrä tietojärjestelmän roolia liiketoiminnassa. Esimerkiksi, jos liiketoimintaprosessien kuvausta tai läpinäkyvää liiketoimintamallia ei ole saatavilla. 
• Koko prosessi ei riipu IT-palvelusta. Esimerkiksi kun osa töistä tehdään urakoitsijoiden toimesta, eikä IT-asiantuntijoilla ole heihin suoraa vaikutusvaltaa.

Rakentaisin keskustelun näin: 

1. Selitämme yrityksille, että onnettomuuksia sattuu kaikille ja toipuminen vie aikaa. Parasta on näyttää tilanteet, miten tämä tapahtuu ja mitkä seuraukset ovat mahdollisia.
2. Näytämme, että kaikki ei riipu IT-palvelusta, mutta olet valmis auttamaan vastuualueesi toimintasuunnitelmassa.
3. Pyydämme yritysasiakasta vastaamaan: jos maailmanloppu tapahtuu, mikä prosessi pitäisi palauttaa ensin? Kuka osallistuu ja miten? 

   Yritykseltä vaaditaan yksinkertainen vastaus, esimerkiksi: puhelinkeskuksen on jatkettava hakemusten rekisteröintiä 24/7.

4. Pyydämme yhtä tai kahta järjestelmän käyttäjää kuvailemaan tätä prosessia yksityiskohtaisesti. 
   On parempi käyttää analyytikkoa auttamaan, jos yritykselläsi on sellainen.

   Aluksi kuvaus voi näyttää tältä: puhelinpalvelu vastaanottaa pyyntöjä puhelimitse, postitse ja viesteillä verkkosivustolta. Sitten hän syöttää ne verkkokäyttöliittymän kautta 1C:hen ja tuotanto vie ne sieltä tällä tavalla.

5. Sitten tarkastellaan, mitkä laitteisto- ja ohjelmistoratkaisut tukevat prosessia. Kattavan suojan saamiseksi otamme huomioon kolme tasoa: 
   • sovellukset ja järjestelmät sivustossa (ohjelmistotaso),   
   • itse sivusto, jossa järjestelmät toimivat (infrastruktuuritaso), 
   • verkkoon (usein unohtavat sen).

6. Selvitämme mahdolliset vikakohdat: järjestelmäsolmut, joista palvelun suorituskyky riippuu. Huomaamme erikseen solmut, joita muut yritykset tukevat: teleoperaattorit, isännöintipalveluntarjoajat, datakeskukset ja niin edelleen. Tämän avulla voit palata yritysasiakkaan luo seuraavaan vaiheeseen.

Miltä suojelemme: riskeiltä

Seuraavaksi selvitämme yritysasiakkaalta, miltä riskeiltä suojaudumme ensin. Kaikki riskit voidaan jakaa kahteen ryhmään: 

• ajan menetys palvelun seisokkien vuoksi;
• tietojen menetys fyysisten vaikutusten, inhimillisten tekijöiden jne. vuoksi.

Yritykset pelkäävät menettävänsä sekä dataa että aikaa – kaikki tämä johtaa rahan menettämiseen. Esitämme siis kysymyksiä jokaiselle riskiryhmälle: 

• Voimmeko tässä prosessissa arvioida, kuinka paljon tietojen menetys ja ajan menetys maksavat rahassa? 
• Mitä tietoja emme voi menettää? 
• Missä emme voi sallia seisokkeja? 
• Mitkä tapahtumat ovat meille todennäköisimpiä ja uhkaavimpia?

Keskustelun jälkeen ymmärrämme, kuinka virhepisteet priorisoidaan. 

Kuinka paljon suojaamme: RPO ja RTO 

Kun kriittiset vikapisteet ovat selvät, laskemme RTO- ja RPO-indikaattorit. 

Haluan muistuttaa teitä siitä RTO (toipumisaikatavoite) — Tämä on sallittu aika onnettomuushetkestä palvelun täydelliseen palautumiseen. Liikekielellä tämä on hyväksyttävä seisokkiaika. Jos tiedämme, kuinka paljon rahaa prosessi toi, voimme laskea tappiot jokaisesta seisokkiminuutista ja laskea hyväksyttävän tappion. 

RPO (palautuspistetavoite) — kelvollinen tietojen palautuspiste. Se määrittää ajan, jonka aikana voimme menettää tietoja. Liiketoiminnan kannalta tietojen katoamisesta voi seurata esimerkiksi sakkoja. Tällaiset tappiot voidaan myös muuntaa rahaksi. 

Toipumisaika on laskettava loppukäyttäjälle: kuinka kauan hän voi kirjautua järjestelmään. Joten laskemme ensin yhteen ketjun kaikkien linkkien palautumisajat. Tässä tehdään usein virhe: he ottavat palveluntarjoajan RTO:n SLA:sta ja unohtavat loput ehdot.

Katsotaanpa konkreettista esimerkkiä. Käyttäjä kirjautuu sisään 1C:hen, järjestelmä avautuu tietokantavirheellä. Hän ottaa yhteyttä järjestelmänvalvojaan. Tietokanta sijaitsee pilvessä, järjestelmänvalvoja ilmoittaa ongelmasta palveluntarjoajalle. Oletetaan, että kaikki viestintä kestää 15 minuuttia. Pilvessä tämän kokoinen tietokanta palautetaan varmuuskopiosta tunnissa, joten palveluntarjoajan puolella RTO on tunti. Mutta tämä ei ole lopullinen määräaika; käyttäjälle on lisätty 15 minuuttia ongelman havaitsemiseen. 
 
Seuraavaksi järjestelmänvalvojan on tarkistettava, että tietokanta on oikea, yhdistettävä se 1C:hen ja aloitettava palvelut. Tämä vaatii vielä tunnin, mikä tarkoittaa, että järjestelmänvalvojan puolella RTO on jo 2 tuntia ja 15 minuuttia. Käyttäjä tarvitsee vielä 15 minuuttia: kirjaudu sisään, tarkista, että tarvittavat tapahtumat ovat ilmestyneet. 2 tuntia 30 minuuttia on palvelun palautumisaika tässä esimerkissä.

Nämä laskelmat osoittavat yritykselle, mistä ulkoisista tekijöistä toipumisaika riippuu. Jos esimerkiksi toimisto on veden alla, sinun on ensin löydettävä vuoto ja korjattava se. Se vie aikaa, joka ei riipu IT:stä.  

Kuinka suojelemme: työkalujen valinta erilaisiin riskeihin

Keskusteltuaan kaikista asioista asiakas ymmärtää jo onnettomuuden kustannukset yritykselle. Nyt voit valita työkaluja ja keskustella budjetista. Esimerkeillä asiakastapauksista näytän sinulle, mitä työkaluja tarjoamme eri tehtäviin. 

Aloitetaan ensimmäisestä riskiryhmästä: huoltoseisokeista johtuvista tappioista. Tämän ongelman ratkaisujen pitäisi tarjota hyvä RTO.

1. Isännöi sovellusta pilvessä 

   Aluksi voit siirtyä pilveen - palveluntarjoaja on jo miettinyt korkean käytettävyyden kysymyksiä. Virtualisointipalvelimet kootaan klusteriksi, varataan virta ja verkko, tiedot tallennetaan vikasietoisiin tallennusjärjestelmiin ja palveluntarjoaja on taloudellisesti vastuussa seisokeista.

   Voit esimerkiksi isännöidä virtuaalikoneen, jonka tietokanta on pilvessä. Sovellus muodostaa yhteyden tietokantaan ulkoisesti vakiintuneen kanavan kautta tai samasta pilvestä. Jos jossakin klusterin palvelimista ilmenee ongelmia, VM käynnistyy uudelleen viereisellä palvelimella alle 2 minuutissa. Sen jälkeen DBMS käynnistyy siinä ja muutaman minuutin kuluttua tietokanta tulee saataville.

   RTO: mitattuna minuuteissa. Nämä ehdot voidaan määritellä palveluntarjoajan kanssa tehdyssä sopimuksessa.
   Maksaa: Laskemme pilviresurssien kustannukset sovelluksellesi. 
   Miltä se ei suojaa sinua: massiivisista vioista palveluntarjoajan toimipaikalla, esimerkiksi kaupunkitason onnettomuuksista.

2. Klusteroi sovellus  

   Jos haluat parantaa RTO:ta, voit vahvistaa edellistä vaihtoehtoa ja sijoittaa välittömästi klusteroidun sovelluksen pilveen.

   Voit toteuttaa klusterin aktiivinen-passiivinen tai aktiivinen-aktiivinen tilassa. Luomme useita virtuaalikoneita toimittajan vaatimusten perusteella. Luotettavuuden lisäämiseksi jaamme ne eri palvelimille ja tallennusjärjestelmille. Jos palvelin jollakin tietokannasta epäonnistuu, varmuuskopiosolmu ottaa kuorman haltuunsa muutamassa sekunnissa.

   RTO: Mitattu sekunneissa.
   Maksaa: hieman kalliimpi kuin tavallinen pilvi, klusterointi vaatii lisäresursseja.
   Miltä se ei suojaa sinua: Ei silti suojaa massiivisia paikan päällä tapahtuvia vikoja vastaan. Mutta paikalliset häiriöt eivät kestä niin kauan.

   Käytännöstä: Vähittäiskauppayrityksellä oli useita tietojärjestelmiä ja verkkosivustoja. Kaikki tietokannat sijaitsivat paikallisesti yrityksen toimistossa. DR:tä ei ajateltu ennen kuin toimisto jäi ilman sähköä useita kertoja peräkkäin. Asiakkaat olivat tyytymättömiä verkkosivustojen kaatumiseen. 
    
   Palvelun saatavuusongelma ratkesi pilveen siirtymisen jälkeen. Lisäksi onnistuimme optimoimaan tietokantojen kuormituksen tasapainottamalla liikennettä solmujen välillä.

3. Siirry katastrofikestävään pilveen

   Jos haluat varmistaa, että luonnonkatastrofikaan pääsivustolla ei häiritse työtäsi, voit valita katastrofin kestävän pilven. Tässä vaihtoehdossa palveluntarjoaja jakaa virtualisointiklusterin kahteen palvelinkeskukseen. Palvelinkeskusten välillä tapahtuu jatkuvaa synkronista replikointia, yksitellen. Konesalien väliset kanavat ovat varattuja ja kulkevat eri reittejä, joten tällainen klusteri ei pelkää verkkoongelmia. 

   RTO: yleensä 0.
   Maksaa: Kallein pilvivaihtoehto. 
   Miltä se ei suojaa sinua: Se ei auta tietojen korruptiota vastaan, eikä myöskään inhimilliseltä tekijältä, joten on suositeltavaa tehdä varmuuskopioita samanaikaisesti. 

   Käytännöstä: Yksi asiakkaistamme kehitti kattavan katastrofipalautussuunnitelman. Hän valitsi seuraavan strategian: 

   • Katastrofienkestävä pilvi suojaa sovellusta infrastruktuuritason häiriöiltä. 
   • Kaksitasoinen varmuuskopiointi tarjoaa suojan inhimillisen virheen varalta. Varmuuskopioita on kahdenlaisia: "kylmä" ja "kuuma". "Kylmä" varmuuskopio on pois käytöstä, ja sen käyttöönotto vie aikaa. "Kuuma" varmuuskopio on jo valmis käytettäväksi ja palautuu nopeammin. Se on tallennettu erityiseen säilytysjärjestelmään. Kolmas kopio tallennetaan nauhalle ja säilytetään toisessa huoneessa. 

   Kerran viikossa asiakas testaa suojauksen ja tarkistaa kaikkien varmuuskopioiden toimivuuden, myös nauhalta tulleiden. Joka vuosi yritys testaa koko katastrofien kestävän pilven. 

4. Järjestä replikointi toiseen sivustoon 

   Toinen vaihtoehto globaalien ongelmien välttämiseksi pääsivustolla: tarjoa maantieteellinen varaus. Toisin sanoen, luo varmuuskopiointivirtuaalikoneita toisessa kaupungissa sijaitsevassa paikassa. Tähän soveltuvat erikoisratkaisut DR:lle: käytämme yrityksessämme VMware vCloud Availability (vCAV). Sen avulla voit määrittää suojauksen useiden pilvipalveluntarjoajien sivustojen välillä tai palauttaa pilveen paikalliselta sivustolta. Olen jo puhunut yksityiskohtaisemmin vCAV-työskentelysuunnitelmasta täällä. 

   RPO ja RTO: 5 minuutista alkaen. 

   Maksaa: kalliimpi kuin ensimmäinen vaihtoehto, mutta halvempi kuin laitteiston replikointi katastrofikestävässä pilvessä. Hinta koostuu vCAV-lisenssin hinnasta, hallinnointimaksuista, pilviresurssien kustannuksista ja PAYG-mallin mukaisista vararesursseista (10 % sammutettujen virtuaalikoneiden käyttöresurssien hinnasta).

   Käytännöstä: Asiakas piti Moskovassa pilvessämme 6 virtuaalikonetta eri tietokannoilla. Aluksi suojaus toteutettiin varmuuskopioinnilla: osa varmuuskopioista oli tallennettu pilveen Moskovassa ja osa Pietarissamme. Ajan myötä tietokantojen koko kasvoi, ja varmuuskopiosta palauttaminen alkoi viedä enemmän aikaa. 
    
   Varmuuskopioihin lisättiin VMware vCloudin saatavuuteen perustuva replikointi. Virtuaalikoneiden jäljennökset tallennetaan varmuuskopiosivustolle Pietarissa, ja ne päivitetään 5 minuutin välein. Jos pääsivustolla tapahtuu vika, työntekijät siirtyvät itsenäisesti Pietarin virtuaalikoneen kopioon ja jatkavat työskentelyä sen kanssa. 

Kaikki harkitut ratkaisut tarjoavat korkean käytettävyyden, mutta eivät suojaa tietojen katoamiselta ransomware-viruksen tai vahingossa tapahtuneen työntekijän virheen vuoksi. Tässä tapauksessa tarvitsemme varmuuskopiot, jotka tarjoavat vaaditun RPO:n.

5. Älä unohda varmuuskopiointia

Kaikki tietävät, että sinun on tehtävä varmuuskopiot, vaikka sinulla olisi siistein katastrofinkestävä ratkaisu. Muistutan siis vain lyhyesti muutamasta seikasta.

Tarkkaan ottaen varmuuskopiointi ei ole DR. Ja siksi: 

• Se on pitkä aika. Jos tiedot mitataan teratavuina, palautuminen kestää yli tunnin. Sinun on palautettava, määritettävä verkko, tarkistettava, että se käynnistyy, katsottava, että tiedot ovat kunnossa. Joten voit tarjota hyvän RTO: n vain, jos tietoja on vähän. 
• Tietoja ei välttämättä palauteta ensimmäisellä kerralla, ja sinun on varattava aikaa toiminnon toistamiseen. Esimerkiksi joskus emme tiedä tarkalleen, milloin tiedot katosivat. Oletetaan, että katoaminen havaittiin klo 15.00 ja kopioita tehdään tunnin välein. Klo 15.00 alkaen katsomme kaikki palautuspisteet: 14:00, 13:00 ja niin edelleen. Jos järjestelmä on tärkeä, pyrimme minimoimaan palautuspisteen iän. Mutta jos tuore varmuuskopio ei sisältänyt tarvittavia tietoja, otamme seuraavan kohdan - tämä on lisäaikaa. 

Tässä tapauksessa varmuuskopiointiaikataulu voi tarjota tarvittavan RPO. Varmuuskopioita varten on tärkeää tarjota geovaraus, jos pääsivustossa on ongelmia. On suositeltavaa säilyttää jotkin varmuuskopiot erikseen.

Lopullisen katastrofipalautussuunnitelman tulee sisältää vähintään kaksi työkalua:  

• Yksi vaihtoehdoista 1-4, joka suojaa järjestelmiä vioittumiselta ja putoamiselta.
• Varmuuskopiointi tietojen suojaamiseksi katoamiselta. 

Myös varaviestintäkanavasta kannattaa huolehtia siltä varalta, että pääinternet-palveluntarjoaja kaatuu. Ja - voila! — DR minimipalkoilla on jo valmis. 

Lähde: will.com