1 open besluit1414 voorstellen

Onderwerp

Dienstbeschrijving en toetsing

De dienstbeschrijving is de enige invoer van een team. Een toetspijplijn in de opslagplaats Afnemers toetst ieder voorstel, langs iedere ingang, aan de geldende regels: rol, velden, capaciteit, zones en instemming.

Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas

Domein
Volgt uit
Functies
Producten
Verwant

Wat het is

De dienstbeschrijving legt vast wat een team afneemt: dienst en naam, eigenaar, kostenplaats, classificatie, profiel, capaciteit, versie, koppelingen, onderhoudsvenster en bewaartermijnen. Zij staat per team in de opslagplaats Afnemers. Iedere wijziging is een voorstel dat een toetspijplijn automatisch toetst aan de geldende regels, voordat een persoon of de samenvoegregel eraan te pas komt.

Waarom zo

Omdat portaal, API en rechtstreeks gebruik van versiebeheer alle drie een voorstel in dezelfde opslagplaats opleveren, is één toetsing genoeg voor iedere ingang. Formulier en toetsing delen hetzelfde schema, en de toetsing rekent met de som van alle beschrijvingen, zodat capaciteit en reserve niet ongemerkt worden overschreden. De instemming van een broneigenaar ligt vooraf vast, zodat een standaardlevering geen handmatige stap nodig heeft.

De velden, de grenzen en de indeling van de opslagplaats zijn een voorstel.

Uitspraken

1 vastgesteld15 voorstellen

Alle 15 voorstellen vaststellen

De dienstbeschrijving

VastgesteldRegel#

De dienstbeschrijving is de enige invoer van een team voor een levering, en iedere wijziging ervan wordt opnieuw getoetst. Waarden die het platform bepaalt, zoals de inhoud van de standaardinrichting, staan als gepubliceerde versie in de opslagplaats Catalogus; de dienstbeschrijving verwijst ernaar, zodat een team ze niet per ongeluk wijzigt.

VoorstelWaarde#

In de eerste levering heeft de dienstbeschrijving deze velden, elk met de controle die de toetsing uitvoert.

VeldInhoudControle bij toetsing
Dienst en naamApplicatiecluster of beheerde database binnen een applicatiecluster van het team; naam volgens de vaste naamgevingNaam uniek op het platform en volgens de vaste opbouw; dienst staat in de catalogus; een database noemt haar applicatiecluster
Eigenaar en vervangerTwee personen met een RWS-account en hun teamBeiden actief in het identiteitsbeheer; niet dezelfde persoon
KostenplaatsKostenplaats of project van het teamGeldig en gekoppeld aan de eigenaar
ClassificatieVertrouwelijkheid, integriteit en beschikbaarheid van de gegevens, volgens het classificatieschema van RWSBepaalt de toegestane netwerkzones en maatregelen; het profiel is een continuïteitskeuze en verlaagt die eisen niet, ook niet in het ontwikkelprofiel
ProfielOntwikkelen en beproeven in de eerste levering; later ook reguliere productieProfiel voor deze dienst vrijgegeven
CapaciteitWerkermaat, minimum- en maximumaantal werkers; databasegrootteCapaciteit bij het maximumaantal werkers past binnen het teamquotum; het feitelijke verbruik wordt gemeten en gerapporteerd
VersieEen vrijgegeven versie of ‘standaard’Versie vrijgegeven en binnen de ondersteuningstermijn; ‘standaard’ wordt bij de toetsing vertaald naar die versie en zo in de gegenereerde clusterdefinitie vastgelegd
KoppelingenPer verbinding bron, doel, poort, richting en gebruiksdoel; bij een koppeling met een bestaand systeem ook de instemming van de eigenaar van de bronZonecontrole tegen de geldende versie van de zonematrix
OnderhoudsvensterEen van de vaste venstersHet venster bestaat en past bij het profiel
Bewaartermijn en einddatumBewaartermijn van gegevens en back-ups; einddatum voor tijdelijke omgevingenTermijn volgens de archiefregels; einddatum verplicht in ontwikkelen en beproeven, daarna beëindiging
VoorstelRegel#

