Selv om det er en flom, bør 1C fungere! Vi er enige med virksomheten på DR

Tenk deg: du betjener IT-infrastrukturen til et stort kjøpesenter. Det begynner å regne i byen. Strømmer av regn bryter gjennom taket, vann fyller butikklokaler helt til ankelene. Vi håper at serverrommet ditt ikke er i kjelleren, ellers kan ikke problemer unngås.  

Historien som beskrives er ikke en fantasi, men en samlet beskrivelse av et par hendelser i 2020. I store selskaper er en katastrofegjenopprettingsplan (DRP) alltid tilgjengelig for denne saken. I selskaper er dette ansvaret til spesialister på forretningskontinuitet. Men i mellomstore og små bedrifter faller løsning av slike problemer på IT-tjenester. Du må selv forstå forretningslogikken, forstå hva som kan feile og hvor, komme opp med beskyttelse og implementere det. 

Det er flott hvis en IT-spesialist kan forhandle med virksomheten og diskutere behovet for beskyttelse. Men jeg har sett mer enn én gang hvordan et selskap sparte på en katastrofegjenopprettingsløsning (DR) fordi det anså den som overflødig. Når en ulykke skjedde, truet en lang bedring med tap, og virksomheten var ikke klar. Du kan gjenta så mye du vil: «Jeg sa det til deg», men IT-tjenesten vil fortsatt måtte gjenopprette tjenester.

Fra arkitektens stilling vil jeg fortelle deg hvordan du unngår denne situasjonen. I den første delen av artikkelen vil jeg vise det forberedende arbeidet: hvordan diskutere tre spørsmål med kunden for valg av sikkerhetsverktøy: 

• Hva beskytter vi?
• Hva beskytter vi mot?
• Hvor mye beskytter vi? 

I den andre delen vil vi snakke om alternativer for å svare på spørsmålet: hvordan forsvare deg selv. Jeg vil gi eksempler på tilfeller av hvordan ulike kunder bygger sin beskyttelse.

Hva vi beskytter: identifisere kritiske forretningsfunksjoner 

Det er bedre å begynne å forberede seg ved å diskutere handlingsplanen etter en krise med bedriftskunden. Den største vanskeligheten her er å finne et felles språk. Kunden bryr seg som regel ikke om hvordan IT-løsningen fungerer. Han bryr seg om tjenesten kan utføre forretningsfunksjoner og få inn penger. For eksempel: hvis siden fungerer, men betalingssystemet er nede, er det ingen inntekt fra kunder, og "ekstremistene" er fortsatt IT-spesialister. 

En IT-profesjonell kan ha problemer med slike forhandlinger av flere grunner:

• IT-tjenesten forstår ikke helt informasjonssystemets rolle i næringslivet. For eksempel hvis det ikke finnes en tilgjengelig beskrivelse av forretningsprosesser eller en transparent forretningsmodell. 
• Ikke hele prosessen avhenger av IT-tjenesten. For eksempel når en del av arbeidet utføres av entreprenører, og IT-spesialister ikke har direkte innflytelse på dem.

Jeg vil strukturere samtalen slik: 

1. Vi forklarer bedrifter at ulykker skjer med alle, og utvinning tar tid. Det beste er å demonstrere situasjoner, hvordan dette skjer og hvilke konsekvenser som er mulige.
2. Vi viser at ikke alt avhenger av IT-tjenesten, men du er klar til å hjelpe med en handlingsplan innenfor ditt ansvarsområde.
3. Vi ber bedriftskunden svare: hvis apokalypsen inntreffer, hvilken prosess bør gjenopprettes først? Hvem deltar i det og hvordan? 

   Et enkelt svar kreves fra virksomheten, for eksempel: kundesenteret må fortsette å registrere søknader 24/7.

4. Vi ber en eller to brukere av systemet om å beskrive denne prosessen i detalj. 
   Det er bedre å involvere en analytiker for å hjelpe hvis bedriften din har en.

   Til å begynne med kan beskrivelsen se slik ut: kundesenteret mottar forespørsler på telefon, per post og via meldinger fra nettsiden. Deretter legger han dem inn i 1C via webgrensesnittet, og produksjonen tar dem derfra på denne måten.

