Drift og forvaltning

Denne delen av rammeverket er ment både for planlegging før anskaffelse, der virksomheten kan definere krav til drift og sikkerhet, og for drift etter anskaffelse.

Du kan også velge å sette ut drift til en tredjepart, men du beholder ansvaret for compliance. En slik avtale må sikre at tredjepartsleverandøren leverer i tråd med regulatoriske krav.

Driftsmodeller for skytjenester

Tradisjonell IT-drift må transformeres for skyen. Du må finne riktig balanse mellom sentraliserte plattformtjenester og desentraliserte team som har ansvar for hele livsløpet til egne applikasjoner. Valget avhenger av størrelsen, modenheten og strukturen på virksomheten din.

Sentralisert modell

Denne modellen baserer seg på et sentralisert IT-driftsteam som har ansvar for all infrastruktur og applikasjoner. Utviklingsteamene har ansvar for å utvikle og levere kode, mens driftsteamet står for utrulling, drift og overvåking av applikasjonene. Fordelen med dette er at det byr på tydelig ansvar, konsistent tilnærming og enklere standardisering. Ulempen er at det blir en flaskehals, i tillegg til at det blir lengre responstid på forespørsler til driftsteamet. Utviklere får også mindre kjennskap til hvordan ting kjører i produksjon.

Sentralisert driftsmodell er anbefalt for mindre virksomheter (rundt tjue IT-ansatte), tradisjonelle organisasjoner som er i begynnelsen av skyreisen og svært regulerte miljøer.

Desentralisert modell

Her har produktteamet fullt ansvar for både utvikling og drift. Dette betyr at teamet ikke bare bygger applikasjonen eller tjenesten, men også håndterer utrulling, forespørsler, hendelser, og overvåkning i produksjon. Produktteamet består ofte av både utviklere og driftspesialister som jobber tett sammen. Fordelen med denne modellen er raskere respons på problemer, i tillegg til tettere forhold mellom utvikling og drift. Utfordringer med denne modellen er at det kan forekomme duplisert arbeid og varierende kvalitet. Det kan også være overveldende for små team.

Desentralisert modell er best egnet for store virksomheter som har DevOps-kultur og Cloud-native applikasjoner (optimalisert for sky).

Hybrid modell

En hybrid modell har både et sentralisert plattformteam og ett eller flere produktteam, med tydelig ansvarsdeling.

Plattformteam (sentralisert)	Produktteam (desentralisert)
Infrastruktur	Egne applikasjoner
Plattform for utrulling	Utrulling av egen kode for applikasjonen
Nettverk og tilkobling	Håndtering av hendelser og forespørsler for applikasjonen
IT-styring og compliance	Utvikling av funksjonalitet og tilleggstjenester
Overvåkning av infrastruktur	Overvåkning av applikasjon

Et scenario som forklarer denne ansvarsdelingen, er når applikasjonen krasjer. I et slikt tilfelle er det produktteamet som undersøker og fikser applikasjonsfeilen, og plattformteamet hjelper til hvis feilen er relatert til infrastruktur. Et annet scenario er når det oppstår en hendelse som er relatert til nettverk. Da er det plattformteamet som eier problemet og løser hendelsen, mens produktteamet rapporterer og venter.

Kostnadskonsekvenser

Valg av driftsmodell har kostnadskonsekvenser. En desentralisert modell med produktteam krever mer kompetanse per team, og kan føre til duplisering av ressurser, mens en sentralisert modell kan redusere bemanningskostnader, men skape flaskehalser og lengre responstid.

Kravene til overvåking, sikkerhetskopiering, gjenoppretting og endringshåndtering bør tilpasses basert på kritikalitet. For svært kritiske systemer bør kravene være strengere, det vil si hyppigere sikkerhetskopiering, kortere responstid, omfattende testing og høyere grad av overvåkning.

For mindre kritiske systemer kan kravene være mer fleksible, med lengre intervaller mellom sikkerhetskopier, enklere overvåkning og mindre omfattende endringsprosesser. Dette balanserer risiko mot kostnader og ressurser.

