Op dinsdag 9 mei 2016 had Salesforce last van een verstoring van hun dienstverlening via internet. Salesforce is een bedrijf dat levert software levert om verkoop, relatiebeheer en/of marketing mee uit te voeren. Hun software wordt gebruikt door meer dan 2 miljoen mensen. En op het datacenter van Salesforce in Washington D.C. was een stroomstoring. Waardoor klanten die op dat datacenter zaten geen toegang hadden tot de dienstverlening.
Het probleem werd veroorzaakt door een defecte stroomonderbreker, maar omdat meerdere dubbele voedingssystemen niet waren ingeschakeld, viel vervolgens het hele computersysteem uit. Hierop verhuisde men de dienstverlening naar het datacenter in Chicago en na bijna 2 uur leek de dienstverlening weer hersteld. Helaas waren er fouten in de database waren ontstaan, die ook nog gerepliceerd waren naar de stand-by database. En daarvan de back-up niet goed gegaan, waarmee er geen back-up met meest recente klantdata meer was. Alle pogingen om de laatste versie te herstellen mislukten, dus werd teruggegaan naar de back-up van de vorige dag ervoor. Wel konden alle wijzigingen opnieuw uitgevoerd worden, maar dat bleek niet samen te gaan met de belasting van de servers die dag – ook omdat klanten achterstallig werk wilden inhalen. Dus werd een deel van de functionaliteit uitgeschakeld. Uiteindelijk was na zes dagen alle dienstverlening weer terug op het gewenste niveau.
Dit artikel gaat over storingen in professionele (lees: zakelijke) omgevingen. Over de wet van Murphy. Want in onze ervaring komt een storing daar nooit alleen. En wij vinden dat veel professionele ICT-organisaties laten daar heel veel punten liggen. Want als een ongeluk nooit alleen komt, kan er van elke storing enorm veel geleerd worden. En dat laten veel organisaties liggen.
Waarom een ongeluk nooit alleen komt
De vraag dringt zich op waarom een ongeluk dan nooit alleen komt in professionele ICT-organisaties. Dat komt omdat ICT-organisaties zich wapenen tegen verstoringen. Belangrijke systemen wordt vaak dubbel uitgevoerd. Schijven van individuele servers zijn vaak al dubbel uitgevoerd. Net als voedingen. Er is een back-up oplossing actief. Er is een pieper-systeem geïnstalleerd waarmee storingen nog voordat gebruikers er iets van merken, gedetecteerd worden. Er zijn dus meerdere vangnetten actief om problemen in de operationele systemen te voorkomen.
Dus als er een grote(re) verstoring optreedt, hebben meerdere van deze vangnetten niet gefunctioneerd. Een harde schijf stond al langere ongemerkt in storing. Een voeding was al langere tijd stuk. Het back-up systeem was wel actief, maar is sinds een laatste wijziging niet meer getest. Het pieper-systeem werkt prima voor alle gewone oplossingen, maar niet voor dit broodje speciaal. En natuurlijk vindt deze storing precies plaats in de drukste periode van het jaar, waar het systeem net niet op berekend was.
Zo zie je: een ongeluk komt nooit alleen.
Waarom ICT-organisaties niet leren van verstoringen
De wet van Murphy is keihard van toepassing in professionele ICT-organisaties. Ook al zijn er nog zoveel vangnetten, er gaat altijd wel ergens iets mis, waardoor die verstoring toch optreedt.
Het goede nieuws is: er zijn vaak heel veel leerpunten te halen uit één enkele verstoring. Het slechte nieuws: vaak beperken ICT- organisaties zich tot een paar (niet al te diepgaande) leerpunten per verstoring. Hoe dat kan? Daar zijn meerdere oorzaken voor.
Allereerst wordt er in de ICT voor het leren van verstoringen een term gebruikt, die naar onze mening de lading niet goed dekt: root cause analysis. Dit suggereert dat er maar één oorzaak aangepakt hoeft te worden. Vaak komt er uit de root cause analysis een externe oorzaak die niet of slecht te beïnvloeden is: een leverancier die iets niet goed heeft gedaan, een stroomstoring, een verbinding die uitviel, etc. Dat daarmee de rest van het systeem als dominostenen omviel, wordt gemakshalve vergeten. Daarom spreken we liever van een grondige evaluatie in plaats van een cause analysis.
Ook worden naar onze mening evaluaties niet goed uitgevoerd. Er wordt te smal en te oppervlakkig geëvalueerd.
Te smal omdat men zich vaak beperkt tot de gebieden waar men zelf (het meeste) invloed op heeft. Terwijl andere afdelingen vaak een belangrijke oorzaak zijn van de problemen. Een softwareontwikkelaar die iets ongetest in de operationele omgeving zet bijvoorbeeld.
Te oppervlakkig omdat er vaak niet doorgevraagd wordt: Waarom raakte die server overbelast? Waarom wordt er niet getest? Waarom is die defecte schijf niet eerder opgemerkt? Hoe kunnen we dat voorkomen? Wat kunnen we ervan leren? Hierdoor wordt een heel potentieel leerpunten vaak misgelopen.
Tot slot worden de leerpunten die wel boven gehaald worden vaak niet goed opgevolgd. De punten worden wel ergens op een lijstje gezet, maar vervolgens door de waan van de dag overspoeld. En uiteindelijk nooit opgelost. Totdat de volgende verstoring optreed en men zich afvraagt waarom telkens weer dezelfde (soort) storing optreedt.
Hoe een goede evaluatie te organiseren
Hoe een goede evaluatie te organiseren heb ik uitgebreid beschreven in een ander artikel. Ik zal me hier beperken tot de hoofdpunten. Een goede evaluatie laat zich namelijk raden aan de hand van wat ik hierboven beschreven heb: breed genoeg en diep genoeg, en de leerpunten goed opvolgen.
Een evaluatie maak je breed doe je door de juiste mensen uit te nodigen. Dit betekent iedereen die verantwoordelijk is voor een onderdeel dat een aandeel heeft gehad in de verstoring. Ja, ook je leveranciers horen daarbij. En goede vertegenwoordigers van degenen die last hebben gehad van de verstoring. Of daar last van hadden kunnen hebben. Neem in de doelstelling van bijeenkomst op dat je zoveel mogelijk oorzaken wil wegnemen. En communiceer deze doelstelling aan het begin aan alle aanwezigen.
Een evaluatie maak je diep door dóór te vragen. De 5x waarom-methode is daar een goed middel voor. Door iedere keer de waarom-vraag te stellen op het antwoord van de vorige waarom-vraag kom je achter diepere oorzaken van verstoringen:
- Waarom is de server overbelast geraakt? → Vanwege een nieuwe module die gisteren geïnstalleerd is.
- Waarom veroorzaakt een nieuwe module een overbelasting? → Vanwege een programmeerfout in die module.
- Waarom zitten er programmeerfouten in nieuwe modules? → Omdat ze niet goed getest worden.
- Waarom worden nieuwe modules niet getest? → Omdat load- en stresstesten niet verplicht zijn voor nieuwe modules.
- Waarom zijn load- en stresstesten niet verplicht voor nieuwe modules? → Omdat de load- en stresstesten niet makkelijk uit te voeren zijn voor ontwikkelaars.
- etc.
Conclusie
De conclusie laat zich raden: ook al komt een ongeluk nooit alleen en lijkt de wet van Murphy van toepassing, het goede nieuws is: met één (simpele) verstoring kun je vaak een enorme slag slaan in de stabiliteit van je ICT-systemen. Je hoeft er alleen een grondige evaluatie voor uit te voeren en de leerpunten eruit goed op te volgen. In onze ervaring komen de meeste organisaties binnen vijf grondig uitgevoerde evaluaties naar de gewenste stabiliteit en performance van hun ICT-omgeving. Helaas laten de meeste organisaties deze enorme kans gewoon liggen. En dat vinden wij dood- en doodzonde.
