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.
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.
Vertraging bij de ValidatieService
Op 27 januari was het tijdelijk niet mogelijk om dossiers aan te maken in DRP. Dit is vergelijkbaar met het voortdurende probleem dat speelt sinds 14 januari, maar is niet helemaal hetzelfde. In dit geval bleek de ValidatieService die DRP gebruikt om dossiers goed te keuren langzaam. Het gevolg hiervan is dat dossiers op elkaar moesten wachten en tijdens het aanmaken al mislukten. De oorzaak bleek te liggen in een aantal pods van de ValidatieService, die op het Standaard Platform niet goed bereikbaar waren, waardoor de totale capaciteit van de ValidatieService beperkt was. Dit is opgelost door de ValidatieService als geheel te herstarten. DRP heeft hiervoor kortstondig (ongeveer 3 minuten) in onderhoud gestaan.
Niet mogelijk om grondslagen toe te voegen
Rond 12 uur bleek het niet meer mogelijk om grondslagen toe te voegen uit het Basis Wettenbestand. Deze regelingen worden geleverd vanuit LinkedData Overheid (LiDO). Het leek er even op dat de storing snel verholpen was, omdat LiDO weer beschikbaar was, echter werd bij een zoekvraag naar een regeling niet alle regelingonderdelen teruggegeven, waardoor het alsnog niet mogelijk was om de grondslag toe te voegen. Om 16:30 is het probleem volledig opgelost.
Netwerkstoring
Op 16 januari zagen we connectiviteitsproblemen met het Standaard Platform waarop een deel van de backend van DRP gehost wordt. De storing bleek onderdeel van een grotere netwerkstoring bij het Standaard Platform. Dit is uiteindelijk door de leverancier verholpen.
Onmogelijk om dossiers aan te maken
Op 15 januari was het tijdelijk niet mogelijk om dossiers aan te maken. Dit lijkt op het probleem dat als sinds 14 januari speelt, maar dit is niet precies hetzelfde. In dit geval liepen de responstijden van de repository webclient op. Deze wordt gebruikt om documenten te downloaden uit de KOOP-collecties. Dit is onder andere nodig voor het goedkeuren van dossiers in DRP. De oorzaak bleek te liggen in een kopieeractie die wordt uitgevoerd in het kader van een hostingmigratie. Als onderdeel hiervan moeten alle collecties van KOOP worden overgezet naar een andere locatie. Deze handelingen vormden een te grote belasting voor het systeem dat hierdoor erg traag werd. Als gevolg van deze storing is ervoor gekozen om de kopieeractie stop te zetten. Later is deze weer hervat, maar met een beperking op de maximaal te gebruiken bandbreedte.
Onmogelijk om dossiers aan te maken tijdens piekmomenten
Sinds 14 januari kampen gebruikers bijna dagelijks met het probleem dat het tijdelijk niet mogelijk is om dossiers aan te maken. Dit probleem doet zich zowel voor bij invoer in de website als via het 3PAS koppelvlak. Het speelt met name in de ochtend tussen 11:00 en 12:00 omdat er dan veel (geautomatiseerd) wordt aangeleverd. In de software kunnen aanleveringen niet goed parallel verwerkt worden. Hierdoor moeten dossiers wachten voordat het voorgaande dossier volledig is aangemaakt. Wanneer er te veel op hetzelfde moment wordt aangeleverd, vallen er dossiers uit nadat er enige tijd gewacht is. Er is geen duidelijk aanwezige reden waarom het probleem sinds dit moment speelt.
Sinds 6 februari is het probleem gedeeltelijk opgelost door verbeteringen in het goedkeuringsmechanisme. Hierdoor gaat het goedkeuren van documenten sneller waardoor aanleveringen minder lang op elkaar hoeven te wachten. Het probleem is volledig opgelost met versie 9.9 van DRP. Hierin zit een verbetering die ervoor zorgt dat 3PAS aanleveringen parallel verwerkt kunnen worden, waardoor ze helemaal niet meer hoeven te wachten. Dit heeft als extra voordeel dat ook gebruikers van de website sneller documenten kunnen aanmaken.
Geen verkeer over VPN tunnels
Monitoring gaf aan dat er geen verkeer mogelijk was over de VPN tunnels die DRP gebruikt voor de communicatie met achterliggende systemen. Het probleem is na 10 minuten vanzelf opgehouden. De applicatie is niet in onderhoud geweest.
Netwerkstoring
Rond 9.30 uur heeft KOOP een melding gekregen dat er bij de hostingpartner ODC Noord een storing was. Het effect van de storing was dat DRP niet meer bij zijn eigen database kon, waardoor werken in de applicatie onmogelijk was. Doordat het hele team op een planningsevenement was, duurde het even voordat de applicatie in onderhoudsmodus werd geplaatst. Dit is rond 11:15 alsnog gedaan. ODC Noord heeft de storing kunnen verhelpen en rond 13:00 is DRP uit onderhoud gehaald.
Ongeldige doorverwijzing
Sommige gebruikers werden bij het inloggen onterecht doorverwezen naar de DigiD inlog provider die al enkele jaren niet meer bestaat. Het is niet duidelijk waar dit door werd veroorzaakt, niet alle gebruikers hadden hier last van. De pagina verversen werkte bij de meeste gebruikers als workaround, zodat ze naar het reguliere KOOP inlogscherm werden verwezen. Het probleem is vanzelf opgehouden. Voor de zekerheid is de DigidBridge (verwijzer naar DigiD) helemaal uitgezet.
Storing mogelijk veroorzaakt door onderhoud bij hostingpartij
Deze storing was vergelijkbaar met de storing van 25 november. Ook op deze dag werd er onderhoud uitgevoerd aan het Standaard Platform waarop DRP gehost wordt. In theorie moet dit platform overdag aangepast kunnen worden, zonder dat de applicaties die daarop draaien er last van hebben. In de praktijk bleek dat DRP erg traag was, waardoor het aanmaken van nieuwe dossiers niet snel genoeg ging. Acties van gebruikers moesten vervolgens op elkaar wachten wat leidde tot foutmeldingen voor de gebruikers.
Storing mogelijk veroorzaakt door onderhoud bij hostingpartij
Op deze dag werd er onderhoud uitgevoerd aan het Standaard Platform waarop DRP gehost wordt. In theorie moet dit platform overdag aangepast kunnen worden, zonder dat de applicaties die daarop draaien er last van hebben. In de praktijk bleek dat DRP erg traag was, waardoor het aanmaken van nieuwe dossiers niet snel genoeg ging. Acties van gebruikers moesten vervolgens op elkaar wachten wat leidde tot foutmeldingen voor de gebruikers.
Storing bij netwerkprovider Odido
We kregen de melding dat de generieke ValidatieService van KOOP niet beschikbaar was. Deze ValidatieService wordt gebruikt bij het goedkeuren van documenten en bij de Word-import. Dit deel van de applicatie werkte dan ook niet. Omdat er nog wel ingelogd kon worden, is besloten om de applicatie niet in onderhoudsmodus te plaatsen. Gebruikers konden in principe doorwerken, maar werden wel vaak geconfronteerd met foutmeldingen.
De oorzaak leek achteraf te liggen bij een storing bij netwerkprovider Odido. Het is echter niet duidelijk waarom deze specifieke dienst van KOOP niet beschikbaar was, en andere diensten wel correct functioneerden.
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 oktober 2024 t/m september 2025
Opgelost binnen aangegeven oplostijd in periode oktober 2024 t/m september 2025
Prio 1
4 uur (kantooruren)
17
76%*
Prio 2
8 uur (kantooruren)
24
33%*
Prio 3
40 uur (kantooruren)
52
71%*
*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
Een overzicht van het aantal geabonneerde gebruikers per gemeente op de e-mailservice Berichten over uw Buurt rondom uw woonadres is nog niet beschikbaar. KOOP en Logius werken aan de realisatie van een platform dat voorziet in deze informatiebehoefte. Zodra er meer bekend is over de opleverdatum, communiceren we dit via de tweewekelijkse nieuwsbrief.