Overvåking og driftsinnsikt

Det er viktig å ha innsikt i hvordan systemer oppfører seg, slik at du kan oppdage og løse problemer før de påvirker brukere.

Overvåkning av infrastruktur

De grunnleggende elementene for infrastruktur er servere, lagring og nettverk. For å kunne overvåke ytelse og stabilitet for beregningsressurser, er det viktig å følge med på sentrale indikatorer. De sentrale indikatorene er prosessor (CPU), minne, lagring og nettverk.

• CPU: Hvor mye prosessorkraft brukes?
• Minne: Hvor mye minne brukes?
• Lagring: Hvor mange lese- og skriveoppgaver gjennomføres per sekund?
• Nettverk: Hvor mye inngående og utgående trafikk er det?

Beregningsressurser (Compute)

Utnyttelsen av CPU kan gi en indikasjon på om applikasjonen eller infrastrukturen er i ferd med å bli overbelastet. Minnebruk gir innsikt i hvor mye av tilgjengelig minne som blir brukt, ettersom høy bruk kan føre til redusert ytelse eller ustabilitet. Nettverkstrafikk er relevant for funksjonaliteten til applikasjoner og integrasjoner.

For å kunne reagere tidlig på avvik bør du definere terskler for varsling. Advarsler kan for eksempel være at bruken av CPU overstiger 75 prosent over en periode på ti minutter, mens kritiske varsler utløses når den overstiger 90 prosent i mer enn fem minutter. Du kan konfigurere tilsvarende varslinger for minnebruk. Slike terskler gjør det mulig å skille mellom midlertidige stigninger og reelle problemer for kapasitet.

Når et varsel utløses, er første steg å identifisere årsaken til økt ressursbruk, for eksempel ved å undersøke hvilken prosess eller tjeneste som bruker mest. Dersom belastningen skyldes mangel på kapasitet, kan det være nødvendig å skalere løsningen enten vertikalt eller horisontalt. Les mer om vertikal og horisontal skalering.

Lagring

Overvåking av handlinger knyttet til lagring kan avdekke flaskehalser. For at ytelsen skal være stabil og forutsigbar, er det viktig å overvåke sentrale målinger. Sentrale målinger for lagring er:

• Diskplassutnyttelse: andel av tilgjengelig diskplass som er i bruk
• ((IOPS+Input/Output per second – en måling for hvor mange lese- og skrivehandlinger et lagringssystem kan utføre per sekund. Det sier noe om hvor raskt lagringen kan behandle data, og hvor godt den tåler mange forespørsler samtidig.)): antall lese- og skrivehandlinger som utføres per sekund
• Gjennomstrømming: datamengde som kan leses eller skrives per sekund
• Latens: responstid for handlinger mot lagring

Du kan for eksempel konfigurere varsling for når bruken for lagringsløsningen overstiger 90 prosent, i tillegg til varsling for når nivåene til IOPS nærmer seg definerte grenser for lagringsløsningen. Hvis du opplever utfordringer med lagring, er det viktig å iverksette tiltak. Første steg kan være å rydde opp i gamle filer, logger eller midlertidige data som ikke lenger er nødvendige for drift. Dersom dette ikke er tilstrekkelig, kan det være aktuelt å øke størrelsen på lagringsløsningen for å sikre kapasiteten. For data som er sjeldent i bruk, bør det vurderes rimeligere lagringsløsninger for arkivering, slik at kostnader reduseres samtidig som den primære lagringen avlastes.

Nettverk

For å oppdage kapasitetsproblemer og feil tidlig må nettverket overvåkes kontinuerlig. Dette bidrar til stabil kommunikasjon mellom systemer, tjenester og brukere. Viktige målinger i forbindelse med dette er:

• Båndbredde: hvor står andel av tilgjengelig nettverkskapasitet som er i bruk
• Tap av pakker: indikasjon på hvor mange datapakker som går tapt under overføring
• Latenstid: måler forsinkelsen i kommunikasjonen
• Antall forbindelser: avdekker overbelastning, feil på konfigurasjon eller ustabile nettverkskomponenter

Tydelige terskler for varsling kan fange avvik før de påvirker tjenestene. Du kan for eksempel konfigurere varsling som utløser når båndbredden overstiger 75 prosent i en lengre periode. Et annet eksempel er varsling for tap av pakker eller at latenstiden er mer enn det som er normalt.

Verktøy for overvåkning av infrastruktur

Leverandørene fra rammeavtalen tilbyr verktøy som kan tas i bruk for overvåkning.

Leverandør	Verktøy	Beskrivelse
AWS	CloudWatch	Samler målinger for CPU, minne, lagring og nettverk
	CloudWatch Logs	Innsamling av logger for systemer og drift
Google Cloud	Cloud Monitoring	Overvåking av infrastruktur
	Cloud Logging	Innsamling og analyse av logger knyttet til infrastruktur
Oracle Cloud	OCI Monitoring Service	Samler målinger for CPU, minne, lagring og nettverk
	OCI Logging Analytics	Innsamling og analyse av logger knyttet til infrastruktur
IBM Cloud	Monitoring with Sysdig	Samler målinger og varslinger for infrastruktur
	IBM Log Analysis	Analyse av logger knyttet til infrastruktur

Overvåkning av applikasjoner

Selv om infrastrukturen fungerer som forventet, kan applikasjonen fortsatt oppleves som treg. Overvåkning av applikasjoner innebærer å se på applikasjonens ytelse, spore transaksjoner og identifisere flaskehalser. Det gir også innsikt i hvordan applikasjonen oppleves i produksjonsmiljø.

Målinger

Følgende målinger kan brukes for applikasjoner:

• Responstid
• Gjennomstrømming
• Feilrate
• ((Apdex+Application Performance Index – måling av hvor fornøyde brukere er med ytelsen til en applikasjon. Den gir en poengsum basert på hvor raskt applikasjonen svarer på forespørsler.))

Responstid måler hvor lang tid en forespørsel tar fra start til slutt. Gjennomstrømming måles i antall forespørsler per sekund eller transaksjoner per minutt, og viser hvor mye belastning applikasjonen håndterer. Feilrate angir en prosentandel for forespørsler som feiler, og Apdex måler brukertilfredshet.

Distribuert sporing

Distribuert sporing følger en forespørsel gjennom flere tjenester i et system, for eksempel fra en applikasjon til database via tjenester mellom dem. Dette viser hvor tiden går, og hvor eventuelle flaskehalser oppstår. Hver forespørsel består av det som kalles "Trace", som representerer hele forespørselen, mens hvert segment av forespørselen kalles en "Span".

Et eksempel på en distribuert sporing kan være en forespørsel som tar totalt 950 millisekunder, hvor server for webtjeneste bruker 150 millisekunder, applikasjonsserver tar 300 millisekunder og databasen tar 500 millisekunder. Her identifiseres databasen som flaskehals, og tiltak kan rettes mot den.

Verktøy for overvåkning av applikasjoner

Leverandørene fra rammeavtalen tilbyr også verktøy for overvåkning av applikasjoner.

Leverandør	Verktøy	Beskrivelse
AWS	X-Ray	Distribuert sporing for feilsøking i applikasjoner
	CloudWatch ServiceLens/Application Signals	Gir innsikt i applikasjonene med målinger, sporing og logging
Google Cloud	Cloud Trace	Distribuert sporing av forespørsler
	Cloud Profiler	Profilering av applikasjonenes ytelse over tid
Oracle Cloud	Application Performance Monitoring	Overvåker applikasjonens ytelse
	OCI Service Connector Hub	Kobler logger og hendelsesdata mellom tjenester
IBM Cloud	IBM Cloud Observability	Gir innsikt i applikasjonene med målinger, sporing og logging