5. Deretter ser vi på hvilke maskinvare- og programvareløsninger som støtter prosessen. For omfattende beskyttelse tar vi hensyn til tre nivåer: 
   • applikasjoner og systemer på nettstedet (programvarenivå),   
   • selve nettstedet der systemene kjører (infrastrukturnivå), 
   • nettverk (de glemmer det ofte).

6. Vi finner ut mulige feilpunkter: systemnoder som ytelsen til tjenesten avhenger av. Vi noterer separat noder som støttes av andre selskaper: telekomoperatører, vertsleverandører, datasentre og så videre. Med dette kan du gå tilbake til bedriftskunden for neste trinn.

Hva vi beskytter mot: risikoer

Deretter finner vi først ut av bedriftskunden hvilke risikoer vi beskytter oss mot. Alle risikoer kan deles inn i to grupper: 

• tap av tid på grunn av driftsstans;
• tap av data på grunn av fysiske påvirkninger, menneskelige faktorer, etc.

Bedrifter er redde for å miste både data og tid – alt dette fører til tap av penger. Så igjen stiller vi spørsmål for hver risikogruppe: 

• For denne prosessen, kan vi anslå hvor mye tap av data og tidstap koster i penger? 
• Hvilke data kan vi ikke miste? 
• Hvor kan vi ikke tillate nedetid? 
• Hvilke hendelser er mest sannsynlige og mest truende for oss?

Etter diskusjon vil vi forstå hvordan vi skal prioritere feilpoeng. 

Hvor mye vi beskytter: RPO og RTO 

Når de kritiske feilpunktene er klare, beregner vi RTO- og RPO-indikatorene. 

Jeg vil minne deg på det RTO (gjenopprettingstidsmål) — dette er den tillatte tiden fra ulykkesøyeblikket til tjenesten er fullstendig gjenopprettet. På forretningsspråk er dette akseptabel nedetid. Hvis vi vet hvor mye penger prosessen ga inn, kan vi beregne tapene fra hvert minutt med nedetid og beregne akseptabelt tap. 

RPO (gjenopprettingspunktmål) — gyldig datagjenopprettingspunkt. Det bestemmer tiden vi kan miste data. Fra et forretningsmessig synspunkt kan tap av data føre til for eksempel bøter. Slike tap kan også konverteres til penger. 

Gjenopprettingstiden må beregnes for sluttbrukeren: hvor lenge vil han kunne logge på systemet. Så først legger vi opp restitusjonstiden for alle ledd i kjeden. Det gjøres ofte en feil her: de tar leverandørens RTO fra SLA, og glemmer de gjenværende vilkårene.

La oss se på et spesifikt eksempel. Brukeren logger på 1C, systemet åpner med en databasefeil. Han kontakter systemansvarlig. Databasen ligger i skyen, systemadministratoren rapporterer problemet til tjenesteleverandøren. La oss si at all kommunikasjon tar 15 minutter. I skyen vil en database av denne størrelsen bli gjenopprettet fra en sikkerhetskopi om en time, derfor er RTO på tjenesteleverandørsiden en time. Men dette er ikke den endelige fristen; for brukeren er det lagt til 15 minutter for å oppdage problemet. 
 
Deretter må systemadministratoren sjekke at databasen er riktig, koble den til 1C og starte tjenestene. Dette krever ytterligere en time, noe som betyr at RTO på administratorsiden allerede er 2 timer og 15 minutter. Brukeren trenger ytterligere 15 minutter: logg inn, sjekk at nødvendige transaksjoner har dukket opp. 2 timer og 30 minutter er den totale tjenestegjenopprettingstiden i dette eksemplet.

Disse beregningene vil vise virksomheten på hvilke eksterne faktorer gjenopprettingsperioden avhenger. For eksempel, hvis kontoret er oversvømmet, må du først finne lekkasjen og fikse den. Det vil ta tid, som ikke er avhengig av IT.  

Slik beskytter vi: velge verktøy for ulike risikoer

Etter å ha diskutert alle punktene, forstår kunden allerede kostnadene ved en ulykke for virksomheten. Nå kan du velge verktøy og diskutere budsjettet. Ved hjelp av eksempler på kundesaker vil jeg vise deg hvilke verktøy vi tilbyr for ulike oppgaver. 

