Čak i ako je poplava, 1C bi trebao raditi! Slažemo se s poslovanjem na DR

Zamislite: servisirate IT infrastrukturu velikog trgovačkog centra. U gradu počinje padati kiša. Potoci kiše probijaju se kroz krov, voda puni maloprodajne prostore do gležnja. Nadamo se da vaša poslužiteljska soba nije u podrumu, inače se problemi ne mogu izbjeći.  

Opisana priča nije fantazija, već skupni opis nekoliko događaja iz 2020. U velikim tvrtkama plan oporavka od katastrofe ili plan oporavka od katastrofe (DRP) uvijek je pri ruci za ovaj slučaj. U korporacijama, to je odgovornost stručnjaka za kontinuitet poslovanja. Ali u srednjim i malim tvrtkama rješavanje takvih problema pada na IT usluge. Morate sami razumjeti poslovnu logiku, razumjeti što može zakazati i gdje, osmisliti zaštitu i implementirati je. 

Sjajno je ako IT stručnjak može pregovarati s tvrtkom i razgovarati o potrebi zaštite. Ali više sam puta vidio kako je tvrtka škrtarila na rješenju za oporavak od katastrofe (DR) jer ga je smatrala suvišnim. Kad bi se dogodila nesreća, dugi oporavak prijetio je gubicima, a posao nije bio spreman. Možete ponavljati koliko god želite: “Rekao sam ti”, ali IT služba će ipak morati vratiti usluge.

S pozicije arhitekta, reći ću vam kako izbjeći ovu situaciju. U prvom dijelu članka pokazat ću pripremni rad: kako razgovarati s kupcem o tri pitanja za odabir sigurnosnih alata: 

• Što štitimo?
• Od čega se štitimo?
• Koliko štitimo? 

U drugom dijelu govorit ćemo o mogućnostima odgovora na pitanje: kako se obraniti. Navest ću primjere slučajeva kako različiti kupci grade svoju zaštitu.

Što štitimo: prepoznavanje kritičnih poslovnih funkcija 

Bolje je započeti s pripremom raspravom o akcijskom planu nakon hitne situacije s poslovnim korisnikom. Glavna poteškoća ovdje je pronaći zajednički jezik. Kupca obično ne zanima kako IT rješenje radi. Njega zanima može li služba obavljati poslovne funkcije i donositi novac. Na primjer: ako stranica radi, ali sustav plaćanja nije u funkciji, nema prihoda od klijenata, a "ekstremisti" su još uvijek IT stručnjaci. 

IT stručnjak može imati poteškoća u takvim pregovorima iz nekoliko razloga:

• IT služba ne razumije u potpunosti ulogu informacijskog sustava u poslovanju. Na primjer, ako nema dostupnog opisa poslovnih procesa ili transparentnog poslovnog modela. 
• Ne ovisi cijeli proces o IT usluzi. Primjerice, kada dio posla obavljaju izvođači, a informatičari nemaju izravan utjecaj na njih.

Ja bih strukturirao razgovor ovako: 

1. Objašnjavamo tvrtkama da se nesreće događaju svima, a oporavak zahtijeva vrijeme. Najbolje je pokazati situacije, kako se to događa i kakve su posljedice moguće.
2. Pokazujemo da ne ovisi sve o IT službi, ali ste spremni pomoći akcijskim planom u svom području odgovornosti.
3. Molimo poslovnog korisnika da odgovori: ako se dogodi apokalipsa, koji proces treba prvo obnoviti? Tko i kako u tome sudjeluje? 

   Od poduzeća se traži jednostavan odgovor, na primjer: pozivni centar treba nastaviti prijavljivati ​​prijave 24/7.

4. Molimo jednog ili dva korisnika sustava da detaljno opišu ovaj proces. 
   Bolje je za pomoć uključiti analitičara ako ga vaša tvrtka ima.

   Za početak, opis može izgledati ovako: pozivni centar prima zahtjeve telefonom, poštom i porukama s web stranice. Zatim ih preko web sučelja unosi u 1C, a proizvodnja ih na taj način preuzima od tamo.

5. Zatim gledamo koja hardverska i softverska rješenja podržavaju proces. Za sveobuhvatnu zaštitu uzimamo u obzir tri razine: 
   • aplikacije i sustavi unutar stranice (softverska razina),   
   • samo mjesto gdje se sustavi izvode (razina infrastrukture), 
   • mrežu (na to često zaborave).

