...
Driften av FtB, som det refereres til her, gjelder både det ordinære produksjonsmiljø og test/integrasjonsmiljøet, som konsesjonshaverne utvikler sine sluttbrukerløsninger mot.
Innhold
| Innholdsfortegnelse |
|---|
Fellestjenester BYGG - enkel modell
...
Som en ser av modellen, er det fra sluttbrukerløsningene 2 innganger til FtB-universet:
Gjennom Altinn: Innsending av søknad, signeringsoppdrag, nabovarsel til distribusjon m.m. Grunnfunksjonaliteten er å distribuere det som sendes inn til rette mottakere, enten via Altinn til personer, privat eller i bedriftsrolle, eller gjennom KS FIKS (SvarInn/SvarUt) til kommuner og sektormyndigheter.
Gjennom FtB-API’ene: Validering, status (på innsending), nedlastning osv er det 2-veis utveksling av meldinger og data. Som del av kvalitetssikringen av det innsendte brukes eksterne tjenester til datavalidering.
Siden tjenestene og funksjonaliteten i FtB er dokumentert andre steder, blir det ikke dokumentert her. Denne siden fokuserer på drift og vakt, til orientering for konsesjonshavere.
...
Driftsoppsettet for FtB-universet er designet med utgangspunkt i at tjenesten har en stor samfunnsmessig nytte, stor verdi; at den kan være en viktig komponent i kommersielle aktørers tekniske løsninger og av stor verdi for mange ledd i konsesjonhavers verdikjede samt at den har en høy teknisk kompleksitet med mange eksterne kontaktpunkter, noe som gir en viss sårbarhet for forstyrrelser.
Ansvar
Fellestjenester Bygg, overordnet: Kari Befring Bjørnstad, Fagdirektør Stab, DiBK
Fellestjenester Bygg, drift og utvikling: Helga Jerven, Teknisk prosjektleder, DiBK
Kontaktkanaler
| Inkluder side | ||
|---|---|---|
|
Leveranse
Fellestjenester Bygg skal være i drift og overvåket i henhold til bruksavtale mellom DiBK og konsesjonshavere.
...
DiBK benytter følgende kategorier ved hendelseshåndtering:
Kategori | Beskrivelse | Tidsfrist for igangsetting av tiltak |
A – Kritisk | En hendelse skal prioriteres som kritisk dersom hele eller vesentlige deler av Fellestjenester BYGG er utilgjengelig, eller sikkerheten i løsningen er betydelig svekket. | Snarest, og senest innen 2 timer etter at DiBK er opplyst om hendelsen. |
B - Alvorlig | En hendelse skal prioriteres som alvorlig dersom hendelsen medfører redusert tilgjengelighet eller sikkerhet, og hendelsen gjør arbeidet vanskeligere for tjenesteleverandøren eller sluttbrukeren. | Innen 6 timer etter at DiBK er opplyst om hendelsen. |
C – Mindre alvorlig | En hendelse skal prioriteres som mindre alvorlig dersom hendelsen har liten betydning for sluttbrukeren, og partene kan akseptere hendelsen i en kortere periode. | Ved ledig kapasitet. |
Tabell 1: Prioritering av hendelser
...