Predstavljajte si: servisirate IT infrastrukturo velikega nakupovalnega centra. V mestu začne deževati. Potoki dežja prebijajo streho, voda polni trgovske prostore do gležnjev. Upamo, da vaša strežniška soba ni v kleti, sicer se težavam ne morete izogniti.
Opisana zgodba ni fantazija, ampak skupen opis nekaj dogodkov leta 2020. V velikih podjetjih je za ta primer vedno pri roki načrt za obnovitev po katastrofi ali načrt za obnovitev po katastrofi (DRP). V korporacijah so za to odgovorni strokovnjaki za neprekinjeno poslovanje. Toda v srednjih in majhnih podjetjih reševanje tovrstnih problemov pade na IT storitve. Sami morate razumeti poslovno logiko, razumeti, kaj lahko spodleti in kje, pripraviti zaščito in jo implementirati.
Odlično je, če se strokovnjak za IT lahko pogaja s podjetjem in razpravlja o potrebi po zaščiti. Več kot enkrat sem videl, kako je podjetje varčevalo z rešitvijo za obnovitev po katastrofi (DR), ker je menila, da je odveč. Ko se je zgodila nesreča, je dolgotrajno okrevanje grozilo z izgubo, posel pa ni bil pripravljen. Lahko ponavljate, kolikor želite: "Sem ti rekel," vendar bo IT služba vseeno morala obnoviti storitve.
S položaja arhitekta vam bom povedal, kako se tej situaciji izogniti. V prvem delu članka bom prikazal pripravljalno delo: kako se s stranko pogovoriti o treh vprašanjih za izbiro varnostnih orodij:
- Kaj ščitimo?
- Pred čim se ščitimo?
- Koliko varujemo?
V drugem delu bomo govorili o možnostih odgovora na vprašanje: kako se braniti. Navedel bom primere, kako različne stranke gradijo svojo zaščito.
Kaj ščitimo: prepoznavanje kritičnih poslovnih funkcij
Bolje je, da se priprave začnete tako, da se s poslovno stranko pogovorite o akcijskem načrtu po izrednih razmerah. Glavna težava pri tem je najti skupni jezik. Stranki običajno ni vseeno, kako IT rešitev deluje. Skrbi ga, ali lahko služba opravlja poslovne funkcije in prinaša denar. Na primer: če spletno mesto deluje, vendar plačilni sistem ne deluje, ni dohodka od strank, "ekstremisti" pa so še vedno IT strokovnjaki.
Strokovnjak za IT ima lahko pri takih pogajanjih težave iz več razlogov:
- Služba IT ne razume v celoti vloge informacijskega sistema v poslovanju. Na primer, če ni na voljo opisa poslovnih procesov ali transparentnega poslovnega modela.
- Celoten postopek ni odvisen od storitve IT. Na primer, ko del del opravijo izvajalci, informatiki pa nanje nimajo neposrednega vpliva.
Pogovor bi strukturiral takole:
- Podjetjem pojasnjujemo, da se nesreče zgodijo vsem, okrevanje pa zahteva čas. Najbolje je prikazati situacije, kako se to zgodi in kakšne posledice so možne.
- Pokažemo, da ni vse odvisno od IT storitve, vendar ste pripravljeni pomagati z akcijskim načrtom na vašem področju odgovornosti.
- Poslovnega naročnika prosimo za odgovor: če pride do apokalipse, kateri proces je treba najprej vzpostaviti? Kdo in kako pri tem sodeluje?
Od podjetja se zahteva preprost odgovor, na primer: klicni center mora še naprej prijavljati prijave 24/7.
- Prosimo enega ali dva uporabnika sistema, da podrobno opišeta ta postopek.
Za pomoč je bolje vključiti analitika, če ga vaše podjetje ima.Za začetek lahko opis izgleda takole: klicni center sprejema zahteve po telefonu, po pošti in prek sporočil s spletne strani. Nato jih prek spletnega vmesnika vnese v 1C, od tam pa jih na ta način vzame proizvodnja.
- Nato pogledamo, katere strojne in programske rešitve podpirajo proces. Za celovito zaščito upoštevamo tri stopnje:
- aplikacije in sistemi znotraj spletnega mesta (raven programske opreme),
- samo mesto, kjer sistemi delujejo (raven infrastrukture),
- omrežja (nanj pogosto pozabijo).
- Ugotovimo možne točke okvare: sistemska vozlišča, od katerih je odvisna uspešnost storitve. Ločeno omenjamo vozlišča, ki jih podpirajo druga podjetja: telekomunikacijski operaterji, ponudniki gostovanja, podatkovni centri ipd. S tem se lahko vrnete k poslovni stranki za naslednji korak.
Pred čim se zaščitimo: tveganja
Nato od poslovne stranke izvemo, pred katerimi tveganji se najprej zaščitimo. Vsa tveganja lahko razdelimo v dve skupini:
- izguba časa zaradi izpada storitev;
- izguba podatkov zaradi fizičnih vplivov, človeških dejavnikov itd.
Podjetja se bojijo izgube podatkov in časa – vse to vodi v izgubo denarja. Zato znova postavljamo vprašanja za vsako rizično skupino:
- Ali lahko za ta proces ocenimo, koliko stane izguba podatkov in izguba časa v denarju?
- Katerih podatkov ne moremo izgubiti?
- Kje ne smemo dovoliti izpadov?
- Kateri dogodki so za nas najverjetnejši in najbolj grozeči?
Po razpravi bomo razumeli, kako dati prednost točkam napak.
Koliko varujemo: RPO in RTO
Ko so kritične točke odpovedi jasne, izračunamo indikatorja RTO in RPO.
Naj vas spomnim na to RTO (cilj časa okrevanja) — to je dovoljeni čas od trenutka nesreče do popolne vzpostavitve storitve. V poslovnem jeziku je to sprejemljiv izpad. Če vemo, koliko denarja je proces prinesel, lahko izračunamo izgube iz vsake minute izpada in izračunamo sprejemljivo izgubo.
RPO (cilj točke obnovitve) — veljavna točka za obnovitev podatkov. Določa čas, v katerem lahko izgubimo podatke. S poslovnega vidika lahko izguba podatkov povzroči na primer globe. Takšne izgube je mogoče pretvoriti tudi v denar.
Za končnega uporabnika je treba izračunati čas obnovitve: kako dolgo se bo lahko prijavil v sistem. Torej najprej seštejemo čas obnovitve vseh členov v verigi. Tukaj pogosto pride do napake: ponudnikov RTO vzamejo iz SLA in pozabijo na preostale pogoje.
Poglejmo konkreten primer. Uporabnik se prijavi v 1C, sistem se odpre z napako baze podatkov. Obrne se na skrbnika sistema. Baza podatkov se nahaja v oblaku, sistemski skrbnik sporoči težavo ponudniku storitev. Recimo, da vsa komunikacija traja 15 minut. V oblaku bo baza podatkov te velikosti obnovljena iz varnostne kopije v eni uri, zato je RTO na strani ponudnika storitev ena ura. A to ni končni rok, uporabniku je dodanih 15 minut za odkrivanje težave.
Nato mora skrbnik sistema preveriti, ali je baza podatkov pravilna, jo povezati z 1C in zagnati storitve. To zahteva še eno uro, kar pomeni, da je RTO na administratorjevi strani že 2 uri in 15 minut. Uporabnik potrebuje še 15 minut: prijavite se, preverite, ali so se pojavile potrebne transakcije. 2 uri 30 minut je skupni čas obnovitve storitve v tem primeru.
Ti izračuni bodo podjetju pokazali, od katerih zunanjih dejavnikov je odvisno obdobje okrevanja. Na primer, če je pisarna poplavljena, morate najprej najti mesto puščanja in ga odpraviti. Potreben bo čas, ki ni odvisen od IT.
Kako se zaščitimo: izbira orodij za različna tveganja
Po razpravi o vseh točkah stranka že razume stroške nesreče za podjetje. Zdaj lahko izberete orodja in razpravljate o proračunu. Na primerih strank vam bom pokazal, katera orodja ponujamo za različne naloge.
Začnimo s prvo skupino tveganj: izgube zaradi izpadov storitev. Rešitve za to težavo bi morale zagotoviti dober RTO.
- Gostite aplikacijo v oblaku
Za začetek se lahko preprosto preselite v oblak - ponudnik je že premislil o vprašanjih visoke razpoložljivosti. Virtualizacijski gostitelji so sestavljeni v gručo, napajanje in omrežje sta rezervirana, podatki so shranjeni na sistemih za shranjevanje, ki so odporni na napake, ponudnik storitev pa je finančno odgovoren za izpade.
Na primer, lahko gostite virtualni stroj z bazo podatkov v oblaku. Aplikacija se bo navzven povezala z bazo preko vzpostavljenega kanala ali iz istega oblaka. Če pride do težav z enim od strežnikov v gruči, se bo VM znova zagnal na sosednjem strežniku v manj kot 2 minutah. Po tem se bo v njem zagnal DBMS in v nekaj minutah bo baza podatkov na voljo.
RTO: merjeno v minutah. Ti pogoji so lahko določeni v pogodbi s ponudnikom.
Stroški: Izračunamo stroške virov v oblaku za vašo aplikacijo.
Pred čim vas ne bo zaščitil: od množičnih okvar na mestu ponudnika, na primer zaradi nesreč na ravni mesta. - Združite aplikacijo v gruče
Če želite izboljšati RTO, lahko okrepite prejšnjo možnost in aplikacijo v gruči takoj postavite v oblak.
Gručo lahko implementirate v aktivno-pasivnem ali aktivno-aktivnem načinu. Izdelamo več VM-jev glede na zahteve prodajalca. Za večjo zanesljivost jih razporedimo po različnih strežnikih in sistemih za shranjevanje. Če strežnik z eno od podatkovnih baz odpove, rezervno vozlišče v nekaj sekundah prevzame obremenitev.
RTO: Merjeno v sekundah.
Stroški: nekoliko dražji od običajnega oblaka, za združevanje v gruče bodo potrebni dodatni viri.
Pred čim vas ne bo zaščitil: Še vedno ne bo zaščitil pred množičnimi okvarami na kraju samem. Toda lokalne motnje ne bodo trajale tako dolgo.Iz prakse: Trgovsko podjetje je imelo več informacijskih sistemov in spletnih strani. Vse baze podatkov so se nahajale lokalno v pisarni podjetja. O DR ni bilo niti pomisliti, dokler pisarna ni večkrat zapored ostala brez elektrike. Stranke so bile nezadovoljne z zrušitvami spletnih strani.
Težava z razpoložljivostjo storitve je bila odpravljena po prehodu v oblak. Poleg tega nam je uspelo optimizirati obremenitev baz podatkov z uravnoteženjem prometa med vozlišči. - Premaknite se v oblak, odporen proti katastrofam
Če želite zagotoviti, da tudi naravna katastrofa na glavnem mestu ne bo motila vašega dela, lahko izberete oblak, odporen na katastrofe.V tej možnosti ponudnik razširi virtualizacijski grozd na 2 podatkovna centra. Stalno sinhrono podvajanje poteka med podatkovnimi centri, ena proti ena. Kanali med podatkovnimi centri so rezervirani in potekajo po različnih poteh, zato se takšna gruča ne boji težav z omrežjem.
RTO: teži k 0.
Stroški: Najdražja možnost oblaka.
Pred čim vas ne bo zaščitil: Ne bo pomagalo proti poškodbam podatkov, pa tudi proti človeškemu faktorju, zato je priporočljivo, da hkrati delate varnostne kopije.Iz prakse: Ena od naših strank je razvila celovit načrt za obnovitev po katastrofi. To je strategija, ki jo je izbral:
- Oblak, odporen na katastrofe, ščiti aplikacijo pred napakami na ravni infrastrukture.
- Dvonivojska varnostna kopija zagotavlja zaščito v primeru človeške napake. Obstajata dve vrsti varnostnih kopij: "hladne" in "vroče". »Hladna« varnostna kopija je v onemogočenem stanju in potrebuje čas za uvedbo. »Vroča« varnostna kopija je že pripravljena za uporabo in se hitreje obnovi. Shranjeno je v posebnem sistemu za shranjevanje. Tretja kopija je posneta na trak in shranjena v drugi sobi.
Enkrat tedensko naročnik testira zaščito in preveri delovanje vseh varnostnih kopij, tudi tistih s traku. Podjetje vsako leto testira celoten oblak, odporen na katastrofe.
- Organizirajte replikacijo na drugo mesto
Druga možnost, kako se izogniti globalnim težavam na glavnem spletnem mestu: zagotoviti geo-rezervacijo. Z drugimi besedami, ustvarite rezervne virtualne stroje na mestu v drugem mestu. Za to so primerne posebne rešitve za DR: v našem podjetju uporabljamo VMware vCloud Availability (vCAV). Z njegovo pomočjo lahko konfigurirate zaščito med več mesti ponudnikov oblaka ali obnovite v oblak z lokalnega mesta. O shemi za delo z vCAV sem že govoril podrobneje .
RPO in RTO: od 5 minut.
Stroški: dražje od prve možnosti, a cenejše od replikacije strojne opreme v oblaku, odpornem proti katastrofam. Cena je sestavljena iz stroška licence vCAV, administrativnih stroškov, stroška virov v oblaku in rezervnih virov po modelu PAYG (10% stroška delovnih virov za izklopljene VM).
Iz prakse: Stranka je hranila 6 virtualnih strojev z različnimi bazami podatkov v našem oblaku v Moskvi. Sprva je bila zaščita zagotovljena z varnostno kopijo: nekaj varnostnih kopij je bilo shranjenih v oblaku v Moskvi, nekaj pa na naši strani v Sankt Peterburgu. Sčasoma so se baze podatkov povečale in obnovitev iz varnostne kopije je začela vzeti več časa.
Podvajanje, ki temelji na razpoložljivosti VMware vCloud, je bilo dodano varnostnim kopijam. Replike virtualnih strojev so shranjene na rezervnem mestu v Sankt Peterburgu in se posodabljajo vsakih 5 minut. Če pride do okvare na glavnem mestu, zaposleni samostojno preklopijo na repliko virtualnega stroja v Sankt Peterburgu in nadaljujejo delo z njim.
Vse obravnavane rešitve zagotavljajo visoko razpoložljivost, vendar ne ščitijo pred izgubo podatkov zaradi virusa ransomware ali naključne napake zaposlenih. V tem primeru bomo potrebovali varnostne kopije, ki bodo zagotovile zahtevani RPO.
5. Ne pozabite na varnostno kopiranje
Vsi vedo, da morate narediti varnostne kopije, tudi če imate najbolj kul rešitev, odporno na nesreče. Zato vas bom samo na kratko spomnil na nekaj točk.
Strogo gledano, varnostno kopiranje ni DR. In zato:
- To je dolgo časa. Če se podatki merijo v terabajtih, bo obnovitev trajala več kot eno uro. Obnoviti morate, dodeliti omrežje, preveriti, ali se vklopi, ali so podatki v redu. Torej lahko zagotovite dober RTO le, če je malo podatkov.
- Podatkov morda ne bo mogoče obnoviti prvič in morate pustiti čas za ponovitev dejanja. Na primer, včasih ne vemo natančno, kdaj so bili podatki izgubljeni. Recimo, da je bila izguba opažena ob 15.00, kopije pa se delajo vsako uro. Od 15.00 pogledamo vse točke okrevanja: 14, 00 in tako naprej. Če je sistem pomemben, poskušamo zmanjšati starost obnovitvene točke. Če pa sveža varnostna kopija ni vsebovala potrebnih podatkov, vzamemo naslednjo točko - to je dodaten čas.
V tem primeru lahko urnik varnostnega kopiranja zagotovi zahtevano RPO. Pri varnostnih kopijah je pomembno zagotoviti geo-rezervacijo v primeru težav z glavnim mestom. Priporočljivo je, da nekatere varnostne kopije shranite ločeno.
Končni načrt za obnovitev po nesreči mora vsebovati vsaj 2 orodji:
- Ena od možnosti 1-4, ki bo zaščitila sisteme pred okvarami in padci.
- Varnostno kopiranje za zaščito podatkov pred izgubo.
Prav tako je vredno poskrbeti za rezervni komunikacijski kanal v primeru izpada glavnega internetnega ponudnika. In - voila! — DR pri minimalnih plačah je že pripravljen.
Vir: www.habr.com