Laat in ieder geval een overstroming, maar 1C moet lukken! Onderhandelen met het bedrijfsleven over DR

Stel je voor: je onderhoudt de IT-infrastructuur van een groot winkelcentrum. Het begint te regenen in de stad. Regenstromen breken door het dak, water vult winkelpanden tot aan de enkels. Wij hopen dat uw serverruimte zich niet in de kelder bevindt, anders zijn problemen niet te vermijden.  

Het beschreven verhaal is geen fantasie, maar een collectieve beschrijving van een aantal gebeurtenissen uit 2020. Bij grote bedrijven is voor dit geval altijd een disaster recovery plan, oftewel disaster recovery plan (DRP), aanwezig. In bedrijven is dit de verantwoordelijkheid van specialisten op het gebied van bedrijfscontinuïteit. Maar in middelgrote en kleine bedrijven valt het oplossen van dergelijke problemen onder de verantwoordelijkheid van IT-diensten. U moet zelf de bedrijfslogica begrijpen, begrijpen wat er kan mislukken en waar, bescherming bedenken en implementeren. 

Het is geweldig als een IT-specialist met de business kan onderhandelen en de noodzaak van bescherming kan bespreken. Maar ik heb meer dan eens gezien hoe een bedrijf beknibbelde op een Disaster Recovery (DR)-oplossing omdat het deze als overbodig beschouwde. Toen zich een ongeluk voordeed, dreigde een lang herstel met verliezen, en het bedrijf was er niet klaar voor. Je kunt zoveel herhalen als je wilt: “Ik zei het toch”, maar de IT-dienst zal de services nog steeds moeten herstellen.

Vanuit de positie van een architect zal ik je vertellen hoe je deze situatie kunt vermijden. In het eerste deel van het artikel zal ik het voorbereidende werk laten zien: hoe je drie vragen met de klant bespreekt bij het kiezen van beveiligingstools: 

• Wat beschermen we?
• Waar beschermen we tegen?
• Hoeveel beschermen we? 

In het tweede deel zullen we het hebben over de opties om de vraag te beantwoorden: hoe kun je jezelf verdedigen. Ik zal voorbeelden geven van gevallen waarin verschillende klanten hun bescherming opbouwen.

Wat we beschermen: het identificeren van kritieke bedrijfsfuncties 

Beter kun je al beginnen met de voorbereiding door het post-noodactieplan met de zakelijke klant te bespreken. De grootste moeilijkheid hier is het vinden van een gemeenschappelijke taal. Het maakt de klant doorgaans niet uit hoe de IT-oplossing werkt. Het maakt hem uit of de dienst zakelijke functies kan vervullen en geld kan binnenbrengen. Bijvoorbeeld: als de site werkt, maar het betalingssysteem ligt eruit, zijn er geen inkomsten van klanten en zijn de ‘extremisten’ nog steeds IT-specialisten. 

Een IT-professional kan om verschillende redenen moeite hebben met dergelijke onderhandelingen:

• De IT-dienst begrijpt de rol van het informatiesysteem in het bedrijfsleven niet volledig. Bijvoorbeeld als er geen beschrijving van bedrijfsprocessen of een transparant bedrijfsmodel beschikbaar is. 
• Niet het hele proces is afhankelijk van de IT-dienst. Bijvoorbeeld wanneer een deel van de werkzaamheden door opdrachtnemers wordt uitgevoerd en IT-specialisten daar geen directe invloed op hebben.

Ik zou het gesprek als volgt structureren: 

1. We leggen bedrijven uit dat ongelukken iedereen overkomen en dat herstel tijd kost. Het beste is om situaties aan te tonen, hoe dit gebeurt en welke gevolgen mogelijk zijn.
2. Wij laten zien dat niet alles afhangt van de IT-dienstverlening, maar dat jij wel bereid bent te helpen met een actieplan op jouw verantwoordelijkheidsgebied.
3. We vragen de zakelijke klant om te antwoorden: als de apocalyps zich voordoet, welk proces moet dan als eerste worden hersteld? Wie participeert daarin en hoe? 

   Vanuit de business wordt een eenvoudig antwoord gevraagd: het callcenter moet bijvoorbeeld 24/7 aanvragen blijven registreren.

4. We vragen een of twee gebruikers van het systeem om dit proces gedetailleerd te beschrijven. 
   Het is beter om een ​​analist in te schakelen als uw bedrijf er een heeft.

   Om te beginnen kan de beschrijving er als volgt uitzien: het callcenter ontvangt verzoeken per telefoon, per post en via berichten van de website. Vervolgens voert hij ze via de webinterface in 1C in, waarna de productie ze op deze manier van daaruit overneemt.

