In de Service Niveau Overeenkomst staat een beschikbaarheid voor de DRP productieomgeving van minimaal 99% en van de preproductieomgeving minimaal 95%. De hieronder opgegeven beschikbaarheidspercentages hebben een tijdsvenster van 24 uur per dag, 7 dagen per week gemiddeld over de hele maand.
*In april 2025 haalde de preproductieomgeving de minimale beschikbaarheid van 95% niet. Dit kwam doordat deze omgeving meerdere keren niet meer is opgestart na zijn IIS (Internet Information Services) reset. Deze geautomatiseerde reset vindt elke ochtend plaats en duurt normaal gesproken ongeveer 1 minuut.
Responstijd
In de Service Niveau Overeenkomst staat de responstijd van de invoeromgeving met een standaard geborgde piekbelasting van maximaal 0,3 seconden. De responstijd van de invoeromgeving staat gelijk aan de gemeten responstijd van de inlogpagina van DRP.
Onder 'incidenten' verstaan we: elke gebeurtenis die niet tot de standaardoperatie van een dienst behoort en die een interruptie of een vermindering van de kwaliteit van die dienst kan veroorzaken. Afhankelijk van de aard en ernst van het incident wordt een bepaalde prioriteit toegekend:
Prioriteit
Omschrijving
Prio 1
Een ernstige verstoring die alle gebruikers van DRP raakt waardoor het niet langer mogelijk is om op de gebruikelijke wijze documenten in te voeren of waardoor de interne werking zodanig verslechterd is dat documenten niet meer gepubliceerd kunnen worden.
Prio 2
Een verstoring die slechts enkele gebruikers of organisaties raakt waardoor het niet langer mogelijk is om op de gebruikelijke wijze documenten in te voeren.
Prio 3
Alle incidenten die niet vallen onder de definities van Prio 1 of Prio 2.
In onderstaand overzicht wordt weergegeven hoeveel incidenten er in de afgelopen periode door gebruikers zijn gemeld.
Alle incidenten die Prio 1 toegekend hebben gekregen worden hieronder toegelicht en incidenten met Prio 2 met een dusdanige impact dat ze het vermelden waard zijn.
Instabiel gedrag door infrastructuurproblemen
De DRP-software wordt gedeeltelijk gehost op het Standaard Platform van Logius. Dit is een containerplatform waar meerdere afnemers gebruik van maken en waar ook meerdere applicaties van KOOP op draaien. In de ochtend van 30 januari meldden de beheerders dat er problemen waren met de zogenaamde NGINX Ingress Controllers. Deze controllers zorgen voor de verdeling van het verkeer naar de verschillende pods van het containerplatform. Doordat deze controllers niet goed functioneerden werden de DRP-applicaties instabiel. Dit zorgde voor verschillende foutmeldingen bij het werken in de applicaties en bij het aanleveren via het 3PAS-koppelvlak. De applicatie is wel online gebleven en gebruikers konden doorwerken, maar moesten bij een foutmelding de actie steeds opnieuw proberen.
Vrijdagmiddag leek het probleem voor even opgelost, maar maandag waren de problemen direct weer terug. De oorzaak bleek te zijn dat het Standaard Platform werd overvraagd door Chinese webcrawlers. De beheerder van het Standaard Platform heeft hiervoor een werkbare oplossing gevonden, waarna het probleem maandag aan het einde van de middag was opgelost. Het incident blijft nog in behandeling voor een structurele fix.
Niet mogelijk om vrijgegeven dossiers te verwerken en voorbeelden te maken
Na het vrijgeven ter publicatie worden voor ieder dossier verschijningsvormen aangemaakt. Dit zijn de bestanden die getoond worden op Officielebekendmakingen.nl (PDF, HTML, ODT, etc). Door een storing op het hostingplatform van de diensten van KOOP, konden deze niet gemaakt worden. We hebben ervoor gekozen om de backendverwerking stil te zetten. Het effect hiervan was dat gebruikers wel in de applicatie konden werken. Vrijgegeven dossiers werden echter niet opgepakt. Tevens was het niet mogelijk om een voorbeeld van het dossier te bekijken. Nadat de platformverstoring was verholpen is de backendverwerking weer aangezet, rond 20:45 uur waren alle dossiers volledig verwerkt.
Niet mogelijk om vrijgegeven dossiers te verwerken en tijdelijke onbeschikbaarheid van de applicatie
Onderhanden werk van DRP wordt opgeslagen in een werkrepository. Deze werkrepository bleek niet beschikbaar vanuit de backend. Hierdoor konden publicatieopdrachten niet verwerk worden. Dossiers konden wel in de frontend van de applicatie worden aangemaakt. Het probleem is maandagochtend opgelost door de DRP-software opnieuw te installeren. Tijdens het installeren was de volledige applicatie niet beschikbaar.
Niet mogelijk om dossiers aan te maken
Op 23 oktober hebben we een storing gehad waardoor er geen nieuwe dossiers aangemaakt konden worden en bestaande dossiers maar beperkt bewerkt konden worden. De oorzaak was dat er geen nieuwe mappen aangemaakt konden worden in de Werk Repository. Dit is een Windows netwerk-share die gebruikt wordt om het onderhanden werk van de gebruikers op te slaan. Voor ieder dossier wordt een map aangemaakt waar vervolgens aangemaakte voorbeelden en geüploade afbeeldingen worden opgeslagen. Doordat er praktisch niet te werken viel in de applicatie, hebben we besloten om deze rond 13:30 in onderhoudsmodus te plaatsen.
Rond 15:00 is het probleem opgelost. De software die ten grondslag ligt aan de werkrepository kent een limiet van het aantal mappen die opgeslagen mag worden. Deze limiet is verhoogd waardoor de situatie is hersteld. We hebben vervolgens eerst de vastgelopen dossiers hersteld en daarna DRP weer uit de onderhoudsmodus gehaald. Het ophogen van de limiet is een tijdelijk oplossing, we gaan ons beraden op een structurele fix zodat dit in de toekomst niet nog een keer kan gebeuren.
Storing in statusverwerking (prio 2)
Documenten die in DRP ter publicatie worden vrijgegeven, worden aangeboden aan een centraal publicatieplatform. Het publicatieplatform zorgt vervolgens voor de afhandeling van de publicatieopdracht op de gewenste datum. Bij het ontvangen en verwerken van publicatieopdrachten geeft het publicatieplatform de status van elke opdracht terug in DRP, zodat gebruikers kunnen zien in welk stadium van het proces de opdracht zich bevindt. Op 1 oktober was een storing bij het terugkoppelen van statussen. De publicatieopdrachten werden zelf wel correct verwerkt, maar in DRP leek het alsof alle opdrachten in dezelfde status bleven hangen. Dit had daarnaast het effect dat gebruikers opdrachten die nog in behandeling waren niet konden afbreken. Dit komt doordat de opdracht pas kan worden afgebroken wanneer deze de status 'Afwachten publicatie' heeft bereikt. Het probleem is om 14:20 verholpen, waarna de statussen van alle opdrachten weer werden bijgewerkt. Publicatieopdrachten konden vanaf dat moment ook weer worden afgebroken.
Niet mogelijk om in te loggen in DRP applicaties
Bij het inloggen in de DRP applicaties wordt er altijd doorverwezen naar CAM, dit is het centrale authenticatie mechanisme van KOOP. Op 17 september werd er in plaats van naar Active Directory (KOOP account) verwezen naar de DigidBridge. De DigidBridge werd vroeger gebruikt om te kunnen inloggen met een DigiD-OP. Dit mechanisme bestaat echter al jaren niet meer. Dit probleem is plotseling opgetreden. Uiteindelijk is het snel verholpen door de DigidBridge claimsprovider uit te schakelen en Active Directory weer standaard te maken.
Redactioneel bijwerken opdrachten worden niet verwerkt
Op 8 juli hebben we DRP 9.18 live gezet. Een van de aanpassingen is dat regelingen voor lokaleregelgeving.overheid.nl alleen nog in xml-formaat worden aangemaakt en niet meer in xhtml-formaat. De volgende dag zagen we dat opdrachten om regelingen redactioneel bij te werken niet werden verwerkt. Een gebruiker kon wel een redactionele wijziging starten en afronden, maar de aanpassing werd niet zichtbaar op lokaleregelgeving.overheid.nl. De oorzaak hiervan was dat ergens in het publicatieproces toch nog een xhtml-verschijningsvorm werd verwacht, waardoor het proces niet kon worden afgerond. Dit is op 10 juli opgelost door dit mechanisme aan te passen. De achterstallige opdrachten zijn vervolgens alsnog goed verwerkt.
3PAS aanleveringen niet mogelijk met verlopen certificaten
In de avond van 18 juni is het autorisatiemechanisme (CAM) van DRP gemigreerd naar een nieuwe hostingaanbieder (ODC-Noord). De migratie was succesvol. De volgende dag bleek echter dat een beperkt aantal organisaties niet langer kon aanleveren op het 3PAS-koppelvlak. Dit bleek veroorzaakt te worden doordat deze organisaties gebruikmaken van certificaten die zijn verlopen. Op de vorige hostinglocatie was een instelling actief die ervoor zorgde dat het was toegestaan om een verlopen certificaat te gebruiken. Dit is een onveilige en onwenselijke situatie. Om het probleem voor de betreffende organisaties snel op te lossen is ervoor gekozen om deze instelling ook op de nieuwe locatie actief te maken. Dit zal echter een tijdelijke situatie zijn. Met de verschillende leveranciers zijn afspraken gemaakt dat de instelling per 1 augustus 2025 weer wordt uitgezet. Dit betekent dat deze organisaties ongeveer één maand de tijd hebben om hun certificaten te vernieuwen. De leveranciers ondersteunen de organisaties hierbij.
Het is niet mogelijk om een 3PAS-aanlevering te doen met een recent DigiCert QuoVadis certificaat (prio 2)
Om vanuit een zaaksysteem of VTH-pakket aan te kunnen leveren op het 3PAS-koppelvlak wordt de verzendende partij geïdentificeerd aan de hand van een PKIoverheid certificaat. DigiCert QuoVadis is één van de Trusted Service Providers (TSP) die dergelijke certificaten mag uitgeven. DigiCert QuoVadis heeft de opbouw van recent uitgegeven certificaten veranderd waardoor deze nu niet werken in combinatie met 3PAS. Een beperkt aantal organisaties heeft last van dit probleem, maar dit aantal zal groeien wanneer er niet snel een oplossing gevonden wordt. Het gaat om organisaties die vanaf juni 2025 een DigiCert QuoVadis PKIoverheid certificaat hebben vernieuwd.
Er zijn bruikbare workarounds beschikbaar.
Onbeschikbaarheid van IdentifierService
Op 10 juni was er een update gepland van de IdentifierService. De IdentifierService wordt door DRP gebruikt om nadat een dossier ter publicatie is vrijgegeven een uniek publicatienummer te genereren (bijv. gmb-2025-1234). De update zou tijdens kantooruren doorgevoerd worden. Dit is technisch mogelijk omdat het vrijgeven tijdelijk gepauzeerd kan worden, zonder dat gebruikers daar last van hebben. In de praktijk bleek echter dat aanleveringen via 3PAS niet goed verwerkt konden worden. Uiteindelijk heeft dit probleem ongeveer 30 minuten geduurd waarna de IdentifierService weer operationeel was. Dergelijk onderhoud zal in de toekomst buiten kantooruren worden doorgevoerd in combinatie met een onderhoudsbericht.
Uitval storage platform
Vanaf 16:00 zagen we dat nieuwe documenten niet verwerkt werden. De oorzaak bleek te liggen in de backend van de file storage waar publicaties worden opgeslagen om te ontsluiten via het Internet. Na een herstart van het file storage platform is de storing verholpen. Om te voorkomen dat het aantal fouten zou oplopen is DRP tussen 17:00 en 17:30 in onderhoud geweest, waardoor geen nieuwe publicaties konden worden aangemaakt.
Overbelasting VPN tunnel
KOOP is bezig met een hostingmigratie van haar diensten en infrastructuur naar een nieuwe aanbieder. Inmiddels is vrijwel alle software overgezet naar de nieuwe locatie, echter de data nog niet. Om ervoor te zorgen dat de applicaties nog steeds data kunnen ophalen en wijzigen zijn VPN tunnels ingericht waar het dataverkeer doorheen kan lopen. Op 26 februari vielen er in DRP meerdere documenten uit bij het transformeren naar de verschijningsvormen zoals ze op Officielebekendmakingen.nl gepubliceerd worden, doordat data niet snel genoeg door de VPN tunnel ging. Omdat alle producten van KOOP gebruik maken van deze tunnel, was het niet direct duidelijk waardoor het probleem werd veroorzaakt. Uiteindelijk bleek dat Wetten.nl veel extra verkeer genereerde; waarschijnlijk door bots van Google en andere zoekmachines.
Omdat het werken in DRP niet goed mogelijk was, is DRP om 9:20 in onderhoudsmodus geplaatst. In de loop van de middag stabiliseerde de situatie waarnaar DRP vanaf 14:10 weer bruikbaar was. Bij Wetten.nl zijn maatregelen genomen om het verkeer binnen de perken te houden. KOOP gaat alle data in het tweede kwartaal van 2025 ook verhuizen naar het nieuwe platform. Hierna zijn de VPN tunnels niet meer nodig, en kan dit specifieke probleem niet meer voorkomen.
Storing Repository Webclient
DRP maakt gebruik van een webclient om bestanden te kunnen benaderen die zijn opgeslagen op de algemene publicatie repository van KOOP. Op de publicatie repository worden bijvoorbeeld alle publicaties die via DROP worden gemaakt geplaatst, zodat ze via internet opgevraagd kunnen worden. Op de publicatie repository staan echter ook bestanden die gebruikt worden in het creatieproces in DRP. Op 13 februari was de repositorry webclient plotseling niet bereikbaar, waardoor DRP ook deze bestanden niet meer kon ophalen. Als gevolg hiervan was het niet langer mogelijk om nieuwe documenten aan te maken. Een herstart van de repository webclient heeft het probleem vrij snel kunnen verhelpen.
Netwerkstoring
Op 3 februari hadden we last van een netwerkstoring waardoor systemen waarvan DRP afhankelijk is, af en aan niet benaderbaar waren. Als gevolg hiervan was het niet mogelijk om in de applicatie te kunnen werken of aan te leveren op het koppelvlak. De storing is uiteindelijk verholpen door onze hostingpartner Standaard Platform.
Oplostijden
In de Service Niveau Overeenkomst staat de norm beschreven dat per 12 maanden 90% van het aantal incidenten binnen de aangegeven oplostijd wordt opgelost. In onderstaande tabel staat hoeveel incidenten er in de afgelopen 12 maanden waren en hoeveel er daarvan opgelost zijn binnen de aangegeven oplostijd.
Oplostijden incidenten
Type incident
Oplostijd volgens SNO
Aantal in periode februari 2025 t/m januari 2026
Opgelost binnen aangegeven oplostijd in periode februari 2025 t/m januari 2026
Prio 1
4 uur (kantooruren)
10
80%*
Prio 2
8 uur (kantooruren)
18
28%*
Prio 3
40 uur (kantooruren)
36
61%*
*We gaan intern analyseren waarom het KOOP in de afgelopen 12 maanden niet is gelukt om, met name voor prio 2 incidenten, aan de norm te kunnen voldoen.
Wijzigingenbeheer
In de Service Niveau Overeenkomst staan doorlooptijden beschreven voor standaardwijzigingen. En staat de norm beschreven dat per maand 90% van het aantal standaardwijzigingen binnen de aangegeven doorlooptijd wordt afgehandeld. In onderstaande tabel staat hoeveel standaardwijzigingen er in de afgelopen maand waren en hoeveel er daarvan gehaald zijn binnen de aangegeven doorlooptijd.
*De data in deze tabel hebben een onnauwkeurigheid. Niet alle wijzigingen worden altijd op de juiste manier geregistreerd.
Onderhoud
Voor het doorvoeren van software-updates werkt KOOP in sprints van twee weken. In de nieuwsbrief leest u of de release van de nieuwe software doorgaat en wat de verbeteringen zijn. Tijdens de release staat de applicatie in onderhoud.
Portalen
Documenten die via DRP gepubliceerd worden, worden aan de buitenwereld ontsloten via de portalen Officielebekendmakingen.nl, Lokaleregelgeving.overheid.nl en Berichten over uw Buurt.
Het portaal Lokaleregelgeving.overheid.nl kent nog geen formele beschikbaarheidscriteria. Indien in de toekomst deze beschikbaarheidscriteria alsnog worden vastgesteld, zullen deze worden toegevoegd aan de Service Niveau Overeenkomst en zullen we hier rapporteren of deze gehaald zijn.
Berichten over uw Buurt rondom een zelfgekozen adres
