"Tegen mijn mensen zeg ik altijd: "luister, je gaat regelmatig domme dingen doen", zegt IT-director Rich Casselberry van Enterasys, een leverancier van netwerksystemen. "Je mag best iets stoms doen als je over de verkeerde informatie beschikt. Maar het wordt pas echt een probleem als je iets doms doet omdat je dom bent. Het is zaak om op zulke momenten niet te flippen, waardoor het ongeval alleen maar ernstiger wordt, en je moet de boel ook niet proberen weg te moffelen. Je moet juist proberen om herhaling te voorkomen."

Wij hebben een paar pareltjes verzameld van systeembeheerders die dapper genoeg waren om hun blunders met ons te delen. Verprutste back-ups, mensen met adminrechten die ze beter niet hadden kunnen hebben, dingen die mis kunnen gaan bij het uitschakelen van de verkeerde apparatuur… in sommige gevallen hebben we de namen gefingeerd om de betrokkenen te sparen. Andere techneuten wilden best hun jeugdzonden met naam en toenaam delen.

Achteraf gezien zijn deze rampjes uiteraard heel erg grappig, maar lach vooral niet te hard. We weten vrij zeker dat jij ooit eens harder af bent gegaan, ooit.

Bekentenis nummer 1: De zaak van de mysterieuze, onzichtbare back-up

Ons eerste verhaal van rampspoed draait om een ervaren ict-pro die niet bij zijn echte naam genoemd wil worden, dus we noemen hem even Guus Ongeluk.

Guus is het allemaal niet bespaard gebleven vanaf het moment dat hij tien jaar geleden is begonnen bij een grote producent van netwerkapparatuur in het noordoosten van de Verenigde Staten. Zo was daar de dag dat hij een variabele in de omgeving veranderde waardoor alle financiële applicaties crashten. Dat kwam hem op een e-mail van zijn baas te staan met het verzoek "om nooit meer te hacken op dit systeem". Of wat de denken van die keer dat hij het centrale ERP-systeem onderuit haalde door /dev/tty te overschrijven? Volgens Guus is het hem verboden ooit nog voet te zetten in de telecom-kast, sinds het moment dat hij het klaarspeelde om de hele T1-verbinding met zijn pager plat te leggen.

Maar zijn grootste ramp kwam toen hij een Emerald-systeem voor tape back-up installeerde. Hoezo handleiding lezen? Het draaien van install.exe moet genoeg zijn. Kinderspel.

Het leek allemaal prima te werken. Vier uur later kwam de eerste back-up van de band rollen, en alles zag er goed uit.

We spoelen de band even zes maanden door. Guus wordt 's nachts thuis opgebeld door een van zijn vrienden van het werk. De tape van die avond is volledig leeg, zo meldt zijn collega. Sterker, alle tapes van de afgelopen vier weken zijn leeg.

Al snel kwam Guus erachter dat de back-upsoftware standaard in demo-modus werd ingesteld. Demo-modus gedraagt zich precies zoals de gewone modus, met een even lange duur van verschillende operaties, met als enige verschil dat helemaal niets naar de tapes werd weggeschreven. Dat stond keurig in de handleiding, maar die had Guus dus niet van tevoren gelezen.

Gelukkig gebruikte het bedrijf ADP voor het verwerken van de loonstrookjes, en die hadden nog wel alle gegevens netjes bewaard. Slechts een week ging er uiteindelijk aan data verloren. Het slechte nieuws? Guus moest tot drie uur 's nachts loonstrookenvelopjes vullen samen met zijn baas, het hoofd van de financiële afdeling, de complete loonafdeling en de nieuwe CIO van het bedrijf die hij op dat moment voor het eerst ontmoette.

"Ik moet zeggen, ik had me bijzonder populair gemaakt", grapt Guus. "Volgens mij ben ik niet ontslagen omdat ze het van mij gewend zijn. Ik kan niks goed doen, zo moeten ze hebben gedacht."

Wat hebben we allemaal geleerd, spelende vrouw? 1: je moet niet de back-ups testen, maar de restore, zegt Guus. "Niemand kan het een zier schelen of de back-ups het doen, het gaat om de restores." 2: Denk na voordat je tikt. 3: Neem voor alle zekerheid je pager (of Blackberry) niet mee de telecom-kast in.

Bekentenis nummer 2: Soms vergt het een conciërge om de troep op de ict-afdeling op te ruimen

Op een late avond in 1997 was Josh Stephens in zijn eentje aan het werk met de console bij een groot telecombedrijf in het midwesten van de VS. Hij voerde wat wijzigingen door aan de Cisco Catalyst-switches van de belangrijkste klant van zijn bedrijf, die zich enkele staten verderop bevond. Dat is waar het helemaal fout ging.