5. Vervolgens kijken we welke hardware- en softwareoplossingen het proces ondersteunen. Voor uitgebreide bescherming houden we rekening met drie niveaus: 
   • applicaties en systemen binnen de site (softwareniveau),   
   • de site zelf waar de systemen draaien (infrastructuurniveau), 
   • netwerk (ze vergeten het vaak).

6. We ontdekken mogelijke faalpunten: systeemknooppunten waarvan de prestaties van de dienst afhankelijk zijn. We noteren afzonderlijk knooppunten die worden ondersteund door andere bedrijven: telecomoperatoren, hostingproviders, datacenters, enzovoort. Hiermee kunt u weer terug naar de zakelijke klant voor de volgende stap.

Waartegen we beschermen: risico's

Vervolgens zoeken wij bij de zakelijke klant uit tegen welke risico’s wij ons eerst beschermen. Alle risico's kunnen in twee groepen worden verdeeld: 

• tijdverlies als gevolg van serviceonderbreking;
• verlies van gegevens als gevolg van fysieke impact, menselijke factoren, enz.

Bedrijven zijn bang om zowel gegevens als tijd te verliezen - dit alles leidt tot geldverlies. Daarom stellen we opnieuw vragen per risicogroep: 

• Kunnen we voor dit proces inschatten hoeveel dataverlies en tijdverlies in geld kost? 
• Welke gegevens mogen we niet kwijtraken? 
• Waar kunnen we geen downtime toestaan? 
• Welke gebeurtenissen zijn het meest waarschijnlijk en het meest bedreigend voor ons?

Na bespreking zullen we begrijpen hoe we faalpunten kunnen prioriteren. 

Hoeveel we beschermen: RPO en RTO 

Wanneer de kritieke faalpunten duidelijk zijn, berekenen wij de RTO- en RPO-indicatoren. 

Ik zal je dat herinneren RTO (doelstelling voor hersteltijd) — dit is de toegestane tijd vanaf het moment van het ongeval totdat de dienst volledig is hersteld. In zakelijke taal is dit acceptabele downtime. Als we weten hoeveel geld het proces heeft opgeleverd, kunnen we de verliezen per minuut downtime berekenen en het acceptabele verlies berekenen. 

RPO (herstelpuntdoelstelling) — geldig gegevensherstelpunt. Het bepaalt de tijd gedurende welke we gegevens kunnen verliezen. Vanuit zakelijk oogpunt kan dataverlies bijvoorbeeld leiden tot boetes. Dergelijke verliezen kunnen ook in geld worden omgezet. 

Voor de eindgebruiker moet de hersteltijd worden berekend: hoe lang kan hij inloggen op het systeem. Daarom tellen we eerst de hersteltijd van alle schakels in de keten bij elkaar op. Hier wordt vaak een fout gemaakt: ze halen de RTO van de provider uit de SLA en vergeten de overige voorwaarden.

Laten we eens naar een specifiek voorbeeld kijken. De gebruiker logt in op 1C, het systeem wordt geopend met een databasefout. Hij neemt contact op met de systeembeheerder. De database staat in de cloud, de systeembeheerder meldt het probleem bij de serviceprovider. Laten we zeggen dat alle communicatie 15 minuten duurt. In de cloud wordt een database van deze omvang binnen een uur hersteld vanaf een back-up. Daarom is de RTO aan de kant van de serviceprovider een uur. Maar dit is niet de uiterste deadline; voor de gebruiker zijn er 15 minuten aan toegevoegd om het probleem op te sporen. 
 
Vervolgens moet de systeembeheerder controleren of de database correct is, deze verbinden met 1C en de services starten. Hiervoor is nog een uur nodig, wat betekent dat de RTO aan de kant van de beheerder al 2 uur en 15 minuten bedraagt. De gebruiker heeft nog 15 minuten nodig: inloggen, controleren of de benodigde transacties zijn verschenen. In dit voorbeeld is de totale servicehersteltijd 2 uur en 30 minuten.

Deze berekeningen laten het bedrijf zien van welke externe factoren de herstelperiode afhankelijk is. Als het kantoor bijvoorbeeld onder water staat, moet u eerst het lek opsporen en repareren. Het zal tijd kosten, die niet afhankelijk is van IT.  

Hoe we beschermen: tools kiezen voor verschillende risico's

