De 4 bouwstenen van een goede IT Root Cause Analysis

Elke minuut die je van een root cause analysis af kan halen brengt je een minuut dichter bij het herstellen van de performance en / of beschikbaarheid van een proces dat belangrijk is voor jouw organisatie. Helaas leidt de explosie aan monitoringtools binnen een organisatie tot verwarring, disfunctioneren van tools en vingerwijzen tussen de afdelingen. Om ze beter te laten samen werken moet je begrijpen hoe ze opgebouwd zijn.

Bekijk Root Cause Analysis (RCA) eens als een software stack, vergelijkbaar met OSI. Hoe hoger in de stack hoe duidelijker het wordt voor de Business. Elke laag in deze stack wordt gevoed door unieke monitoringdata en stelt je in staat om de juiste analyses te doen. Noodzakelijkerwijs geeneens door dezelfde tool.

Hieronder de 4 lagen zoals ik deze zie:

  • Business Service RCA
  • Application-Driven RCA
  • Network Fault RCA
  • Device Root RCA

Uiteindelijk heb je alle lagen nodig om een RCA tot een succes te maken en je dient ze ook stap-voor-stap uit te voeren om de logische samenhang te zien. Laten we elke laag eens dieper gaan bekijken.

1. Device Root RCA

De hardware laag is het fundament dat je laat weten of een server, storage, switch, router of load-balancer beschikbaar is en of deze snel of langzaam functioneert. Als de hardware pingbaar is weet je dat hij beschikbaar is en met de juiste diagnose/monitors kun je pinpointen welke component van de hardware problemen geeft. Voor de root cause van performance problemen moet je de data uit de monitoring over tijd uitzetten om een trend te spotten. Dit kan dan gaan om CPU of Memory Usage maar ook over de aantallen fouten in een logfile.

Maar stel nu dat de servers of netwerkapparatuur niet te bereiken is? Hoe weet je dan zeker dat hij ook echt down is en niet dat er een netwerkissue is vanuit jouw perspectief naar de hardware? Om dit te kunnen zien moeten we naar de volgende laag.

2. Network fault RCA

De volgende laag is Network RCA. Een mooie manier is een tool implementeren waarmee je het netwerk kunt modelleren; routers, switches en de relaties hiertussen. Wanneer er een verstoring optreedt kan je met deze tool een goede RCA uitvoeren om te bepalen welke netwerkapparatuur op de route naar de applicatie down is. Je kunt deze RCA ook uitvoeren door te kijken naar alle events die de netwerkapparatuur versturen maar dan wordt je overspoeld met meldingen en kun je de impact niet goed bepalen. Dit zelfde concept kun je ook toepassen op gevirtualiseerde infrastructuur waar je de “route” van het SAN naar de virtuele host in kaart kunt brengen om zo te bepalen waar het stokt.

3. Application-Driven RCA

De volgende stap is APM, Application Performance Management. Dit behelst twee monitoring mechanismen; network flow analysis en end-to-end application monitoring.

Het eerste mechanisme geeft je inzicht waar applicaties zich in je IT infrastructuur bevinden en hoeveel capaciteit ze van de omliggende infrastructuur vragen. Wanneer gebruikers klagen over de performance van de applicatie kun je met bandbreedte monitoring bijvoorbeeld pinpointen waar de problemen zich bevinden.

Het tweede mechanisme geeft je inzicht in de KPI’s Performance, Availability en Volume van de applicatie vanuit het perspectief van de eindgebruiker. Inzicht in network round trip en de response tijden van de server maken dat je beter kunt analyseren waar de verstoring zich bevindt. Om vervolgens een verdere drilldown te doen kun je laag 1 en 2 gebruiken zoals in eerdere paragraven besproken.

4. Business Service RCA

Met bovenstaande lagen kunnen we 1 of meerdere dashboards maken waarin de data gevisualiseerd wordt en correlatie van de informatie mogelijk is. De eerste drie lagen zijn vooral bedoelt voor technisch personeel en niet de business.

Voor de business is echter een additionele laag nodig. De laag die de vertaling maakt van IT Infrastructuur naar bedrijfsprocessen. Bijvoorbeeld; Verkoop product, Overboeken geld en wijzigen persoonsgegevens.

In deze laag bewaak je de applicatie en infrastructuur componenten gegroepeerd op de bedrijfsprocessen die ze ondersteunen. Daarmee kun je de impact van verstoringen in de IT infrastructuur relateren aan de dienst die je naar de klant levert. Eigenlijk is dit het hoogste, meest abstracte niveau en bijna altijd het startpunt van het bepalen van de status van je omgeving. Daarmee is dit ook het startpunt voor een drilldown bij een verstoring in lagere lagen om een technische RCA te kunnen doen.

Conclusie

Bovenstaande is alleen uit te voeren als je grip hebt op welke bedrijfsprocessen je aanbiedt en welke IT infrastructuur daar onder ligt. De koppeling van bedrijfsproces naar IT moet ook vastgelegd zijn. Het ITIL proces Configuratie Management is zeer belangrijk.

Let wel. Uiteindelijk heb je altijd mensen nodig om events aan elkaar te correleren en kan, hoe mooi de tool er ook uitziet, een tool niet het geheel overzien.

Deze blogpost is een samenvatting van eerder geschreven stukken en eigen ervaring en ik wil dit graag gaan gebruiken als basis voor het opzetten van monitoring voor (middel)grote bedrijven waar ik als consultant werk uitvoer. De volgende stap voor mij is het vertalen van deze lagen naar tools die nu in de markt beschikbaar zijn. Daarmee kunnen bedrijven precies zien welke gaps zijn nog hebben en hoe ze die kunnen dichten. Mochten jullie als lezer nog toevoegingen zien moedig ik je aan die met mij te delen. Dit maakt de theorie krachtiger omdat het vanuit de praktijk gevoed is.

Over Coen Meerbeek

Splunk consultant @ Blue Factory, eigenaar en oprichter @ BuzzardLabs, basketbalspeler en Xbox-gamer. Lees meer van Coen op Launchers.nl en Twitter.

Laat wat van je horen

*