"Ik weet nog steeds niet hoe ik het voor elkaar kreeg, maar om de een of andere reden riep ik een broadcast storm op en ging de STP zo tekeer dat niet alleen de switch waar ik in zat afsloeg, maar dat alle switches in hetzelfde gebouw dat deden", zegt Stephens. Die storm trof honderden gebruikers van het callcentrum, waarbij velen midden in hun klantgesprekken werden afgebroken.

Het ergste was dat alle switches 'hard' uitgeschakeld moesten worden, en een voor een methodisch geheel moesten worden opgestart. Het datacentrum was honderden kilometers verderop, en er was geen ict-personeel gestationeerd. Dus belde Stephens de mensen op die daar nog het meest bij in de buurt kwamen: de facilitaire dienst.

"Uiteindelijk kwam ik uit bij een conciërge die de sleutels had tot al mijn LAN-kasten. Die heb ik telefonisch gewezen naar de Catalyst-switches, en hem uitgelegd hoe ze uit te schakelen", zegt hij. "Ik heb hem ook beloofd dat hij niet ontslagen zou worden als er iets mis zou gaan."

Ondanks dat het callcentrum er voor meer dan een uur uit lag, kwam niemand te weten waar de storing aan lag, zegt Stephens, die tegenwoordig VP Technologie en Hoofd Geek (ja, dat is de officiële titel!) is bij SolarWinds, een producent van software voor netwerkbeheer.

De lessen? 1: Voer geen veranderingen door zonder dat je het hebt ingepland op een geschikt moment, hoe klein deze ook lijken, zegt Stephens. 2: Doe nooit een Change Control als je geen ict-middelen in de buurt van de apparatuur tot je beschikking hebt om op terug te vallen. 3: Wees aardig tegen conciërges. Ze zouden wel eens een keer je hachje kunnen redden.

Bekentenis nummer 3: Weg bij die terminal en handen in de lucht!

Een van de onvermijdelijke dingen in het leven van een techie is dat wanneer managers adminrechten krijgen op ingewikkelde systemen, het regelmatig verkeerd afloopt.

Johanna Rothman was eind jaren 80 hoofd ontwikkeling bij een kleine producent van gedistribueerde verwerkingssystemen in de buurt van Boston. Het management dwong zijn werknemers tot het maken van overuren, en daar hoorde Rothman bij. Na drie maanden was Rothman en haar team chagrijnig en uitgeput, waardoor een ongeluk in een klein hoekje zat.

"Het was op een avond rond negen uur dat ik zag dat we een verzameling bestanden hadden die moesten worden gewist", vertelt Rothman. "Ik zat op een Unixsysteem, en die liet mij niet toe om de bestanden te verwijderen omdat ik geen root-toegang had. Goed, ik was het hoofd van de afdeling, dus ik heb het root-wachtwoord. Ik log in als root. I draai rm –r (recursieve delete) op de map waarvan ik zeker weet dat het de juiste map is. Dat wist ik gewoon!"

Na een tijdje houdt het rm-commando ermee op. Rothman, die op dat moment nog steeds alle applicaties aan het wissen was, sluit het proces af en belt de ict-beheerder om uit te leggen wat ze gedaan had.

"Hij zei: "Ga bij het toetsenbord vandaan, ik kom langs om een restore uit te voeren." Daarop zei ik: "Ik kan helpen, waar zijn de tapes?", waarop hij antwoordde: "Ga gewoon, loop weg. Meer hulp heb ik niet van jou nodig.""

Het terugzetten duurde twee dagen. Op beide dagen nam ze een uitslaapdag, en ze beval haar team om hetzelfde te doen. Ze liet ook verontschuldigende voicemails achter bij alle ontwikkelaars.

"Ik denk dat de enige reden dat ze me niet hebben ontslagen is dat het management het te druk had met de crisis, en niet hadden gezien wat voor een potje ik ervan had gemaakt", zegt Rothman, die tegenwoordig leiding geeft aan haar eigen ict-consultancy en zich verre houdt van Unix root-mappen.

Lering die we hieruit trekken? 1: Het is absoluut onnodig dat leidinggevenden de beschikking hebben over het root-wachtwoord, zegt Rothman. 2: Te veel overwerk maakt mensen moe en dom. Hoe vermoeider ze zijn, des te stommer de dingen worden die ze doen.

Bekentenis nummer 4: "Sure, we can"

Hier een zeldzaam geval van een back-upramp waarbij de back-up op zich geslaagd is. Minder geslaagd is het medium waar de gegevens naartoe zijn weggeschreven.