6. Otkrivamo moguće točke kvara: čvorove sustava o kojima ovisi izvedba usluge. Posebno izdvajamo čvorove koje podržavaju druge tvrtke: telekom operateri, pružatelji usluga hostinga, podatkovni centri i tako dalje. S tim se možete vratiti poslovnom korisniku za sljedeći korak.

Od čega se štitimo: rizici

Zatim od poslovnog kupca doznajemo od kojih se rizika prvo štitimo. Svi rizici mogu se podijeliti u dvije skupine: 

• gubitak vremena zbog prekida usluge;
• gubitak podataka uslijed fizičkih utjecaja, ljudskog faktora itd.

Poduzeća se boje gubitka podataka i vremena - sve to dovodi do gubitka novca. Stoga ponovno postavljamo pitanja za svaku rizičnu skupinu: 

• Za ovaj proces, možemo li procijeniti koliko gubitak podataka i gubitak vremena koštaju u novcu? 
• Koje podatke ne smijemo izgubiti? 
• Gdje ne možemo dopustiti zastoje? 
• Koji nam događaji najvjerojatnije i najviše prijete?

Nakon rasprave, razumjet ćemo kako odrediti prioritete točaka neuspjeha. 

Koliko štitimo: RPO i RTO 

Kada su kritične točke kvara jasne, izračunavamo RTO i RPO indikatore. 

Sjećam se da RTO (cilj vremena oporavka) — ovo je dopušteno vrijeme od trenutka nesreće do potpunog uspostavljanja usluge. Poslovnim jezikom, to je prihvatljivo vrijeme zastoja. Ako znamo koliko je novaca proces donio, možemo izračunati gubitke od svake minute zastoja i izračunati prihvatljiv gubitak. 

RPO (cilj točke oporavka) — važeća točka za oporavak podataka. Određuje vrijeme tijekom kojeg možemo izgubiti podatke. S poslovne točke gledišta, gubitak podataka može rezultirati novčanim kaznama, na primjer. Takvi se gubici također mogu pretvoriti u novac. 

Za krajnjeg korisnika potrebno je izračunati vrijeme oporavka: koliko dugo će se moći prijaviti u sustav. Dakle, prvo zbrojimo vrijeme oporavka svih karika u lancu. Ovdje se često radi pogreška: uzimaju RTO pružatelja iz SLA-a, a zaboravljaju na preostale uvjete.

Pogledajmo konkretan primjer. Korisnik se prijavljuje u 1C, sustav se otvara s pogreškom baze podataka. Kontaktira administratora sustava. Baza se nalazi u oblaku, administrator sustava prijavljuje problem davatelju usluge. Recimo da sva komunikacija traje 15 minuta. U oblaku će baza podataka ove veličine biti vraćena iz sigurnosne kopije za sat vremena, stoga je RTO na strani pružatelja usluga sat vremena. Ali to nije krajnji rok, korisniku je dodano 15 minuta za otkrivanje problema. 
 
Zatim administrator sustava treba provjeriti je li baza podataka ispravna, povezati je s 1C i pokrenuti usluge. To zahtijeva još jedan sat, što znači da je RTO na strani administratora već 2 sata i 15 minuta. Korisniku treba još 15 minuta: prijaviti se, provjeriti jesu li se pojavile potrebne transakcije. 2 sata i 30 minuta je ukupno vrijeme oporavka usluge u ovom primjeru.

Ti će izračuni pokazati poslovanju o kojim vanjskim čimbenicima ovisi razdoblje oporavka. Na primjer, ako je ured poplavljen, prvo morate pronaći mjesto curenja i popraviti ga. Trebat će vremena, koje ne ovisi o IT-u.  

Kako se štitimo: odabir alata za različite rizike

Nakon rasprave o svim točkama, kupac već razumije cijenu nezgode za tvrtku. Sada možete odabrati alate i razgovarati o proračunu. Koristeći primjere slučajeva klijenata, pokazat ću vam koje alate nudimo za različite zadatke. 

Započnimo s prvom skupinom rizika: gubici zbog prekida usluge. Rješenja za ovaj problem trebala bi pružiti dobar RTO.