La oss starte med den første risikogruppen: tap på grunn av driftsstans. Løsninger på dette problemet bør gi god RTO.

1. Vert applikasjonen i skyen 

   Til å begynne med kan du ganske enkelt flytte til skyen - leverandøren har allerede tenkt gjennom problemene med høy tilgjengelighet. Virtualiseringsverter settes sammen til en klynge, strøm og nettverk er reservert, data lagres på feiltolerante lagringssystemer, og tjenesteleverandøren er økonomisk ansvarlig for nedetid.

   Du kan for eksempel være vert for en virtuell maskin med en database i skyen. Applikasjonen vil koble til databasen eksternt via en etablert kanal eller fra samme sky. Hvis det oppstår problemer med en av serverne i klyngen, vil VM starte på nytt på naboserveren på mindre enn 2 minutter. Etter det vil DBMS starte opp i den, og om noen minutter vil databasen bli tilgjengelig.

   RTO: målt i minutter. Disse vilkårene kan spesifiseres i avtalen med leverandøren.
   Koste: Vi beregner kostnadene for skyressurser for applikasjonen din. 
   Hva den ikke vil beskytte deg mot: fra massive feil på leverandørens nettsted, for eksempel på grunn av ulykker på bynivå.

2. Klynger applikasjonen  

   Hvis du ønsker å forbedre RTO, kan du styrke det forrige alternativet og umiddelbart plassere en klynget applikasjon i skyen.

   Du kan implementere en klynge i aktiv-passiv eller aktiv-aktiv modus. Vi lager flere VM-er basert på leverandørens krav. For større pålitelighet distribuerer vi dem på tvers av forskjellige servere og lagringssystemer. Hvis serveren med en av databasene svikter, tar backup-noden over belastningen på noen få sekunder.

   RTO: Målt i sekunder.
   Koste: litt dyrere enn en vanlig sky, ekstra ressurser vil være nødvendig for klynging.
   Hva den ikke vil beskytte deg mot: Vil fortsatt ikke beskytte mot massive feil på stedet. Men lokale forstyrrelser vil ikke vare like lenge.

   Fra praksis: Butikkbedriften hadde flere informasjonssystemer og nettsider. Alle databaser var lokalisert lokalt på selskapets kontor. Ingen DR ble tenkt på før kontoret ble stående uten strøm flere ganger på rad. Kunder var misfornøyde med nettstedkrasj. 
    
   Problemet med tjenestetilgjengelighet ble løst etter flytting til skyen. I tillegg klarte vi å optimalisere belastningen på databasene ved å balansere trafikk mellom noder.

3. Flytt til en katastrofesikker sky

   Hvis du trenger å sikre at arbeidet ikke blir avbrutt selv av en naturkatastrofe på hovedsiden, kan du velge en katastrofebestandig sky.I dette alternativet sprer leverandøren virtualiseringsklyngen over 2 datasentre. Konstant synkron replikering skjer mellom datasentre, en-til-en. Kanalene mellom datasentre er reservert og går langs ulike ruter, så en slik klynge er ikke redd for nettverksproblemer. 

   RTO: har en tendens til 0.
   Koste: Det dyreste skyalternativet. 
   Hva den ikke vil beskytte deg mot: Det vil ikke hjelpe mot datakorrupsjon, så vel som fra den menneskelige faktoren, så det anbefales å ta sikkerhetskopier samtidig. 

   Fra praksis: En av våre kunder utviklet en omfattende katastrofegjenopprettingsplan. Dette er strategien han valgte: 

   • En katastrofetolerant sky beskytter applikasjonen mot feil på infrastrukturnivå. 
   • To-nivå sikkerhetskopiering gir beskyttelse i tilfelle menneskelige feil. Det finnes to typer sikkerhetskopier: "kald" og "varm". En "kald" sikkerhetskopi er i deaktivert tilstand og tar tid å distribuere. En "hot" backup er allerede klar til bruk og gjenopprettes raskere. Den er lagret på et spesielt dedikert lagringssystem. Den tredje kopien er tatt opp på bånd og lagret i et annet rom. 

   En gang i uken tester klienten beskyttelsen og kontrollerer funksjonaliteten til alle sikkerhetskopier, inkludert de fra tape. Hvert år tester selskapet hele den katastrofebestandige skyen. 

