Beheerbeleid, monitoring, backup/restore en operatie

21.1 Doel en scope

Dit hoofdstuk beschrijft de technische operationele inrichting van OefenHub. Het hoofdstuk legt vast hoe de applicatie beheerd, gemonitord, geback-upt, hersteld, uitgerold en operationeel bewaakt wordt. De uitwerking hoort bij het Technisch Ontwerp en beschrijft geen nieuwe functionele eisen voor eindgebruikers.

De operationele baseline sluit aan op de gekozen middel-zware modulaire monoliet:

• één deploybare .NET/Blazor-applicatie;
• één relationele database;
• één applicatieconnectionstring in de eerste baseline;
• meerdere moduleprojecten met eigen DbContext en schema waar zij persistente data bezitten;
• TickerQ voor geplande en retrybare achtergrondverwerking;
• technische oefenmodules als afzonderlijke moduleprojecten;
• geen aparte basisprojecten voor Audit, Security, Workflows of centrale ReadModels.

Operationeel beheer moet de modulegrenzen respecteren. Monitoring, logging, backup, restore en incidentanalyse mogen domeinoverstijgend inzicht bieden, maar mogen geen tweede functionele bron van waarheid worden naast de domeinmodules en database-informatie.

21.2 Afbakening ten opzichte van andere hoofdstukken binnen het Technisch Ontwerp

Onderwerp	Primaire plek binnen Technisch Ontwerp	Rol van dit hoofdstuk
Solution- en projectopbouw	02-architectuuroverzicht-en-solution-opbouw	Operationele gevolgen voor deployment, monitoring en beheer
Projectstructuur en dependency-richting	03-applicatielagen-projectstructuur-en-dependency-richting	Beheerbaarheid van modulegrenzen en runtimeconfiguratie
Identity, login en provisioning	04-identiteit-authenticatie-en-rolcontext	Operationele controle op providerkoppeling, loginfouten en provisioningincidenten
Autorisatie en contextcontrole	05-autorisatie-policies-en-server-side-contextcontrole	Monitoring van access denied, verdachte toegangspogingen en beheerherstel
Database, migrations en seeddata	07-databaseontwerp-migraties-seeddata-en-constraints	Backup/restore, migratievolgorde, rollback en operationele databasechecks
TickerQ en background jobs	18-background-jobs-tickerq-en-periodieke-verwerking	Operationeel beheer, interne dashboardtoegang, failed jobs en jobherstel
Logging en foutafhandeling	19-logging-audit-securitylogging-en-technische-foutafhandeling	Logretentie, monitoring, incidentanalyse en operationele escalatie
Security infrastructuur	20-security-infrastructuur-secrets-en-omgevingen	Operationeel beheer van secrets, headers, rate limiting, omgevingen en interne tooling
Teststrategie	23-teststrategie-acceptatieherleidbaarheid-en-kwaliteitsgrenzen	Smoke tests, releasechecks, restoretests en operationele kwaliteitsgrenzen
Privacy en retentie	25-privacy-retentie-anonimisering-en-gegevensbescherming	Operationele borging van bewaartermijnen, exports, logs en anonimisering

Dit hoofdstuk beschrijft operationele afspraken. Wanneer tijdens beheer blijkt dat een functionele regel ontbreekt of anders moet werken, wordt die wijziging niet alleen hier aangepast maar ook beoordeeld op impact voor Functioneel Ontwerp, Software Requirements Specification, database-informatie, schermdocumentatie en usecases.

21.3 Operationele uitgangspunten

Uitgangspunt	Technische betekenis
Beheer is veilig standaardgedrag	Interne dashboards, jobbeheer, logs en technische beheeracties zijn nooit publiek toegankelijk.
Observability is verplicht	Iedere relevante request-, workflow-, job- en foutstroom moet herleidbaar zijn met correlation-id's.
Backup is pas bruikbaar na restoretest	Een backupstrategie is niet compleet zonder periodiek bewezen herstel.
Migrations zijn onderdeel van releasebeheer	Databasewijzigingen worden niet los of handmatig buiten releasecontrole uitgevoerd, behalve bij expliciete incidentprocedure.
Geen stille half-afgeronde beheeracties	Failed jobs, mislukte workflows en migratiefouten moeten zichtbaar, herleidbaar en herstelbaar zijn.
Geen persoonsgegevens in technische logs	Operationele logs bevatten identifiers en context, maar geen wachtwoorden, tokens, antwoorden, volledige payloads of onnodige persoonsgegevens.
Beheeracties blijven auditbaar in het eigenaardomein	Domeinspecifieke beheer- en historiegegevens blijven bij het domein dat eigenaar is van de bronmutatie.
Operationele tooling volgt autorisatie	Alleen bevoegde beheerders of technisch beheer krijgen toegang tot interne dashboards en herstelacties.

21.4 Omgevingen en operationele scheiding

OefenHub werkt minimaal met gescheiden omgevingen voor lokale ontwikkeling, test/acceptatie en productie. Iedere omgeving heeft eigen configuratie, secrets, identity-providerconfiguratie, database, TickerQ-persistence en operationele logging.

