Disaster Recovery Plan

X-Guard B.V. heeft een beschrijving, contactpersonen en plan per service waarbij een storing of incident kan plaatsvinden. Alle elementen in onze dienstverlening zijn onderdeel van een ‘’self healing auto scaling microservice architecture’’. Dit betekent concreet dat in bijna alle gevallen een probleem opgelost wordt door slimme horizontale schaling. Dit betekent uiteraard niet dat we geen problemen kunnen voorkomen waarbij meer nodig is dan auto-recovery.

De plannen per service zijn niet openbaar. Deze bevatten persoonsgegevens van personeel en details over netwerk- en softwarearchitectuur die niet publiek (of met klanten) gedeeld worden. In onze SLA staat gedefinieerd aan welke verplichting wij moeten voldoen om de continuïteit van de service te garanderen. De continuïteit is erg belangrijk: we werken met alarmen en elk alarm dat niet verzonden kan worden om welke reden dan ook, is een ernstige situatie.

De IT servicedesk van X-Guard is 24/7 beschikbaar voor het oplossen van eventuele problemen. Zoals genoemd in de SLA wordt alle communicatie over storingen en onderhoud gevoerd via https://status.x-guard.nl.

Alle elementen in onze microservice architectuur worden automatisch getest (wekelijks) via een tooling die ‘random’ elementen laat vastlopen. Dit gebeurt bijvoorbeeld met tooling als Pumba (https://github.com/alexei-led/pumba). Dit verzekerd de continuïteit en geeft antwoord op de vraag wanneer er voor het laatst getest is.

Bijna alle updates die wij plaatsen zijn ‘’zero impact’’ en worden uitgerold tijdens kantooruren aan het begin van de week. Wanneer een update wel downtime heeft, zal hier uiterlijk één week vóór het onderhoud een aankondiging over gedaan worden, inclusief de tijdswindow. Het bepalen van de window wordt gedaan op basis van de inhoud van de update, er zijn hier geen generieke richtlijnen voor omdat elke update specifieke aandachtspunten heeft die de afweging voor het juiste moment beïnvloeden.

Elke versie van de app, maar ook van andere softwarecomponenten, worden altijd uitgebreid getest in meerdere fasen:

  • Local development
  • Pull request reviews
  • Shared remote developement tests
  • Alpha testing
  • Beta testing
  • (Release candidate)
  • Stable

In alle fasen van het ontwikkelproces wordt er scherp op toegezien dat er geen nieuwe problemen worden geïntroduceerd. De applicatie wordt actief getest op ±10 verschillende telefoons en periodiek getest op nog eens ±20 telefoons.

Op zoek naar meer informatie?