Įsivaizduokite: aptarnaujate didelio prekybos centro IT infrastruktūrą. Mieste pradeda lyti. Pro stogą veržiasi lietaus upeliai, iki kulkšnių vanduo užpildo prekybos patalpas. Tikimės, kad jūsų serverio patalpa nėra rūsyje, kitaip problemų nepavyks išvengti.
Aprašyta istorija yra ne fantazija, o kolektyvinis kelių 2020 m. įvykių aprašymas. Didelėse įmonėse atkūrimo planas arba atkūrimo planas (DRP) šiuo atveju visada yra po ranka. Korporacijose už tai atsako veiklos tęstinumo specialistai. Tačiau vidutinėse ir mažose įmonėse tokių problemų sprendimas tenka IT paslaugoms. Reikia pačiam perprasti verslo logiką, suprasti, kas ir kur gali nepavykti, sugalvoti apsaugą ir ją įgyvendinti.
Puiku, jei IT specialistas gali derėtis su verslu ir aptarti apsaugos poreikį. Tačiau ne kartą mačiau, kaip įmonė sutaupė atkūrimo nelaimės (DR) sprendimu, nes laikė jį nereikalingu. Įvykus nelaimei, ilgas atsigavimas grėsė nuostoliais, o verslas nebuvo pasiruošęs. Galite kartoti kiek norite: „Aš tau taip sakiau“, tačiau IT tarnyba vis tiek turės atkurti paslaugas.
Iš architekto pozicijos aš jums pasakysiu, kaip išvengti šios situacijos. Pirmoje straipsnio dalyje parodysiu parengiamuosius darbus: kaip aptarti tris klausimus su klientu renkantis saugos priemones:
- Ką mes saugome?
- Nuo ko mes saugomės?
- Kiek mes saugome?
Antroje dalyje kalbėsime apie variantus, kaip atsakyti į klausimą: kaip apsiginti. Pateiksiu pavyzdžių, kaip skirtingi klientai kuria savo apsaugą.
Ką mes saugome: svarbiausių verslo funkcijų nustatymas
Ruoštis geriau pradėti nuo veiksmų plano po ekstremalios situacijos aptarimo su verslo klientu. Pagrindinis sunkumas čia yra rasti bendrą kalbą. Klientui dažniausiai nerūpi, kaip veikia IT sprendimas. Jam rūpi, ar tarnyba gali atlikti verslo funkcijas ir atnešti pinigų. Pvz.: jei svetainė veikia, bet neveikia mokėjimo sistema, pajamų iš klientų nėra, o „ekstremistai“ vis tiek yra IT specialistai.
IT specialistui tokiose derybose gali kilti sunkumų dėl kelių priežasčių:
- IT tarnyba iki galo nesuvokia informacinės sistemos vaidmens versle. Pavyzdžiui, jei nėra verslo procesų aprašymo arba skaidraus verslo modelio.
- Ne visas procesas priklauso nuo IT paslaugos. Pavyzdžiui, kai dalį darbų atlieka rangovai, o IT specialistai jiems neturi tiesioginės įtakos.
Pokalbį susisteminčiau taip:
- Verslui aiškiname, kad nelaimingų atsitikimų nutinka visiems, o pasveikimas užtrunka. Geriausia yra parodyti situacijas, kaip tai vyksta ir kokios galimos pasekmės.
- Mes parodome, kad ne viskas priklauso nuo IT paslaugos, tačiau esate pasirengę padėti parengti veiksmų planą savo atsakomybės srityje.
- Verslo kliento prašome atsakyti: jei įvyktų apokalipsė, kurį procesą pirmiausia reikėtų atkurti? Kas ir kaip jame dalyvauja?
Iš įmonės reikia paprasto atsakymo, pavyzdžiui: skambučių centras turi toliau registruoti prašymus 24 valandas per parą, 7 dienas per savaitę.
- Mes prašome vieno ar dviejų sistemos vartotojų išsamiai aprašyti šį procesą.
Jei jūsų įmonė turi, geriau pasitelkti analitiką.Iš pradžių aprašymas gali atrodyti taip: skambučių centras gauna užklausas telefonu, paštu ir žinutėmis iš svetainės. Tada jis įveda juos į 1C per žiniatinklio sąsają, o gamyba tokiu būdu paima juos iš ten.
- Tada žiūrime, kokie techninės ir programinės įrangos sprendimai palaiko šį procesą. Siekdami visapusės apsaugos, atsižvelgiame į tris lygius:
- programos ir sistemos svetainėje (programinės įrangos lygis),
- pati svetainė, kurioje veikia sistemos (infrastruktūros lygis),
- tinklą (jie dažnai apie tai pamiršta).
- Išsiaiškiname galimus gedimo taškus: sistemos mazgus, nuo kurių priklauso paslaugos našumas. Atskirai atkreipiame dėmesį į mazgus, kuriuos palaiko kitos įmonės: telekomunikacijų operatoriai, prieglobos paslaugų teikėjai, duomenų centrai ir pan. Tai atlikę galite grįžti pas verslo klientą kitam žingsniui.
Nuo ko saugome: rizikos
Toliau iš verslo kliento sužinome, nuo kokių rizikų apsisaugome pirmiausia. Visas rizikas galima suskirstyti į dvi grupes:
- laiko praradimas dėl paslaugų prastovos;
- duomenų praradimas dėl fizinio poveikio, žmogiškųjų veiksnių ir kt.
Įmonės bijo prarasti tiek duomenis, tiek laiką – visa tai veda prie pinigų praradimo. Taigi vėl užduodame klausimus kiekvienai rizikos grupei:
- Ar galime įvertinti, kiek kainuoja duomenų praradimas ir laiko praradimas?
- Kokių duomenų negalime prarasti?
- Kur negalime leisti prastovų?
- Kokie įvykiai mums labiausiai tikėtini ir grėsmingiausi?
Po diskusijos suprasime, kaip teikti pirmenybę gedimo taškams.
Kiek mes saugome: RPO ir RTO
Kai aiškūs kritiniai gedimo taškai, apskaičiuojame RTO ir RPO rodiklius.
Leiskite man tai jums priminti RTO (atkūrimo laiko tikslas) — tai leistinas laikas nuo avarijos momento iki visiško paslaugų teikimo atkūrimo. Verslo kalba tai priimtina prastovos laikas. Jei žinome, kiek pinigų atnešė procesas, galime apskaičiuoti nuostolius iš kiekvienos prastovos minutės ir apskaičiuoti priimtinus nuostolius.
RPO (atkūrimo taško tikslas) — galiojantis duomenų atkūrimo taškas. Jis nustato laiką, per kurį galime prarasti duomenis. Verslo požiūriu duomenų praradimas gali užtraukti, pavyzdžiui, baudas. Tokius nuostolius taip pat galima konvertuoti į pinigus.
Galutiniam vartotojui reikia paskaičiuoti atkūrimo laiką: kiek laiko jis galės prisijungti prie sistemos. Taigi pirmiausia susumuojame visų grandinės grandžių atkūrimo laiką. Čia dažnai daroma klaida: jie paima teikėjo RTO iš SLA ir pamiršta apie likusias sąlygas.
Pažvelkime į konkretų pavyzdį. Vartotojas prisijungia prie 1C, sistema atsidaro su duomenų bazės klaida. Jis susisiekia su sistemos administratoriumi. Duomenų bazė yra debesyje, sistemos administratorius praneša apie problemą paslaugų teikėjui. Tarkime, kad visas bendravimas trunka 15 minučių. Debesyje tokio dydžio duomenų bazė iš atsarginės kopijos bus atkurta per valandą, todėl paslaugų teikėjo pusėje RTO yra valanda. Tačiau tai nėra galutinis terminas; vartotojui buvo pridėta 15 minučių, kad nustatytų problemą.
Tada sistemos administratorius turi patikrinti, ar duomenų bazė yra teisinga, prijungti ją prie 1C ir paleisti paslaugas. Tam reikia dar valandos, vadinasi, RTO iš administratoriaus pusės jau yra 2 valandos ir 15 minučių. Vartotojui reikia dar 15 minučių: prisijunkite, patikrinkite, ar atsirado reikiamos operacijos. Šiame pavyzdyje visas paslaugos atkūrimo laikas yra 2 valandos 30 minučių.
Šie skaičiavimai parodys, nuo kokių išorinių veiksnių priklauso atkūrimo laikotarpis. Pavyzdžiui, jei biuras užtvindytas, pirmiausia reikia rasti nuotėkį ir jį sutvarkyti. Tai užtruks, o tai nepriklauso nuo IT.
Kaip mes saugome: pasirenkame priemones įvairioms rizikoms
Aptaręs visus punktus, klientas jau supranta nelaimingo atsitikimo kainą verslui. Dabar galite pasirinkti įrankius ir aptarti biudžetą. Remdamasis klientų atvejų pavyzdžiais, parodysiu, kokius įrankius siūlome įvairioms užduotims atlikti.
Pradėkime nuo pirmosios rizikos grupės: nuostoliai dėl paslaugų prastovos. Šios problemos sprendimai turėtų užtikrinti gerą RTO.
- Priglobkite programą debesyje
Pirmiausia galite tiesiog pereiti prie debesies - teikėjas jau apgalvojo aukšto prieinamumo problemas. Virtualizacijos kompiuteriai surenkami į klasterį, rezervuojama maitinimas ir tinklas, duomenys saugomi gedimams atspariose saugojimo sistemose, o paslaugų teikėjas yra finansiškai atsakingas už prastovą.
Pavyzdžiui, galite talpinti virtualią mašiną su duomenų baze debesyje. Programa prisijungs prie duomenų bazės išoriškai per nustatytą kanalą arba iš to paties debesies. Jei iškyla problemų su vienu iš klasterio serverių, VM bus paleistas iš naujo kaimyniniame serveryje greičiau nei per 2 minutes. Po to jame bus paleista DBVS, o po kelių minučių duomenų bazė taps prieinama.
OTR: matuojama minutėmis. Šios sąlygos gali būti nurodytos sutartyje su teikėju.
Kaina: apskaičiuojame debesies išteklių kainą jūsų programai.
Nuo ko neapsaugos: dėl didžiulių gedimų teikėjo svetainėje, pavyzdžiui, dėl nelaimingų atsitikimų mieste. - Sugrupuokite programą
Jei norite patobulinti RTO, galite sustiprinti ankstesnę parinktį ir nedelsdami įdėti į debesį sugrupuotą programą.
Klasterį galite įdiegti aktyviu-pasyviu arba aktyviu-aktyviu režimu. Kuriame keletą VM pagal tiekėjo reikalavimus. Siekdami didesnio patikimumo juos platiname skirtinguose serveriuose ir saugojimo sistemose. Jei serveris su viena iš duomenų bazių sugenda, atsarginis mazgas perima apkrovą per kelias sekundes.
OTR: Matuojama sekundėmis.
Kaina: šiek tiek brangesnis nei įprastas debesis, klasterizavimui reikės papildomų resursų.
Nuo ko neapsaugos: Vis tiek neapsaugos nuo didžiulių gedimų vietoje. Tačiau vietiniai sutrikimai truks neilgai.Iš praktikos: Mažmeninės prekybos įmonė turėjo keletą informacinių sistemų ir interneto svetainių. Visos duomenų bazės buvo lokaliai įmonės biure. Apie jokią DR nebuvo galvojama tol, kol biuras kelis kartus iš eilės liko be elektros. Klientai buvo nepatenkinti svetainės gedimais.
Paslaugos prieinamumo problema buvo išspręsta persikėlus į debesį. Be to, mums pavyko optimizuoti duomenų bazių apkrovą subalansuojant srautą tarp mazgų. - Perkelkite į nelaimėms atsparų debesį
Jei jums reikia užtikrinti, kad net stichinė nelaimė pagrindinėje svetainėje netrukdytų jūsų darbui, galite pasirinkti nelaimėms atsparų debesį. Šiuo atveju teikėjas paskirsto virtualizacijos klasterį per 2 duomenų centrus. Nuolatinis sinchroninis replikavimas tarp duomenų centrų, vienas su vienu. Kanalai tarp duomenų centrų yra rezervuoti ir eina skirtingais maršrutais, todėl toks klasteris nebijo tinklo problemų.
OTR: linkęs į 0.
Kaina: Brangiausias debesies pasirinkimas.
Nuo ko neapsaugos: Tai nepadės nuo duomenų sugadinimo, kaip ir nuo žmogiškojo faktoriaus, todėl rekomenduojama tuo pačiu pasidaryti atsargines kopijas.Iš praktikos: Vienas iš mūsų klientų sukūrė išsamų atkūrimo planą nelaimės atveju. Štai kokią strategiją jis pasirinko:
- Nelaimėms atsparus debesis apsaugo programą nuo gedimų infrastruktūros lygiu.
- Dviejų lygių atsarginė kopija užtikrina apsaugą žmogiškosios klaidos atveju. Yra dviejų tipų atsarginės kopijos: „šaltas“ ir „karštas“. „Šalta“ atsarginė kopija yra išjungta ir užtrunka, kol ji įdiegiama. „Karšta“ atsarginė kopija jau paruošta naudoti ir atkuriama greičiau. Jis saugomas specialiai tam skirtoje saugojimo sistemoje. Trečia kopija įrašoma į juostą ir saugoma kitoje patalpoje.
Kartą per savaitę klientas išbando apsaugą ir patikrina visų atsarginių kopijų, įskaitant iš juostos, funkcionalumą. Kiekvienais metais įmonė išbando visą nelaimėms atsparų debesį.
- Tvarkykite replikaciją į kitą svetainę
Kitas variantas, kaip išvengti globalių problemų pagrindinėje svetainėje: pateikti geografinę rezervaciją. Kitaip tariant, sukurkite atsargines virtualias mašinas kito miesto svetainėje. Tam tinka specialūs DR sprendimai: mūsų įmonėje naudojame VMware vCloud Availability (vCAV). Su jo pagalba galite konfigūruoti apsaugą tarp kelių debesies paslaugų teikėjų svetainių arba atkurti į debesį iš vietinės svetainės. Aš jau kalbėjau išsamiau apie darbo su vCAV schemą .
RPO ir RTO: nuo 5 minučių.
Kaina: brangesnis nei pirmasis variantas, bet pigesnis nei aparatinės įrangos replikacija nelaimėms atspariame debesyje. Kainą sudaro vCAV licencijos kaina, administravimo mokesčiai, debesų išteklių kaina ir rezerviniai resursai pagal PAYG modelį (10% išjungtų VM darbo resursų kainos).
Iš praktikos: Klientas mūsų debesyje Maskvoje laikė 6 virtualias mašinas su skirtingomis duomenų bazėmis. Iš pradžių apsaugą užtikrino atsarginė kopija: dalis atsarginių kopijų buvo saugomos debesyje Maskvoje, o dalis – mūsų Sankt Peterburgo svetainėje. Laikui bėgant duomenų bazių dydis augo, o atkūrimas iš atsarginės kopijos pradėjo užtrukti ilgiau.
Prie atsarginių kopijų buvo pridėta replikacija, pagrįsta VMware vCloud prieinamumu. Virtualių mašinų kopijos saugomos atsarginėje svetainėje Sankt Peterburge ir atnaujinamos kas 5 minutes. Jei pagrindinėje vietoje įvyksta gedimas, darbuotojai savarankiškai pereina prie Sankt Peterburgo virtualios mašinos kopijos ir toliau su ja dirba.
Visi apsvarstyti sprendimai užtikrina aukštą pasiekiamumą, tačiau neapsaugo nuo duomenų praradimo dėl išpirkos reikalaujančio viruso ar atsitiktinės darbuotojo klaidos. Tokiu atveju mums reikės atsarginių kopijų, kurios suteiks reikiamą RPO.
5. Nepamirškite apie atsarginę kopiją
Visi žino, kad reikia kurti atsargines kopijas, net jei turite šauniausią nelaimėms atsparų sprendimą. Taigi tik trumpai priminsiu keletą dalykų.
Griežtai kalbant, atsarginė kopija nėra DR. Ir štai kodėl:
- Tai ilgas laikas. Jei duomenys matuojami terabaitais, atkūrimas užtruks ilgiau nei vieną valandą. Reikia atkurti, priskirti tinklą, patikrinti, ar jis įsijungia, žiūrėti, ar duomenys tvarkingi. Taigi galite pateikti gerą RTO tik tada, kai yra mažai duomenų.
- Pirmą kartą duomenys gali būti neatstatyti, todėl reikia skirti laiko veiksmui pakartoti. Pavyzdžiui, kartais tiksliai nežinome, kada duomenys buvo prarasti. Tarkime, praradimas pastebėtas 15.00 val., o kopijos daromos kas valandą. Nuo 15.00 žiūrime į visus atkūrimo taškus: 14:00, 13:00 ir pan. Jei sistema svarbi, stengiamės sumažinti atkūrimo taško amžių. Bet jei naujoje atsarginėje kopijoje nebuvo reikiamų duomenų, imame kitą tašką - tai yra papildomas laikas.
Tokiu atveju atsarginių kopijų tvarkaraštis gali pateikti reikiamą RPO. Dėl atsarginių kopijų svarbu numatyti geografinį rezervavimą, jei kiltų problemų dėl pagrindinės svetainės. Kai kurias atsargines kopijas rekomenduojama saugoti atskirai.
Galutiniame atkūrimo po nelaimių plane turėtų būti bent 2 įrankiai:
- Vienas iš 1-4 variantų, kuris apsaugos sistemas nuo gedimų ir kritimų.
- Atsarginė kopija, kad apsaugotumėte duomenis nuo praradimo.
Taip pat verta pasirūpinti atsarginiu ryšio kanalu tuo atveju, jei sugestų pagrindinis interneto tiekėjas. Ir - voila! — DR prie minimalių atlyginimų jau paruošta.
Šaltinis: www.habr.com