Sjabloon voor incidentrapport van een evenementenwebsite
Een statuspagina kan ‘hersteld’ melden terwijl de ticketknop nog faalt. Het rapport laat zien welke bezoekerstaken geraakt zijn, wat het team toen wist en hoe herstel is gecontroleerd. Dit sjabloon vult het plan voor verantwoordelijkheden tijdens de storing aan.
De redactie van Boletolibre
Gepubliceerd
Download het bewerkbare rapport
Incidentrapport downloaden (Markdown in het Engels)
Zet vóór de verkoop of evenementdag een lege kopie klaar. Noteer URL’s, regio’s, talen, tijdsgrenzen, acties, leverancierszaken, herstelcontrole en eigenaren. Bewaar logs en screenshots op een geautoriseerde plek; plak geen kopergegevens of geheimen in het rapport.
Begin bij de gevolgen voor bezoekers
Noem editie en fase: voorverkoop, verkoop, deuren of nazorg. Leg vast welke taak faalde, waar dit werd gezien en door wie. Een werkende homepage bewijst niet dat registratie, externe betaling, bevestiging of toegangsinfo werkt. Staat het evenement op Boletolibre.com, controleer dan zo nodig de openbare vermelding en de echte ticketbestemming.
Scheid de vroegste bevestigde fout van de eerste ontdekking. Beperk regio, taal of apparaat alleen met bewijs. Minder pageviews zijn geen telling van verloren aankopen. AWS adviseert prioriteit naar impact en duidelijke verantwoordelijkheid.[1]
Bewaar waarnemingen en besluiten in volgorde
Noteer alarm, melding, wijziging, escalatie, tijdelijke oplossing, bericht en hertest met tijdzone. Elke regel bevat bron, bewijs, besluit en eigenaar. Bewaar wat men destijds wist, ook als later bewijs dit corrigeert.
- Koppel publicatie, DNS-wijziging of leverancierszaak aan het wijzigingsrecord; nabijheid in tijd bewijst geen oorzaak.
- Bewaar logs en screenshots met beperkte toegang en wijs een bewaareigenaar aan.
- Noteer goedgekeurd bezoekersbericht en publicatietijd.
Google SRE legt nadruk op een tijdlijn, impactgegevens en concrete verbeteracties zonder schuldtoewijzing.[3]
Bewijs herstel met het bezoekerstraject
Scheid tijdelijke beperking van definitieve reparatie. Leg goedkeuring, bekende goede versie en resterende problemen vast. Een controleur opent eventinformatie, registratie, officiële kooproute, bevestiging en hulp vanuit een openbare sessie en noteert resultaat, tijd, taal en bewijs.
Loopt betaling via een andere aanbieder, controleer dan jouw link en overdracht; de aanbieder bevestigt zijn eigen verwerking. Houd testgegevens uit echte verkooprapporten.
Analyseer na stabilisatie
Scheid bevestigde oorzaken, mogelijke factoren en open vragen. Waarom kon dit gebeuren, waarom vonden controles het niet en wat vertraagde de reactie? AWS vraagt om impact, bewijs en preventie zonder bij ‘menselijke fout’ te stoppen.[2]
Een gewijzigde ticketlink of één taalpagina met een oude ingang kan verschillende gevolgen geven. Mogelijke blootstelling van gegevens hoort bij bevoegde specialisten; dit rapport stelt geen datalek vast.
Sluit acties met eigenaar en hertest
Geef elke actie een eigenaar, doelmoment, bewijs van uitvoering en hertestresultaat. Toegewezen is niet afgerond. Bekijk open punten vóór de volgende verkoop of editie.
Deel lessen zonder beperkte logs te verspreiden. Het sjabloon vervangt geen incidentprocedure, beveiligingsonderzoek of contractuele beoordeling.
Bronnen en verder lezen
- Responding to eventsAWS Well-Architected Framework · Geraadpleegd
- Perform post-incident analysisAWS Well-Architected Framework · Geraadpleegd
- Postmortem Culture: Learning from FailureGoogle SRE Workbook · Geraadpleegd