Omgeving	Doel	Belangrijke regels
Development	Lokale ontwikkeling en moduleontwikkeling	Mag ontwikkelseeddata bevatten. Mag geen productiedata gebruiken.
Test	Technische integratietests en CI-validatie	Wegwerpbaar. Database mag automatisch worden opgebouwd en verwijderd.
Acceptance	Acceptatie, smoke tests en releasevalidatie	Benadert productieconfiguratie. Geen echte leerling-/gebruikersdata tenzij expliciet toegestaan en geanonimiseerd.
Production	Werkelijke applicatieomgeving	Strikte secrets, backup, monitoring, logging, rate limiting, interne dashboardafscherming en change control.

Configuratieverschillen tussen omgevingen worden expliciet beheerd via environment variables voor niet-geheime configuratie, secretbestanden, Docker Compose secrets, Docker/Portainer Swarm secrets wanneer Swarm wordt gebruikt, of omgevingseigen configuratiebronnen. Gevoelige waarden staan niet in broncode, containerimages, Dockerfiles, appsettings in de repository of gedeelde documentatie.

De V1.0-secretbaseline volgt het huidige inzicht dat productie initieel in een Dockeromgeving live gaat. Daarom is file-based secretbeheer buiten repository en image de operationele voorkeur. De exacte route blijft afhankelijk van de gekozen Docker-/Portainer-modus; wanneer die route bij implementatie anders uitpakt, wordt de veiligste gelijkwaardige file-based oplossing gekozen of wordt een nieuw Technisch Ontwerp-besluit gevraagd.

21.4.1 Minimale omgevingconfiguratie

Configuratiegebied	Voorbeelden	Operationele controle
Database	connectionstring, command timeout, migrationmodus	Applicatie start niet zonder geldige configuratie.
Identity provider	authority, client-id, callback, issuer, audience	Smoke test op login/provisioningflow.
Cookie/security	cookie flags, SameSite, secure policy, HSTS	Verificatie in security smoke tests.
TickerQ	persistence, schema, dashboardbeschikbaarheid, retryinstellingen	Jobdashboard intern bereikbaar en niet publiek.
Logging	sink, niveau, retentie, correlation, masking	Test op correlation-id en geen gevoelige logging.
PDF/export	OefenHub:Reporting:TempExportPath, maximale bestandsgrootte, cleanuptermijn	Locatie buiten webroot, standaardretentie 24 uur, cleanup minimaal iedere 6 uur en achterstandsignalering vanaf 48 uur.
SignalR	reconnectbeleid, hubroutes, transportinstellingen	Live-meekijk smoke test.
Rate limiting	limieten per endpointgroep/context	Test op begrensde misbruikscenario's.
Secrets	databasewachtwoorden, client secrets, SMTP- of storagecredentials	Secretbestanden/Compose secrets/Swarm secrets buiten repository en image; waarden niet loggen.

21.5 Operationele rollen en toegang

Operationele toegang is niet hetzelfde als functionele beheerdertoegang binnen OefenHub. Een functionele beheerder kan applicatiebeheer uitvoeren volgens de beheerfunctionaliteit, maar krijgt niet automatisch toegang tot hosting, database, logs, secrets of interne jobdashboards.

Roltype	Voorbeelden	Toegang
Functionele beheerder	OefenHub-beheerder in de applicatie	Applicatiebeheer binnen Admin, supportflows, contentbeheer, accountbeheer volgens autorisatie.
Technisch beheerder	Hosting/applicatiebeheerder	Deployment, configuratie, logs, TickerQ-dashboard, backup/restore, incidentanalyse.
Databasebeheerder	DBA of technisch beheer met DB-rechten	Backup, restore, migratieanalyse, performanceanalyse. Geen inhoudelijke gebruikersacties.
Ontwikkelaar	Developer/maintainer	Broncode, tests, CI/CD, lokale/testomgevingen. Productietoegang alleen volgens beheerbeleid.
Auditor/analist	Controle of incidentanalyse	Alleen noodzakelijke logging/history, bij voorkeur read-only en geminimaliseerd.

Operationele toegang moet minimaal voldoen aan:

• least privilege;
• gescheiden accounts waar mogelijk;
• MFA waar ondersteund;
• geen gedeelde persoonlijke accounts;
• logging van beheeracties;
• periodieke controle op toegang;
• directe intrekking bij rolwijziging of vertrek.

21.6 Monitoringstrategie

Monitoring moet aantonen of OefenHub beschikbaar, veilig, performant en consistent draait. Monitoring is niet alleen infrastructuurmonitoring, maar omvat ook applicatiesignalen, domeinprocessen, background jobs en functionele kernstromen.

21.6.1 Monitoringlagen