Sikkerhetskopiering og gjenoppretting

Sikkerhetskopiering og gjenoppretting sikrer kontinuitet og tilgjengelighet, spesielt for kritiske systemer og data. Det innebærer å planlegge for feil og uforutsette hendelser. Dette innebærer å ha automatiserte løsninger for sikkerhetskopiering, tydelige prioriteringer for hvilke systemer som må være operative først, og etablerte roller og ansvarsområder ved hendelser. Det er også viktig med regelmessig testing av gjenopprettingsprosedyrer for å sikre at planene fungerer i praksis, og at data kan gjenopprettes innenfor akseptabel tid.

Hvor ofte data skal sikkerhetskopieres og hvor lenge de skal oppbevares avhenger av kritikalitet, hyppighet på endringer og regulatoriske krav.

Datatype	Frekvens	Oppbevaring	Eksempel
Kritiske databaser	Kontinuerlig	30 dager	Kundedatabase
Viktige data	Daglig	30 dager	Forretningsdata
Standard data	Ukentlig	90 dager	Dokumenter
Arkiv	Månedlig	5 år	Compliance data

Typer innen sikkerhetskopiering

Det finnes flere typer sikkerhetskopiering som benyttes for å balansere tid for gjenoppretting, lagringsbehov og kompleksitet.

En full sikkerhetskopiering innebærer en komplett kopi av all data i systemet. Denne metoden gir den raskeste og enkleste gjenopprettingen siden all nødvendig data finnes i én enkel sikkerhetskopiering. Ulempen er at den krever mest lagringsplass og tar lengst tid å gjennomføre. Full sikkerhetskopiering kjøres derfor vanligvis med lavere frekvens, som for eksempel ukentlig.

Inkrementell sikkerhetskopiering tar kun med endringer som har skjedd siden forrige sikkerhetskopiering, enten den var full eller inkrementell. Dette er den mest effektive løsningen ettersom den har kort kjøretid, noe som gjør at den er godt egnet for daglig sikkerhetskopiering. Ved gjenoppretting må du ha med siste fulle sikkerhetskopiering og alle påfølgende inkrementelle sikkerhetskopieringer i riktig rekkefølge, noe som kan øke tiden det tar for gjenoppretting.

Differensiell sikkerhetskopiering lagrer alle endringer som har skjedd siden siste fulle sikkerhetskopiering. Denne løsningen er et kompromiss mellom full og inkrementell sikkerhetskopiering. Den krever mer lagringsplass enn inkrementell, men gir raskere gjenoppretting siden det kun er nødvendig å kombinere siste fulle sikkerhetskopiering og den siste som er differensiell. Differensiell sikkerhetskopiering kjøres ofte daglig for å oppnå en god balanse mellom lagring og tid for gjenoppretting.

Automatisering av sikkerhetskopiering

Sikkerhetskopiering bør du automatisere for å sikre forutsigbarhet, redusere menneskelige feil og sikre at sikkerhetskopiering faktisk blir gjennomført i henhold til din virksomhets definerte krav. Alle skyleverandørene i rammeavtalen tilbyr tjenester for sentralisert og automatisert sikkerhetskopiering, som gir god kontroll over gjennomføring, lagring og gjenoppretting.

Disse tjenestene støtter styring basert på retningslinjer, der regler for sikkerhetskopiering defineres én gang, og de blir da automatisk håndhevet på tvers av ressurser og miljøer. Dette inkluderer automatisk planlegging av sikkerhetskopiering slik at de tas til faste tider uten manuelt arbeid.

Tjenestene tilbyr også håndtering av oppbevaring, som sikrer at sikkerhetskopier lagres så lenge det er nødvendig i henhold til interne retningslinjer og regulatoriske krav, og slettes automatisk når de ikke lenger skal beholdes. Du kan også konfigurere regler for livssyklusen til sikkerhetskopiene. Dette betyr at eldre sikkerhetskopier kan flyttes til rimeligere lagringsløsninger eller løsninger for arkivering. Dette gir kostnadseffektiv lagring over tid, samtidig som krav til tilgjengelighet og gjenoppretting ivaretas.

