Version 1.4 december 2022
Følgende er de generelle NSP deploymentregler. Risikovurdering kan gøre, at der kan forekomme undtagelser.
Eksterne testmiljøer
Det eksterne testmiljø Test1 er det miljø, der først deployes på.
Det eksterne testmiljø Test2 deployes som udgangspunkt først, når NSP QA er gennemført og der er forventning om, at leverancen skal idriftsættes i produktion. Såfremt der kan gennemføres anvendertest, sker dette i Test2.
Det eksterne testmiljø Prodtest til cNSP deployes samtidig med produktion. dNSP miljøet for Prodtest deployes samtidig med, at den første region deployer til produktion.
Det eksterne testmiljø Uddannelse til cNSP deployes samtidig med produktion. dNSP deployes samtidig med, at den sidste region deployer til produktion. Dog kan der bestilles en anden kadence for udrulning af testdata. Se: Testdata.
Læs mere om NSP testmiljøer her: Introduktion til testmiljøer
Internt miljø
Det interne miljø Staging anvendes bl.a. til afvikling af performancetest eller anden intern test i særlige situationer. Staging miljøet deployes som oftest samtidig med deployment på Test1.
Produktionsmiljøer
Når NSP staging afsluttes med en status, hvor der kan deployes til produktion laves en deployment på alle cNSP´ens fire søjler og eventuelt på NSP setup´ets centrale services.
Ved afsluttet cNSP deployment deployes / tilbydes til deployment på de regionale dNSP´ere.
dNSP deployes automatisk ved mindre ændringer. Deployment sker trinvis for regionerne hvis ikke der er tale om en hasterettelse.
Ved ændringer der påvirker sikkerhedsservicen vil regionen altid blive varslet og spurgt om de ønsker et servicevindue; selv ved mindre ændringer. Dog kan en fejlsituation gøre at regionen informeres på bagkant. Ved større ændringer af en komponent eller af sikkerhedsservicen vil der fra NSP Operatør side altid kunne forlanges et servicevindue hos regionen.
Tidspunkter hvor der ikke idriftsættes nye services og komponenter
Der kan forekomme tidspunkter på året, hvor det vurderes for hensigtsmæssigt ikke at idriftsætte nye services og komponenter. Beslutningen om dette vil blive taget efter en samlet konkret risikoafvejning mellem at sikre størst mulig sikkerhed og robusthed for den kritiske infrastrukturdrift, opvejet mod de forretningsmæssige fordele der vil være ved at understøtte brugere/anvendere med den pågældende service.
I risikovurderingen vil behov og mulighed for at applikationssupport indgå, herunder specielt om der foreligger specifikke aftaler om døgn-, weekend- og helligdag support.
De tidspunkter der kan blive omfattet af ikke idriftsættelse er:
- dage der grænser op mod weekender
- dage der grænser op til helligdage, herunder jul & nytår
- dage der grænser op til hovedferier
For sikkerhedsmæssige opdateringer af infrastruktur, services og komponenter, gælder som hovedregel, at de har fortrin frem for opdateringer af services- og komponenter.
Information
Der udsendes ikke direkte information til den enkelte bruger af NSP´en eller de eksterne testmiljøer ved ændringer. Dog ville snitflade ændringer eller ophør af services altid meldes direkte med en længere varsling.
Information kan dog løbende hentes for den enkeltes platform via link: Inventory - Hosts. Support kan hjælpe hvis nødvendigt med at identificerer den "host" der er aktuel for den enkelte bruger.