Observability Maturity Model

Over dit onderwerp valt veel te zeggen, te veel om in één artikel samen te vatten. Daarom begin ik met een introductie om het kader te schetsen en ga ik in op level 1 van het maturiteitsmodel. In het volgende artikel behandel ik de overige levels.

De industrie werkt actief aan het definiëren van een standaard Observability Maturity Model. Zo’n model kan worden gebruikt om te bepalen waar je organisatie momenteel staat en wat er nodig is om het gewenste niveau te bereiken. Er bestaat op dit moment echter nog geen gestandaardiseerd Observability Maturity Model. Daarom heb ik mijn eigen model ontwikkeld. Het is gebaseerd op bestaande documentatie, maar ik heb het laatste niveau toegevoegd, dat ik heb gelabeld als: autonome observability. In deze reeks artikelen licht ik elk niveau gedetailleerd toe en richt ik me op het kernconcept per niveau, wie de primaire stakeholders zijn en wat het belangrijkste businessresultaat is.

Figuur 1: Observability Maturity Model

Introdutie van het Observability Maturity Model

Het model bestaat uit 5 levels:

• Level 1: Monitoring. Dit bestaat in de basis al decennialang. 

• Level 2: Observability. Metrics, logs en traces staan los van elkaar in silo's. 
• Level 3: Causal Observability. Metrics, logs en traces worden gecombineerd.
• Level 4: Proactieve observability. AI en machine learning worden toegepast op observability‑data om proactiever en voorspellender te kunnen werken. Op dit niveau voegen we ook context toe in de vorm van businessdata.
• Level 5: Autonoom IT-management. Door gebruik te maken van agentic AI kunnen we het IT‑landschap automatisch beheren.

In deze artikelen ga ik elk niveau van het model toelichten om dieper in te gaan op het concept van Observability. In deze introductie begin ik met monitoring en bespreek ik het verschil tussen monitoring en observability. Voor elk niveau schrijf ik een apart artikel.

Tot slot bespreek ik een visie voor de nabije toekomst met “Autonomous IT Management”. Ik heb dit in de praktijk nog niet gezien, maar gezien de ontwikkelingen op het gebied van AI kan ik me niet voorstellen dat dit nog ver in de toekomst ligt.

Level 1: Monitoring

“Ja natuurlijk doen we aan observability, we hebben een uitstekend monitoringtool”

Het interessante aan deze uitspraak is dat monitoring en observability vaak als hetzelfde worden gezien, maar naar mijn mening klopt dat niet. Het korte verschil is dat monitoring zich bezighoudt met zaken die al bekend zijn. Als je weet dat het een probleem kan worden wanneer het CPU‑gebruik 85% of hoger is, kun je je monitoringsysteem configureren om het CPU‑gebruik te meten en een alert te sturen wanneer deze waarde wordt bereikt of overschreden. Wat daarna gebeurt, is dat OPS deze alert ontvangt en — na hopelijk te hebben onderzocht wat er aan de hand is — een proces opnieuw start. Probleem opgelost… voor even. Tot het opnieuw gebeurt, en het proces opnieuw wordt herstart.

In dit scenario zijn een aantal zaken niet optimaal.

1. Het ontvangen van deze alert betekent niet automatisch dat er iets mis is met de applicatieservice. Als de service gewoon goed draait en je toch deze alert blijft krijgen, wordt deze op een gegeven moment genegeerd. Hierdoor wordt monitoring uiteindelijk niet meer betrouwbaar.

2. In dit scenario werken OPS en DEV mogelijk niet goed samen. (Ja, het is 2026 en soms zijn DEV en OPS nog steeds gescheiden.) Dit is eigenlijk een onderwerp op zich, maar binnen dit scenario maakt het het onderzoeken van het probleem erg lastig. Zelfs wanneer je DEVOPS‑teams hebt die volledig verantwoordelijk zijn voor de service, beperkt het gebruik van alleen dit monitoringsysteem de mogelijkheden om grondig te onderzoeken wat er daadwerkelijk aan de hand is.

Wat vs Waarom