Nadat alle punten zijn besproken, begrijpt de klant al wat de kosten van een ongeval voor het bedrijf zijn. Nu kunt u hulpmiddelen kiezen en het budget bespreken. Aan de hand van voorbeelden van klantcases laat ik u zien welke tools wij bieden voor verschillende taken. 

Laten we beginnen met de eerste groep risico's: verliezen als gevolg van serviceuitval. Oplossingen voor dit probleem moeten een goede RTO opleveren.

1. Host de applicatie in de cloud 

   Om te beginnen kunt u eenvoudig naar de cloud overstappen - de provider heeft al nagedacht over de kwesties van hoge beschikbaarheid. Virtualisatiehosts worden samengevoegd tot een cluster, stroom en netwerk worden gereserveerd, gegevens worden opgeslagen op fouttolerante opslagsystemen en de serviceprovider is financieel verantwoordelijk voor downtime.

   U kunt bijvoorbeeld een virtuele machine hosten met een database in de cloud. De applicatie maakt extern verbinding met de database via een gevestigd kanaal of vanuit dezelfde cloud. Als er problemen optreden met een van de servers in het cluster, zal de VM in minder dan 2 minuten opnieuw opstarten op de naburige server. Daarna zal het DBMS erin opstarten en binnen een paar minuten zal de database beschikbaar zijn.

   RTO: gemeten in minuten. Deze voorwaarden kunnen worden vastgelegd in de overeenkomst met de aanbieder.
   kosten: Wij berekenen de kosten van cloudbronnen voor uw applicatie. 
   Waar het je niet tegen zal beschermen: van enorme storingen op de locatie van de provider, bijvoorbeeld als gevolg van ongelukken op stadsniveau.

2. Cluster de applicatie  

   Als je de RTO wilt verbeteren, kun je de vorige optie versterken en direct een geclusterde applicatie in de cloud plaatsen.

   U kunt een cluster in de actief-passieve of actief-actieve modus implementeren. We creëren verschillende VM’s op basis van de vereisten van de leverancier. Voor een grotere betrouwbaarheid verdelen we ze over verschillende servers en opslagsystemen. Als de server met een van de databases uitvalt, neemt het back-upknooppunt de belasting binnen enkele seconden over.

   RTO: Gemeten in seconden.
   kosten: iets duurder dan een gewone cloud, er zijn extra middelen nodig voor clustering.
   Waar het je niet tegen zal beschermen: Biedt nog steeds geen bescherming tegen enorme storingen ter plaatse. Maar lokale verstoringen zullen niet zo lang duren.

   Uit de praktijk: Het retailbedrijf beschikte over verschillende informatiesystemen en websites. Alle databases bevonden zich lokaal in het kantoor van het bedrijf. Er werd niet aan DR gedacht totdat het kantoor meerdere keren achter elkaar zonder stroom kwam te zitten. Klanten waren ontevreden over website-crashes. 
    
   Het probleem met de beschikbaarheid van diensten werd opgelost na de overstap naar de cloud. Bovendien zijn we erin geslaagd de belasting van de databases te optimaliseren door het verkeer tussen de knooppunten te verdelen.

3. Stap over naar een rampbestendige cloud

   Als u ervoor moet zorgen dat het werk zelfs door een natuurramp op de hoofdsite niet wordt onderbroken, kunt u kiezen voor een rampbestendige cloud, waarbij de provider het virtualisatiecluster over 2 datacenters verspreidt. Er vindt voortdurend synchrone replicatie plaats tussen datacenters, één-op-één. De kanalen tussen datacenters zijn gereserveerd en gaan langs verschillende routes, dus zo’n cluster is niet bang voor netwerkproblemen. 

   RTO: neigt naar 0.
   kosten: De duurste cloudoptie. 
   Waar het je niet tegen zal beschermen: Het helpt niet tegen gegevenscorruptie, maar ook niet tegen de menselijke factor, dus het wordt aanbevolen om tegelijkertijd back-ups te maken. 

   Uit de praktijk: Een van onze klanten heeft een uitgebreid rampenherstelplan ontwikkeld. Dit is de strategie die hij koos: 

   • Een rampentolerante cloud beschermt de applicatie tegen storingen op infrastructuurniveau. 
   • Back-up op twee niveaus biedt bescherming in geval van menselijke fouten. Er zijn twee soorten back-ups: “koud” en “warm”. Een “koude” back-up is uitgeschakeld en het duurt even voordat deze is geïmplementeerd. Een ‘hot’ backup is al klaar voor gebruik en wordt sneller hersteld. Het wordt opgeslagen op een speciaal speciaal opslagsysteem. Het derde exemplaar wordt op band opgenomen en in een andere kamer opgeslagen. 

   Eén keer per week test de klant de beveiliging en controleert de functionaliteit van alle backups, ook die vanaf tape. Jaarlijks test het bedrijf de gehele rampbestendige cloud. 

