Support-SLA's, back-ups en herstel
Betrouwbaarheidstaal heeft pas waarde als duidelijk is wat er tijdens een echt incident gebeurt. Responstijden, back-upkopieën en herstelvragen hebben scope, eigenaarschap en een geteste procedure nodig.
- Auteur
- Intercube
- Herzien
- Leestijd
- 9 min leestijd
01
Een support-SLA definieert de responsafspraak
Een support-SLA benoemt welke incidenten meetellen, hoe severity wordt bepaald, wanneer de klok loopt en wat een eerste reactie inhoudt. Ze maakt onderscheid tussen support tijdens kantooruren en dekking daarbuiten, en vermeldt welk kanaal klanten moeten gebruiken. Een losse responstijd zonder deze definities helpt weinig tijdens een incident.
Respons is niet hetzelfde als oplossing. Infrastructuurstoringen, applicatiefouten en externe dependencies vragen elk om een ander onderzoek. De afspraak maakt de eerste stap voorspelbaar, terwijl de technische diagnose bepaalt welk herstel nodig is.
02
Back-ups zijn grondstof voor herstel
Een geslaagde back-uptaak bewijst dat data ergens is weggeschreven. Niet dat de juiste data binnen de gewenste tijd kan worden hersteld. Bruikbare afspraken beschrijven scope, frequentie, retentie, scheiding van opslag, toegang, monitoring en het proces om herstel aan te vragen en uit te voeren.
Applicaties combineren vaak databases, uploads, gegenereerde bestanden, zoekindexen en externe systemen. Herstelplanning bepaalt welke bronnen leidend zijn, welke opnieuw opgebouwd kunnen worden en welke hetzelfde moment moeten vertegenwoordigen.
- Welke data en configuratie vallen binnen de back-upscope?
- Hoe vaak worden kopieën gemaakt en hoe lang blijven zij bewaard?
- Wie mag herstel aanvragen, goedkeuren en uitvoeren?
- Hoe wordt herstelde data met applicatiegedrag gevalideerd?
03
RPO en RTO vragen om een werkbaar plan
Een recovery point objective beschrijft het maximaal beoogde dataverlies. Een recovery time objective beschrijft de beoogde tijd om een dienst te herstellen. Beide hangen af van architectuur, back-upontwerp, incidenttype en beslissingen tijdens herstel. Het zijn geen losse marketinggetallen.
Als exacte doelen belangrijk zijn, koppel ze dan aan de betreffende systemen, uitzonderingen, testmethode, escalatie en commerciële afspraak. Een transactionele database kan een ander doel nodig hebben dan mediabestanden of een opnieuw op te bouwen zoekindex.
04
Test de samenwerking, niet alleen de tooling
Incidenten leggen communicatieproblemen net zo snel bloot als technische. Teams moeten weten wie severity bepaalt, waar updates verschijnen, wie applicatiebesluiten neemt en hoe infrastructuur engineers de nodige context krijgen. Beoordeel of oefen dit proces voordat het nodig is.
Een sterke betrouwbaarheidsafspraak combineert degelijke infrastructuur met helder eigenaarschap. Het applicatieteam beheert bedrijfslogica en releases. De hostingpartner beheert het afgesproken platformdeel en leidt infrastructuurwerk. Herstel werkt wanneer die verantwoordelijkheden zonder vertraging aansluiten.
Betrouwbaarheidsvragen voor een incident
- Severitydefinities, responstijden, supportkanalen en dekkingsuren.
- Het verschil tussen eerste reactie, onderzoek en oplossing.
- Back-upscope, frequentie, retentie, monitoring en herstelverantwoordelijkheid.
- Applicatiespecifieke herstelprioriteiten en validatiestappen.
- Communicatie en besliseigenaarschap tijdens een incident.