Is een storing in jouw keten echt jouw probleem?

Dat er een melding binnenkomt, is één ding. Weten wie er verantwoordelijk is, is iets heel anders. In ketens met meerdere leveranciers, cloudplatformen en on-premises systemen ontstaat een grijs gebied zodra iets uitvalt. De helpdesk wijst naar de netwerkprovider. De netwerkprovider wijst naar de applicatieleverancier. Intussen staat de eindgebruiker stil. Dit is geen uitzondering, het is een structureel probleem in elke complexe IT-omgeving.

De kern van het probleem is niet de storing zelf. Het is het gebrek aan zichtbaarheid op het moment dat het misgaat.

Waarom eigenaarschap bij storingen zo moeilijk vast te stellen is

Moderne IT-omgevingen zijn zelden enkelvoudig. Je werkt met SaaS-applicaties, managed services, eigen infrastructuur en soms OT-koppelingen. Al die lagen zijn van elkaar afhankelijk, maar niemand heeft standaard een compleet beeld van hoe die afhankelijkheden eruitzien.

Stel dat een product applicatie traag reageert. Is dat een database probleem op je eigen servers? Een capaciteitsknelpunt bij de cloudprovider? Netwerklatentie door een ISP? Of een bug in een recente update van een derde partij? Zonder ketenmonitoring geeft niemand een definitief antwoord. Iedereen verdedigt zijn eigen domein, en de analyse duurt langer dan de storing zelf.

Dit is precies waar verantwoordelijkheid verdampt. Niet door kwade wil, maar door gebrek aan gedeeld inzicht.

Wat ketenmonitoring feitelijk zichtbaar maakt

Ketenmonitoring gaat verder dan het bewaken van individuele componenten. Het brengt de relaties tussen systemen in kaart. Je ziet niet alleen dat server X uitvalt, maar ook welke applicaties, gebruikers en processen daardoor worden geraakt en in welke volgorde.

Een goed ingericht monitoring platform koppelt signalen aan een CMDB. Zo weet je direct welke CI’s betrokken zijn bij een incident, wie de beheerder is en of er een wijziging op die CI openstaat of kort geleden is uitgevoerd die verband kan houden met de storing. Juist die laatste categorie wordt vaak gemist: een wijziging die volgens het changeproces netjes is afgerond, blijft in de meeste tools onzichtbaar op het moment dat de storing zich meldt. Dat is informatie die bij handmatige analyse minuten tot uren kost om te verzamelen.

Bij Gensys leveren we monitoring oplossingen die deze keten zichtbaarheid standaard ondersteunen. Niet als feature, maar als uitgangspunt.

Het verschil tussen een signaal en een oorzaak

Een alert is geen diagnose. Dat klinkt logisch, maar in de praktijk wordt een alert vaak behandeld alsof het de oorzaak aanwijst. Systeem Y geeft een foutmelding, dus systeem Y is het probleem. Maar systeem Y kan een slachtoffer zijn van een defect hogerop in de keten.

Root cause analysis vereist correlatie. Je hebt tijdstempels nodig, afhankelijkheid kaarten, historische data en het overzicht van recent doorgevoerde wijzigingen. Moderne monitoring tools bieden event correlation: meerdere signalen worden samengebracht en vergeleken met bekende patronen. Pas dan ontstaat een betrouwbaar beeld van wat de werkelijke oorzaak is.

Een praktijkvoorbeeld: een MSP ontvangt meldingen van tien klanten tegelijk over een trage e-mail. De individuele monitors wijzen allemaal naar de mailserver van de klant. Event correlation laat zien dat alle tien klanten via dezelfde upstream relay lopen, en dat die relay twee minuten eerder een configuratiewijziging heeft ontvangen. De oorzaak ligt buiten het klantdomein, maar zonder correlatie vindt elke beheerder het probleem bij zichzelf.

Wat je contractueel moet vastleggen voordat je begint

Technische zichtbaarheid lost weinig op als de verantwoordelijkheden niet contractueel zijn vastgelegd. SLA’s met leveranciers moeten specifieker zijn dan “99,9% uptime”. Je wilt weten: welke meet tool is leidend, wie heeft inzage in de metingen, en wat geldt als bewijs bij een dispuut?

Leg ook vast wie de ketenmonitoring beheert. In een gedeeld verantwoordelijkheidsmodel, zoals bij veel cloudoplossingen het geval is, is de verdeling op papier helder maar in de praktijk vaag. Zorg dat je ITSM-processen aansluiten op die contractuele verdeling. Een incident moet bij de juiste partij terechtkomen, niet bij de eerste die de telefoon opneemt.