Naast die velden legt de dienstbeschrijving de sjabloonversie vast, de gevraagde toestand (actief of beëindigen), bij een koppeling de verwijzing naar de instemming, en vanaf de vrijgave voor bedrijfskritische productie de keuze of de gegevens buiten eigen beheer mogen (FortKnox). Vaste waarden komen ongewijzigd uit de sjabloonversie.

De opslagplaats Afnemers

VoorstelOntwerpbesluit#

De opslagplaats Afnemers heeft per team een map teams/<team>/ met een teambestand (kostenplaatsen, quotum en de instemmingen van eigenaren van bronnen) en per dienst een map teams/<team>/<naam>/ met dienstbeschrijving en catalogusbestand. Het pad bepaalt het team. Het teambestand wijzigt alleen na beoordeling door platformbeheer, via het eigenaarsbestand.

Toelichting

Afnemers zijn gescheiden door de paden, de rolcontrole in de toetsing en het rolbeleid in het portaal. Dat aangesloten teams elkaars dienstbeschrijvingen kunnen lezen, is aanvaard: zij bevatten geen geheimen. Afgewezen: een opslagplaats per team, waarbij toetsing, beoordeling en uitvoering per opslagplaats worden herhaald; dat past alsnog bij een team met een eigen vertrouwensdomein.

VoorstelOntwerpbesluit#

Een koppeling met een bestaand systeem vraagt een geldige, vastgelegde instemming van de eigenaar van de bron. Die instemming staat vooraf in het teambestand, met identiteit, gegevens, doel en einddatum, zodat een levering zonder persoon in het pad kan verlopen; de eerste koppeling met een bron vraagt daarom vooraf een voorstel op het teambestand. De eigenaar van de bron beoordeelt haar jaarlijks opnieuw.

Toelichting

Het platform dwingt het leesrecht in de bron niet af; de instemming van de eigenaar is daarom een voorwaarde, ook als een verbinding buiten de toegestane stromen wordt goedgekeurd. Afgewezen: de instemming bij iedere levering beoordelen, wat een handmatige stap per levering oplevert; eenmalig per bron volstaat. De acceptatieproef Toegang en koppeling toont het aan.

VoorstelUitgangspunt#

Een team kan zelf aanvragen, wijzigen binnen quotum en varianten, verbindingen binnen de zonematrix declareren, de einddatum in ontwikkelen en beproeven verlengen, beëindigen en werkruimten gebruiken. Een team kan niet zelf vaste waarden, sjablonen of de standaardinrichting wijzigen, een voorstel buiten de varianten goedkeuren, zijn quotum ophogen, voor een ander team aanvragen of iets laten uitvoeren zonder samengevoegd voorstel.

Toelichting

Zie de ontwerpkeuze Zelfservice binnen vooraf afgesproken kaders.

De toetspijplijn

VoorstelOntwerpbesluit#

Beleidstoetsing, zonecontrole en geheimencontrole draaien als één toetspijplijn op ieder voorstel in Afnemers, dus voor iedere ingang: Forgejo Actions op de runner op het basisdienstencluster, met de werkstroomdefinitie van de hoofdtak. Zij controleert rol van de aanvrager, pad, schema, vaste waarden, velden, capaciteit, instemming en zones, en zet uitkomst en regelversie als statusvermelding bij het voorstel. Bij een afwijking gaat het voorstel met uitleg terug naar het team; een verbinding buiten de toegestane stromen gaat naar netwerkbeheer.

Toelichting

Een afgewezen aanvraag maakt geen onderdelen aan. De werking van de zonecontrole hoort bij het domein netwerk.

VoorstelRegel#

