Även om det är en översvämning borde 1C fungera! Vi håller med verksamheten på DR

Föreställ dig: du servar IT-infrastrukturen i ett stort köpcentrum. Det börjar regna i staden. Strömmar av regn bryter igenom taket, vatten fyller butikslokaler ända till fots. Vi hoppas att ditt serverrum inte finns i källaren, annars kan problem inte undvikas.  

Berättelsen som beskrivs är inte en fantasi, utan en samlad beskrivning av ett par händelser under 2020. I stora företag finns alltid en katastrofåterställningsplan, eller en katastrofåterställningsplan (DRP), till hands för detta fall. I företag är detta ansvaret för affärskontinuitetsspecialister. Men i medelstora och små företag faller det på IT-tjänster att lösa sådana problem. Du måste själv förstå affärslogiken, förstå vad som kan misslyckas och var, komma på skydd och implementera det. 

Det är bra om en IT-specialist kan förhandla med verksamheten och diskutera behovet av skydd. Men jag har sett mer än en gång hur ett företag snålat med en katastrofåterställningslösning (DR) eftersom det ansåg det vara överflödigt. När en olycka inträffade hotade en lång återhämtning förluster och verksamheten var inte redo. Du kan upprepa så mycket du vill: "Jag sa det till dig", men IT-tjänsten måste fortfarande återställa tjänsterna.

Från en arkitekts position ska jag berätta för dig hur du undviker denna situation. I den första delen av artikeln kommer jag att visa förarbetet: hur man diskuterar tre frågor med kunden för att välja säkerhetsverktyg: 

• Vad skyddar vi?
• Vad skyddar vi mot?
• Hur mycket skyddar vi? 

I den andra delen kommer vi att prata om alternativ för att svara på frågan: hur man försvarar sig själv. Jag kommer att ge exempel på fall på hur olika kunder bygger sitt skydd.

Vad vi skyddar: identifiera kritiska affärsfunktioner 

Det är bättre att börja förbereda sig genom att diskutera handlingsplanen efter en nödsituation med företagskunden. Den största svårigheten här är att hitta ett gemensamt språk. Kunden bryr sig oftast inte om hur IT-lösningen fungerar. Han bryr sig om tjänsten kan utföra affärsfunktioner och ta in pengar. Till exempel: om sajten fungerar, men betalningssystemet är nere, finns det inga intäkter från kunder, och "extremisterna" är fortfarande IT-specialister. 

En IT-proffs kan ha svårt i sådana förhandlingar av flera skäl:

• IT-tjänsten förstår inte helt informationssystemets roll i verksamheten. Till exempel om det inte finns någon tillgänglig beskrivning av affärsprocesser eller en transparent affärsmodell. 
• Inte hela processen beror på IT-tjänsten. Till exempel när en del av arbetet utförs av entreprenörer, och IT-specialister inte har direkt inflytande på dem.

Jag skulle strukturera samtalet så här: 

1. Vi förklarar för företag att olyckor händer alla och att återhämtning tar tid. Det bästa är att visa situationer, hur detta går till och vilka konsekvenser som är möjliga.
2. Vi visar att allt inte beror på IT-tjänsten utan du är redo att hjälpa till med en handlingsplan inom ditt ansvarsområde.
3. Vi ber företagskunden att svara: om apokalypsen inträffar, vilken process ska återställas först? Vem deltar i det och hur? 

   Ett enkelt svar krävs från verksamheten, till exempel: callcentret behöver fortsätta registrera ansökningar 24/7.

4. Vi ber en eller två användare av systemet att beskriva denna process i detalj. 
   Det är bättre att involvera en analytiker för att hjälpa till om ditt företag har en.

   Till att börja med kan beskrivningen se ut så här: callcentret tar emot förfrågningar per telefon, per post och via meddelanden från webbplatsen. Sedan matar han in dem i 1C via webbgränssnittet, och produktionen tar dem därifrån på det här sättet.

