Als ‘someone else’s computer’ een storing heeft

Ik heb de computers en netwerkcomponenten die voor mij aan het werk zijn zelf nog nooit gezien. Ze zijn ergens en ze doen het gewoon. Het gekke is, ik ken eigenlijk de specialisten van mijn leverancier niet, en zij mij ook niet. Ik weet ook niet precies waar ze vandaan komen en waar ze hun werk doen. Ik weet ook niet precies waar mijn data is en wie er op één of andere manier bij kan.

Trouble in Paradise

Laatst was er een probleempje: mijn leverancier liet weten dat er even geen nieuwe systemen kunnen worden toegevoegd in mijn data center en dat bestaande systemen niet kunnen opschalen. En ook was er een storing niet al te lang geleden. Eentje die een flink aantal van mijn systemen raakte. Sommige stonden uit, dus daar was geen probleem. Andere systemen zijn niet business kritisch dus als die het een poosje niet doen zijn we niet gelijk nerveus.

Een poosje werd trouwens iets van zeven uur, eigenlijk wel erg lang. En we hadden weinig informatie over de storing en hoe lang het oplossen zou gaan duren. Mijn leverancier neemt ook niet met ons direct contact op en begrijpt ook niet de impact van het probleem op onze business. We zijn één van heel veel klanten en krijgen geen persoonlijke benadering. Wanneer precies ons probleem voorbij was, hebben we met trial en error vastgesteld.

Sommige van mijn systemen zijn missie-kritiek: die mogen niet uit. Maar dat gingen ze wel. Voor twee ervan hebben we een multi-region failover-voorziening, maar helaas raakte deze storing ook de failover regio. Een andere keten hebben we deels ook in onze oude, on premises data center draaien. Na een handmatige failover heeft die omgeving gelukkig de grootste problemen kunnen opvangen.

Inmiddels heb ik de analyse gezien van het incident bij mijn leverancier: een menselijke fout, ondanks alle protocollen die dat zouden moeten verhinderen. En ook nog met grote impact. Dat zou mijn eigen IT-staf kunnen gebeuren en natuurlijk ook de professionals die voor mijn leverancier werken.

Public Cloud – met beide voeten op de grond

Mijn nieuwe data center – het zal je duidelijk zijn – is een public cloud. En op veel terreinen zijn we er zeer content mee. De wendbaarheid en productiviteit in development en build-processen, de schaalbaarheid in zware rekentaken en opslagcapaciteit, de tevredenheid van software ontwikkelaars en de hoge mate van inzicht in kosten en prestaties (inclusief de CO2-uitstoot) zijn top. Ook de controle en structuur in uitrolprocessen is enorm vergroot, dankzij de automatisering van de IT zelf – infra as code. En daarmee is het aantal fouten na een release sterk teruggelopen.

De afgelopen periode heeft ook waardevolle inzichten opgeleverd. Zoals hernieuwd: de public cloud is someone else’s computer. Die stuk kan gaan, vol kan raken, wordt door mensen bediend en staat in een fysieke omgeving. De cloud is niet een magische, oneindige, onfeilbare machine. En dat betekent dat we rekening moeten houden met uitval. Uitval die mogelijk meerdere regio’s treft van een leverancier. De SLA-indicaties die mijn leverancier per clouddienst afgeeft, zijn ongetwijfeld een met inrichting onderbouwde ambitie, maar zijn geenszins een garantie. De cloudarchitectuur moet dat onder ogen zien.

Hard werken voor Hoge Beschikbaarheid

Voor echt hoog beschikbare systemen is een passende architectuur nodig, waarin een failover-omgeving en een failover-proces een belangrijke plek innemen. Per keten, per systeem en misschien per feature is de vraag hoe afhankelijk je organisatie ervan is. Welke downtime acceptabel is, en welke alternatieven voor geval van uitval van de primaire omgeving mogelijk en wenselijk zijn.

Voor ultra H/A systemen is een oplossing binnen de omgeving van één leverancier waarschijnlijk niet afdoende. Een tweede, fysiek op afstand gelegen public cloud leverancier, on premises omgeving of private data center (ook wel multi cloud of hybrid cloud) zijn serieus te nemen opties. Met consequenties voor het kunnen toepassen van leverancier specifieke diensten en voorzieningen in de productie-implementatie.

En wat je failover plan ook is – je moet het oefenen. Je moet je scripts en tools en vooral je werkinstructie en je mensen niet pas uitproberen als er een echt incident plaatsheeft. Dat moet regelmatig worden getoetst. En daar hoort bij hoe je systemen na een uitval weer kunt starten: in welke volgorde met wat voor configuratie.

Als gedachtenexperiment: wat als een regio uitvalt en alle gebruikers min of meer tegelijk een failover doen naar één bepaalde fallback regio, wat voor impact zou het starten of opschalen van alle passive of active systemen op de resources in de data centers van die regio kunnen hebben? Dit is uiteraard moeilijk te testen, maar wel in onze procedures mee te wegen.

Conclusion

De middelen die ik dankzij mijn public cloud leverancier tot mijn beschikking heb zijn geweldig. De opbrengsten zijn onomstotelijk. Tegelijk is het essentieel om bewust te zijn van de afhankelijkheid en de risico’s. En de juiste mitigatie te realiseren. Zodat een storing niet grote delen van mijn bedrijf of zelfs van de BV Nederland stillegt.

Lucas Jellema is CTO bij Conclusion.