We schrijven 27 jaar geleden, en David Guggenheim heeft net zijn eerste 'echte' baan binnen als manager voor biologische gegevens bij een milieuconsultancy in zuidelijk Californië. Het was een tijd dat het bedrijf zelf een PDP-11 had staan, en via dial-up toegang had tot een time-share IBM 360 Mainframe in Los Angeles.

"We moesten een belangrijk project die op die mainframe stond archiveren. Dus ging ik aan de slag en voerde ik de JCL (Job Control Language) in zodat onze gegevens op tape zouden worden gezet die vervolgens naar ons kantoor worden verstuurd", zegt hij. "Ik verstuurde de opdacht, gerustgesteld dat onze gegevens een veilige back-up tegemoet gaan."

Een paar dagen later stak een bezorger zijn hoofd door onze deur, en schreeuwde: "Is hier een David Guggenheim aanwezig?"

In zijn vrachtwagen stonden de dozen opgestapeld tot het plafond van de laadruimte, en allemaal waren ze geadresseerd aan Guggenheim. Hij opende de eerste doos, en die was helemaal gevuld met ponskaarten. Voor alle andere dozen gold hetzelfde.

"Het was onze data van de mainframe", zegt hij. "Ik realiseerde tot mijn afschuw dat ik niet output naar tape heb gespecificeerd, maar output naar ponskaart. Heel precies kan ik mijn JCL niet meer herinneren, maar het verschil zat hem volgens mij tussen een specificatie '=0' en '=1'. Het was een vernedering."

Het werd nog erger. De rekening kwam binnen, een paar dagen nadat de medewerkers genoeg vloerruimte hadden gemaakt om al die dozen kwijt te kunnen. Een back-up naar ponskaart kostte 1000 dollar, en dat zijn de dollars uit 1982.

"Ik had het hele budget naar de maan geholpen, een bos uitgeroeid, en nog stonden onze gegevens niet op tape", zegt Guggenheim, tegenwoordig Dr. Guggenheim PhD, voorzitter van 1planet 1ocean, en een senior-lid van The Ocean Foundation. "Vanaf dat moment heb ik mijn carrière aangewend om het milieu te verbeteren, zodat ik het misschien een beetje goed kan maken voor al die dode bomen die ik heb veroorzaakt."

De lessen? 1: Kleine vergissingen kunnen grote gevolgen hebben, dus controleer alles tot vervelens toe. 2: Erken je fouten meteen. Schaamte is een goede leraar. 3: Je moet wel de humor inzien van een enorme blunder, zegt Guggenheim. "Dan komt hij een stuk minder hard aan."

Bekentenis nummer 5: "We trekken de stekker eruit! Letterlijk!"

Eentje van eigen bodem. Midden jaren 90 was Jan Aleman een interim ict-manager voor KPN in Nederland, als tijdelijk vervanging voor een ontslagen CTO. Voordat de CTO werd weggewuifd, had deze nog wel een failover-systeem voor de facturering aangeschaft bij IBM voor de lieve som van 300.000 dollar.

"Een bijzonder kundige verkoper van IBM had hem dat veel te dure stukje hardware aan weten te smeren, met de garantie dat als het primaire systeem het begeeft, de processen naadloos overgaan naar de secundaire systemen", zegt Aleman. "Het zou compleet redundant zijn, en helemaal niets kon verkeerd gaan. Nou, ok, zei ik: laten we even kijken of het werkt."

Aleman trok onder de neus van de IBM-verkoper de stekker eruit van het primaire systeem. Alle kernsystemen van het bedrijven gingen op zwart. Het bedrijfskritische factureringssyteem lag er voor de rest van de middag uit. De telecomswitches draaiden nog wel, maar niemand op het kantoor kon zijn werk nog doen.

Hoewel het failoversysteem draaide, was deze nooit getest. Aleman stelde daarop direct verplichte tweewekelijkse testen in voor tijdens het weekeinde.

"Ik had de stekker uit het bedrijf getrokken", zegt Aleman, tegenwoordig CEO bij Servoy, een ontwikkelaar van hybride SaaS/on-premise software. "De directie was uiteraard niet blij, maar voor mij had het geen consequenties. Ik vraag me nog steeds af hoe ik dat geflikt heb."

Wat hebben we geleerd? 1: Test systemen altijd uit voordat je het bedrijf ervan af laat hangen. 2: Denk goed, lang en ernstig na voordat je een stekker uit de muur trekt.

Bekentenis nummer 6: Zorg goed voor mijn domein!

'Fred' (niet zijn echte naam) was in 2003 ict-manager voor een plaatselijke kabelaar in het midwesten van de VS. Dat bedrijf had toen zo'n 35.000 abonnees. Om de dienstverlening naar een hoger plan te trekken, besloot het om een doorverkoper te worden van domeinnamen voor Network Solutions.

