Een nieuwe kijk op ketenmonitoring

Ieder bedrijf is bekend met de last die ICT-verstoringen kunnen veroorzaken. Bij ProRail hebben die verstoringen soms grote gevolgen voor het treinverkeer. Een nieuwe kijk op ketenmonitoring wordt ingezet om verstoringen nog verder terug te dringen.

Guido van Laar

Iedereen die in Nederland met de trein reist of het nieuws volgt, merkt welke gevolgen technische mankementen aan het spoor kunnen hebben. Hier geldt de wet ‘risico is kans maal effect’: ook al zijn de ICT-systemen robuust en is de kans klein dat er iets faalt, het effect van falen op het treinverkeer is bijna altijd enorm. ProRail is daarom actief bezig om de kans op ICT-storingen steeds verder terug te dringen en de omvang van de gevolgen te verkleinen. Naast maatregelen als moderniseren en disaster tolerant maken van rekencentra, zet ProRail monitoring van de ICT-systemen in.
Al doende hebben we bij ProRail gemerkt dat het onder monitoring brengen van ICT-systemen nieuwe problemen met zich mee brengt: meer dan eens ontstaat een overvloed aan meldingen waar beheerders niet altijd iets mee kunnen. Ook komt het voor dat de monitoring geen problemen signaleert, terwijl de afnemers van de ICT-diensten wel degelijk problemen ervaren.
Verbeteracties werden ingezet vanuit de bestaande meldingen en beredeneerd vanuit de beschikbare ICT-componenten en beheertooling. Grote aantallen onterechte meldingen werden weggefilterd en meldingen die wél een indicatie zijn voor echte problemen werden geaccentueerd. Deze verbeteracties leidden deels tot resultaat. Echter ook na het wegfilteren bleven veel echte meldingen onopgemerkt door de nog steeds grote hoeveelheid niet ter zake doende meldingen.
De bestaande manier van monitoring en de bestaande verbeteracties droegen dus onvoldoende bij tot het terugdringen van verstoringen.
ICT-diensten worden steeds meer afhankelijk van een samenstelling van ICT-systemen, de zogenaamde ketens. Daardoor wordt het moeilijker overzicht over het functioneren van de ICT te behouden. Een goede monitoring van de ketens wordt steeds belangrijker.
Om de bestaande problemen met monitoring te overwinnen, heeft ProRail een nieuwe kijk op monitoring ontwikkeld, waarin de ICT-dienstverlening aan de bedrijfsprocessen de drijfveer is.

Doel van ketenmonitoring
Het doel van ketenmonitoring is in één zin: de afnemers merken niets of anders zo weinig mogelijk van falende ICT.
‘Niets merken van’ betekent in de praktijk: een falende ICT-functie eerder ontdekken én eerder oplossen dan het moment waarop de afnemer die nodig heeft.
‘Zo weinig mogelijk merken van’ betekent in de praktijk: het herstel beginnen voordat de afnemer last heeft van het falen. Zo beperk je de tijdsduur van de hinder voor de afnemer.
Ook moet de monitoring op tijd gebeurtenissen detecteren die duiden op afnemende prestatie en uitval van redundantie. Afnemende prestatie en uitval van redundantie bedreigen immers de dienstverlening op langere termijn.
In dit artikel wordt de term monitoring gebruikt voor het real time bewaken van het functioneren van de ICT en van gebeurtenissen die op korte termijn om actie vragen. Het bewaken van trends en het opstellen van statistieken van systeemgedrag worden soms ook onder monitoring geschaard, maar bij ProRail rekenen wij dat onder de term ‘Analyseren’. Analyse gaat meer over de langere termijn en monitoring vindt plaats in het hier en nu.

Nadenken over risico’s
De paradigmaverschuiving in de nieuwe kijk op monitoring is dat we vooraf nadenken over de risico’s voor de ICT-dienstverlening als gevolg van falen, in plaats van na inbeheername met monitoring reageren op onverwacht systeemgedrag. Vooraf nadenken over risico’s geeft focus op het bepalen wat we wel en niet moeten monitoren en welke herstelactie we voorzien bij iedere melding van de monitoring. Monitoring van een gebeurtenis is alleen zinvol als er een zinvolle herstelactie te bedenken is bij die gebeurtenis.
ProRail is dan ook bezig met een traject waarin ketenmonitoring al tijdens ontwikkeling wordt mee-ontworpen en daarna ‘getest en wel’ aan de beheerders wordt aangeleverd. We zetten met deze nieuwe kijk op ketenmonitoring een deel van de Non Functional Requirements om in concrete ontwerprichtlijnen.
Ook bij vooraf nadenken zullen we overigens risico’s over het hoofd zien. Na het inrichten van de monitoring volgens dit concept zal verdere bijstelling en verbetering met behulp van Continual Service Improvement nodig zijn. Maar ook dan blijft de aandacht gericht op de risico’s voor de dienstverlening, meer dan op de ICT-componenten zelf.