5. Sedan tittar vi på vilka hårdvaru- och mjukvarulösningar som stödjer processen. För ett heltäckande skydd tar vi hänsyn till tre nivåer: 
   • applikationer och system inom webbplatsen (mjukvarunivå),   
   • själva platsen där systemen körs (infrastrukturnivå), 
   • nätverk (de glömmer ofta bort det).

6. Vi tar reda på möjliga felpunkter: systemnoder som tjänstens prestanda beror på. Vi noterar separat noder som stöds av andra företag: telekomoperatörer, värdleverantörer, datacenter och så vidare. Med detta kan du återvända till företagskunden för nästa steg.

Det vi skyddar mot: risker

Därefter tar vi reda på av företagskunden vilka risker vi skyddar oss från först. Alla risker kan delas in i två grupper: 

• tidsförlust på grund av driftstopp;
• förlust av data på grund av fysisk påverkan, mänskliga faktorer, etc.

Företag är rädda för att förlora både data och tid - allt detta leder till förlust av pengar. Så återigen ställer vi frågor för varje riskgrupp: 

• Kan vi uppskatta hur mycket dataförlust och tidsförlust kostar i pengar för denna process? 
• Vilken data kan vi inte förlora? 
• Var kan vi inte tillåta stillestånd? 
• Vilka händelser är mest sannolika och mest hotfulla för oss?

Efter diskussion kommer vi att förstå hur man prioriterar felpunkter. 

Hur mycket vi skyddar: RPO och RTO 

När de kritiska felpunkterna är klara, beräknar vi RTO- och RPO-indikatorerna. 

Jag minns att RTO (återhämtningstidsmål) — Detta är den tillåtna tiden från olyckstillfället tills tjänsten är helt återställd. På affärsspråk är detta acceptabel driftstopp. Om vi ​​vet hur mycket pengar processen inbringade kan vi beräkna förlusterna från varje minut av stillestånd och beräkna den acceptabla förlusten. 

RPO (återvinningspunktsmål) — giltig dataåterställningspunkt. Det bestämmer under vilken tid vi kan förlora data. Ur affärsmässig synvinkel kan dataförlust ge till exempel böter. Sådana förluster kan också omvandlas till pengar. 

Återställningstiden måste beräknas för slutanvändaren: hur länge kommer han att kunna logga in i systemet. Så först lägger vi ihop återhämtningstiden för alla länkar i kedjan. Ett misstag görs ofta här: de tar leverantörens RTO från SLA och glömmer de återstående villkoren.

Låt oss titta på ett specifikt exempel. Användaren loggar in på 1C, systemet öppnas med ett databasfel. Han kontaktar systemadministratören. Databasen ligger i molnet, systemadministratören rapporterar problemet till tjänsteleverantören. Låt oss säga att all kommunikation tar 15 minuter. I molnet kommer en databas av denna storlek att återställas från en säkerhetskopia på en timme, därför är RTO på tjänsteleverantörens sida en timme. Men detta är inte den sista deadline, för användaren har 15 minuter lagts till för att upptäcka problemet. 
 
Därefter måste systemadministratören kontrollera att databasen är korrekt, ansluta den till 1C och starta tjänsterna. Detta kräver ytterligare en timme, vilket innebär att RTO på administratörens sida redan är 2 timmar och 15 minuter. Användaren behöver ytterligare 15 minuter: logga in, kontrollera att nödvändiga transaktioner har dykt upp. 2 timmar 30 minuter är den totala serviceåterställningstiden i detta exempel.

Dessa beräkningar kommer att visa verksamheten på vilka externa faktorer återhämtningsperioden beror på. Om kontoret till exempel är översvämmat måste du först hitta läckan och åtgärda den. Det kommer att ta tid, vilket inte beror på IT.  

Så skyddar vi: att välja verktyg för olika risker

Efter att ha diskuterat alla punkter förstår kunden redan kostnaden för en olycka för verksamheten. Nu kan du välja verktyg och diskutera budgeten. Med hjälp av exempel på kundcase kommer jag att visa dig vilka verktyg vi erbjuder för olika uppgifter. 