Bij het overdragen van de verkochte domeinnamen werden alle aanvragen tot verlenging doorgestuurd naar iemand van de business support unit van Network Solutions. "We gingen ervan uit dat alleen de domeingerelateerde berichten van klanten daar naartoe gingen, en niet die van onze eigen domeinen", zegt Fred. Hij kwam er snel achter dat de veronderstelling de moeder is van onwetendheid.

Want ja hoor: op een avond rond 10 uur vloog alles bij de ISP eruit: DNS, e-mail, de eigen websites, websites gehost voor zakelijke klanten- alles deed gewoon poef.

Het probleem? De ISP was zelf vergeten om zijn domeinen te vernieuwen. De medewerker op business support dacht dat Fred berichten kreeg over de vernieuwingen (die kreeg hij niet), en Fred dacht dat alles pico bello in orde was, omdat hij geen bericht kreeg (pico bello was het niet).

"Tegen de tijd dat we wisten wat het probleem was, je denkt er immers niet snel aan om even te kijken of je domein verlopen was, waren we van de rootservers geschopt. Het duurde 24 uur voordat alles weer draaide", zegt Fred. Om het maar te schetsen met een variant op de bekende reclames van Mastercard: 1) domeinvernieuwing: Een tientje. 2) een laat belletje naar klantondersteuning: 0 dollar. 3) het over de kop laten gaan van de internetverbinding en e-mail van 35.000 mensen in je woonplaats: onbetaalbaar.

Geleerde lessen? 1: Zorg ervoor dat belangrijke meldingen naar meerdere mensen verstuurd worden. 2: Leg je domeinnamen vast voor tien jaar, zodat je er bijna zeker van kan zijn dat eventuele vernieuwingen op het bordje van je opvolger komen.

Bekentenis nummer 7: Soms kun je gewoon bluffen

'Paul' (niet zijn echte naam) werkte vier jaar geleden als freelance data-analyst aan een project voor een Amerikaanse overheidsklant, ter waarde van 20.000 dollar. Na twee maanden zwoegen leverde hij een eerste draft van het project aan, en vertrok voor een zakelijk tripje van een week.

Voordat hij vertrok brandde Paul alle projectgegevens op een schijfje, zodat hij het in het hotel kon afmaken. En zoals hij dat altijd deed, wiste hij de 4 GB aan bestanden om schijfruimte vrij te maken.

Je kon het zien aankomen: Paul raakte zijn schijfje kwijt: 20.000 dollar aan werk weg in een oogwenk. Wat doe je dan als slimme consulent? Natuurlijk, je stuurt een factuur naar de klant voor het complete project, en binnen mum van tijd ontving hij een cheque.

"Na een half jaar had ik nog niets van die klant gehoord", zegt Paul. "Dat vond ik ongelooflijk, want op zijn minst had ik gerekend op commentaar en veranderingen aan de draft. Na een jaar nog steeds niets."

Pas twee jaar na het indienen van de draft kwam het gevreesde telefoontje.

"'Ga je het project nog afmaken?' was de vraag die aan de andere kant van de telefoon werd gesteld", zegt Paul. "Ik antwoordde dat ik met geen mogelijkheid nog met de gegevens van twee jaar terug verder kon werken, of dat ik nog achter de adviezen van toen kon gaan staan. Uiteraard wist ik dondersgoed dat ik hoe dan ook geen nieuwe gegevens of actuele adviezen kon verstrekken gebaseerd op de oorspronkelijke gegevens. De klant accepteerde die uitleg gelukkig, en begon over de prijs van een eventueel nieuw project."

Om zichzelf in te dekken voegt Paul er nog wel aan toe dat die eerste draft voor 95 procent volledig was, en dat de klant hem had gezegd dat ze veel van zijn adviezen al hadden toegepast.

Paul is hervormd tot een absolute 'back-up-malloot'.

"Ik kan op elk willekeurig moment ongeveer tien kopieën van al mijn gegevens overleggen, en ik kan hoe dan ook gegevens van ieder project binnen vijf minuten terughalen, ook al is het al drie jaar oud", vertelt Paul. "Ik heb een harde les geleerd en die ga ik voorlopig niet vergeten."

De lesjes nog eens op een rij? 1: Je kunt nooit te veel back-ups hebben. 2: Hou harde kopieën bij de hand, voor het geval dat. 3:Mocht je toch al je gegevens verliezen voordat je het uiteindelijke product hebt geleverd, zorg er dan voor dat je op dat moment voor de overheid werkt. Die let misschien niet op.

Bron: Techworld