Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
De eerste levering bouwt het vlootbeheer en beheercel 1 in AM4 op en levert daarop de eerste dienst; zie de reikwijdte van de eerste levering. Een ontwikkelteam van interne en externe medewerkers doet dat werk en draagt het resultaat over aan platformbeheer.
Dit onderwerp legt vast wie waarover beslist, welke werkafspraken voor iedere wijziging gelden, in welke omgevingen wordt gewerkt, hoe namen en versiebeheer zijn opgebouwd, hoe een nieuw team start en hoe een werkinstructie is opgebouwd.
Na de oplevering moet RWS het platform zelf kunnen beheren. Daarom bouwt het ontwikkelteam alles als code, via beoordeelde wijzigingen en in opslagplaatsen die aan platformbeheer worden overgedragen, en beslist RWS over ontwerp, risico en acceptatie. Het ontwikkelteam krijgt geen blijvende beheerrechten, zodat bouwen en beheren gescheiden blijven.
De rolverdeling en de plaats van het versiebeheer zijn vastgesteld. De werkafspraken, de omgevingen, de naamgeving, de indeling van de opslagplaatsen en de startvolgorde zijn een voorstel: zij volgen de principes voor gecontroleerde, reproduceerbare wijzigingen en houden het werk herhaalbaar en overdraagbaar, ook als het team wisselt.
Het ontwikkelteam bouwt en beproeft de eerste levering; RWS beslist over ontwerp, risico en acceptatie. Iedere rol heeft een benoemde persoon en een plaatsvervanger voordat de bouw begint.
Voor de vrijgave naar productie geldt de verdeling bij vrijgave en restrisico.
Bij de eerste levering is iedere rol verantwoordelijk voor een eigen deel van het werk en beslist zij over dat deel.
| Rol | Verantwoordelijk voor | Beslist over |
|---|---|---|
| Productverantwoordelijke platform (RWS) | Prioriteit en volgorde van het werk; acceptatie van opleveringen. | Wat af is en wat eerst komt; als diensteigenaar van het platform ook de vrijgave voor reguliere en bedrijfskritische productie. |
| Architect (RWS) | Samenhang met het doelbeeld; vastleggen van ontwerpbesluiten. | Afwijkingen van de standaard en van de gekozen productversies. |
| CISO-functie en beveiligingsadviseur (RWS) | Beveiligingskaders, vaststelling van de normen van de baseline, beoordeling van uitzonderingen en advies over restrisico’s. | Beveiligingsadvies bij de vrijgave voor productie; medeondertekening voor het restrisico. |
| SOC | Aansluiting van logbronnen, detectieregels en incidentafhandeling. | Welke signalen worden gevolgd en opgevolgd. |
| Netwerkbeheer (RWS) | Bouw en beheer van het nieuwe datacenternetwerk, de zones, het adresplan en de externe koppelingen. | Netwerkvarianten, zonecontrole en de routekaart van het netwerk. |
| Opslagbeheer (RWS) | Bouw en beheer van het opslagcluster per cel; uitgifte van koppelgegevens per cluster; capaciteitsbeheer en uitbreiding. | Foutdomeinen, opslaggebieden en uitbreiding van het opslagcluster. |
| Identiteitsbeheer (RWS) | Identiteitsbronnen, rollenmodel, herbeoordeling van rechten en de voeding van het identiteitsbeheer per cel vanuit de centrale RWS-bronnen. | Rollen en koppelingen met bestaande bronnen. |
| Ontwikkelteam | Bouwen als code, testen, documenteren en overdragen. | Technische uitwerking binnen de gegeven kaders. |
| Platformbeheer | Meelopen vanaf de start en overname van het beheer na acceptatie. | Of beheer de oplevering kan dragen. |
| Eerste applicatieteam | Testtoepassing en beoordeling van de bruikbaarheid. | Of de dienst het werk lichter maakt. |
Netwerkbeheer en opslagbeheer leveren het datacenternetwerk en het opslagcluster buiten de opdracht van het ontwikkelteam; loopt een van beide uit, dan schuift de eerste levering op. Zie de beheersing van de aandachtspunten.
Het ontwikkelteam krijgt geen blijvende beheerrechten op productie, alleen tijdelijke, taakgebonden rechten die het niet zelf toekent. Na de nazorgperiode die op de overdracht volgt, worden ook die ingetrokken.
Zo blijven bouwen en beheren ook tijdens de bouw gescheiden. Hoe lang de nazorg duurt en hoe de intrekking wordt gecontroleerd, staat bij nazorg en intrekking.
Clusters, instellingen, beleid, pijplijnen (geautomatiseerde reeksen bouw- en controlestappen) en draaiboeken staan als code in versiebeheer, en niemand past een omgeving met de hand aan, ook niet onder tijdsdruk. De enige uitzondering is de noodroute; een wijziging langs die route wordt binnen één werkdag alsnog in code vastgelegd.
De werkafspraken van het ontwikkelteam maken het werk herhaalbaar, controleerbaar en overdraagbaar. Zij werken het principe uit dat wijzigingen gecontroleerd en reproduceerbaar worden doorgevoerd. Dat de uitvoerende voorzieningen goedgekeurde versies zelf ophalen en afwijkingen melden, volgt uit GitOps.
Iedere wijziging van het ontwikkelteam loopt via een wijzigingsvoorstel dat twee beoordelaars naast de auteur beoordelen; een wijziging aan beveiliging, netwerk of identiteit beoordeelt ook de betrokken RWS-rol. De geautomatiseerde controles moeten slagen op precies die vastlegging voordat de wijziging wordt doorgevoerd, en alleen een standaardwijziging wordt daarna automatisch samengevoegd.
Dezelfde regels gelden voor het portaal, de API en direct gebruik van het versiebeheer; de takbeveiliging dwingt ze af. Zie ook geen herhaalde beoordeling.
Geheimen staan in het geheimenbeheer, nooit in code. De pijplijnen controleren op uitgelekte geheimen, en een gevonden geheim geldt als incident: het wordt ingetrokken en vervangen, het gebruik ervan wordt onderzocht en de gecompromitteerde waarde wordt nooit hersteld.
Het ontwikkelteam volgt de ondersteunde standaardconfiguratie van de leverancier. Afwijken mag alleen met een ontwerpbesluit van de architect; raakt de afwijking de beveiligingsbaseline, dan is zij ook een uitzondering op de baseline.
Zie uitzonderingen op de baseline en het principe werk onder architectuur.
Het ontwikkelteam gebruikt alleen de gekozen productversies, binnen hun ondersteuningstermijn. De leverancier bevestigt vóór de acceptatie van een opgeleverd onderdeel de ondersteuning van iedere combinatie van versies. Bijwerken hoort bij het lopende werk en verloopt per laag langs hetzelfde pad als een nieuwe versie.
Het ontwikkelteam levert op in iteraties van twee weken en toont werkende resultaten aan de productverantwoordelijke en aan platformbeheer.
Een opgeleverd onderdeel van de eerste levering is pas af als het aan de definitie van gereed voldoet.
| Criterium | Wanneer voldaan |
|---|---|
| Code | Alle inrichting staat in versiebeheer, is beoordeeld volgens de werkafspraken en wordt opgehaald door de uitvoerende voorziening. |
| Automatische controle | Tests, beleidstoetsing en de controle op geheimen slagen; de compliancescan toont geen open afwijking met hoog risico, tenzij die is vastgelegd als goedgekeurde uitzondering met einddatum. |
| Beveiliging | De toepasselijke maatregelen van de baseline werken en het bewijs is vastgelegd, of er is een goedgekeurde uitzondering met einddatum. |
| Bewaking en logging | Meldingen komen bij platformbeheer; audit- en beveiligingslogboeken komen bij het SOC, dat de ontvangst heeft bevestigd. |
| Herstel | De back-up is ingericht en het herstel van het opgeleverde onderdeel is ten minste één keer uitgevoerd, met vastgelegde hersteltijd. |
| Documentatie | De draaiboeken voor installatie, update, herstel en veelvoorkomende storingen en de ontwerpbesluiten zijn bijgewerkt. |
| Overdracht | De primaire en plaatsvervangende beheerders van platformbeheer hebben de belangrijkste handelingen en draaiboeken onder begeleiding zelf uitgevoerd. |
Herstelproeven voor de volledige dienst horen bij de acceptatieproeven.
Tijdens de eerste levering wordt in vier omgevingen gewerkt, elk met eigen regels. Zodra een omgeving RWS-gegevens verwerkt of met RWS-netwerken is verbonden, gelden de normale beheer- en beveiligingsregels.
| Omgeving | Doel en inhoud | Regels |
|---|---|---|
| Leeromgeving | Oefenen met de gekozen productversies, in een eigen rek van cel 1 met acht servers. Vlootbeheer, clusterbeheer en basisdienstencluster draaien er als compacte clusters op virtuele machines van de werkervirtualisatie van de leeromgeving. De leeromgeving bewijst werking en volgorde, geen prestaties. | Geen RWS-gegevens en geen RWS-koppelingen; mag worden gewist. |
| Beheercel 1 | Fundament, eerste dienst en acceptatie. | Volledige baseline; wijzigen alleen via wijzigingsvoorstellen. |
| Proefgroep binnen cel 1 | Een of meer applicatieclusters. | Als beheercel 1; de uitrol komt hier vóór de eerste uitrolgolf. |
| Herstelomgeving | Controleren en terugzetten van kopieën; voor een herstelproef of incident uit code opgebouwd en na vastlegging van het bewijs verwijderd. | Eigen aanmelding, geheimen en netwerk; capaciteit uit de reserve van de andere cel, in de eerste levering uit cel 1. |
De samenstelling van de leeromgeving, met drie opslagknooppunten, drie werkerknooppunten, één besturingsknooppunt en een koude reserveserver, staat in het domein Beheercellen & samenhang.
Namen volgen één vaste opbouw, zodat de automatisering, de bewaking en het SOC dezelfde objecten herkennen. Adresreeksen, domeinnamen en namen van apparatuur worden eerst vastgelegd in de datacenterregistratie.
| Object | Opbouw | Voorbeeld |
|---|---|---|
| Platformcluster | Cel, functie en volgnummer; voor het vlootbeheer alleen functie en volgnummer | c1-bd-01 (basisdiensten), c1-cb-01 (clusterbeheer), c1-vw-01 (werkervirtualisatie), vl-01 (vlootbeheer) |
| Opslagcluster | Cel, functie en volgnummer | c1-os-01 |
| Applicatiecluster | Team, omgeving, cel en volgnummer | onderhoud-ont-c1-01 |
| Gehost platformcluster | Functie, omgeving, cel en volgnummer | bouw-prd-c1-01 (bouwcluster voor de pijplijnen), portaal-prd-c1-01 (portaal), mesh-prd-c1-01 (besturing van het dienstennetwerk, doelsituatie) |
| Database | Toepassing, omgeving en volgnummer | planning-ont-01 |
| Server | Cel, rek, functie en volgnummer | c1-r04-os-03 |
| Domeinnaam | Functie onder het domein van het cluster | api.onderhoud-ont-c1-01.c1.dc3.internal |
| Dienstnaam van een bedrijfskritische dienst | Dienst onder het vlootdomein, zonder cel; de naam blijft gelijk bij overname door de andere cel, met een certificaat uit de tussen-CA ‘vloot’ | planning.dc3.internal |
Netwerkbeheer legt vóór de eerste uitrol de domeinen en de regels voor unieke namen vast; de voorbeelden gebruiken het private domein dc3.internal.
De opslagplaatsen van het platform staan in het eigen versiebeheer van het platform, Forgejo op het basisdienstencluster, zodat inrichting en herstel op eigen voorzieningen steunen. De broncode van toepassingen blijft in het RWS-brede versiebeheer van de applicatieteams, los van dat van het platform.
Het ontwikkelteam werkt met een beperkt aantal gescheiden opslagplaatsen, elk met een eigenaar en vaste beoordelaars. De hoofdtak van iedere opslagplaats is ook beschermd tegen de beheerders van het versiebeheer.
| Opslagplaats | Inhoud | Beoordeling door |
|---|---|---|
| Platform | Inrichting van het vlootbeheer, de cellen, het opslagcluster en de platformclusters. | Ontwikkelteam en platformbeheer |
| Beleid | Beveiligings- en compliancebeleid, toegestane varianten, de normen van de baseline en goedgekeurde uitzonderingen met eigenaar en einddatum. | Architect en beveiligingsadviseur |
| Catalogus | Dienstsjablonen, standaardinrichting, pijplijnsjabloon, register van toegelaten software van derden en documentatie voor afnemers, gepubliceerd als genummerde versies. | Productverantwoordelijke; voor het register van toegelaten software ook de beveiligingsadviseur |
| Afnemers | Dienstbeschrijvingen per team en per dienst. | Applicatieteam en platformbeheer |
| Draaiboeken | Beheer-, herstel- en incidentprocedures en ontwerpbesluiten. | Platformbeheer |
Dat de hoofdtak alleen beoordeelde en ondertekende wijzigingen aanneemt, volgt uit GitOps.
Tot het basisdienstencluster draait, staan de opslagplaatsen van het platform in een tijdelijk versiebeheer op de beheerwerkplek, met dezelfde beoordelingsregels en een kopie van de volledige geschiedenis buiten de werkplek. Daarna gaan zij met die geschiedenis over naar het versiebeheer van het platform.
Een applicatieteam verwijst vanuit zijn eigen opslagplaats naar een genummerde versie van het pijplijnsjabloon en de standaardinrichting in de opslagplaats Catalogus. De koppeling loopt in één richting: de bouwpijplijn van het team haalt sjabloon en broncode op; het platform heeft geen toegang tot de opslagplaatsen van teams en de pijplijn van een team heeft geen ondertekensleutel.
Hoe software van teams wordt gebouwd, ondertekend en toegelaten, staat in het domein Softwarelevering & toelating.
Een nieuw ontwikkelteam start in een vaste volgorde, zodat het zo snel mogelijk productief is. De startperiode is afgerond wanneer het team in de leeromgeving een cluster volledig vanuit code kan opbouwen, herstellen en afbreken.
| Stap | Wat het team doet |
|---|---|
| De kernbegrippen, de dienstverlening, de opbouw van het platform, het groeipad, de eerste levering, de werkinstructies, de beveiliging en de beproeving leren kennen, met de productversies, de technische invulling van de baseline en het ontwerp van opslag en netwerk; de ontwerpbesluiten bespreken met de architect. |
| Screening, persoonlijke accounts, meerfactoraanmelding en de beheerwerkplek regelen voordat iemand iets installeert. |
| Installatie, update, back-up en herstel oefenen tot die vanuit code herhaalbaar zijn. |
| De opslagplaatsen aanmaken, met een beschermde hoofdtak, vaste beoordelaars en de automatische controles: eerst in het tijdelijke versiebeheer, na de oplevering van het basisdienstencluster in het versiebeheer van het platform. Ook installatie en herstel van dat versiebeheer oefenen in de leeromgeving. |
| De nulmeting uitvoeren, samen met de productverantwoordelijke. |
| Beginnen met de registratie van apparatuur, netwerken en adressen, en de firmwarebasislijn vaststellen. |
De nulmeting legt vast hoe lang een vergelijkbare levering nu duurt; zie de opbrengst van de invoering. De firmwarebasislijn legt de firmwareversies en beveiligingsinstellingen van alle servers vast.
Iedere werkinstructie voor de bouw van het platform volgt dezelfde opbouw, zodat een nieuw teamlid snel ziet wat nodig is en wanneer iets af is.
| Onderdeel | Inhoud |
|---|---|
| Doel | Wat het onderdeel oplevert, waarom het op deze plaats in de volgorde staat en de bedoeling van de belangrijkste ontwerpkeuzes, elk met het afgevallen eenvoudiger alternatief. |
| Voorwaarden | Wat vooraf klaar moet zijn, zoals voorgaande onderdelen, adressen en toegang. |
| Stappen | De handelingen in volgorde, iedere stap met een vastgelegd resultaat in versiebeheer of in de registratie. |
| Parameters | De ontwerpwaarden die het team toepast. |
| Werkwijze | Een terugkerende of geautomatiseerde bewerking in tabelvorm; de werkwijze beschrijft de handelingen, en het team automatiseert haar zelf. |
| Controle en bewijs | Wat wordt gecontroleerd, hoe, en welk bewijs bij de oplevering hoort; ‘Gereed wanneer’ vat het resultaat samen. |
| Terugvaloptie | Hoe een mislukte stap veilig wordt teruggedraaid of hersteld. |
Een werkwijze beschrijft een terugkerende bewerking in een vaste indeling. Een naam tussen punthaken, zoals <cel>, staat voor een waarde uit de dienstbeschrijving of uit de datacenterregistratie.
| Onderdeel | Betekenis |
|---|---|
| Vooraf | De voorwaarden voor de eerste stap en waar zij zijn vastgelegd; is een voorwaarde niet vervuld, dan begint de werkwijze niet. |
| Stappen | De handelingen in volgorde; iedere stap noemt wie of wat haar uitvoert en levert een controleerbaar resultaat op. |
| Controle en vastlegging | Per stap waaraan het slagen te zien is en welk bewijs wordt vastgelegd in versiebeheer, de registratie, het logboek of het geheimenbeheer. |
| Afwijking | Bij een mislukte stap: terugdraaien of stoppen, wie een melding krijgt en waar de afwijking wordt bijgehouden. |