1. Host aplikacije u oblaku 

   Za početak, možete se jednostavno preseliti u oblak - pružatelj je već razmislio o pitanjima visoke dostupnosti. Virtualizacijski hostovi su sastavljeni u klaster, napajanje i mreža su rezervirani, podaci se pohranjuju na sustave za pohranu otporne na greške, a pružatelj usluge je financijski odgovoran za zastoje.

   Na primjer, možete ugostiti virtualni stroj s bazom podataka u oblaku. Aplikacija će se eksterno povezati s bazom podataka putem uspostavljenog kanala ili iz istog oblaka. Ako dođe do problema s jednim od poslužitelja u klasteru, VM će se ponovno pokrenuti na susjednom poslužitelju za manje od 2 minute. Nakon toga će se u njemu pokrenuti DBMS, a za nekoliko minuta baza će postati dostupna.

   OTR: mjereno u minutama. Ovi uvjeti mogu biti navedeni u ugovoru s pružateljem usluga.
   trošak: Izračunavamo troškove resursa u oblaku za vašu aplikaciju. 
   Od čega vas neće zaštititi: od masovnih kvarova na mjestu pružatelja, na primjer, zbog nesreća na razini grada.

2. Grupirajte aplikaciju  

   Ako želite poboljšati RTO, možete pojačati prethodnu opciju i odmah smjestiti klasteriranu aplikaciju u oblak.

   Možete implementirati klaster u aktivno-pasivnom ili aktivno-aktivnom načinu rada. Izrađujemo nekoliko VM-ova na temelju zahtjeva dobavljača. Radi veće pouzdanosti, distribuiramo ih na različite poslužitelje i sustave za pohranu. Ako poslužitelj s jednom od baza podataka zakaže, rezervni čvor za nekoliko sekundi preuzima opterećenje.

   OTR: Mjereno u sekundama.
   trošak: nešto skuplji od običnog oblaka, bit će potrebni dodatni resursi za klasteriranje.
   Od čega vas neće zaštititi: Još uvijek ne štiti od masivnih kvarova na licu mjesta. Ali lokalni poremećaji neće tako dugo trajati.

   Iz prakse: Maloprodajna tvrtka imala je nekoliko informacijskih sustava i web stranica. Sve baze podataka bile su smještene lokalno u uredu tvrtke. O DR-u se nije razmišljalo sve dok ured nekoliko puta zaredom nije ostao bez struje. Korisnici su bili nezadovoljni padom web stranice. 
    
   Problem s dostupnošću usluge je riješen nakon prelaska u oblak. Osim toga, uspjeli smo optimizirati opterećenje baza podataka balansiranjem prometa između čvorova.

3. Prijeđite na oblak otporan na katastrofe

   Ako trebate osigurati da rad ne bude prekinut ni prirodnom katastrofom na glavnom mjestu, možete odabrati oblak otporan na katastrofe. U ovoj opciji pružatelj širi virtualizacijski klaster na 2 podatkovna centra. Konstantna sinkrona replikacija događa se između podatkovnih centara, jedan na jedan. Kanali između podatkovnih centara su rezervirani i idu različitim rutama, tako da se takav klaster ne boji mrežnih problema. 

   OTR: teži 0.
   trošak: Najskuplja opcija oblaka. 
   Od čega vas neće zaštititi: Neće pomoći protiv oštećenja podataka, kao ni od ljudskog faktora, stoga je preporučljivo napraviti sigurnosne kopije u isto vrijeme. 

   Iz prakse: Jedan od naših klijenata razvio je opsežan plan oporavka od katastrofe. Ovo je strategija koju je odabrao: 

   • Oblak otporan na katastrofe štiti aplikaciju od kvarova na razini infrastrukture. 
   • Sigurnosna kopija na dvije razine pruža zaštitu u slučaju ljudske pogreške. Postoje dvije vrste sigurnosnih kopija: "hladne" i "vruće". "Hladna" sigurnosna kopija je u onemogućenom stanju i treba joj vremena da se implementira. “Vruća” sigurnosna kopija već je spremna za upotrebu i brže se obnavlja. Pohranjuje se na posebno namjenskom sustavu skladištenja. Treća kopija se snima na kasetu i pohranjuje u drugu prostoriju. 

   Klijent jednom tjedno testira zaštitu i provjerava funkcionalnost svih backupa, uključujući i one s trake. Svake godine tvrtka testira cijeli oblak otporan na katastrofe. 