Monitoring laat je weten dát er iets gebeurt. Maar het vertelt je niet waarom iets gebeurt. 

Daar komt het concept van Observability om de hoek kijken. Binnen dit concept kun je de staat van een systeem bepalen op basis van de output: metrics (zoals het CPU‑gebruik uit het eerdere voorbeeld), logs en traces. Monitoring geeft je doorgaans antwoord op de vraag: “Staat het check‑engine lampje aan?” (een bekende faalmodus). Observability daarentegen is de diagnostische motor die je in staat stelt te vragen: “Waarom gaat het check‑engine lampje aan, terwijl de bestuurder normaal rijdt?” Het is een werkwijze die een diepere analyse van het probleem mogelijk maakt.

Data is de sleutel

Wat hierbij essentieel is om te begrijpen, is dat we veel meer data over een systeem verzamelen met als doel om echt tot de kern van het probleem te komen. In mijn voorbeeld moeten DEV en OPS samenwerken. Observability stelt beide teams in staat om naar dezelfde data te kijken en daardoor tot dezelfde conclusies te komen.

Betekent dit dat monitoring niet meer nodig is nu we Observability hebben? Absoluut niet. Monitoring maakt onderdeel uit van het bredere Observability‑concept. Idealiter wil je weten dát er iets aan de hand is, maar je hebt ook de tools nodig om goed te kunnen begrijpen waarom dit gebeurt. Alleen zo kun je voorkomen dat het opnieuw gebeurt.

Waarde voor de business

Het belangrijkste businessresultaat in deze fase is het minimaliseren van downtime en het verbeteren van de beschikbaarheid van services. Oftewel: het verlagen van de MTTD (Mean Time to Detect). Dit blijft echter nog steeds puur reactief, omdat monitoring je alleen waarschuwt voor een bekend scenario dat zich voordoet. Idealiter wil je voorkomen dat dit überhaupt gebeurt. Desondanks is het een begin, en géén monitoring hebben is een stuk erger.

Het is mogelijk om de businesswaarde te vergroten door monitoringevents te koppelen aan een grafische weergave van je IT‑landschap. Als dit goed wordt gedaan, kun je snel bepalen waar in je landschap een storing optreedt en wat de mogelijke impact is op je service. Dit voorkomt echter nog steeds geen storingen. Om storingen te voorkomen, moet je data analyseren en de juiste verbeteringen doorvoeren. En precies daar speelt observability een cruciale rol. 

Primaire Stakeholders

De primaire stakeholders van monitoringdata zijn meestal IT‑Operations­teams die kunnen handelen op basis van monitoringalerts. Hun doel is strikt het herstellen van de service (het opnieuw starten van het proces), niet het oplossen van de onderliggende bug. In deze fase zijn operationele teams nog steeds aan het brandjes blussen en reageren ze vooral, in plaats van proactief te werken.

Tools en werkwijzen

Monitoring bestaat al zeer lange tijd en er is een groot aanbod aan tools om uit te kiezen. Binnen opensource zie je vaak tools als Prometheus, Nagios en Zabbix. Ook commercieel is er volop keuze, maar commerciële oplossingen doen doorgaans veel meer dan alleen monitoring. Denk aan tools zoals Dynatrace, Datadog, New Relic, maar ook tooling die geïntegreerd is in de hyperscale cloudplatformen. Goede voorbeelden hiervan zijn Amazon CloudWatch en Azure Monitor.

Conclusie

Hoewel dit fundamentale niveau veel voordelen kan bieden, betekent het vertrouwen op alleen monitoring dat we voortdurend achter de feiten aanlopen. We opereren reactief en pakken slechts de symptomen aan.

Lees verder in deel 2, waarin we dieper ingaan op de volgende niveaus. We verkennen hoe het verzamelen van Logs, Metrics en Traces — zelfs wanneer deze nog gesiloed zijn — leidt tot de volgende grote businessuitkomst: een significante verlaging van de Mean Time To Resolution (MTTR).

Ben je het hiermee eens? Gedachten of aanvullingen? Ik hoor graag je feedback.