Ieder voorstel in Afnemers wordt getoetst aan de geldende regelversie, die met de vastlegging bij het voorstel wordt bewaard, en met de werkstroomdefinitie van de hoofdtak. Een voorstel dat buiten de eigen map van het team of aan die werkstroomdefinitie wijzigt, is geen standaardwijziging.

Toelichting

Een voorstel verandert zo zijn eigen toetsing niet. De toetsing toetst in één keer de baselinemaatregelen voor een dienstbeschrijving, zodat beveiligingseisen deel zijn van iedere levering. Aangetoond met een negatieve proef en het toetsverslag.

VoorstelOntwerpbesluit#

De toetsing leidt de rol van de aanvrager af uit de teams van het versiebeheer, die de groepen van teamleden en teameigenaren in de toegangsvoorziening volgen, en de zones uit de datacenterregistratie. De runner leest daarvoor de datacenterregistratie, alleen lezend.

VoorstelOntwerpbesluit#

De invoerregels staan als één schema per sjabloonversie in de opslagplaats Catalogus. Formulier en toetsing gebruiken hetzelfde schema, zodat een voorstel uit het formulier niet alsnog op de vorm wordt afgewezen.

VoorstelWaarde#

De toetsing geeft binnen 15 minuten een uitkomst: afwijzing, beoordeling of door naar uitvoering. Duurt zij langer, dan volgt een melding, en bij herhaling een extra runner.

Toelichting

De norm is gelijk aan de faalgrens bij het maken van een cluster.

Grenzen die de toetsing bewaakt

VoorstelOntwerpbesluit#

Een aanvraag past binnen het teamquotum en de vrije capaciteit van de cel, en reserve wordt niet uitgegeven. De toetsing rekent met de grenzen per cel in de opslagplaats Platform en met de som van alle dienstbeschrijvingen in Afnemers, zodat twee gelijktijdige aanvragen samen niet boven een grens uitkomen.

Toelichting

Zo blijft reserve voor uitval beschikbaar. De plaatsen op het clusterbeheer tellen mee zoals het clusterbeheer ze vastlegt; zie het domein clusterbeheer.

VoorstelWaarde#

De toetsing en platformbeheer bewaken deze capaciteitsgrenzen.

GrensMetingActie
Plaatsen op het clusterbeheerBezette, aangevraagde en gereserveerde plaatsen tegen de 10 van cel 1Bij 8 van 10 zet platformbeheer de uitbreiding in gang (zes werkerknooppunten voor 24 clusters); bij 10 van 10 weigert de toetsing een nieuw cluster met uitleg
Werkercapaciteit per profielSom van de maximumaantallen werkers per maat, met de verhouding van virtuele processoren per fysieke kernBoven de reserveerbare capaciteit van de werkervirtualisatie weigert de toetsing; de reserve van één werkerknooppunt blijft vrij
TeamquotumSom van de maxima van het team tegen het teambestandAfwijzing met uitleg; ophogen loopt via een wijzigingsvoorstel op het teambestand, beoordeeld door platformbeheer
OpslagquotaUitgegeven quota; feitelijk verbruik van het opslagclusterUitgegeven quota samen onder 75 procent van de bruikbare capaciteit; boven 65 procent feitelijk verbruik geen nieuwe of hogere quota
PortaalclusterProcessor of geheugen van een knooppunt boven 85 procent gedurende 15 minutenExtra werker tot het maximum van zes; daarboven een grotere maat via een wijzigingsvoorstel op de clusterdefinitie
Toelichting

De grenzen van opslag en clusterbeheer zelf horen bij de domeinen opslag en clusterbeheer.

VoorstelRegel#

De omgevingen voor ontwikkelen en beproeven en reguliere productie van een team staan in aparte clusters, en een database staat in een cluster van hetzelfde team en profiel. In ontwikkelen en beproeven is een einddatum verplicht; in bedrijfskritische productie is de keuze voor FortKnox verplicht.

Toelichting

Zo blijven ontwikkel-, test- en productieomgevingen gescheiden. De toetsing controleert het.

Verwijzen hiernaar

Onderwerpen 3