Laag	Te bewaken signalen	Voorbeelden
Infrastructuur	CPU, geheugen, opslag, netwerk, certificaten	Schijfruimte bijna vol, certificaat verloopt, hoge CPU.
Applicatie	HTTP-statussen, latency, exceptions, startup health	Toename 500-fouten, trage login, falende PDF-export.
Database	connectiviteit, querylatency, locks, migratiestatus, backupstatus	Langzame historyquery, migration niet toegepast.
Identity provider	bereikbaarheid, loginfouten, tokenvalidatie	Keycloak niet bereikbaar, issuer mismatch.
Mailprovider	bereikbaarheid, verzendfouten, timeoutpercentages, failed maildelivery jobs	Provider niet bereikbaar, authenticatiefout, te veel retries.
TickerQ/jobs	pending, running, failed, retries, stale jobs	Cleanup faalt, verlopen uitnodigingen blijven pending.
SignalR	connecties, reconnects, hubfouten	Veel reconnect failures bij live meekijken.
Security	access denied, rate limiting, verdachte patronen	Veel IDOR-pogingen of brute-force-achtig verkeer.
Exports	PDF-generatie, tijdelijke bestanden, cleanup	Exportlocatie loopt vol.

21.6.2 Health checks

De applicatie krijgt health checks die onderscheid maken tussen eenvoudige beschikbaarheid en diepere readiness.

Check	Doel	Verwachte inhoud
Liveness	Is het proces actief?	Minimale check zonder externe afhankelijkheden.
Readiness	Kan de app verkeer verwerken?	Databaseconnectie, essentiële configuratie, identity provider basisbereikbaarheid waar passend.
Database health	Is de database bereikbaar en consistent genoeg?	Connectie, eventueel migrationversie.
Scheduling health	Kan TickerQ jobs verwerken?	Persistence bereikbaar, geen structurele failed backlog boven grens.
Export health	Is tijdelijke exportlocatie bruikbaar?	Locatie bestaat, schrijfbaar, voldoende ruimte.
SignalR health	Is de realtime-laag beschikbaar?	Hubregistratie en basisconnectiviteit.

Health checks mogen geen gevoelige configuratie of persoonsgegevens teruggeven. Publieke of semi-publieke health endpoints geven hoogstens globale status. Detailinformatie hoort alleen in interne monitoring.

21.6.3 Alertcategorieën

Ernst	Betekenis	Voorbeelden	Actie
Info	Relevante operationele gebeurtenis	Release gestart, job batch voltooid	Geen directe actie.
Warning	Mogelijk probleem of verslechtering	Retrybacklog groeit, veel 403's, exportcleanup te laat	Controle door technisch beheer.
Error	Fout met gebruikers- of dataverwerkingsimpact	PDF-export faalt structureel, login provisioning faalt	Actieve opvolging vereist.
Critical	Beschikbaarheid, dataverliesrisico of securityincident	Database onbereikbaar, backup mislukt, verdachte toegangspiek	Directe escalatie.

21.7 Logging, correlation en operationele herleidbaarheid

Operationele herleidbaarheid is noodzakelijk bij cross-module workflows, background jobs, provisioning, live meekijken, exports en beheeracties. Iedere relevante request en iedere jobuitvoering krijgt een correlation-id die wordt doorgegeven aan alle betrokken modulecontracten.

Serilog en Seq vormen de baseline voor gestructureerde technische logging en operationele loganalyse. Serilog levert de gestructureerde logevents via de .NET loggingabstractie; Seq wordt gebruikt als centrale viewer voor zoeken, filteren en incidentanalyse. Toegang tot Seq is intern/beheerd, volgt least privilege en mag geen functionele brondata of onbeperkte persoonsdata ontsluiten.

De concrete Serilog-/Seq-configuratie, minimale logniveaus, sinkkeuze, scrubbing en retentietermijnen staan in Technisch Ontwerp: logging, audit, securitylogging en technische foutafhandeling. Operationeel beheer controleert of de Seq-retentiepolicies, toegang en opslaggrenzen daarmee overeenkomen.

21.7.1 Verplichte operationele contextvelden

Veld	Gebruik
CorrelationId	Verbindt request, workflow, job, databaseactie en logregels.
RequestId	Technische requestherleiding binnen Web/API.
JobId	Herleiding naar TickerQ/jobpersistence.
JobType	Type achtergrondtaak of retrybare verwerking.
ModuleName	Module die logregel of actie produceert.
ActionName	Functionele of technische actie.
UserId	Alleen als nodig en bij voorkeur als interne identifier, geen naam/e-mail.
RoleContext	Actieve rolcontext wanneer relevant.
EntityType	Domeinobjecttype, zoals Ticket, ExerciseRun, RelationshipInvitation.
EntityId	Interne identifier of soft link naar betrokken object.
Result	Succeeded, Failed, Denied, Retried, Skipped.
ErrorCode	Gestandaardiseerde technische of domeinfoutcode.

21.7.2 Wat niet gelogd mag worden

Niet loggen	Reden
Wachtwoorden, tokens, refresh tokens, cookies	Credentials/geheime waarden.
Volledige identity-providerresponses	Kan tokens of persoonsgegevens bevatten.
Volledige oefenantwoorden of vraagpayloads	Leerlingdata en modulepayloads zijn inhoudelijk gevoelig.
Volledige PDF-inhoud	Exportinhoud is geen logdata.
Vrije berichtinhoud of ticketdiscussies	Persoons- en communicatiedata.
Volledige stacktraces naar gebruiker	Informatiebeveiliging. Intern mag beperkt en gemaskeerd gelogd worden.
Secrets of connectionstrings	Configuratiegeheimen.

21.8 Backupstrategie