NIS2 en DORA stellen bovendien eisen aan aantoonbaar beheer van derde partijen. Je bent als organisatie verantwoordelijk voor risico’s in je keten, ook als de storing bij een leverancier ontstaat. Dat maakt goede registratie geen optie maar een vereiste.

Hoe je bewijs verzamelt bij een leverancier geschil

Stel dat de storing aantoonbaar buiten je domein lag, maar de leverancier betwist dat. Wat heb je nodig? Tijd gestempelde logs, meetdata uit een onafhankelijk systeem en een aaneengesloten reeks events die de causaliteit aantonen. Dat is precies wat een goed geconfigureerde monitoring omgeving levert.

Zonder eigen monitoring ben je afhankelijk van de logs die de leverancier je aanlevert. Die zijn zelden compleet, soms pas beschikbaar na dagen, en soms selectief. Met eigen data sta je sterker. Niet als aanval op de leverancier, maar als feitelijke basis voor een zakelijk gesprek.

Gensys levert monitoring oplossingen waarbij je de data in eigen beheer houdt. On-premises of in je eigen cloudomgeving. Je bepaalt wie toegang heeft en hoe lang data bewaard blijft. Dat is geen luxe, het is noodzakelijk zodra je serieuze afspraken wilt afdwingen.

Wanneer een storing collectief eigendom is

Niet elke storing heeft één eigenaar. In gedistribueerde omgevingen kunnen meerdere partijen tegelijk bijdragen aan een probleem. Dat is geen excuus voor diffuse verantwoordelijkheid, maar het vereist wel een andere aanpak.

Bij ketenstoringen waarbij meerdere leveranciers betrokken zijn, helpt een gezamenlijk dashboard. Alle betrokken partijen zien dezelfde data, in real time. Dat verkort de discussie en versnelt de oplossing. In PSA-omgevingen voor MSP’s is dit inmiddels gangbaar. In andere sectoren nog niet.

De praktijk leert dat het benoemen van een “incident commander”, één partij die de coördinatie op zich neemt ongeacht waar de oorzaak ligt, de meeste tijdwinst oplevert. Technisch eigenaarschap en coördinatie zijn twee verschillende rollen.

Zichtbaarheid is geen luxe

Een storing hoeft niet lang te duren om schade te veroorzaken. De echte schade zit in de tijd die verloren gaat aan discussie over wie verantwoordelijk is. Dat is tijd die niet besteed wordt aan herstel.

Organisaties die ketenmonitoring serieus inrichten, verkorten niet alleen de hersteltijd. Ze maken ook een einde aan de rondjes over verantwoordelijkheid die het herstel vertragen. Ze beschikken over data, over context en over bewijs. Dat verandert de relatie met leveranciers van reactief naar zakelijk gelijkwaardig.

Bekijk het assortiment van Gensys voor monitoring oplossingen die je die zichtbaarheid geven, op elk niveau van je keten.

Veelgestelde vragen over storingen in de IT-keten

Hoe weet ik of een cloudprovider de oorzaak is van mijn storing?

Vergelijk je interne monitoring data met de statuspagina van de provider, maar vertrouw daar niet blind op. Statuspagina’s worden soms vertraagd bijgewerkt. Gebruik een externe monitoring tool die onafhankelijk van de provider meet, zodat je beschikt over je eigen tijdlijn. Event correlation tussen je eigen systemen en externe services geeft je een betrouwbaarder beeld dan één enkele bron.

Dan heb je twee opties. Je bewijst met eigen data het tegendeel, of je onderzoekt of de storing aan jouw kant toch een andere oorzaak heeft. Eigen monitoring data is hierbij essentieel. Een leverancier die niets ziet, ziet mogelijk alleen zijn eigen component. Als je de hele keten monitort, zie je patronen die hij niet ziet.

Door bij contractverlenging duidelijkere afspraken te maken over meetmethoden en verantwoordelijkheid. Leg vast welk monitoringsysteem leidend is bij incidentanalyse. Stel ook periodieke ketenreviews in waarbij alle betrokken leveranciers aanschuiven. Preventie zit niet in betere techniek alleen, maar in gedeelde afspraken over hoe je met data omgaat.

Zet de tijdlijn van de storing naast het overzicht van wijzigingen op de betrokken CI’s, en kijk daarbij niet alleen naar wijzigingen die nog openstaan maar ook naar wijzigingen die kort daarvoor zijn uitgevoerd. Een afgeronde verandering is in de administratie klaar, maar het effect ervan wordt vaak pas onder productiebelasting zichtbaar. Een monitoring platform dat aan de CMDB gekoppeld is, toont die samenhang direct in plaats van dat iemand die achteraf moet reconstrueren.