Låt oss börja med den första gruppen risker: förluster på grund av driftstopp. Lösningar på detta problem bör ge bra RTO.

1. Värd applikationen i molnet 

   Till att börja med kan du helt enkelt flytta till molnet - leverantören har redan tänkt igenom frågorna om hög tillgänglighet. Virtualiseringsvärdar sätts samman till ett kluster, ström och nätverk reserveras, data lagras på feltoleranta lagringssystem och tjänsteleverantören är ekonomiskt ansvarig för driftstopp.

   Du kan till exempel vara värd för en virtuell maskin med en databas i molnet. Applikationen kommer att ansluta till databasen externt via en etablerad kanal eller från samma moln. Om problem uppstår med en av servrarna i klustret kommer den virtuella datorn att starta om på den angränsande servern på mindre än 2 minuter. Därefter startar DBMS i den och om några minuter blir databasen tillgänglig.

   RTO: mätt i minuter. Dessa villkor kan anges i avtalet med leverantören.
   Kostnad: Vi beräknar kostnaden för molnresurser för din applikation. 
   Vad det inte kommer att skydda dig från: från massiva fel på leverantörens webbplats, till exempel på grund av olyckor på stadsnivå.

2. Klusta applikationen  

   Om du vill förbättra RTO kan du stärka det tidigare alternativet och omedelbart placera en klustrad applikation i molnet.

   Du kan implementera ett kluster i aktivt-passivt eller aktivt-aktivt läge. Vi skapar flera virtuella datorer baserat på leverantörens krav. För större tillförlitlighet distribuerar vi dem över olika servrar och lagringssystem. Om servern med en av databaserna misslyckas tar backupnoden över belastningen på några sekunder.

   RTO: Mätt i sekunder.
   Kostnad: något dyrare än ett vanligt moln, ytterligare resurser kommer att krävas för klustring.
   Vad det inte kommer att skydda dig från: Kommer fortfarande inte att skydda mot stora fel på plats. Men lokala störningar kommer inte att pågå lika länge.

   Från praktiken: Detaljhandelsföretaget hade flera informationssystem och hemsidor. Alla databaser fanns lokalt på företagets kontor. Ingen DR tänkte på förrän kontoret blev strömlöst flera gånger i rad. Kunder var missnöjda med webbplatskrascher. 
    
   Problemet med tjänstens tillgänglighet löstes efter flytt till molnet. Dessutom lyckades vi optimera belastningen på databaserna genom att balansera trafik mellan noder.

3. Flytta till ett katastrofsäkert moln

   Om du behöver se till att inte ens en naturkatastrof på huvudsidan stör ditt arbete, kan du välja ett katastroftåligt moln.I det här alternativet distribuerar leverantören virtualiseringsklustret över 2 datacenter. Konstant synkron replikering sker mellan datacenter, en-till-en. Kanalerna mellan datacenter är reserverade och går längs olika vägar, så ett sådant kluster är inte rädd för nätverksproblem. 

   RTO: tenderar till 0.
   Kostnad: Det dyraste molnalternativet. 
   Vad det inte kommer att skydda dig från: Det hjälper inte mot datakorruption, såväl som från den mänskliga faktorn, så det rekommenderas att göra säkerhetskopior samtidigt. 

   Från praktiken: En av våra kunder utvecklade en omfattande katastrofåterställningsplan. Detta är strategin han valde: 

   • Ett katastroftolerant moln skyddar applikationen från fel på infrastrukturnivå. 
   • Säkerhetskopiering på två nivåer ger skydd vid mänskliga fel. Det finns två typer av säkerhetskopior: "kall" och "het". En "kall" säkerhetskopia är i ett inaktiverat tillstånd och tar tid att distribuera. En "het" säkerhetskopia är redan klar för användning och återställs snabbare. Den lagras på ett speciellt dedikerat lagringssystem. Den tredje kopian spelas in på band och förvaras i ett annat rum. 

   En gång i veckan testar klienten skyddet och kontrollerar funktionen hos alla säkerhetskopior, inklusive de från band. Varje år testar företaget hela det katastroftåliga molnet. 