Backup is verplicht voor de relationele database en voor operationele configuratie die nodig is om OefenHub te herstellen. Omdat PDF-bestanden tijdelijke output zijn en opnieuw gegenereerd worden vanuit databasegegevens, zijn tijdelijke exports geen primaire backupbron.

21.8.1 Backupscope

Object	Backup nodig?	Toelichting
Relationele database	Ja	Primaire bron voor accounts, catalogus, oefenruns, berichten, tickets, jobs en beheerdata.
TickerQ/jobpersistence	Ja	Onderdeel van database of scheduling-schema; nodig om pending/failed jobs niet kwijt te raken.
Applicatieconfiguratie	Ja	Niet de secrets zelf in documentatie, maar reproduceerbare configuratie per omgeving.
Secrets	Ja, via secret store/beheerproces	Niet in applicatiebackup of logs.
Uploads	Vooralsnog beperkt	Vrije uploads zijn in eerste versie niet leidend; eventuele toegestane bestanden krijgen eigen beleid.
Tijdelijke PDF-bestanden	Nee	Worden periodiek opgeschoond en opnieuw opgebouwd uit brondata.
Logs	Afhankelijk van beleid	Nodig voor incidentanalyse, maar geen brondata voor functionele restore.
Build artifacts	Ja, via CI/CD-artifactopslag	Nodig voor rollback naar vorige applicatieversie.

21.8.2 Backupfrequentie en bewaartermijnen

Exacte frequenties worden operationeel vastgesteld, maar de technische baseline moet ten minste deze categorieën ondersteunen:

Type backup	Doel	Richting
Volledige databasebackup	Herstel na groot incident	Minimaal dagelijks voor productie.
Transaction/log backup of equivalent	Beperken van dataverlies	Niet vereist voor de V1.0-baseline zolang de RPO van 5 × 24 uur aantoonbaar wordt gehaald; mag platformmatig worden gebruikt.
Pre-deployment backup	Rollback bij releaseproblemen	Voor databasewijzigingen met migratierisico.
Configuratiebackup	Reproduceerbare omgeving	Bij configuratiewijzigingen.
Restoretestbackup	Periodieke herstelvalidatie	Op acceptatie of aparte restoreomgeving.

21.8.3 Recovery point objective en recovery time objective

OefenHub is in de V1.0-baseline geen kritieke 24/7-dienst en kent geen hoge-beschikbaarheidseis. Backup en restore zijn daarom gericht op aantoonbare herstelbaarheid en gegevensbehoud, niet op near-zero downtime of continue beschikbaarheid.

Hersteldoel	V1.0-baseline	Toelichting
Recovery point objective (RPO)	Maximaal 5 × 24 uur dataverlies	De backupinrichting moet kunnen herstellen naar een bruikbaar herstelpunt van maximaal vijf dagen oud. Dagelijkse databasebackups zijn voldoende wanneer retentie, opslag en monitoring dit aantoonbaar ondersteunen.
Recovery time objective (RTO)	Maximaal 3 werkdagen na besluit tot restore	De RTO loopt vanaf het expliciete besluit om een restore uit te voeren, niet vanaf eerste incidentmelding of analysefase.
Beschikbaarheidsniveau	Geen high-availability baseline	Hot standby, active-active, multi-region failover en zero-downtime restore vallen buiten de V1.0-baseline.
Restorevalidatie	Periodiek en releasegericht aantonen	Restoretests tonen aan dat database, configuratie, secretsproces, applicatieversie en basale smoke tests samen herstelbaar zijn.

De RPO/RTO-baseline geldt voor productiegegevens in de database, beheerbare configuratie/content en eventuele productieuploads die als brondata zijn toegestaan. Tijdelijke PDF-bestanden, build artifacts en technische logs zijn geen primaire functionele brondata, maar worden wel meegenomen in operationeel beheer voor rollback, analyse of compliance waar dat nodig is.

21.9 Restorestrategie

Een backup is pas operationeel betrouwbaar wanneer herstel periodiek getest is. Restoreprocedures moeten niet alleen de database terugzetten, maar ook controleren of de applicatie na herstel functioneel veilig kan starten.

21.9.1 Restoretypen

Restoretype	Doel	Procedurele aandachtspunten
Volledige omgevingsrestore	Productie herstellen na groot incident	Database, configuratie, secrets, applicatieversie, jobs en smoke tests.
Point-in-time restore	Herstel naar moment vóór fout	Vereist logbackup of platformequivalent.
Selectieve analyse-restore	Incidentonderzoek zonder productie te raken	Alleen in afgeschermde omgeving met privacymaatregelen.
Pre-release rollbackrestore	Terug naar situatie vóór migratie	Applicatieversie en databaseschema moeten compatibel zijn.
Restoretest	Bewijzen dat backups bruikbaar zijn	Periodiek uitvoeren en resultaat vastleggen.

21.9.2 Restorevalidatie

Na restore worden minimaal de volgende controles uitgevoerd:

