På denne siden beskrives forhold og rutiner gjeldende for drift av Fellestjenester BYGG (FtB). Målgruppen er søknadsløsninger og eByggesaksløsninger med integrasjon mot FtB.

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.

Fellestjenester BYGG - enkel modell

Modellen viser i grove trekk hvordan Fellestjenester BYGG-universet er satt sammen teknisk og hvilke komponenter, hvilke tjenester, og tjenesteleverandører som inngår i universet. Siden tjenesten er under stadig utvikling, vil modellen og beskrivelsen endre seg over tid.

Som en ser av modellen, er det fra sluttbrukerløsningene 2 innganger til FtB-universet:

1. 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.

2. 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.

Driftsmiljøet - kort beskrivelse

Det tekniske driftsmiljøet er bygd opp slik at det gi en stabil, trygg og funksjonell plattform for kontinuerlig drift og utvikling av FtB.

I bunnen ligger MS Azure, der applikasjonene, som leverer de eksterne tjenestene, grensesnittene, som definerer tjenestene og transaksjonsdatabasen, som holder orden på dataflyten og dokumenterer prosessene løpende.

MS Azure-komponentene, serverne m.m., konfigureres og driftes av Iver AS. Det er satt opp kontinuerlig overvåking av belastning på RAM, prosessor- og databasekapasitet. Behov for justering av tilgjengelige tekniske ressurser og endringer i konfigurasjon gjøres av Iver AS i samråd med DiBK og Arkitektum AS.

Det rapporteres løpende til transaksjons-, bruks- og feillogger. Transaksjons- og bruksloggene gir grunnlag for forskjellige typer statistikk som dokumenterer bruken og nytteverdien av tjenesten. Loggene er tilgjengelige i tjenestens ElasticSearch-miljø. Feilloggene gir input til ElasticSearch Watcher og OpsGenie, som varsler applikasjonsvakten ut fra gitte kriterier som indikerer at tjenesten ikke fungerer som forventet.

I tillegg, fordi tjenesten har mange eksterne avhengigheter, er det laget en “helsesjekk”-funksjonalitet som sjekker intern funksjonalitet og kontakten til eksterne tjenester. “Helsesjekken” kjører på utsiden av FtB-universet.

Applikasjonsvakten driftes av Arkitektum AS, i et DevOps-opplegg. Vaktordningen er til enhver tid satt opp og bemannet etter kravene til oppetid og tilgjengelighet for FtB, som er avtalt mellom konsesjonshaver og DiBK i Bruksavtalen.

Driftsoppsett

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.

HEJ: Kanskje vi kan lenke hit og evt. utvide denne siden med rollene du beskriver under? Kontaktkanaler

Ansvar

Fellestjenester Bygg, overordnet: Kari Befring Bjørnstad, Fagdirektør Stab, DiBK

Fellestjenester Bygg, drift og utvikling: Helga Jerven, Teknisk prosjektleder, DiBK

Kontaktkanaler

Leveranse

Fellestjenester Bygg skal være i drift og overvåket i henhold til bruksavtale mellom DiBK og konsesjonshavere.

Innen for vakttiden, vil hendelser og henvendelser bli fulgt opp innen for en time etter varsling. Berørte parter i verdikjeden, som DiBK har et avtaleforhold til, vil bli informert som minimum gjennom FtB-bloggen. I tilfelle der vakten vurderer at hendelsen er kritisk for tjenesten eller for en eller flere konsesjonshavere, vil DiBK bli rådført og berørte konsesjonshavere kontaktet, via registrert kontaktpunkt, for orientering og rådføring.

Hendelser og henvendelser vil bli kategorisert etter hendelseshåndteringen beskrevet i bruksavtalen (utklipp):

DiBK benytter følgende kategorier ved hendelseshåndtering:

Tabell 1: Prioritering av hendelser

Vakt vil ta for seg henvendelser og hendelser i rekkefølge og søke å løse dem raskest mulig og innen for tidssfristen. Vaktens oppgave er å vurdere omfang og konsekvens; avbøtende eller korrigerende tiltak; løse opp i problemet så vidt mulig og rapportere hendelsen og løsning til servicedesken og til FtB-bloggen.

Det er viktig at DiBK har korrekte, oppdaterte kontaktpunkter hos konsesjonshavere for å kunne levere denne servicen. Kontaktpunktene registreres i Fellestjenester-forum.

Uten for vakttiden kan henvendelser rettes til FtB servicedesken som er betjent innen for daglig kontortid.

Daglig drift - vakt og overvåking

Teknisk miljø;

• MS Azure skyløsning: Iver AS. 24/7-driftsovervåking og -oppfølging med alarmering til vakt

• ElasticSearch: Arkitektum AS, standard vaktordning

Applikasjonsmiljø:

• FtB-universet: Arkitektum AS, standard vaktordning

• Eksterne avhengigheter: Arkitektum AS, standard vaktordning

• ElasticSearch/Kibana: Arkitektum AS, standard vaktordning

• OpsGenie og “Helsesjekken”: Arkitektum AS, standard vaktordning

Vakt vil forberede, utføre og kontrollere alle ordinære utrullinger (deployment) av endret funksjonalitet i FtB-universet. Ved hotfix-korreksjoner vil som oftest vakten være naturlig involvert eller minst orientert om hendelsen.