4. Organiseer replicatie naar een andere site 

   Een andere optie om mondiale problemen op de hoofdsite te voorkomen: zorg voor geo-reservering. Met andere woorden: maak back-up virtuele machines op een locatie in een andere stad. Speciale oplossingen voor DR zijn hiervoor geschikt: in ons bedrijf maken wij gebruik van VMware vCloud Availability (vCAV). Met behulp hiervan kunt u de beveiliging tussen verschillende sites van cloudproviders configureren of vanaf een lokale site naar de cloud herstellen. Over de regeling voor het werken met vCAV heb ik al uitgebreider gesproken hier. 

   RPO en RTO: vanaf 5 minuten. 

   kosten: duurder dan de eerste optie, maar goedkoper dan hardwarereplicatie in een rampbestendige cloud. De prijs bestaat uit de kosten van een vCAV-licentie, administratiekosten, de kosten van cloudbronnen en reservebronnen volgens het PAYG-model (10% van de kosten van werkbronnen voor uitgeschakelde VM's).

   Uit de praktijk: De klant bewaarde 6 virtuele machines met verschillende databases in onze cloud in Moskou. In eerste instantie werd de bescherming geboden door middel van back-up: een deel van de back-upkopieën werd opgeslagen in de cloud in Moskou, en een deel werd opgeslagen op onze locatie in St. Petersburg. In de loop van de tijd werden de databases groter en het herstellen vanaf een back-up begon meer tijd te kosten. 
    
   Replicatie op basis van VMware vCloud Availability is toegevoegd aan back-ups. Replica's van virtuele machines worden opgeslagen op een back-upsite in Sint-Petersburg en worden elke 5 minuten bijgewerkt. Als er een storing optreedt op de hoofdlocatie, schakelen medewerkers zelfstandig over naar een replica van de virtuele machine in Sint-Petersburg en blijven ermee werken. 

Alle overwogen oplossingen bieden een hoge beschikbaarheid, maar bieden geen bescherming tegen gegevensverlies als gevolg van een ransomware-virus of een onbedoelde fout van een medewerker. In dit geval hebben we back-ups nodig die de vereiste RPO bieden.

5. Vergeet de back-up niet

Iedereen weet dat je back-ups moet maken, zelfs als je de coolste, rampenbestendige oplossing hebt. Daarom herinner ik u kort aan een paar punten.

Strikt genomen is back-up geen DR. En dat is waarom: 

• Het is een lange tijd. Als de gegevens in terabytes worden gemeten, duurt het herstel meer dan een uur. U moet herstellen, een netwerk toewijzen, controleren of het wordt ingeschakeld en zien of de gegevens in orde zijn. Je kunt dus alleen een goede RTO bieden als er weinig gegevens zijn. 
• Het is mogelijk dat de gegevens de eerste keer niet worden hersteld en dat u tijd nodig heeft om de actie te herhalen. Er zijn bijvoorbeeld momenten waarop we niet precies weten wanneer gegevens verloren zijn gegaan. Laten we zeggen dat het verlies om 15.00 uur werd opgemerkt en dat er elk uur kopieën worden gemaakt. Vanaf 15.00 uur kijken we naar alle herstelpunten: 14:00, 13:00 enzovoort. Als het systeem belangrijk is, proberen we de ouderdom van het herstelpunt te minimaliseren. Maar als de nieuwe back-up niet de benodigde gegevens bevatte, nemen we het volgende punt: dit is extra tijd. 

In dit geval kan het back-upschema het vereiste bieden RPO. Voor back-ups is het belangrijk om geo-reservering te bieden in geval van problemen met de hoofdsite. Het wordt aanbevolen om enkele back-ups afzonderlijk op te slaan.

Het definitieve rampenherstelplan moet minimaal twee instrumenten bevatten:  

• Een van de opties 1-4, die systemen beschermt tegen storingen en vallen.
• Back-up om gegevens tegen verlies te beschermen. 

Het is ook de moeite waard om voor een back-upcommunicatiekanaal te zorgen voor het geval de belangrijkste internetprovider uitvalt. En - voila! — DR tegen minimumlonen is al klaar. 

Bron: www.habr.com