14 mei 2012 -
Een programmeerfout haalt de website van de NS onderuit. Een softwarefout in een switch legt een ziekenhuis lam. Een software upgrade die werd uitgevoerd veroorzaakt een landelijke verstoring van het mobiele internetverkeer. Een kapot ‘cross connect’ kastje is er de oorzaak van dat alarmnummer 112 urenlang niet bereikbaar is. IT-ers gissen naar de oorzaak van een grote storing bij de Rabobank.
Overal gaat wel eens iets mis en iedereen maakt wel eens een fout. Waar gehakt wordt vallen spaanders. Het menselijk relativeringsvermogen is ook bij IT-ers goed ontwikkeld. Net als andere professionals steken zij echter niet graag de hand in eigen boezem.
De meest in het oog springende rode draad is dat de technologie – die in eerste instantie uitstekend heeft gefunctioneerd – om verder onverklaarde redenen de mens in de steek laat. De achterliggende conclusie is dat technologie inherent onbetrouwbaar is (‘het kan zomaar mis gaan’), terwijl de mens – superieur als wij cognitieve wezens zijn – telkens weer moet optreden als reddende engel. Dit stelt communicatieadviseur Ewold de Bruijne. Foute rekensommen
Twee belangrijke zaken worden structureel zorgvuldig buiten beschouwing gelaten. De eerste is dat de diepere oorzaak, de ‘root cause’, in 80 procent de gevallen menselijk falen betreft. Ergens in het steeds complexer wordende proces van automatisering en IT-beheer maakt iemand een fout. Dat is menselijk en onvermijdelijk, alleen al omdat de kosten van het reduceren van een foutmarge exponentieel oplopen. Economisch gezien (of commercieel beschouwd) wordt het onverantwoord geacht om 100 procent foutloos functioneren te garanderen. Als het menselijke dienstverlening betreft is het humaan om een redelijke mate van tolerantie te hanteren. Van machines mag echter meer worden verwacht. Zeker nu de invloed van machines op het dagelijks leven van vrijwel iedereen in de Westerse wereld al zo groot is geworden.
Lekker klooien
Een tweede aspect dat IT-ers liever niet lijken te willen benoemen, is dat zij bij het opsporen van fouten en het oplossen van problemen angstvallig vast blijven houden aan suboptimale processen en werkwijzen. In plaats van gebruik te maken van de aller-modernste technologie (die gewoon beschikbaar en inmiddels ook heel betaalbaar is), blijven ze in de regel doen wat ze altijd al doen. Daarom duurt het vaak erg lang voordat de oorzaak (het kapotte onderdeel, de verkeerd uit een machine gerolde routine, een fout in de software) wordt gevonden. In plaats van ‘klooien’ gebruiken ze liever het woord ‘testen’. In plaats van ‘geen idee wat er mis is’, zeggen ze liever ‘alles moet opnieuw worden geïnstalleerd’.
Klik op ‘Ignore’
IT-ers ‘bashen’ (kleineren) is commercieel geen handige zet. Bovendien doet dat ook geen recht aan de vakkundigheid die deze professionals echt wel bezitten en ook niet aan hun oprechtheid en gedrevenheid. Ze moeten roeien met de riemen die ze hebben en hun werk wordt er zeker niet eenvoudiger op. De kern van de zaak is echter dat zij riemen laten liggen die weldegelijk binnen handbereik liggen. Veel meer dan zij nu doen, kunnen IT-ers bijvoorbeeld gebruik maken van intelligente, zelflerende expertsystemen.
Superbrein
De ontwikkeling van ondersteunde technologie is inmiddels zo ver gevorderd dat zij zeer effectief gebruik kunnen maken van kunstmatige intelligentie. Slimme machines kunnen andere machines continu monitoren. Ze kunnen moeiteloos de prestaties van alle componenten in de meest complexe infrastructuren real-time in hun onderlinge samenhang analyseren. Ze kunnen als het nodig is duizenden tests tegelijk uitvoeren, systemen resetten, updates uitvoeren, back-up systemen inschakelen, en nog veel meer. In feite is in deze expertsystemen de geaccumuleerde kennis en ervaring opgeslagen van de beste IT-engineers, plus jarenlange ervaring en alle mogelijke statistische gegevens.
Inmiddels lossen de beste op ‘autonomics’ gebaseerde expertsystemen in de praktijk al circa 60 procent van alle ICT-incidenten al op, zonder enige menselijke tussenkomst. Deze systemen reduceren de gemiddelde oplostijd, de ‘mean-time to resolution’ (MTTR), van uren tot minuten – in de meest complexe situaties – en van minuten tot seconden – in de meest eenvoudige situaties. Routines waar hooggeschoolde IT-ers hun hoofd bij moeten houden, voeren deze systemen uit op machinesnelheid.
Laat IT-ers doen waar ze goed in zijn Weerstand tegen de introductie van nieuwe technologie verwacht je eigenlijk overal, behalve in de technologie bepaalde beroepen zelf. Toch is deze paradox springlevend. IT-ers houden niet van robots die hun werk overnemen. Zonde, want als ze dat wel zouden doen, zou dat de betrouwbaarheid van onze steeds complexer wordende IT-systemen ten goede komen. Bovendien zouden zij, IT-ers, zich dan veel meer kunnen richten op waar ze goed in zijn: automatiseringsoplossingen aandragen die onze leven gemakkelijker maken, processen stroomlijnen waardoor de kostprijs van diensten en producten verder omlaag kan, nieuwe creatieve business concepten helpen ontwikkelen, enzovoort.
Grotendeels kan ik me wel vinden in de intonatie en weergave van het artikel. Vaak doe ik nog een stapje terug en bekijk situaties, incidenten met een grootschalig effect, met de nodige afstand.
Nu is dat gegeven niet iedereen gegeven dus zie je soms meer, andere dingen, dan diegenen die er midden in zit.
Kennis en wetmatigheden van de IT
Veel IT-ers hebben weinig tot geen idee hoe de IT zich beweegt als materie, hoe die zich verhoud tot hetgeen waar zij binnen hun eigen vakgebied mee bezig zijn.
Natuurlijk, een professional kan heel goed zijn binnen eigen discipline maar de overall keten, waar zij/hij deel van uit maakt, maakt geen deel uit van diens belevings en ervaringswereld.
Aangezien commerciële bedrijven dit ook niet hebben maar wel targets moeten halen, Non - IT-ers nooit is verteld over de wetmatigheden van de IT, kom je dit soort excessen steeds vaker tegen.
Toekomstige grootschalige incidenten
In andere blogs en reacties heb ik al naar voren gebracht dat de verdeling en heers binnen de IT, het gebruik van IT als sluitstuk op de begrotingen, voor de komende tijd sporen zullen nalaten.
Ik heb daarmee al in verschillende grotere incidenten mijn gelijk bewezen. KPN vs een hacker, Vodafone en een uitgebrand crosspoint in Rotterdam, de in het artikel vermelde incidenten.
We gaan er vast nog wel een paar tegemoet zien de reden? Die is zeer eenvoudig. Als je goed ingevoerde professionals met spoed gaat vervangen door weinig ervaren juniors, omdat het recessie is, dan kom je in aanraking met een andere IT wetmatigheid.
\\\\\\\\\\\\\\\'If you pay Peanuts you\\\\\\\\\\\\\\\'ll get monkeys\\\\\\\\\\\\\\\'
Als je kennis en ervaring wegsaneerd, om welke reden dan ook, en je keten van kennis conserveren niet op orde hebt, dan weet je dat je continue meer zal betalen dan de besparing die je beoogde.
Dat is de keerzijde van automatiseren want zolang er steeds meer mensen, werkzaam in de IT, niet goed weten wat echt automatiseren is, de wetmatigheden ook niet kennen, dan kun je gewoon wachten op het volgende incident.
En zo eenvoudig ligt het dan ook nog eens.
de_speelkelder@hotmail.com
|
|
14
-
05
-
2012
|
12
:
27
uur
naar mijn gevoel een goede kritische doorlichting en misschien leidt dit naar flexibel en creatief denken in IT
Annemieke Hovestadt
|
|
14
-
05
-
2012
|
19
:
25
uur
Als er geen budgetten in organisaties aanwezig waren, zou dit een eerlijk artikel zijn. IT-ers moeten inderdaad roeien met de riemen die ze hebben, maar in organisaties hangt aan iedere riem een prijskaartje; zowel bij proactief als bij reactief gebruik. Oftewel: er is geen oneindig budget en dus zullen er keuzes gemaakt moeten worden. En dan liefst geen pay peanuts keuze.
Ik rechtvaardig geen \\\\\\\\\\\\\\\'blunders\\\\\\\\\\\\\\\' als bij KPN en Vodafone, maar ik pleit wel voor meer begrip voor IT-ers: zonder financiële grenzen kan er meer voorkomen worden, maar uiteindelijk zijn ook IT-ers mensen waar spaanders omheen kunnen liggen om het simpele feit dat ze mensen zijn en hakken. Het probleem is vaak dat mensen die zelf geen verstand hebben van IT wel praten alsof spaanders voorkomen hadden kunnen worden als ze zelf de IT-hakbijl vast hadden gehad. Maar een voorstel in die richting wordt ook niet in dank afgenomen. Ik ben nog op zoek naar een update om dit probleem aan te kunnen pakken...
U stelt het heel aardig. Er lopen teveel mensen rond die spreken alsof ze snappen wat automatiseren is of houden uit hoofde van functie door anciënniteit heel graag een vinger in de pap met allerlei kwalijke gevolgen van dien.
Als je snap hoe IT zich als materie beweegt, weet je meteen hoe er mee om te gaan. Heeft voorts niets meer te maken met proactief of reactief. Het heeft alles te maken in lijn blijven met de materie IT en juist dat is nu precies wat men of niet wil accepteren, of veronachtzaamt door onwetendheid.
In beide gevallen kan dan worden gerefereerd naar de keerzijde van wat je met automatiseren wil beogen. Het gaat je door schade veel meer kosten dan je vooraf dacht te gaan besparen.
Ik kom steeds minder mensen tegen die de materie IT en de werking van IT begrijpen maar steeds meer mensen die heel graag commercieel bezig zijn en dan zie je dus de keerzijden van besparen.
Of, om maar met de laatste negatieve perikelen te spreken de klachten tijdens de examens welke m.b.v. IT werden/worden afgesloten en de IT problemen die men ondervond. Dergelijke problemen kunnen alleen ontstaan door onwetendheid of het uitfaseren van kennis en ervaring door mensen die inderdaad geen enkel idee hebben hoe met IT om te gaan.
Als je, zoals men de voorbij twee jaar heeft gedaan, op deze wijze, op dergelijke schaal, met ervaring, kennis en kunde durft om te gaan met heel veel goedwillende IT professionals, kan dit soort perikelen tegemoet zien.
Dat is overigens wat ik in verschillende fora al meer dan anderhalf jaar propageer. En we zijn al heel aardig aan het afzakken in niveau wat kennis en ervaring betreft. De keerzijde?
Gewoon wachten tot de volgende grootschalige fail. Die zal vast wel weer komen de komende dagen/weken.
IT is een prachtige materie, een boeiend vak maar als je er geen verstand van hebt ....
SimonSaysNoMore
|
|
19
-
05
-
2012
|
10
:
33
uur
Een fout in de `rekensom´. \'\'...de diepere oorzaak, de ‘root cause’, in 80 procent de gevallen menselijk falen betreft.\'\' Het is niet 80% maar 100%. De mensen maken IT oplossingen waar altijd fouten in zitten. Alleen deze fouten openbaren zich (nog) niet. Dus alle fouten in de IT systemen zijn ten gevolge van menselijk falen.
Als testers moeten wij er voor zorgen deze fouten te vinden voordat zij zich openbaren. Dat zal niet altijd lukken. De reden is, dat we ze niet vinden voor de tijd die ons is gegeven om te zoeken. Of, omdat ze er gewoon er in blijven. Het kost te veel geld om de root cause op te lossen, maar de kans dat de fout zich manifesteert is minimaal. Een keuze die managers bewust en bekwaam maken.
We moeten deze feiten accepteren. Weet wel dat de mens leert van zijn fouten. Het kost alleen onschuldige slachtoffers.
Ik sluit me aan bij Simon, zoals ook op mijn blog te lezen is ((Klik hier) Het valt mij erg tegen dat de auteur hier geen inhoudelijke reactie geeft. Het schrijven van een artikel houdt niet op na publicatie...
Ik vind het schandalig hoe hier een volledig vakgebied - testen - wordt gediskwalificeerd. De \'\'oplossingen\'\' die in het artikel genoemd worden, zijn in de dagelijkse praktijk niet haalbaar. Als dit artikel een gedeelte van een afstudeeropdracht zou zijn, had ik het nog kunnnen begrijpen. Het gat tussen de academische wereld - waar 100% foutloze software mogelijk is - en de echte wereld - waar software maken toch ook echt door mensen gedaan wordt en niet foutloos kan - is erg groot.
Ik ben het met de criticasters maar ten dele eens. Het is uiteindelijk namelijk een probleem dat zich bevind in het segment dat uiteindelijk de beslissingen neemt.
Wanneer die goed en juist inzicht heeft in de IT keten, E2E, dan begrijpt die ook waarom stappen in die keten noodzakelijk zijn en denken stappen te kunnen schrappen, uit tijd en winst bejag, heeft dan zo gevolgen en consequenties.
Het prachtige van de materie IT is dat die wat dit betreft erg voorspelbaar is.
Geen testfase? Dan is dat vragen om moeilijkheden bij implementatie of fouten later in het proces.
Geen Change en Release management? Dat is Russisch roulette spelen bij implementatie. Want de kwaliteitsslag en doorlichting van de voorgenomen implementatie blijft achterwege.
Geen Project Manager met kennis van de E2E keten binnen de IT? Prima, niet klagen als er zaken niet op elkaar blijken aan te sluiten want een Project manager betekend niet dat die kennis heeft van IT Project Management.
In het geval van KPN is het domweg duidelijk dat de dame die acte de presence gaf bij twee vandaag, en riep dat klanten zich toch vooral bewust moesten zijn acht te slaan op zorg voor hun wachtwoorden, terwijl het 'leek' dat een hacker systemen van de KPN had gehackt, wel een groot presentatie van incompetentie ten toon spreidde.
Dat later Eelco Blok namens KPN de maatregelen aankondigde en inhoudelijk toegaf dat er sprake bleek te zijn van mogelijke exploits op de systemen van de KPN, pas na twee dagen, waarna men overging tot het afsluiten van de email van twee miljoen klanten, toont precies mijn betoog.
Als je namelijk geen kennis van zaken hebt en na twee dagen bijvoorbeeld eens gaat kijken naar de gepubliceerde lijst op pastebin, iets wat je het eerste uur had kunnen doen, dan toont dit dat de schade door incompetentie of gemis van kennis alleen maar toeneemt.
Wanneer je, in het geval van de brand bij Vodafone, tegen een gecumuleerde schade aankijkt van boven de twaalf miljoen, plus vervolg schade door claims, terwijl je dit door een investering van vijf miljoen voor redundancy had kunnen voorkomen, toont gebrek aan inzicht wat de waarde van strategische componenten betreft.
En dergelijke zaken vertalen zich, met de materie IT, door vervolgkosten die je juist met IT zou moeten kunnen vervolgen. IT is een strategisch corporate component en niet het sluitstuk op de begroting.
Aan de andere kant heeft de auteur van het stuk, ik spreek graag uit eigen ervaring, wel degelijk een aantal punten. Maar dat heeft dan weer veel meer te maken met het gebrek aan regie in de IT chain zelf.