Controle	Voorbeeld
Applicatie start	Startup zonder configuratie- of migrationfouten.
Database bereikbaar	Health check en basisquery slagen.
Migrationstatus klopt	Geen half toegepaste migrations.
Identitykoppeling werkt	Login/provisioning smoke test op testaccount.
Autorisatie werkt	Leerling/docent/ouder/beheerder contextchecks.
TickerQ werkt	Pending jobs zichtbaar en verwerkbaar.
Jobs niet dubbel uitgevoerd	Idempotentie en jobstatussen controleren.
PDF-export werkt	Tijdelijke export kan opnieuw worden gegenereerd.
SignalR werkt	Basis live-update of hubconnectie smoke test.
Logs/correlation werken	Nieuwe acties hebben correlation-id.

21.10 Databasebeheer en migrations in operatie

Databasebeheer volgt de modulegrenzen uit het Technisch Ontwerp. Iedere module met eigen persistentie heeft een eigen DbContext en schema. Migrations worden niet handmatig los uitgevoerd buiten het releaseproces, tenzij sprake is van een expliciete incidentprocedure.

21.10.1 Releasevolgorde bij databasewijzigingen

Stap	Doel
1. Preflight	Controleer configuratie, databaseconnectie, migratieplan en beschikbare backup.
2. Backup	Maak pre-deployment backup wanneer schemawijzigingen of datamigraties risico geven.
3. Migrations	Voer modulemigrations uit in vastgelegde volgorde.
4. Seed/migratiedata	Voer alleen idempotente en expliciet bedoelde seed- of datamigratiestappen uit.
5. Applicatierelease	Deploy applicatieversie die bij schema hoort.
6. Smoke tests	Controleer login, frontpage, oefeningstart, jobdashboard, PDF en kernflows.
7. Monitoring	Bewaak fouten, performance, migrations en jobstatussen na release.

21.10.2 Backward-compatible migrations

Waar mogelijk worden databasewijzigingen backward-compatible ontworpen:

• nieuwe nullable kolommen vóór verplicht maken;
• nieuwe tabellen zonder bestaande flows te breken;
• oude kolommen pas verwijderen na overgangsrelease;
• data backfill als expliciete migratie- of jobstap;
• featuretoggle of codepad pas activeren nadat schema en data gereed zijn.

Cross-module harde FK's zijn uitzondering. Wanneer zo'n uitzondering toch wordt geïntroduceerd, moet de migratievolgorde en rollbackimpact expliciet worden vastgelegd.

21.11 Seeddata en beheerbare configuratie in operatie

Seeddata is module-eigen en idempotent. Operationeel beheer moet voorkomen dat beheerbare content onbedoeld wordt teruggezet door een release.

Type data	Voorbeeld	Operationeel gedrag
Technische referentiedata	ticketstatussen, resolutietypen	Idempotent controleren en aanvullen.
Initiële beheercontent	popupdefinities, systeemberichttemplates	Alleen initieel of via expliciete migratie aanpassen.
Modulemetadata	technische oefenmodulebeschrijvingen	Via modulehost/catalogproces actualiseren.
Testdata	ontwikkelaccounts, voorbeeldruns	Alleen development/test, nooit productie.
Featuretoggles	sitebrede schakelaars	Beheerd via expliciet beheerdomein, niet stil overschrijven.

Seedmechanismen mogen niet blind iedere deployment bestaande beheeraanpassingen overschrijven.

21.12 TickerQ en joboperatie

TickerQ is onderdeel van de operationele basis. Jobs mogen niet verloren gaan bij applicatieherstart. Daarom wordt TickerQ-persistence gebruikt, bij voorkeur in schema scheduling.

21.12.1 Operationele verantwoordelijkheden van OefenHub.Scheduling

Verantwoordelijkheid	Toelichting
Jobaanname	Domeinen plannen jobs via publieke schedulingcontracten.
Jobpersistence	Jobs, status, pogingen en foutinformatie blijven bewaard.
Triggering	TickerQ triggert jobs volgens planning.
Retrybeleid	Retryconfiguratie wordt per jobtype bepaald.
Failed status	Jobs eindigen na begrensde retries in beheerbare foutstatus.
Dashboard	Interne jobinterface voor technisch beheer.
Correlation	Joblogs zijn gekoppeld aan request/workflow via correlation-id.
Domeinuitvoering	Uitvoering gebeurt via publieke contracten van eigenaarmodules.

21.12.2 TickerQ-dashboard

Het TickerQ-dashboard wordt alleen intern beschikbaar gemaakt. Het dashboard mag niet publiek bereikbaar zijn via internet of reguliere eindgebruikersroutes.

Minimale maatregelen:

• afschermen achter intern netwerk, VPN of streng beheerpad;
• extra autorisatie voor technisch beheer;
• geen toegang voor reguliere applicatiegebruikers;
• geen weergave van gevoelige payloadinhoud;
• logging van beheeracties zoals retry, cancel of manual trigger;
• expliciete configuratie per omgeving.

21.12.3 Failed jobs

Failed jobs zijn operationele incidenten of herstelpunten, geen normale eindtoestand die genegeerd mag worden.

Failed-job aspect	Vereiste
Zichtbaarheid	Failed jobs zijn zichtbaar in intern beheer/monitoring.
Begrensde retries	Geen oneindige retryloops.
Laatste fout	Foutcode en samenvatting worden opgeslagen zonder gevoelige payload.
Correlation	Herleidbaar naar request, workflow of initiërende module.
Idempotentie	Handmatige retry mag geen dubbele domeinmutatie veroorzaken.
Escalatie	Structurele failed jobs leiden tot alert.

