Selvom det er en oversvømmelse, burde 1C fungere! Vi er enige med forretningen på DR

Forestil dig: du servicerer IT-infrastrukturen i et stort indkøbscenter. Det begynder at regne i byen. Regnstrømme bryder gennem taget, vand fylder butikslokaler helt ned til ankel. Vi håber, at dit serverrum ikke er i kælderen, ellers kan problemer ikke undgås.  

Den beskrevne historie er ikke en fantasi, men en samlet beskrivelse af et par begivenheder i 2020. I store virksomheder er en disaster recovery plan, eller disaster recovery plan (DRP), altid klar til denne sag. I virksomheder er dette ansvar for forretningskontinuitetsspecialister. Men i mellemstore og små virksomheder falder løsningen af ​​sådanne problemer på it-tjenester. Du skal selv forstå forretningslogikken, forstå hvad der kan fejle og hvor, komme med beskyttelse og implementere det. 

Det er fantastisk, hvis en it-specialist kan forhandle med virksomheden og diskutere behovet for beskyttelse. Men jeg har set mere end én gang, hvordan en virksomhed sparede på en disaster recovery-løsning (DR), fordi den fandt den overflødig. Når en ulykke skete, truede en lang bedring med tab, og virksomheden var ikke klar. Du kan gentage så meget, du vil: "Jeg fortalte dig det," men it-tjenesten skal stadig gendanne tjenester.

Fra en arkitekts position vil jeg fortælle dig, hvordan du undgår denne situation. I den første del af artiklen vil jeg vise det forberedende arbejde: hvordan man diskuterer tre spørgsmål med kunden til valg af sikkerhedsværktøjer: 

• Hvad beskytter vi?
• Hvad beskytter vi mod?
• Hvor meget beskytter vi? 

I den anden del vil vi tale om muligheder for at besvare spørgsmålet: hvordan man forsvarer sig selv. Jeg vil give eksempler på cases på, hvordan forskellige kunder opbygger deres beskyttelse.

Hvad vi beskytter: identifikation af kritiske forretningsfunktioner 

Det er bedre at begynde at forberede sig ved at drøfte handlingsplanen efter en nødsituation med erhvervskunden. Den største vanskelighed her er at finde et fælles sprog. Kunden er som regel ligeglad med, hvordan it-løsningen fungerer. Han bekymrer sig om, hvorvidt tjenesten kan udføre forretningsfunktioner og indbringe penge. For eksempel: Hvis siden fungerer, men betalingssystemet er nede, er der ingen indtægter fra kunder, og "ekstremisterne" er stadig it-specialister. 

En it-professionel kan have svært ved sådanne forhandlinger af flere årsager:

• IT-servicen forstår ikke helt informationssystemets rolle i erhvervslivet. For eksempel hvis der ikke er en tilgængelig beskrivelse af forretningsprocesser eller en gennemsigtig forretningsmodel. 
• Ikke hele processen afhænger af it-servicen. Eksempelvis når en del af arbejdet udføres af entreprenører, og it-specialister ikke har direkte indflydelse på dem.

Jeg vil strukturere samtalen sådan her: 

1. Vi forklarer virksomhederne, at ulykker sker for alle, og genopretning tager tid. Det bedste er at demonstrere situationer, hvordan dette sker, og hvilke konsekvenser der er mulige.
2. Vi viser, at ikke alt afhænger af it-servicen, men du er klar til at hjælpe med en handlingsplan inden for dit ansvarsområde.
3. Vi beder erhvervskunden svare: hvis apokalypsen sker, hvilken proces skal genoprettes først? Hvem deltager i det og hvordan? 

   Der kræves et enkelt svar fra virksomheden, for eksempel: Callcenteret skal fortsætte med at registrere ansøgninger 24/7.

4. Vi beder en eller to brugere af systemet om at beskrive denne proces i detaljer. 
   Det er bedre at inddrage en analytiker til at hjælpe, hvis din virksomhed har en.

   Til at begynde med kan beskrivelsen se sådan ud: Callcentret modtager forespørgsler via telefon, mail og via beskeder fra hjemmesiden. Så indtaster han dem i 1C via webgrænsefladen, og produktionen tager dem derfra på denne måde.