4. Organisera replikering till en annan webbplats 

   Ett annat alternativ för hur man undviker globala problem på huvudsidan: tillhandahåll georeservation. Med andra ord, skapa backup virtuella maskiner på en plats i en annan stad. Speciallösningar för DR är lämpliga för detta: i vårt företag använder vi VMware vCloud Availability (vCAV). Med hjälp av den kan du konfigurera skydd mellan flera molnleverantörers webbplatser eller återställa till molnet från en lokal webbplats. Jag har redan pratat mer i detalj om schemat för att arbeta med vCAV här. 

   RPO och RTO: från 5 minuter. 

   Kostnad: dyrare än det första alternativet, men billigare än hårdvarureplikering i ett katastrofsäkert moln. Priset består av kostnaden för en vCAV-licens, administrationsavgifter, kostnaden för molnresurser och reservresurser enligt PAYG-modellen (10 % av kostnaden för arbetsresurser för avstängda virtuella datorer).

   Från praktiken: Klienten behöll 6 virtuella maskiner med olika databaser i vårt moln i Moskva. Till en början gavs skydd genom säkerhetskopiering: några av säkerhetskopiorna lagrades i molnet i Moskva och några lagrades på vår webbplats i St. Petersburg. Med tiden växte databaserna i storlek och återställning från en säkerhetskopia började ta längre tid. 
    
   Replikering baserad på VMware vCloud Availability lades till säkerhetskopior. Repliker av virtuella maskiner lagras på en säkerhetskopia i St. Petersburg och uppdateras var 5:e minut. Om ett fel inträffar på huvudplatsen byter anställda självständigt till en kopia av den virtuella maskinen i St. Petersburg och fortsätter att arbeta med den. 

Alla övervägda lösningar ger hög tillgänglighet, men skyddar inte mot dataförlust på grund av ett ransomware-virus eller ett oavsiktligt anställdfel. I det här fallet kommer vi att behöva säkerhetskopior som ger den RPO som krävs.

5. Glöm inte säkerhetskopiering

Alla vet att du måste göra säkerhetskopior, även om du har den coolaste katastrofsäkra lösningen. Så jag ska bara kort påminna dig om några punkter.

Strängt taget är backup inte DR. Och det är varför: 

• Det är en lång tid. Om data mäts i terabyte tar återställningen mer än en timme. Du måste återställa, tilldela ett nätverk, kontrollera att det slås på, se att data är i ordning. Så du kan bara tillhandahålla en bra RTO om det finns lite data. 
• Data kanske inte återställs första gången, och du måste ge dig tid för att upprepa åtgärden. Till exempel finns det tillfällen då vi inte vet exakt när data gick förlorade. Låt oss säga att förlusten märktes klockan 15.00, och kopior görs varje timme. Från 15.00 tittar vi på alla återhämtningspunkter: 14, 00 och så vidare. Om systemet är viktigt försöker vi minimera åldern på återhämtningspunkten. Men om den nya säkerhetskopian inte innehöll de nödvändiga uppgifterna tar vi nästa punkt - det här är ytterligare tid. 

I det här fallet kan säkerhetskopieringsschemat ge det som krävs RPO. För säkerhetskopiering är det viktigt att tillhandahålla geo-reservation vid problem med huvudsidan. Det rekommenderas att lagra några säkerhetskopior separat.

Den slutliga katastrofåterställningsplanen bör innehålla minst två verktyg:  

• Ett av alternativen 1-4, som skyddar system från fel och fall.
• Säkerhetskopiering för att skydda data från förlust. 

Det är också värt att ta hand om en backup-kommunikationskanal ifall den huvudsakliga internetleverantören går ner. Och - voila! — DR på minimilöner är redan redo. 

Källa: will.com