21.13 Interne beheerinterfaces

Interne beheerinterfaces zijn technische hulpmiddelen voor beheer en operatie. Zij zijn geen onderdeel van de publieke applicatie-ervaring.

Interface	Doel	Bescherming
TickerQ-dashboard	Jobs bekijken, failed jobs analyseren, retries beheren	Intern + technisch beheerautorisatie.
Health detail view	Diepere statusinformatie	Alleen intern.
Log/monitoringdashboard	Fout- en performanceanalyse	Alleen technisch beheer.
Databasebeheerconsole	Databaseonderhoud	Buiten applicatie, strikt beperkt.
Hosting/deploymentconsole	Releases en configuratie	Alleen technisch beheer.

Als een interne interface toch binnen dezelfde webhost draait, moet routing en autorisatie expliciet voorkomen dat reguliere gebruikers deze kunnen bereiken.

21.14 Incidentafhandeling

Incidentafhandeling volgt een vast technisch patroon: detecteren, stabiliseren, analyseren, herstellen, controleren en documenteren.

21.14.1 Incidentfasen

Fase	Activiteit
Detectie	Alert, gebruikersmelding, failed job, logpiek of health-check failure.
Triage	Impact, ernst, betrokken modules, correlation-id's en datarisico bepalen.
Stabilisatie	Verkeer beperken, feature uitschakelen, job pauzeren of rollback voorbereiden.
Analyse	Logs, domeinhistorie, jobstatussen, databasechecks en configuratie controleren.
Herstel	Retry, fix, rollback, restore, hotfix of handmatige beheeractie volgens procedure.
Validatie	Smoke tests, monitoring en domeincontrole.
Nazorg	Root cause, documentatie-impact, tests en eventuele Functioneel Ontwerp-, Software Requirements Specification-, Technisch Ontwerp- of database-informatie-aanpassing.

21.14.2 Incidentclassificatie

Type incident	Voorbeelden	Eerste focus
Beschikbaarheid	App of database onbereikbaar	Stabilisatie, rollback/restore, communicatie.
Dataconsistentie	Halve workflow, failed kritieke job	Correlation, transactionstatus, domeinhistorie.
Security	Verdachte toegang, token/configuratiefout	Beperken, loganalyse, secrets/identity controleren.
Privacy	Onbedoelde dataweergave of export	Toegang stoppen, impactanalyse, logging minimaliseren.
Performance	Trage dashboards, database locks	Queryanalyse, indexen, caching/readmodels.
Background processing	Failed jobs of groeiende backlog	TickerQ-dashboard, retrybeleid, jobpayload, domeincontract.
Export/storage	PDF-generatie faalt, opslag vol	Tijdelijke opslag, cleanup, Reporting/Practice checks.

21.15 Release-, deployment- en rollbackbeleid

Releases worden gecontroleerd uitgevoerd. Een release bestaat uit applicatiecode, moduleversies, configuratie, migrations, seed-/datamigratiestappen en smoke tests.

21.15.1 Release-artifacts

Artifact	Voorbeelden
Applicatiebuild	Deploybare OefenHub.Web-applicatie en gekoppelde assemblies.
Moduleassemblies	Concrete oefenmodules zoals OefenHub.Modules.Arithmetic.Addition.
Database migrations	Module-eigen EF Core migrations.
Configuratieschema	Verwachte environment variables en options.
Seed-/referentiedata	Idempotente datawijzigingen per module.
Testresultaten	CI, architecture tests, migration tests, security/config checks.
Release notes	Technische wijzigingen, migraties, rollbackrisico's.

21.15.2 Deploymentflow

21.15.3 Smoke tests na deployment

Minimaal:

• applicatie start en health checks slagen;
• databaseconnectie werkt;
• migrationstatus is correct;
• login via identity provider werkt;
• mailproviderconfiguratie valideert zonder secrets te tonen, wanneer mail in de omgeving is geactiveerd;
• interne accountcontext wordt opgebouwd;
• server-side autorisatie wijst ongeldige toegang af;
• leerling kan toegankelijke oefening openen of veilige lege toestand zien;
• eenvoudige oefenrun kan starten en voortgang opslaan in test/acceptatie;
• TickerQ-dashboard is intern bereikbaar en jobs kunnen draaien;
• PDF-export werkt op testdata;
• SignalR-basistest werkt;
• securityheaders zijn aanwezig;
• logs bevatten correlation-id's.

21.15.4 Rollbackstrategie

Rollback wordt vooraf beoordeeld per release. Applicatiecode kan vaak sneller teruggedraaid worden dan databasewijzigingen. Daarom moeten databasewijzigingen zoveel mogelijk backward-compatible zijn.

Rollbacktype	Gebruik
Applicatie rollback	Vorige applicatieversie herdeployen wanneer schema compatibel is.
Feature rollback	Featuretoggle uitschakelen of codepad deactiveren.
Job rollback	Jobtype pauzeren, failed jobs markeren of retry blokkeren.
Database restore	Alleen bij ernstig incident; vereist impactanalyse op nieuwere data.
Datafix	Alleen via expliciete procedure, logging en indien nodig review.

