Kerstavond, een kapotte server en een deadline
Kerstavond. Buiten is het donker en koud, binnen branden de lichtjes in de boom. De meeste kantoren zijn leeg, de mailboxen staan op afwezig en heel Nederland maakt zich op voor een paar rustige dagen. Het is de avond waarop niemand aan het werk denkt. Behalve bij bouwbedrijf Heijmans. Daar wordt nog hard gewerkt aan een aanbesteding. Het bestek moet de deur uit, en de deadline kijkt niet op de kalender. En precies op dat moment gebeurt waar elke organisatie bang voor is: een server houdt ermee op. Servers hebben een vervelende eigenschap. Ze gaan zelden stuk op een rustige dinsdagmiddag, als iedereen op kantoor is en de leverancier binnen een uur op de stoep staat. Ze gaan stuk op vrijdagmiddag om vijf uur, in de zomervakantie, of op kerstavond. Het is geen kwade wil. Het voelt alleen wel zo.
Wie in de IT werkt, kent zulke verhalen. Iedere beheerder heeft er wel een, en ze worden met de jaren mooier. Maar dit verhaal hoeft niet mooier gemaakt te worden. Kerstavond, een aanbesteding en een kapotte server: als je het zou verzinnen, zou niemand het geloven. Dit is het verhaal van die avond. Van een server die uitviel op het slechtst denkbare moment, van een deadline die niet kon schuiven, en van vier uur waarin het erop aankwam. Het is ook een verhaal over iets waar je liever niet over nadenkt tot het te laat is: wat doe je als het misgaat?
Storing op kerstavond
Om te begrijpen waarom deze storing zo hard aankwam, moet je iets weten over aanbestedingen. In de bouw worden grote opdrachten zelden zomaar gegund. De opdrachtgever beschrijft wat hij wil laten bouwen, en bouwbedrijven schrijven zich daarop in met een plan en een prijs. Aan zo'n inschrijving wordt vaak wekenlang gewerkt, door calculators, werkvoorbereiders, inkopers en projectleiders. Er zitten tekeningen in, berekeningen, planningen en prijzen van onderaannemers. En dan is er de deadline. Die is bij een aanbesteding heilig. Een inschrijving die te laat binnenkomt, doet niet mee. Niet een beetje minder, maar helemaal niet. Er is geen uitstel wegens omstandigheden en geen begrip voor een kapotte computer. Weken werk zijn dan in één klap niets meer waard, en de kans op de opdracht is verkeken.
Bovendien draait een modern bouwbedrijf net zo goed op computers als op kranen. Calculaties, tekeningen, planningen en contracten: het staat allemaal digitaal, en het staat allemaal ergens. Zolang dat ergens bereikbaar is, denkt niemand erover na. Maar valt de plek weg waar alles samenkomt, dan staat een heel team met lege handen. De kennis zit in de hoofden, het werk zit in de server. Stel je dan de situatie voor. De stukken zijn zo goed als klaar. De laatste controles lopen. En dan reageert het systeem niet meer. Bestanden zijn niet te openen. De documenten waar al die weken aan gewerkt is, staan op een server die niets meer doet. De klok tikt door. In zo'n moment gebeuren er meestal twee dingen. Eerst probeert iedereen het nog een keer. Opnieuw klikken, opnieuw opstarten, even wachten. Daarna dringt het door dat dit niet vanzelf overgaat, en gaat de telefoon. De vraag is dan niet meer wat het kost of wanneer het uitkomt. De vraag is: kan er nu iemand komen?
Dat is het moment waarop blijkt wat een IT-partner waard is. Op een gewone werkdag is iedereen bereikbaar. Op kerstavond is het een ander verhaal. Wie dan opneemt, luistert en zegt dat hij eraan begint, is op dat moment de belangrijkste leverancier die een bedrijf heeft. En er speelt nog iets mee. Op een avond als deze is er geen achtervang. De leverancier van het onderdeel is dicht, de groothandel is dicht en de collega die het systeem ooit heeft ingericht zit ergens aan een gedekte tafel. Wat er opgelost moet worden, moet worden opgelost met wat er op dat moment voorhanden is: de kennis in je hoofd, het gereedschap in je tas en de reserveonderdelen die er toevallig liggen. Dat maakt een spoedklus op een feestdag wezenlijk anders dan dezelfde klus op een gewone werkdag.
Binnen 4 uur weer online
Bij een spoedreparatie is haast de grootste vijand. Dat klinkt tegenstrijdig, maar iedereen die weleens onder druk een storing heeft opgelost, herkent het. De neiging is om meteen van alles te proberen. Onderdelen wisselen, instellingen terugzetten, herstarten en hopen. Soms heb je geluk. Vaker maak je het erger, en ben je kostbare tijd kwijt aan het opruimen van je eigen pogingen. Een goede spoedreparatie begint daarom met een paar minuten rust. Wat doet het nog wel, en wat niet meer? Wat is er als laatste veranderd? Wat zeggen de meldingen en de logboeken? Het is het werk van een dokter op de eerste hulp: eerst kijken wat er aan de hand is, dan pas behandelen. Ervaring maakt hier het verschil. Wie al vaker een server heeft zien uitvallen, herkent patronen. Hij weet welke oorzaken het meest voorkomen en in welke volgorde je ze het snelst kunt uitsluiten. Hij weet ook wat hij niet moet doen: de stap die het probleem misschien oplost, maar die bij pech de gegevens onherstelbaar beschadigt. Onder tijdsdruk is dat laatste het moeilijkst. Er staat iemand naast je die elk kwartier vraagt hoe lang het nog duurt, en de verleiding om een gok te wagen is groot. Vakmanschap is op zo'n moment vooral de discipline om het niet te doen.
Daarna komt de keuze tussen repareren en omzeilen. Bij een storing met een deadline is dat de belangrijkste afweging. Het doel is niet een perfecte server. Het doel is dat de mensen weer bij hun werk kunnen. Soms is de snelste weg het herstellen van het defect. Soms is het verstandiger om de dienst eerst op een andere manier in de lucht te krijgen, en de nette oplossing te bewaren voor na de feestdagen. Wie het einddoel scherp voor ogen houdt, maakt hier de juiste keuze. Er hoort ook iets anders bij: communiceren. Wie zit te wachten met een deadline in zijn nek, wil weten waar hij aan toe is. Niet elk kwartier een technische uitleg, maar wel een eerlijk beeld. Dit weten we, dit proberen we nu, zo lang denken we nodig te hebben. Dan kunnen de mensen aan de andere kant ook plannen. Kunnen ze alvast iets voorbereiden? Moet er een noodscenario komen? Stilte is bij een storing bijna net zo erg als de storing zelf.
Wat er die avond precies stuk was, is voor dit verhaal minder belangrijk dan de uitkomst. Binnen vier uur draaide de complete omgeving weer. Vier uur. Dat is korter dan menig kerstdiner. In die tijd is de oorzaak gevonden, het probleem verholpen en gecontroleerd of alles weer deed wat het moest doen. Dat laatste wordt weleens vergeten. Een server die weer aan staat, is nog geen werkende omgeving. Kunnen de medewerkers weer inloggen? Zijn de bestanden compleet? Is het werk van die middag er nog? Werkt de printer? Pas als op al die vragen het antwoord ja is, is een storing echt voorbij. Niets is erger dan opgelucht ademhalen en een kwartier later ontdekken dat het belangrijkste document ontbreekt.
De offerte op tijd de deur uit
Het mooiste geluid van die kerstavond was niet een server die weer opstartte. Het was de printer die begon te lopen. Pagina na pagina kwam de offerte eruit. Het bestek ging op tijd de deur uit, en Heijmans deed mee aan de aanbesteding. Voor de mensen die er die avond bij waren, zal het vooral een opluchting zijn geweest. Jassen aan, licht uit, alsnog naar huis. Maar achter dat moment zit een les die elke organisatie aangaat, ook als je geen bouwbedrijf bent en nog nooit een bestek hebt gezien. Kritische infrastructuur is onzichtbaar zolang ze werkt. Niemand staat 's ochtends op en denkt: wat fijn dat de server het doet. Je merkt pas dat hij bestaat als hij uitvalt. En dan blijkt in één keer hoeveel ervan afhangt. Het loont daarom om er op een rustig moment over na te denken, in plaats van op kerstavond.
Een paar vragen om jezelf te stellen. Welke systemen kunnen we echt geen dag missen? Vaak zijn dat er minder dan je denkt, maar je moet wel weten welke. Wat gebeurt er als zo'n systeem uitvalt? Is er een reservekopie, en heeft iemand weleens geprobeerd die terug te zetten? Een back-up die nooit getest is, is een gok en geen plan. Merken we het op tijd als er iets misgaat? Veel storingen kondigen zich aan, met een schijf die vol raakt of een onderdeel dat fouten begint te geven. Wie dat in de gaten houdt, voorkomt een deel van de noodgevallen. En de belangrijkste vraag: wie bellen we als het toch gebeurt, en neemt die dan op? Geen van die vragen is ingewikkeld. Ze worden alleen zelden gesteld, omdat er altijd iets dringenders is. Tot de avond dat de server besluit dat het genoeg is geweest.
Wie die vragen wel op tijd stelt, komt vaak tot dezelfde conclusie: honderd procent zekerheid bestaat niet. Elk onderdeel kan stukgaan, hoe duur het ook was en hoe goed het ook is onderhouden. Het doel van goed beheer is daarom niet dat er nooit iets uitvalt. Het doel is dat een storing klein blijft. Dat er een reserve klaarstaat, dat de gegevens veilig zijn en dat er iemand is die weet wat hem te doen staat. Een bedrijf dat dat geregeld heeft, beleeft een storing als een vervelende avond. Een bedrijf dat het niet geregeld heeft, beleeft dezelfde storing als een ramp. Voor Heijmans liep het goed af. Een gehaalde deadline in plaats van een gemiste kans, en een verhaal dat op de kerstborrel van het jaar daarna vast nog eens verteld is. Maar het had ook anders kunnen lopen. Het verschil zat in vier uur, en in iemand die de telefoon opnam.
Wil je weten hoe jouw kritische systemen ervoor staan, of zoek je een partner die er ook is als het tegenzit? Neem contact op met Basecode. Liever op een gewone dinsdag dan op kerstavond.