Een automatische websitecontrole geeft een foutmelding. De eerste reactie ligt voor de hand: de website heeft een storing. Toch is dat technisch gezien nog helemaal niet bewezen.
De fout kan in de website zitten, maar ook in de controlefunctie, configuratie, authenticatie, netwerkroute of interpretatie van het resultaat. Wanneer AI op basis van één mislukte opdracht direct een cache leegt, service herstart of server aanpast, kan het een goed werkende productieomgeving veranderen zonder dat daar bewijs voor was.
Bij het bouwen van INDY kwam ik precies zo’n situatie tegen. Een publieke controle van een beheerde website mislukte doordat de verificatiefunctie een WordPress-specifiek configuratieveld verwachtte. De website zelf was geen WordPress-project en Ploi meldde haar gewoon als actief.
De opdracht was mislukt. Downtime was niet aangetoond. Dat onderscheid is de basis van betrouwbaar incidentonderzoek.
Een foutmelding vertelt eerst waar de controle stopte
Een foutmelding is een waarneming uit één technische laag. Ze vertelt meestal welke stap niet kon worden voltooid, maar niet automatisch wat de uiteindelijke oorzaak is.
Als een WordPress API-aanroep geen verbinding kan maken, kan WordPress onbereikbaar zijn. Het kan ook gaan om verlopen toegangsgegevens, een ontbrekende configuratie of een fout in de koppeling. Als een publieke healthcheck mislukt, kan de website offline zijn. Maar de controle kan ook een verkeerd pad gebruiken of een resultaatcontract verkeerd interpreteren.
Daarom lees ik een eerste fout niet als conclusie, maar als startpunt: deze specifieke controle kon haar werk niet afmaken.
Plaats iedere fout in de juiste technische laag
Voor praktisch onderzoek helpt het om de betrokken lagen bewust van elkaar te scheiden:
- De opdrachtlaag: was de gevraagde actie geldig en volledig?
- De koppeling: kon INDY de juiste backendfunctie bereiken?
- De configuratie: waren domein, type website en vereiste velden correct geregistreerd?
- Het beheersysteem: wat melden WordPress, Ploi of de serverinventaris?
- De infrastructuur: zijn server, webserver, PHP en database beschikbaar?
- De publieke voorkant: wat ontvangt een bezoeker zonder ingelogde sessie?
Een fout in één laag bewijst niet automatisch een defect in alle lagen eronder. Juist door de lagen afzonderlijk te controleren, voorkom ik dat een koppelfout wordt behandeld als een productie-incident.
Het voorbeeld: een controle verwachtte WordPress waar geen WordPress stond
De verificatiefunctie waarmee ik werkte, was oorspronkelijk vooral ingericht voor WordPress-websites. Bij een ander type beheerde website verwachtte ze nog steeds het configuratieveld met de WordPress-URL. Dat veld bestond terecht niet.
De foutmelding verwees daardoor naar ontbrekende WordPress-configuratie. Wie alleen naar de mislukte taak keek, had kunnen concluderen dat de website niet bereikbaar was. Een afzonderlijke read-only controle in Ploi liet echter zien dat het project actief was en als niet-WordPress-site geregistreerd stond.
De vermoedelijke oorzaak verschoof daarmee van “de website is offline” naar “de verificatieroutering gebruikt het verkeerde siteprofiel”. Dat vraagt om een totaal andere oplossing.
Eerst read-only bewijs verzamelen
Mijn incidentproces begint daarom altijd zonder wijzigingen. Eerst verzamel ik de actuele toestand uit meerdere onafhankelijke bronnen.
- Lees de mislukte taak en de exacte fout.
- Controleer of er een nieuw of bestaand open incident bij hoort.
- Zoek het exacte domein en de geregistreerde technische stack op.
- Lees de status van de betrokken website en server.
- Controleer recente taakstatussen en beschikbare metingen.
- Voer waar mogelijk een afzonderlijke publieke controle uit.
Geen van deze stappen herstart een service, leegt een cache of verandert configuratie. Ze beperken alleen de mogelijke oorzaken.
Combineer signalen voordat je een oorzaak aanwijst
Een sterk incidentbeeld ontstaat zelden uit één signaal. Stel dat een publieke pagina een 500-status geeft. Dat is belangrijker wanneer tegelijkertijd de errorlogs nieuwe applicatiefouten tonen en de betrokken service niet goed draait.
Andersom hoeft een hoge serverbelasting uit een oude insight geen actuele storing te verklaren wanneer de huidige CPU- en RAM-metingen normaal zijn en de website correct reageert.
Ik probeer daarom onderscheid te maken tussen actuele observaties, historische waarschuwingen en vermoedens. Alleen actuele, onderling ondersteunende signalen mogen de basis vormen voor een herstelvoorstel.
Een mislukte tool kan zelf een incident verdienen
Dat de website niet defect is, betekent niet dat de fout onbelangrijk is. Een controlefunctie die het verkeerde siteprofiel gebruikt, kan toekomstige storingen missen of valse alarmen blijven veroorzaken.
Het incident hoort dan bij de operationele koppeling, niet bij de website. De impact is dat INDY de publieke bereikbaarheid niet betrouwbaar kan vaststellen. De voorgestelde wijziging moet daarom de verificatieroutering corrigeren, zonder de productieomgeving aan te raken.
Door het incident op de juiste laag te registreren, blijft ook het auditspoor eerlijk. Er staat niet “website offline” wanneer alleen de verificatiefunctie faalde.
Een herstelvoorstel moet vijf dingen bevatten
Na het read-only onderzoek maakt INDY een concreet herstelvoorstel. Dat voorstel bestaat voor mij altijd uit vijf onderdelen:
- Oorzaak: welke verklaring wordt door het verzamelde bewijs ondersteund?
- Impact: wat werkt aantoonbaar niet en wie of wat merkt dat?
- Wijziging: wat is de kleinst mogelijke gerichte oplossing?
- Risico: wat kan deze wijziging onbedoeld beïnvloeden?
- Verificatieplan: welk onafhankelijk bewijs moet na uitvoering aantonen dat het probleem opgelost is?
In dit geval was de gerichte wijziging niet het herstarten van een server of aanpassen van de website. Het voorstel was om de algemene publieke URL voor dit type project te gebruiken zonder WordPress-specifiek veld.
AI mag het eigen voorstel nooit goedkeuren
Een goed onderbouwd voorstel blijft een voorstel. INDY mag niet redeneren dat de oplossing logisch klinkt en zichzelf vervolgens toestemming geven om haar uit te voeren.
Herstel kan productieconfiguratie, caches, services of content raken. Daarom vereist de centrale taaklaag een expliciet akkoord van de gebruiker voor het exacte taakobject. Pas daarna mag de beperkte actie worden vrijgegeven.
Die regel geldt ook wanneer het risico laag lijkt. Anders verschuift de grens ongemerkt: eerst corrigeert AI zelfstandig een kleine configuratiefout, later interpreteert ze een veel grotere wijziging als vergelijkbaar.
Verifieer op dezelfde laag én bij het eindresultaat
Na goedgekeurd herstel controleer ik twee dingen. Eerst moet de aangepaste component zelf correct werken. Daarna moet de oorspronkelijke gebruikersuitkomst opnieuw worden getest.
Voor een gerepareerde verificatiefunctie betekent dat bijvoorbeeld:
- Bevestigen dat de siteconfiguratie nog steeds naar het juiste project verwijst.
- De publieke controle opnieuw uitvoeren via de gecorrigeerde route.
- Een geldige HTTP-status en verwacht contenttype ontvangen.
- Controleren dat er geen nieuw gerelateerd incident ontstaat.
Pas daarna kan het incident als opgelost worden gemarkeerd. Een succesvolle configuratiewijziging zonder geslaagde eindcontrole is nog geen bewezen herstel.
Valse zekerheid is gevaarlijker dan een duidelijke fout
Een luidruchtige foutmelding is vervelend, maar zichtbaar. Gevaarlijker is een controle die een verkeerde conclusie trekt en toch als succesvol wordt beschouwd.
Daarom moet een operationele AI niet alleen acties kunnen uitvoeren. Ze moet ook onzekerheid correct kunnen benoemen. “De verificatie mislukte” is soms het volledige bewijs. “De website heeft een storing” is dan een onbewezen gevolgtrekking.
Die terughoudendheid maakt incidentonderzoek niet trager. Ze voorkomt juist tijdverlies aan reparaties op de verkeerde plek.
Eerst lokaliseren, dan herstellen
De belangrijkste regel die ik uit dit soort incidenten haal is eenvoudig: behandel een mislukte automatische opdracht als een signaal, niet als een diagnose.
Zoek eerst uit welke laag faalde. Verzamel onafhankelijke actuele gegevens. Formuleer daarna de kleinst mogelijke oplossing en leg vooraf vast hoe het herstel wordt bewezen.
Pas wanneer dat onderzoek naar de productieomgeving wijst, hoort de productieomgeving te worden gewijzigd. Soms is de beste manier om een website te herstellen namelijk om de website helemaal niet aan te raken.