5. Derefter ser vi på, hvilke hardware- og softwareløsninger der understøtter processen. For omfattende beskyttelse tager vi højde for tre niveauer: 
   • applikationer og systemer på webstedet (softwareniveau),   
   • selve webstedet, hvor systemerne kører (infrastrukturniveau), 
   • netværk (de glemmer det ofte).

6. Vi finder ud af mulige fejlpunkter: systemknudepunkter, som ydelsen af ​​tjenesten afhænger af. Vi noterer særskilt noder, der understøttes af andre virksomheder: teleoperatører, hostingudbydere, datacentre og så videre. Hermed kan du vende tilbage til erhvervskunden for det næste trin.

Hvad vi beskytter mod: risici

Dernæst finder vi først ud af erhvervskunden, hvilke risici vi beskytter os mod. Alle risici kan opdeles i to grupper: 

• tab af tid på grund af driftsnedetid;
• tab af data på grund af fysiske påvirkninger, menneskelige faktorer mv.

Virksomheder er bange for at miste både data og tid – alt dette fører til tab af penge. Så igen stiller vi spørgsmål til hver risikogruppe: 

• Til denne proces, kan vi estimere, hvor meget datatab og tidstab koster i penge? 
• Hvilke data kan vi ikke miste? 
• Hvor kan vi ikke tillade nedetid? 
• Hvilke begivenheder er mest sandsynlige og mest truende for os?

Efter diskussion vil vi forstå, hvordan man prioriterer fejlpunkter. 

Hvor meget beskytter vi: RPO og RTO 

Når de kritiske fejlpunkter er klare, beregner vi RTO- og RPO-indikatorerne. 

Lad mig minde dig om det RTO (recovery time goal) — dette er den tilladte tid fra ulykkesøjeblikket, indtil tjenesten er fuldstændig genoprettet. På forretningssprog er dette acceptabel nedetid. Hvis vi ved, hvor mange penge processen indbragte, kan vi beregne tabene fra hvert minuts nedetid og beregne det acceptable tab. 

RPO (recovery point goal) — gyldigt datagendannelsespunkt. Det bestemmer den tid, hvor vi kan miste data. Fra et forretningsmæssigt synspunkt kan tab af data f.eks. medføre bøder. Sådanne tab kan også konverteres til penge. 

Gendannelsestiden skal beregnes for slutbrugeren: hvor længe vil han være i stand til at logge på systemet. Så først summerer vi restitutionstiden for alle led i kæden. Der begås ofte en fejl her: de tager udbyderens RTO fra SLA'en og glemmer de resterende vilkår.

Lad os se på et specifikt eksempel. Brugeren logger på 1C, systemet åbner med en databasefejl. Han kontakter systemadministratoren. Databasen er placeret i skyen, systemadministratoren rapporterer problemet til tjenesteudbyderen. Lad os sige, at al kommunikation tager 15 minutter. I skyen vil en database af denne størrelse blive gendannet fra en sikkerhedskopi på en time, derfor er RTO'en på tjenesteudbydersiden en time. Men dette er ikke den endelige deadline; for brugeren er der tilføjet 15 minutter til at opdage problemet. 
 
Dernæst skal systemadministratoren kontrollere, at databasen er korrekt, tilslutte den til 1C og starte tjenesterne. Dette kræver yderligere en time, hvilket betyder, at RTO på administrators side allerede er 2 timer og 15 minutter. Brugeren har brug for yderligere 15 minutter: log ind, tjek at de nødvendige transaktioner er dukket op. 2 timer 30 minutter er den samlede servicegendannelsestid i dette eksempel.

Disse beregninger vil vise virksomheden på hvilke eksterne faktorer genopretningsperioden afhænger. Hvis kontoret for eksempel er oversvømmet, skal du først finde lækagen og rette den. Det vil tage tid, som ikke afhænger af IT.  

Sådan beskytter vi: valg af værktøjer til forskellige risici

Efter at have diskuteret alle punkter, forstår kunden allerede omkostningerne ved en ulykke for virksomheden. Nu kan du vælge værktøjer og diskutere budgettet. Ved hjælp af eksempler på kundecases vil jeg vise dig, hvilke værktøjer vi tilbyder til forskellige opgaver. 