Service Level Agreements
Bij een benadering met focus op de dienstverlening lijkt de Service Level Agreement (SLA) een goed startpunt. De praktijk leert ons echter dat SLA’s nauwelijks een bruikbare basis bieden voor de inrichting van ketenmonitoring. Ze beschrijven percentages up time en reactietijden, maar bieden weinig houvast voor praktische ontwerpkeuzes voor de monitoring.
De nieuwe kijk op ketenmonitoring neemt een andere weg, die overigens wel degelijk leidt tot de naleving van de SLA’s.
Die andere weg neemt als startpunt dat we onszelf als ICT-dienstverleners verantwoordelijk weten voor de kwaliteit die we de afnemers bieden. Hoe goed willen we zelf onze ICT-dienst aan de afnemers leveren? Welke onderbrekingen in die dienstverlening willen we zelf voorkomen?
Vanuit dit verantwoordelijkheidsbesef wordt in zo goed mogelijk overleg met de afnemers nagegaan wat de impact is van ICT-verstoringen op de ondersteunde bedrijfsprocessen.

Succesruimte
Voor het vaststellen van de impact van ICT-verstoringen zijn goed hanteerbare criteria nodig. Tijdens de zoektocht naar goede criteria stuitten we op het NASA Fault Tree Handbook. Bij de NASA ontstond ten gevolge van een aantal mislukte ruimtemissies de noodzaak tot een goed concept voor het vaststellen van de relatie tussen falen van de techniek en het al dan niet slagen van een ruimtemissie. Het concept dat zij daarvoor ontwikkelden, past wonderwel op ICT-dienstverlening en is de centrale gedachte geworden van onze nieuwe kijk op monitoring.
NASA introduceert in haar handboek het begrip Succesruimte.
Dit begrip Succesruimte gaat over de vraag in hoeverre het slagen van een ruimtemissie wordt beïnvloed door falende componenten. De focus ligt steeds op de vraag of de missie succesvol kan worden voortgezet en niet op de falende componenten zelf. Die focus is ook voor ICT-monitoring essentieel.
Bijgaande figuur licht het begrip Succesruimte en de vijf Succesniveaus nader toe en laat zich het gemakkelijkst verklaren door de tekstballonnen van rechts naar links te lezen, van Totaal Succes naar Totaal Falen. (zie figuur 1).

Knipsel

Het concept Succesruimte geeft concrete niveaus die per gebruikersfunctie met de afnemers kunnen worden besproken en waarop de monitoring kan worden ingericht. Niet alle vijf niveaus zijn altijd van toepassing. Het aantal nuttige niveaus hangt met name af van de diversiteit en de urgentie van de functies, het aantal betrokken ICT-systemen en de al dan niet toegepaste redundantie.
De monitoringomgeving meet de essentiële gebeurtenissen (de volgende paragrafen beschrijven hoe die te kiezen) en bevat speciale algoritmiek die per gebeurtenis en combinatie van gebeurtenissen de statusovergangen in de Succesruimte bepaalt.
Dit concept heeft niet alleen aansprekende niveaus, het helpt ook om te bepalen wie met welke urgentie moet worden gealarmeerd. Zonder dit concept is de verleiding groot bij ieder falen waarvan de impact niet geheel duidelijk is, gelijk maar een sms naar de ICT-directeur te sturen. Met dit concept wordt duidelijk dat het alarmeren van de hogere managementlagen pas nodig is als het niveau Minimaal Aanvaardbaar Succes wordt bereikt.

Eindgebruikersperspectief
Bij het opzetten van de monitoring van de essentiële gebeurtenissen beginnen we bij de juiste werking van de gebruikersfuncties die bepalend zijn voor de dienstverlening. We passen hiervoor end to end monitoring toe, ook wel het eindgebruikersperspectief genoemd.
We laten de monitor de belangrijkste gebruikersfuncties meten op zo’n manier dat dit inzicht geeft in de daadwerkelijke bruikbaarheid van de keten. We meten die functies waarvan het falen direct invloed heeft op het Succesniveau van de dienstverlening: is het mogelijk om in te loggen, is het mogelijk toegang te krijgen tot een bepaald webformulier, leidt een aanvraag voor informatie aan een aangrenzend ICT-systeem tot een verwacht antwoord? Zowel de beschikbaarheid van deze functies als de performance ervan wordt gemeten.
Het monitoren van de gebruikersfuncties kan in principe op drie manieren, afhankelijk van de gebruiksfrequentie van de keten: periodieke nabootsing van de gebruikersfuncties, opvangen van foutmeldingen van de applicaties en door een combinatie van beide.