Handmatige datacorrecties in productie zijn uitzonderlijk en moeten herleidbaar zijn.

21.16 Operationele securitychecks

Security is geen apart project, maar wordt operationeel wel expliciet beheerd.

Check	Frequentie/richting	Toelichting
HSTS/HTTPS	Bij release en periodiek	Alleen veilige verbindingen in productie.
Securityheaders/CSP	Bij release	Headers aanwezig en niet te ruim.
Cookieflags	Bij release	Secure, HttpOnly en SameSite correct.
Rate limiting	Bij release en incidenten	Limieten werken op relevante endpoints.
Identity provider config	Bij release en providerwijziging	Authority, callback, issuer en clientconfig correct.
Secretsrotatie	Periodiek en bij incident	Secrets niet in logs of broncode.
Access-denied spikes	Monitoring	Mogelijk misbruik of autorisatiefout.
TickerQ-dashboard exposure	Bij release	Dashboard niet publiek bereikbaar.
Dependency scanning	CI/CD	Kwetsbare packages signaleren.

21.17 Logretentie en operationele dataretentie

Logretentie wordt gescheiden van functionele dataretentie. Functionele data blijft volgens domeinregels bewaard of geanonimiseerd. Technische logs worden korter bewaard en bevatten geen volledige persoonsgegevens of inhoudelijke payloads.

Datatype	Eigenaarschap	Retentierichting
Domeinhistorie	Eigen domeinmodule	Volgens functionele/auditregels van het domein.
Developmentlogs	Operationele logging	Best effort, maximaal 7 dagen.
Test-/acceptatielogs	Operationele logging	14 dagen.
Productie Debug/Verbose	Operationele logging	192 uur (8 dagen), alleen wanneer tijdelijk ingeschakeld.
Productie reguliere technische logs	Operationele logging	120 dagen.
Productie securityrelevante technische logs	Operationele/securitymonitoring	360 dagen, geminimaliseerd en zonder gevoelige payloads.
Critical incidentselectie	Operationele/securitymonitoring	Maximaal 720 dagen na expliciete incidentregistratie.
Jobhistorie	Scheduling	Lang genoeg voor retry, analyse en audit van verwerking.
Tijdelijke PDF-bestanden	Reporting/Scheduling	Standaard 24 uur; cleanup minimaal iedere 6 uur; achterstandsignalering vanaf 48 uur.
Health/metrics	Monitoringplatform	Geaggregeerd waar mogelijk.

Deze termijnen zijn de V1.0-baseline. Kortere termijnen zijn toegestaan wanneer privacy-, hosting- of opslagbeleid dat vereist. Nog langere generieke logretentie vereist een nieuw besluit.

21.18 Performance- en capaciteitsbeheer

Operationeel beheer bewaakt of de gekozen modulaire monoliet binnen acceptabele grenzen blijft presteren.

Belangrijke indicatoren:

• responstijd per rolcontext en hoofdflow;
• queryduur voor geschiedenis, resultaten, dashboards en mailbox;
• aantal actieve SignalR-connecties;
• tijd tussen antwoordbevestiging en live-update;
• PDF-generatietijd en bestandsgrootte;
• jobbacklog en gemiddelde jobduur;
• database locks en connection pool-gebruik;
• memorygebruik bij exports en grote readmodels;
• opslaggroei van logs, jobs, exercise payloads en tijdelijke bestanden.

Wanneer performanceproblemen ontstaan, wordt eerst gekeken naar queryscoping, indexen, readmodelstrategie, paging, materialisatie en caching voordat modulegrenzen worden doorbroken.

21.19 Backup/restore en privacy

Restore naar niet-productieomgevingen mag niet automatisch betekenen dat echte persoonsgegevens beschikbaar worden voor ontwikkeling of test. Wanneer productiedata nodig is voor analyse, geldt minimaal:

• toegang beperken tot strikt noodzakelijke personen;
• waar mogelijk anonimiseren of maskeren;
• geen export naar lokale onbeveiligde machines;
• logs en analysebestanden opruimen na incident;
• geen productiedata gebruiken voor reguliere developmenttests;
• documenteren waarom restore/analyse nodig was.

Bij privacyincidenten wordt logging zorgvuldig gebruikt: genoeg voor reconstructie, maar zonder verdere verspreiding van gevoelige inhoud.

21.20 Operationele beheeracties per domein

Domein	Operationele beheeracties	Let op
Identity	Provisioningfouten analyseren, accountstatus controleren	Geen wachtwoorden of providercredentials wijzigen in OefenHub.
Authorization	Policy/configuratiefouten analyseren	Clientstate nooit als bewijs gebruiken.
Relationships	Verlopen uitnodigingen, conflictanalyse, geforceerde ontkoppeling via beheerflow	Relatiehistorie behouden.
Catalog	Modulemetadata, categoriemigratie, oefeningstatussen	Historische runs niet herschrijven.
Practice	Testrun-cleanup, runanalyse, voortgangsconsistentie	Leerlingresultaten niet handmatig corrigeren zonder expliciete procedure.
Communication	Failed systeemberichten, threadretentie, badge/readmodelherstel	Geen vrije inhoud in technische logs.
Support	Verlopen heropentermijnen, failed doorzetacties, ticketanalyse	Interne en externe discussie scheiden.
LiveMonitoring	LiveViewAudit, connectieproblemen, SignalR-fouten	Meekijken blijft read-only.
Reporting	PDF-exportfouten, tijdelijke bestandsopruiming	PDF opnieuw genereren uit brondata.
Scheduling	Failed jobs, retries, jobdashboard, stale jobs	Jobpayloads veilig houden.
Admin	Beheercontent, templates, features, instellingen	Beheerhistory vastleggen.

21.21 Documentatie-impact bij operationele wijzigingen

Operationele wijzigingen kunnen documentatie-impact hebben. Bij iedere wijziging in deployment, jobs, database, security, logging, backup of monitoring wordt minimaal beoordeeld:

Vraag	Mogelijke documentatie-impact
Wijzigt de functionele werking?	Functioneel Ontwerp, Software Requirements Specification, usecases en schermdocumentatie.
Wijzigt het datamodel?	Database-informatie, ERD, Technisch Ontwerp-hoofdstuk 06/07.
Wijzigt de modulegrens?	Technisch Ontwerp-hoofdstuk 02/03/06.
Wijzigt autorisatie of security?	Technisch Ontwerp-hoofdstuk 05/19/20 en mogelijk Software Requirements Specification.
Wijzigt een job of retryflow?	Technisch Ontwerp-hoofdstuk 18/21.
Wijzigt logging of retentie?	Technisch Ontwerp-hoofdstuk 19/21/25.
Wijzigt test- of releasebeleid?	Technisch Ontwerp-hoofdstuk 21/23.

21.22 Implementatiechecklist

Controlepunt	Verwachting
Omgevingsconfiguratie	Per omgeving expliciet en gevalideerd.
Secrets	Niet in broncode, logs of documentatie.
Health checks	Liveness, readiness en relevante dependencychecks.
Monitoring	Applicatie, database, jobs, SignalR, exports en securitysignalen.
Logging	Correlation-id's en veilige inhoud.
Backup	Databasebackup en configuratieherstel ingericht binnen de RPO van maximaal 5 × 24 uur.
Restoretest	Periodiek uitgevoerd en vastgelegd; herstelpad past binnen de RTO van maximaal 3 werkdagen na restorebesluit.
Migrations	Module-eigen, gecontroleerd en onderdeel van releaseproces.
Seeddata	Idempotent en niet blind overschrijvend.
TickerQ	Persistence, schema, retries volgens de jobtype-defaultmatrix en intern dashboard ingericht.
Failed jobs	Zichtbaar, begrensd retrybaar en beheerbaar.
Interne dashboards	Niet publiek bereikbaar.
Smoke tests	Na deployment uitgevoerd.
Rollbackplan	Per release beoordeeld.
Securitychecks	Headers, HSTS, cookies, rate limiting en dashboardafscherming getest.
Logretentie	Termijnen en privacygrenzen vastgelegd.
Documentatie-impact	Bij operationele wijzigingen beoordeeld.

21.23 Implementatieverificaties

Punt	Te bepalen / te verifiëren
RPO/RTO	Verifiëren dat de productiebackup aantoonbaar voldoet aan RPO 5 × 24 uur en RTO 3 werkdagen na restorebesluit.
Backupfrequentie	Definitieve frequentie en bewaartermijnen per omgeving toetsen aan de vastgelegde RPO.
Restoretestfrequentie	Periodieke restoretest plannen, eigenaar bepalen en resultaat vastleggen.
TickerQ-schema	Verifiëren hoe TickerQ-tabellen in schema scheduling worden geplaatst.
Tijdelijke PDF-opslag	OefenHub:Reporting:TempExportPath, rechten, monitoring, 24-uursretentie en cleanupjob minimaal iedere 6 uur controleren.
Serilog/Seq	Configuratie, opslag, toegang, retentie, masking/scrubbing en exportmogelijkheden toetsen aan de vastgelegde baseline.
TickerQ-dashboard	Exacte afscherming, route en beheerautorisatie bepalen.
Logretentie	Seq-retentiepolicies en opslagmonitoring inrichten volgens de vastgelegde termijnen.
Monitoringplatform	Metrics, dashboards en alerts concreet selecteren.
Securityheaders/CSP	CSP en headerconfiguratie toetsen aan de vastgelegde baseline na frontenduitwerking.
Secrets Docker V1.0	Secretbestanden, Docker Compose secrets of Docker/Portainer Swarm secrets toetsen op rechten, mountlocatie, geen waarden in logs en geen waarden in repository/image.
Releasepipeline	CI/CD-tooling, artifactopslag en environment promotion concretiseren.
Migrationrunner	Bepalen of migrations door applicatie, pipeline of apart toolingproces worden uitgevoerd.
Datafixprocedure	Procedure voor uitzonderlijke productiedatacorrecties vastleggen.
Interne beheeraccounts	Technische beheerrollen, MFA en toegangsreviewproces vastleggen.