Lad os starte med den første gruppe af risici: tab på grund af nedetid. Løsninger på dette problem bør give god RTO.

1. Host applikationen i skyen 

   Til at begynde med kan du blot flytte til skyen - udbyderen har allerede gennemtænkt problemerne med høj tilgængelighed. Virtualiseringsværter samles i en klynge, strøm og netværk reserveres, data lagres på fejltolerante lagersystemer, og tjenesteudbyderen er økonomisk ansvarlig for nedetid.

   For eksempel kan du hoste en virtuel maskine med en database i skyen. Applikationen vil oprette forbindelse til databasen eksternt via en etableret kanal eller fra samme sky. Hvis der opstår problemer med en af ​​serverne i klyngen, genstarter VM'en på naboserveren på mindre end 2 minutter. Derefter starter DBMS'en op i den, og i løbet af få minutter bliver databasen tilgængelig.

   RTO: målt i minutter. Disse vilkår kan specificeres i aftalen med udbyderen.
   Omkostninger: Vi beregner omkostningerne ved cloud-ressourcer til din applikation. 
   Hvad det ikke vil beskytte dig mod: fra massive fejl på udbyderens websted, for eksempel på grund af ulykker på byniveau.

2. Klynge applikationen  

   Hvis du vil forbedre RTO, kan du styrke den tidligere mulighed og straks placere en klynget applikation i skyen.

   Du kan implementere en klynge i aktiv-passiv eller aktiv-aktiv tilstand. Vi opretter flere VM'er baseret på leverandørens krav. For større pålidelighed distribuerer vi dem på tværs af forskellige servere og lagersystemer. Hvis serveren med en af ​​databaserne fejler, overtager backup-noden belastningen på få sekunder.

   RTO: Målt i sekunder.
   Omkostninger: lidt dyrere end en almindelig sky, vil der være behov for yderligere ressourcer til klyngedannelse.
   Hvad det ikke vil beskytte dig mod: Vil stadig ikke beskytte mod massive fejl på stedet. Men lokale forstyrrelser vil ikke vare så længe.

   Fra praksis: Detailvirksomheden havde flere informationssystemer og hjemmesider. Alle databaser var lokaliseret på virksomhedens kontor. Der blev ikke tænkt på noget DR, før kontoret stod uden strøm flere gange i træk. Kunder var utilfredse med hjemmesidenedbrud. 
    
   Problemet med servicetilgængelighed blev løst efter flytning til skyen. Derudover formåede vi at optimere belastningen på databaserne ved at afbalancere trafikken mellem noder.

3. Flyt til en katastrofesikker sky

   Hvis du skal sikre dig, at selv en naturkatastrofe på hovedsiden ikke forstyrrer dit arbejde, kan du vælge en katastrofebestandig sky.I denne mulighed distribuerer udbyderen virtualiseringsklyngen på tværs af 2 datacentre. Konstant synkron replikering sker mellem datacentre, en-til-en. Kanalerne mellem datacentre er reserverede og går ad forskellige ruter, så en sådan klynge er ikke bange for netværksproblemer. 

   RTO: tendens til 0.
   Omkostninger: Den dyreste cloud-mulighed. 
   Hvad det ikke vil beskytte dig mod: Det hjælper ikke mod datakorruption, såvel som fra den menneskelige faktor, så det anbefales at lave sikkerhedskopier på samme tid. 

   Fra praksis: En af vores kunder udviklede en omfattende katastrofeberedskabsplan. Dette er den strategi, han valgte: 

   • En katastrofe-tolerant sky beskytter applikationen mod fejl på infrastrukturniveau. 
   • To-niveau backup giver beskyttelse i tilfælde af menneskelige fejl. Der er to typer sikkerhedskopier: "kold" og "varm". En "kold" backup er i en deaktiveret tilstand og tager tid at implementere. En "hot" backup er allerede klar til brug og gendannes hurtigere. Den opbevares på et specielt dedikeret opbevaringssystem. Den tredje kopi optages på bånd og opbevares i et andet rum. 

   En gang om ugen tester klienten beskyttelsen og kontrollerer funktionaliteten af ​​alle sikkerhedskopier, inklusive dem fra tape. Hvert år tester virksomheden hele den katastrofebestandige sky. 