Periodieke nabootsing is zinvol wanneer de gebruiksfrequentie redelijk laag is, bijvoorbeeld met een interval van 15 minuten of meer. In dat geval is periodieke nabootsing met een frequentie vanaf bijvoorbeeld 5 minuten zinvol. We kiezen het interval ruim korter dan de gemiddelde gebruiksfrequentie, rekening houdend met de gemiddelde hersteltijd. Het gaat er immers om dat de falende functie eerder wordt ontdekt en hersteld dan het moment dat de afnemer die nodig heeft.
Periodiek nabootsen doet de monitor door aanvragen te doen die representatief zijn voor het normale gebruik en gedrag van het ICT-systeem. Die aanvragen worden gedaan vanuit de locaties in het netwerk die het ICT-systeem zelf ook gebruikt. Dat maakt dat de metingen alle ICT-componenten raken en daadwerkelijk inzicht geven in het functioneren van de keten.
Met deze eindgebruikersmonitoring snijdt het mes aan twee kanten: falen wordt opgemerkt, ook als de onderliggende componenten zich niet ongezond melden én het voorkomt dat we álle componenten onder monitoring moeten brengen. Op deze manier zijn we op een betrouwbare manier ‘met grote stappen snel thuis’.
Bij het periodiek monitoren van gebruikersfuncties detecteert de monitor in de tussenliggende periodes eventueel falen niet. In dat geval kan het gebeuren dat de componentmonitoring (zie de volgende paragraaf) een falen als eerste meldt en dat pas later ook de eindgebruikersmonitoring zijn melding geeft.
Opvangen van foutmeldingen van de applicaties ligt voor de hand wanneer de gebruiksfrequentie hoog is, bijvoorbeeld meer dan eens per minuut. In dat geval kan de monitor gebruik maken van de applicatielogging waarin dat falen wordt vastgelegd. De monitor merkt dan het falen op hetzelfde moment als de gebruiker. Je wint dan de tijd die anders verloren gaat aan het telefoontje naar de helpdesk.
Een combinatie van beide biedt uiteraard de voordelen van beide manieren.

Componentperspectief
De volgende stap in het opzetten van de monitoring is de componentmonitoring.
De keuze welke ICT-componenten gemonitord moet worden, wordt in de nieuwe kijk niet primair bepaald door de vraag wat er allemaal op componentniveau fout zou kunnen gaan. Ook hier is de focus op de dienstverlening essentieel. We onderscheiden drie aspecten bij de componentmonitoring.
In de eerste plaats: de ICT-componenten waarvan bekend is dat ze direct invloed hebben op het Succesniveau, moeten worden bewaakt. Sommige componenten leiden bij falen onmiddellijk tot Totaal Falen voor de complete ICT- keten, andere (vooral bij uitval van redundantie) leiden tot één van de hogere Succesniveaus.
In de tweede plaats: de componentmonitoring hoeft niet alles waar te nemen, want als alles goed is doordacht, bewaakt de eindgebruikersmonitoring de meeste risico’s al.  De componentmonitoring moet t.b.v. het herstelproces vooral net voldoende informatie bieden om te achterhalen in welke hoek van de ICT-keten er iets mis is.
In de derde plaats: er vinden in de ICT-systemen gebeurtenissen plaats die in het hier en nu geen invloed hebben op het Succesniveau, maar waarvan de betreffende technisch beheerder wel een melding wil ontvangen. Ook het monitoren van deze gebeurtenissen verdient aandacht en moet worden verzorgd door dezelfde monitoring-omgeving. Ze worden echter niet getoond op het dashboard (zie volgende paragraaf) en ook niet meegenomen in het berekenen van het Succesniveau.

Situation awareness
Om kordaat te kunnen reageren op verstoringen in welk proces dan ook, is het nodig dat er een goed inzicht bestaat in de toestand van dat proces. Inzicht in wat er faalt, wat nog wel in orde is, en welke relatie er is tussen falende componenten en falende eindgebruikersfuncties. Dit overzicht over de situatie heet ook wel Situation awareness.
Ondersteuning van de Situation awareness ontbreekt in de traditionele monitoring, waar vaak alleen de individuele foutmeldingen op een scherm verschijnen en de onderlinge relaties door tijdrovend zoekwerk achterhaald moeten worden.
Situation awareness bereiken we door op een dashboard overzichtelijk alle drie vormen van informatie in hun onderlinge samenhang te tonen: Succesniveau, Eindgebruikersmonitoring en Componentmonitoring. In één oogopslag is zo te zien wat het niveau van dienstverlening is, welke gebruikersfuncties zijn aangetast en welke componenten daar schuldig aan zijn.
Situation awareness bereiken we verder door te zorgen dat vanuit het ketendashboard eenvoudig is door te klikken naar de onderliggende details en naar de aangrenzende ICT-systemen en -ketens waarmee informatie wordt uitgewisseld.
Een dashboard waarop de drie vormen van informatie in hun onderlinge samenhang worden getoond, biedt beheermedewerkers van de helpdeskmedewerker tot en met de ketenbeheerder de informatie die ze nodig hebben om adequaat te reageren, ieder in hun eigen rol.
Een dashboard waarop uitsluitend de Succesniveaus van alle gemonitorde ketens zijn samengebracht is een prima instrument om alle lagen van het ICT-management inzicht te geven in de situatie van alle ketens gezamenlijk.