Gjenoppretting – RTO og RPO

((RTO+ Står for Recovery Time Objective, som er målet for gjenopprettingstid. Tiden angir hvor lenge et system kan være nede etter en hendelse før det skaper uakseptable konsekvenser.)) og ((RPO+Står for Recovery Point Objective. Det er målet for gjenopprettingspunktet. Det definerer hvor mye data man kan akseptere å miste etter en hendelse, basert på siste gjenopprettingspunkt.)) er grunnleggende kriterier som definerer føringer for både sikkerhetskopiering og gjenoppretting. De brukes for å definere hvor mye nedetid og datatap din virksomhet kan akseptere ved en hendelse.

RTO angir hvor lang tid det kan ta før en tjeneste må være gjenopprettet og tilgjengelig igjen etter en hendelse. Dette inkluderer tiden fra feilen inntreffer til systemet er operativt, og dekker aktiviteter som feilhåndtering, gjenoppretting av data, oppstart av tjenester og verifisering av funksjonalitet.

RPO kan uttrykkes som et tidsintervall bakover fra tidspunktet for feilen, og angir hvor oppdatert den gjenopprettede dataen må være. Et RPO på for eksempel 15 minutter betyr at virksomheten aksepterer tap av inntil 15 minutter med data.

Eksempel på dette kan være at en database går ned klokken 14. Sikkerhetskopien består av en full kopi som tas daglig klokken 02, kombinert med logger for transaksjoner som tas hvert kvarter. I dette tilfellet vil RPO være femten minutter, siden maksimalt datatap begrenses til perioden siden siste logg. Dersom systemet kan gjenopprettes og settes i drift igjen innen klokken 16, vil RTO være to timer.

Det er viktig å poengtere at RTO og RPO har direkte sammenheng med kostnad. Et lavt RPO krever hyppigere sikkerhetskopiering, kontinuerlig replikering og gjenoppretting basert på logger, noe som øker både lagrings- og driftskostnader. Tilsvarende vil et lavt RTO ofte kreve høy tilgjengelighet og redundans, som også medfører økte kostnader og kompleksitet.

Testing av gjenoppretting

Selv om sikkerhetskopier tas som planlagt, gir de ingen reell verdi dersom gjenoppretting ikke fungerer når det faktisk gjelder. Det bør derfor testes regelmessig.

Formålet med testing er å avdekke svakheter før en alvorlig hendelse oppstår. Vanlige problemer som ofte oppdages først under testing, er korrupte sikkerhetskopier, mangelfull dokumentasjon og utdaterte prosedyrer, som ofte kan skyldes endringer i arkitektur. I tillegg avdekkes det ofte glemte avhengigheter mellom systemer, integrasjoner eller eksterne tjenester som er kritiske for å få en løsning fullt operativ. Mange blir også overrasket av at gjenoppretting tar lengre tid enn forutsatt.

Det finnes ulike typer tester som bør inngå i en helhetlig strategi. En gjenopprettingstest innebærer at data gjenopprettes til et test- eller verifiseringsmiljø, og at integritet og funksjonalitet på applikasjonen kontrolleres. Slike tester gir høy verdi med relativt lav risiko.

En katastrofegjenopprettingsøvelse er mer omfattende og innebærer å simulere en større hendelse, der hele gjenopprettingsprosedyren gjennomføres som om en katastrofe har inntruffet. Dette inkluderer koordinering mellom tekniske team, beslutningstakere og eventuelle eksterne leverandører. Denne øvelsen gir verdifull innsikt i både tekniske og organisatoriske utfordringer.

En god testprosess begynner med grundig planlegging. Det må være tydelig definert hva som skal testes, hvilke systemer og scenarier som inngår, hvem som deltar, og hvilke kriterier som må være oppfylt for at testen kan anses som vellykket.