4. Organiser replikering til et andet websted 

   En anden mulighed for, hvordan man undgår globale problemer på hovedsiden: giv georeservation. Med andre ord, opret virtuelle backup-maskiner på et sted i en anden by. Specielle løsninger til DR er velegnede til dette: I vores virksomhed bruger vi VMware vCloud Availability (vCAV). Med dens hjælp kan du konfigurere beskyttelse mellem flere cloududbyderwebsteder eller gendanne til skyen fra et lokalt websted. Jeg har allerede talt mere detaljeret om ordningen for at arbejde med vCAV her. 

   RPO og RTO: fra 5 minutter. 

   Omkostninger: dyrere end den første mulighed, men billigere end hardwarereplikering i en katastrofesikker sky. Prisen består af omkostningerne til en vCAV-licens, administrationsgebyrer, omkostningerne til cloud-ressourcer og reserveressourcer i henhold til PAYG-modellen (10 % af omkostningerne til arbejdsressourcer for slukkede VM'er).

   Fra praksis: Klienten havde 6 virtuelle maskiner med forskellige databaser i vores sky i Moskva. Til at begynde med blev beskyttelsen leveret af backup: nogle af sikkerhedskopierne blev gemt i skyen i Moskva, og nogle blev gemt på vores St. Petersborg-websted. Med tiden voksede databaserne i størrelse, og gendannelse fra en sikkerhedskopi begyndte at tage længere tid. 
    
   Replikering baseret på VMware vCloud Tilgængelighed blev tilføjet til sikkerhedskopier. Replikaer af virtuelle maskiner gemmes på en backup-side i St. Petersborg og opdateres hvert 5. minut. Hvis der opstår en fejl på hovedstedet, skifter medarbejderne uafhængigt til en kopi af den virtuelle maskine i St. Petersborg og fortsætter med at arbejde med den. 

Alle de overvejede løsninger giver høj tilgængelighed, men beskytter ikke mod tab af data på grund af en ransomware-virus eller en utilsigtet medarbejderfejl. I dette tilfælde har vi brug for sikkerhedskopier, der giver den nødvendige RPO.

5. Glem ikke backup

Alle ved, at du skal lave sikkerhedskopier, selvom du har den fedeste katastrofesikre løsning. Så jeg vil lige kort minde dig om et par punkter.

Strengt taget er backup ikke DR. Og det er derfor: 

• Det er lang tid. Hvis dataene måles i terabyte, vil gendannelsen tage mere end en time. Du skal gendanne, tildele et netværk, kontrollere, at det tænder, se, at dataene er i orden. Så du kan kun levere en god RTO, hvis der er få data. 
• Dataene bliver muligvis ikke gendannet første gang, og du skal give tid til at gentage handlingen. For eksempel er der tidspunkter, hvor vi ikke ved præcis, hvornår data gik tabt. Lad os sige, at tabet blev bemærket kl. 15.00, og der laves kopier hver time. Fra klokken 15.00 ser vi på alle genopretningspunkter: 14, 00 og så videre. Hvis systemet er vigtigt, forsøger vi at minimere genopretningspunktets alder. Men hvis den friske backup ikke indeholdt de nødvendige data, tager vi det næste punkt - dette er ekstra tid. 

I dette tilfælde kan backup-planen give det nødvendige RPO. For sikkerhedskopier er det vigtigt at sørge for geo-reservation i tilfælde af problemer med hovedsiden. Det anbefales at gemme nogle sikkerhedskopier separat.

Den endelige katastrofegenopretningsplan bør indeholde mindst 2 værktøjer:  

• En af mulighederne 1-4, som vil beskytte systemer mod fejl og fald.
• Sikkerhedskopiering for at beskytte data mod tab. 

Det er også værd at tage sig af en backup-kommunikationskanal, hvis hovedinternetudbyderen går ned. Og - voila! — DR til mindstelønninger er allerede klar. 

Kilde: www.habr.com