Service Management System
Veel organisaties die zich bezighouden met ICT-beheer gebruiken een Service Management System, dat op basis van ITIL-processen de workflow bestuurt, bewaakt en daarover rapporteert.
In de nieuwe kijk levert de monitoring-omgeving twee losse stromen gebeurtenissen aan het Service Management System.
Elke statusverandering in de Succesruimte komt overeen met wat ITIL een ‘Incident’ noemt. Op een Incident moet altijd worden gereageerd. De reactietijd is afhankelijk van het Succesniveau en de verwachte hersteltijd. Hoe dichter bij Totaal Falen en hoe langer de verwachte hersteltijd, hoe korter de vereiste reactietijd. Service Management Systems kennen daarvoor hun eigen prioriteitsniveaus, die een-op-een af te beelden zijn op de niveaus in de Succesruimte.
Daarnaast zijn er de eerdergenoemde gebeurtenissen die een technisch beheerder wil weten, maar die geen invloed hebben op het Succesniveau. In ITIL-termen zijn dat de ‘Events’.
Beide soorten gebeurtenissen leiden tot werkbonnen, of hoe ze in het desbetreffende Service Management System maar mogen heten, bestemd voor diverse oplosgroepen.

Een concreet voorbeeld
De nieuwe kijk op monitoring hebben we toegepast op een van ICT-ketens van ProRail: de ICT-keten die het Incidentproces ondersteunt. Dat is het proces dat de afhandeling verzorgt van de incidenten die plaatsvinden langs het spoor, zoals aanrijdingen, ontsporingen en brandjes. (Niet te verwarren met ICT-Incidenten in de ITIL-betekenis.)
Deze keten dient hier als concreet voorbeeld van het bijzondere nut van het samenbrengen van het Succesniveau en de onderliggende Eindgebruikers- en Componentmonitoring in één samenhangend concept en weergegeven op één overzichtelijk dashboard.
We hebben gezocht naar een indeling van het dashboard die dat overzicht ook daadwerkelijk zou kunnen bieden. Het ontwerp van dat dashboard is nog in ontwikkeling en we verwachten dat hier en daar nog aanpassingen nodig zullen zijn. We hebben gezocht naar een goede combinatie van overzicht en de mogelijkheden die de beschikbare tooling ons biedt. Een goede optie was de ketenplaat zelf te nemen als onderlegger. Maar om voor alle te monitoren ICT-ketens eenzelfde lay-out te bereiken, hebben we toch gekozen voor een abstractere weergave.
Bijgaande figuur toont het dashboard zoals we dat op dit moment operationeel hebben voor het Incidentproces. De tekstballonnen verklaren de diverse onderdelen van het dashboard. (zie figuur 2)

Knipsel2

Figuur 2

Hoe verder
De nu geïmplementeerde keten draait in een Windows-omgeving. ProRail heeft ook omgevingen met ICT-systemen die gebruik maken van hoog beschikbare platformen onder andere operating systems dan Windows.
Momenteel zijn we bezig om de uniforme manier van monitoring verder uit te werken voor de verschillende omgevingen. Belangrijk speerpunt daarbij is het selecteren van een monitoring- en dashboardomgeving die past op deze omgevingen en ook een uitgebreidere algoritmiek mogelijk maakt voor het bepalen van het Succesniveau. Daarnaast zijn we bezig om ook andere beheeraspecten mee te ontwikkelen en die getest en wel op te leveren aan de beheerorganisatie.
Zo willen een volgend volwassenheidsniveau bereiken in de aansluiting tussen ontwikkeling en beheer.

Guido van Laar
ICT-Architect
ProRail B.V.
guido.vanlaar@prorail.nl

Literatuur
NASA, 2002. Fault Tree Handbook with aerospace applications. Washington.

Bart de Best, Zo geef je monitorarchitectuur vorm. IT-Infra, mei 2010, 8 – 13.

 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag