Het ergste wat je als bouwer van digitale infrastructuren kan overkomen, is dat je spullen niet gebruikt worden. Het op een na ergste wat je kan gebeuren, is dat je spullen veel meer worden gebruikt dan oorspronkelijk de bedoeling was.
Er ontstaat dan wat ik noem: ‘sla-creep’, naar analogie van het begrip ‘scope creep’ dat wordt gebruikt bij projecten die alsmaar uitdijen in doelstelling. Je oorspronkelijke service level agreement (sla) wordt steeds verder opgerekt. Meer en meer toepassingen maken gebruik van die servers en firewalls, en wat er allemaal maar in de infrastructuur aanwezig is. De openingstijden worden langer, de afhankelijkheden worden groter, terwijl de toegelaten downtime minder wordt.
Op een dag blijk je ineens niet meer genoeg service-windows te hebben om de upgrades van de leveranciers bij te houden. Uiteindelijk heb je geen enkel service-window meer over en ben je dus niet meer in staat bent om die infrastructuur te vervangen zonder de afgesproken dienstverlening te schaden. De organisatie is er te afhankelijk van geworden.
Als je lang voor de wind vaart raak je aan lager wal.
Ik zie dit gevaar steeds vaker opdoemen. Het antwoord is, net als bij zeilen: ga op tijd overstag! Je infrastructuur moet eigenlijk in staat zijn om tijdens kantooruren opgewaardeerd te worden. Ook al draai je productie, het zou mogelijk moeten zijn om delen van je infrastructuur in-, uit-, of om te schakelen, op een manier die nauwelijks waarneembaar is voor de gebruikers. Dit vergt een doordacht ontwerp, en toepassing van allerhande redundantietechnieken. Dat is niet eenvoudig, maar deze technieken zijn in veel gevallen wel beschikbaar. Stel deze eisen op tijd. Bij de ene applicatie of database is het ingebouwd. Bij andere is deze redundantie slechts met hoge infrastructurele kosten te bereiken.
Doe je dit goed, dan test je als infrastructuurbeheerder meteen bij elke upgrade je ‘fail-over’ of ‘disaster recovery’. Dat deed je toch al te weinig.
