Når virksomheten din flytter til skyen, holder det ikke å videreføre tradisjonell IT-drift som den er. Du må ta et bevisst valg om hvordan ansvar for infrastruktur og applikasjoner skal fordeles – og det valget påvirker alt fra responstid og kvalitet til kostnader og fleksibilitet. Denne artikkelen gir deg oversikt over de tre vanligste driftsmodellene og hjelper deg å finne den som passer din virksomhet best.
God drift handler ikke bare om å holde systemer i gang, men om å levere pålitelige tjenester til brukere. 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 driftsspesialister 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.