4. Organiser replikering til et annet nettsted 

   Et annet alternativ for hvordan du unngår globale problemer på hovedsiden: gi geo-reservasjon. Med andre ord, lag backup virtuelle maskiner på et sted i en annen by. Spesialløsninger for DR er egnet for dette: i vårt selskap bruker vi VMware vCloud Availability (vCAV). Med dens hjelp kan du konfigurere beskyttelse mellom flere skyleverandørsider eller gjenopprette til skyen fra et lokalt nettsted. Jeg har allerede snakket mer detaljert om ordningen for å jobbe med vCAV her. 

   RPO og RTO: fra 5 minutter. 

   Koste: dyrere enn det første alternativet, men billigere enn maskinvarereplikering i en katastrofesikker sky. Prisen består av kostnaden for en vCAV-lisens, administrasjonsgebyrer, kostnaden for skyressurser og reserveressurser i henhold til PAYG-modellen (10 % av kostnaden for arbeidsressurser for avslåtte VM-er).

   Fra praksis: Klienten beholdt 6 virtuelle maskiner med forskjellige databaser i skyen vår i Moskva. Til å begynne med ble beskyttelsen gitt av sikkerhetskopiering: noen av sikkerhetskopiene ble lagret i skyen i Moskva, og noen ble lagret på nettstedet vårt i St. Petersburg. Over tid vokste databasene i størrelse, og gjenoppretting fra en sikkerhetskopi begynte å ta lengre tid. 
    
   Replikering basert på VMware vCloud Availability ble lagt til sikkerhetskopier. Replikaer av virtuelle maskiner lagres på en sikkerhetskopiside i St. Petersburg og oppdateres hvert 5. minutt. Hvis det oppstår en feil på hovedstedet, bytter ansatte uavhengig til en kopi av den virtuelle maskinen i St. Petersburg og fortsetter å jobbe med den. 

Alle løsningene som vurderes gir høy tilgjengelighet, men beskytter ikke mot tap av data på grunn av et løsepengevirus eller en utilsiktet ansattfeil. I dette tilfellet trenger vi sikkerhetskopier som vil gi den nødvendige RPO.

5. Ikke glem sikkerhetskopiering

Alle vet at du må ta sikkerhetskopier, selv om du har den kuleste katastrofesikre løsningen. Så jeg vil bare kort minne deg på noen få punkter.

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

• Det er lenge siden. Hvis dataene måles i terabyte, vil gjenopprettingen ta mer enn én time. Du må gjenopprette, tilordne et nettverk, sjekke at det slår seg på, se at dataene er i orden. Så du kan gi en god RTO bare hvis det er lite data. 
• Dataene gjenopprettes kanskje ikke første gang, og du må gi tid til å gjenta handlingen. For eksempel er det tider når vi ikke vet nøyaktig når data gikk tapt. La oss si at tapet ble lagt merke til klokken 15.00, og det lages kopier hver time. Fra kl 15.00 ser vi på alle restitusjonspunkter: 14, 00 og så videre. Hvis systemet er viktig, prøver vi å minimere alderen på gjenopprettingspunktet. Men hvis den ferske sikkerhetskopien ikke inneholdt de nødvendige dataene, tar vi neste punkt - dette er ekstra tid. 

I dette tilfellet kan sikkerhetskopieringsplanen gi det nødvendige RPO. For sikkerhetskopiering er det viktig å gi geo-reservasjon ved problemer med hovedsiden. Det anbefales å lagre noen sikkerhetskopier separat.

Den endelige katastrofegjenopprettingsplanen bør inneholde minst to verktøy:  

• Ett av alternativene 1-4, som vil beskytte systemer mot feil og fall.
• Sikkerhetskopiering for å beskytte data mot tap. 

Det er også verdt å ta vare på en backup-kommunikasjonskanal i tilfelle hovedleverandøren av Internett går ned. Og - voila! — DR på minstelønn er allerede klar. 

Kilde: www.habr.com