Etter testen må resultatene verifiseres. Det innebærer å kontrollere at data er komplette, applikasjoner fungerer som forventet, og integrasjoner mot andre systemer er operative. Deretter evalueres testresultatet opp mot de definerte RTO- og RPO-kravene for å vurdere om målene ble nådd.

Til slutt må erfaringene brukes aktivt til forbedring. Prosedyrer og dokumentasjon bør oppdateres, identifiserte tekniske svakheter må utbedres, og teamet bør trenes basert på faktiske funn.

Endringshåndtering og utrulling

I skybaserte miljøer skjer endringer hyppig. Nye versjoner av applikasjoner, endringer i konfigurasjon og oppdateringer av infrastruktur kan gjennomføres flere ganger daglig. Tradisjonelle endringsprosesser med tunge godkjenningsløp er ofte ikke tilpasset for disse miljøene. Derfor er det viktig å etablere en moderne tilnærming til endringshåndtering som kombinerer automatisering, sporbarhet og kvalitetssikring med høy endringstakt. Målet er ha tryggere endringer der risiko håndteres gjennom standardiserte prosesser, testing og overvåking fremfor manuelle kontroller.

CI/CD for applikasjoner og infrastruktur

CI/CD står for "Continuous Integration and Continuous Deployment", med andre ord kontinuerlig integrasjon og utrulling. Det handler om å automatisere hele veien fra kodeendring til produksjonssetting, ved å la verktøy og prosesser håndtere bygging, testing og utrulling. Dette reduserer risikoen for menneskelig feil, samtidig som tempoet på utvikling og leveranser øker.

CI innebærer at kode integreres ofte. Det kan være ukentlig eller daglig. Hver endring verifiseres automatisk gjennom bygging og testing, slik at feil oppdages tidlig. CD betyr at applikasjonen til enhver tid er klar for produksjonsmiljø, men at selve utrullingen kan kreve en godkjenning. I CD skjer utrulling til produksjonsmiljø automatisk så lenge alle tester og kontroller er bestått.

En typisk CI/CD-prosess (også kjent som "Pipeline") begynner når en utvikler legger inn kode i versjonskontroll. Dette utløser en automatisert prosess der koden bygges, testes og kvalitetssikres. Deretter kan applikasjonen rulles ut til utviklings- og testmiljøer før den til slutt settes i produksjonsmiljø. I produksjonsfasen benyttes det ofte en gradvis utrulling for å redusere risiko for at det oppstår problemer på grunn av endringer.

Infrastruktur bør behandles på samme måte som applikasjonskode. Med infrastruktur som kode defineres servere, nettverk og andre komponenter for infrastruktur i kode. Denne koden versjoneres og utrulles via egne prosesser. Les mer om infrastruktur som kode.

Moderne utrullingsstrategier

Tradisjonelle utrullinger innebærer ofte at tjenesten stoppes mens ny versjon installeres. Skyplattformer tilbyr bedre alternativer som muliggjør utrulling uten nedetid og med lavere risiko.

Blå-grønn utrulling er en strategi som handler om å drifte to identiske miljøer parallelt. Den eksisterende løsningen kjører i ett miljø, mens ny versjon rulles ut og testes i det andre. Når den nye versjonen er verifisert, flyttes all trafikk over. Skulle det oppstå problemer, kan trafikken raskt flyttes tilbake. Denne metoden gir høy sikkerhet og rask tilbakeføring, men krever midlertidig dobbel infrastruktur og ekstra omtanke rundt ressurser.

Kanariutrulling er en annen strategi som innebærer at en ny versjon eksponeres for en liten andel av brukerne først. Ved å overvåke feil, ytelse og brukeropplevelse kan man avgjøre om utrullingen skal fortsette eller stoppes. Trafikken økes gradvis etter hvert som tilliten for den nye versjonen øker. Denne tilnærmingen begrenser konsekvensene av feil, men forutsetter god overvåking og mer avansert konfigurasjon.