4. Organizirajte replikaciju na drugu stranicu 

   Još jedna opcija kako izbjeći globalne probleme na glavnoj stranici: osigurati geo-rezervaciju. Drugim riječima, stvorite rezervne virtualne strojeve na mjestu u drugom gradu. Za to su prikladna posebna rješenja za DR: u našoj tvrtki koristimo VMware vCloud Availability (vCAV). Uz njegovu pomoć možete konfigurirati zaštitu između nekoliko web-mjesta pružatelja usluga oblaka ili se vratiti u oblak s lokalnog web-mjesta. Već sam detaljnije govorio o shemi za rad s vCAV-om ovdje. 

   RPO i RTO: od 5 minuta. 

   trošak: skuplje od prve opcije, ali jeftinije od hardverske replikacije u oblaku otpornom na katastrofe. Cijena se sastoji od troška vCAV licence, administrativnih naknada, troška cloud resursa i rezervnih resursa po PAYG modelu (10% troška radnih resursa za isključene VM).

   Iz prakse: Klijent je držao 6 virtualnih strojeva s različitim bazama podataka u našem oblaku u Moskvi. U početku je zaštita bila osigurana sigurnosnom kopijom: neke od sigurnosnih kopija bile su pohranjene u oblaku u Moskvi, a neke su bile pohranjene na našoj stranici u Sankt Peterburgu. S vremenom su baze podataka rasle u veličini, a vraćanje iz sigurnosne kopije počelo je zahtijevati više vremena. 
    
   Replikacija temeljena na dostupnosti VMware vCloud dodana je sigurnosnim kopijama. Replike virtualnih strojeva pohranjene su na rezervnom mjestu u St. Petersburgu i ažuriraju se svakih 5 minuta. Ako dođe do kvara na glavnom mjestu, zaposlenici se samostalno prebacuju na repliku virtualnog stroja u St. Petersburgu i nastavljaju raditi s njim. 

Sva razmatrana rješenja pružaju visoku dostupnost, ali ne štite od gubitka podataka zbog ransomware virusa ili slučajne pogreške zaposlenika. U ovom slučaju trebat će nam sigurnosne kopije koje će osigurati traženi RPO.

5. Ne zaboravite na sigurnosnu kopiju

Svi znaju da morate napraviti sigurnosne kopije, čak i ako imate najbolje rješenje otporno na katastrofe. Stoga ću vas samo ukratko podsjetiti na nekoliko točaka.

Strogo govoreći, backup nije DR. I zato: 

• To je dugo vrijeme. Ako se podaci mjere u terabajtima, oporavak će trajati više od jednog sata. Morate vratiti, dodijeliti mrežu, provjeriti uključuje li se, vidjeti jesu li podaci u redu. Dakle, možete pružiti dobar RTO samo ako ima malo podataka. 
• Podaci se možda neće moći vratiti prvi put i morate ostaviti vremena za ponavljanje radnje. Na primjer, postoje trenuci kada ne znamo točno kada su podaci izgubljeni. Recimo, gubitak je uočen u 15.00 sati, a kopiranje se radi svaki sat. Od 15.00 gledamo sve točke oporavka: 14, 00 i tako dalje. Ako je sustav važan, pokušavamo minimizirati starost točke oporavka. Ali ako nova sigurnosna kopija nije sadržavala potrebne podatke, uzimamo sljedeću točku - ovo je dodatno vrijeme. 

U ovom slučaju, rezervni raspored može pružiti potrebno RPO. Za sigurnosne kopije, važno je osigurati geo-rezervaciju u slučaju problema s glavnom stranicom. Preporuča se odvojeno pohraniti neke sigurnosne kopije.

Konačni plan oporavka od katastrofe trebao bi sadržavati najmanje 2 alata:  

• Jedna od opcija 1-4, koja će zaštititi sustave od kvarova i padova.
• Sigurnosna kopija za zaštitu podataka od gubitka. 

Također je vrijedno pobrinuti se za rezervni komunikacijski kanal u slučaju da glavni internetski davatelj usluga padne. I – voila! — DR na minimalnim plaćama je već spreman. 

Izvor: www.habr.com