Skytilpasning – en veileder for reisen ut i skyen 


For mange universiteter og høgskoler er skytjenester attraktive alternativer til selv å drifte IT-systemer og -tjenester som anvendes i forskning, undervisning, administrasjon eller formidling. 

Denne veilederen er basert på beste praksis fra Amazon Web Services Cloud Adaption Framework (eksten lenke), og er skrevet høsten 2017 som del av samarbeidsprosjektet IT-lab mellom UiA (ekstern lenke)og UNINETTs UH-skyprogram. I prosjektet ble konsulenter fra NordCloud (ekstern lenke) engasjert for å veilede UiA gjennom en prosess tilsvarende den som er beskrevet i denne veilederen. 

I prosjektet blir UiA anbefalt å jobbe videre med å utarbeide en sourcingstrategi samt å etablere et kompetanseteam for sky for å sikre at organisasjonen holder fokus på oversikt, styring og kontroll på bruken av skytjenester, slik at det ikke går utover sikkerhet og kostnader. 

Veilederen er delt inn i fem faser. Disse fasene representere ulike stadiene UiA har gått gjennom i prosessen med å gå ut i skyen. 

  1. Idè handler om hva dere bør tenke på når dere skal etablere et prosjekt og hvilken kompetanse dere bør ha med i prosjektgruppen.  

  1. Oversikt handler om forventningsavklaring samt om å sette ord på hvorfor dere ønsker å flytte datarommet ut i skyen. Denne fasen bør være forankret i prosjektbegrunnelsen. 

  1. Formålet med analysen er å samle de erfaringene og den informasjonen prosjektgruppen behøver for å starte arbeidet med å gå ut i skyen.  

  1. I pilotfasen velger dere ut noen tjenster dere analyserer, og utreder for å finne ut hva som kreves for å flytte dem ut i skyen  

  1. Til slutt har kommer fasen for forvatning. For prosjektgruppen og IT-avdelingen er et av målene med denne fasen å lage en styringsmodell for skytjenester for hele institusjonen. 

Nasjonale føringer 

Utvikling av muliggjørende teknologier vil bidra til å nå målene om økt konkurransekraft, løse samfunnsutfordringer og å utvikle fagmiljøer av fremragende kvalitet, ifølge stortingsmelding 7, Langtidsplan for høyere utdanning (ekstern lenke) . Stortingsmelding 18, Konsentrasjon for kvalitet, Strukturmeldingen (ekstern lenke) slår fast at UH-sektoren bør ta i bruk skytjenester og -teknologi som en av flere muliggjørende teknologier (s. 67).  

Digitaliseringsrundskrivet (eksten lenke) anbefaler at offentlige virksomheter tar i bruk skytjenester og lager en sourcingstrategi. Nasjonal strategi for bruk av skytjenester skriver følgende: 

  • "Det offentlige har ei plikt til å drive mest mogleg kostnadseffektivt. Men dei har òg eit ansvar for å ta god vare på innbyggarane sine data og ta i vare innbyggarane sine interesser. Då er det viktig at dei, når dei skal velje IKT-løysingar, kan vurdere alle dei løysingane som er til- gjengelege – òg skytenester. Allmenne skytenester vil vere det rette for nokre verksemder, men ikkje for andre. Ofte kan den beste løysinga vere ein kombinasjon av fleire leveransemodellar."  

Kunnskapsdepartementets Digitaliseringsstrategi for universitets- og høyskolesektoren (ekstern lenke) omtaler ikke sky spesifikt, men den viser til, og bygger på alle de føringene og dokumentene det vises til som bakgrunn for strategien. 

  • "Kunnskapsdepartementets overordnede digitaliseringsstrategi bygger på et omfattende forslag til IKT-strategi, med delstrategier for utdanning, forskning, infrastruktur, informasjonssikkerhet, administrative funksjoner og organisering av IKT-forvaltningen, utarbeidet av en arbeidsgruppe nedsatt av departementet og bestående av representanter for UH-sektoren. Kunnskapsdepartementets digitaliseringsstrategi for UH-sektoren må også sees i sammenheng med krav, føringer og anbefalinger i en rekke ulike rapporter, meldinger, strategier, rundskriv og handlingsplaner."  

Cloudification 

Cloudification  - skytilpasning på norsk - er et begrep som stadig dukker opp som en samlebetegnelse for prosessen med å gå ut i skyen. Transformasjon er et annet begrep som ofte kommer sammen med cloudification. Transformation, eller transformasjon på norsk, handler om nødvendigheten av å endre tradisjonelle tankesett for å være i stand til å utnytte skykonseptet fullt ut. Kompetanseteam omtales også i sammenheng med cloudification, som et virkemiddel for å få til cloudification. 

At disse begrepene dukker opp er et tegn på de utfordringene som virksomheter står overfor mht. å ta i bruk skytjenester. De fleste kjenner til og forstår hva skytjenester er, men det er ikke nødvendigvis slik at de har riktig og nok kunnskap til å ta i bruk skytjenester på en måte som gir best effekt. Det er mange utfordringer knyttet til å ta i bruk skytjenester på en smart måte. Organisasjoner må forstå skykonseptet og være i stand til å ta det i bruk. Det krever annen type kompetanse enn den som brukes for å levere IT-tjenester basert på dagens leveransemodeller. 

Idè 

Arbeidet bør organiseres i et eget prosjekt for å sikre fokus og fremdrift. Dere bør sette ned en fast gruppe, bestående av ulike folk fra IT-avdelingen, det er imidlertid viktig at disse personene har god kjennskap til driften av tjenestene, samt kunnskap om hvordan de er satt sammen og brukes. Denne gruppen bør helst ha deltakere fra ledelsen, evt må arbeidet være godt forankret hos ledelsen. 

Det er viktig å ha med skykritikere i prosjektgruppa. De bidrar med sin kompetanse og har ofte andre innfallsvinkler og stiller spørsmål som de ivrige - pådriverne - ikke stiller. 

Størrelsen på gruppa avhenger av størrelse på organisasjonen, om hele tjenesteporteføljen skal flyttes eller kun én tjeneste. I store omfattende prosjekter bør sluttbrukere og kommunikasjonsavdelingen delta i prosjektet. 

Det kan være en fordel å hente inn en ekstern konsulent som kan hjelpe til med å drive frem prosessen, gjerne en som har kompetanse på skytjenester og erfaring med lignende prosjekter. 

Dere bør sette ned en fast prosjektgruppe, den bør bestå av ulike folk fra IT-avdelingen. Det er viktig at gruppen er satt sammen av folk med god kjennskap til driften av deres tjenester, samt kunnspak om hvordan de ulike tjenestene er satt sammen og brukes. Denne gruppen bør helst ha deltakere fra ledelsen, evt. må arbeidet være godt forankret hos ledelsen. 

Oversikt 

Det er mange gode grunner for å gå ut i skyen. Kanskje har dere en skystrategi som sier noe om hvorfor dere ønsker å ta i bruk skytjenester og –teknologi. Det er viktig at dere tenker gjennom og diskuterer de ulike grunnene til å flytte ut i skyen. Hva ønsker dere å oppnå? Hvilke gevinster forventer dere? 

Dette bør beskrives godt i et business case, prosjektbegrunnelse, som er godt forankret på ledernivå i organisasjonen. 

Eksempler på årsaker: 

  • Ønske om å fokusere mer på dialog og støtte til sluttbrukere heller enn på drift av servere. 

  • Lite og sårbart kompetansemiljø med avhengighet til enkeltpersoner og deres velvilje. 

  • Mangel på tid til å rekke over alle arbeidsoppgaver og krav fra sluttbrukere. 

  • Ønske om å ha en kontrollert tilnærming til bruken av skytjenester (som sluttbrukerne uansett tar i bruk). 

  • Ønske om å være fremtidsrettet og jobbe mer innovativt. 

  • Vi vet at skyen kommer og vi trenger riktig kompetanse til å håndtere det. Vi ønsker å tilpasse oss et fremtidig arbeidsmarked. 

  • Økonomiske grunner. 

Gevinster 

"Hvordan kan vi måle at skyen og skytjenester har gitt oss de forventede gevinster?" Lag en intern oversikt over hvilke parametere dere skal benytte for å måle at overgangen til skytjenester og –teknologi har gitt organisasjonen gevinster. 

Eksempler på måleparametere for gevinster kan være: 

  • Oppetid: Opplever sluttbrukerne deres at tjenestene som IT-avdelingen leverer har god tilgjengelighet? Har dere 24/7-vaktordning på de nødvendige tjenestene? 

  • Redusert risikoen knyttet til enkeltpersoner: Blir dere mer uavhengig av enkeltpersoner ved å flytte ting ut i skyen? Ved å flytte ting ut i skyen trenger man en annen type kompetanse og man trenger annen type feilrettingskompetanse. Man trenger de som kan ha oversiktsbildet og vite hvordan ting henger sammen. Det blir en annen type ansvarsfordeling. 

  • Hvor raskt kan dere levere hvor mye til sluttbrukere? En av de vanligste gevinstene ved å ta i bruk skytjenester at man kan levere mer til sluttbrukere, raskere. En professor ønsker sånn og sånn, man klarer å levere og man kan levere raskere. 

  • Recovery/second site – Medfører lagring i skyen en sikrere løsning ettersom de store skyleverandørene håndterer recovery og second site lagring? Vil dere redusere behovet for å ha egne "second site" datasenter? 

  • Kostnadsberegninger: Dersom dere allerede har et driftssenter som er i OK stand, dere har serverne, dere har kunnskapen - blir det noe særlig billigere å flytte ting ut i skyen?  

Analyse 

Undersøkelsesfasens formål er å innhente de erfaringene og den informasjonen prosjektgruppen behøver for å starte arbeidet med å gå ut i skyen. 

  

Erfaringer fra sektoren 

Før dere starter kan det være smart å innhente erfaringer fra andre i sektoren som har gjort lignende. Kontakt dem direkte eller via UNINETT. Slik kommer dere godt i gang, og kan unngå uønskede fallgruver. 

Oversikt over de tjenestene dere kjører selv 

For å finne ut om dere kan flytte noe ut i skyen, må dere først vite hva dere har. Det anbefales derfor at dere skaffer en fullstendig oversikt over tjenesteporteføljen som er aktuell å flytte ut i skyen og hvilke tjenester disse henger sammen med. Dette kan gjerne ses på som en «vareopptelling» for datarommet. 

For å gjøre denne øvelsen er det viktig at dere har god kjennskap til hvordan de ulike tjenestene brukes og henger sammen. Tenk gjennom hvem som bør delta i denne øvelsen. 

Å få oversikt over alle tjenester, og få kunnskap nok om hver av dem til å kunne kategorisere dem, kan være tidkrevende. Vi anbefaler at dere setter av et team som jobber konsentrert med dette i en periode. 

Kategoriser tjenestene 

Nå skal tjenestene kategoriseres i følgende fem grupper alt etter hvor klare de er til å flyttes ut i skyen: 

  • Ikke ennå  

  • «Lift & shift» 

  • Krever bearbeiding   

  • Klar for skyen  

  • SaaS-kandidat 

Kategori: Ikke ennå 

Tjenester kan havne i kategorien «ikke ennå» av ulike grunner, disse kan for eksempel være: 

  • lovmessige krav 

  • vanskelige lisensmodeller 

  • sterke knytninger til fysisk hardware/installasjon eller lokasjon 

  • avhengighet til eksterne systemer. 

Kategori: «Lift & shift» 

Tjenester kan havne i kategorien «Lift & shift» av ulike grunner, disse kan for eksempel være: 

  • Dette er for virtuelle maskiner som kan flyttes som de er i dag, og man bestemmer seg for å optimalisere for sky i etterkant. 

  • Fordelen med dette er at man kommer seg raskt ut i skyen med tjenesten, men tjenesten bør bearbeides i ettertid for å optimaliseres for sky. 

  • Anbefales som piloter for kompetanseheving innen skytjenester 

  • Krever bearbeiding: Dette er tjenester som kan flyttes, men de må bearbeides noe. For eksempel: 

  • De bruker en database-versjon som ikke er tilgjengelig i skyen, men kan oppgraderes eller endres til å bruke en versjon som er tilgjengelig. 

  • De bruker lokal fillagring. 

  • De har hardkodet konfigurasjon. 

Kategori: Krever bearbeiding 

Tjenester som krever bearbeiding før de kan flyttes i skyen plasseres i denne kategorien. Tjenestene kan flyttes, men de må bearbeides. For eksempel: 

  • De bruker en database-versjon som ikke er tilgjengelig i skyen, men kan oppgraderes eller endres til å bruke en versjon som er tilgjengelig. 

  • De bruker lokal fillagring. 

  • De har hardkodet konfigurasjon. 

Kategori: Klar for skyen 

Tjenester som er klar for skyen hører til her. Dette er tjenester som allerede er implementert på en slik måte at de enkelt kan ta i bruk skyteknologi. For eksempel: 

  • Tjenesten er implementert på en slik måte at flytting/oppbygging av tjenesten i skyen utføres automatisk ved bruk av «infrastructure as a code» & «configuration as a code». 

  • Tjenesten er implementert på en slik måte at den tar i bruk kontainer-teknologi og/eller sky-teknologi som for eksempel «database as a service», fremfor oppretting av VM’er for å kjøre tjenesten. 

  • Overvåkning er på plass. 

Kategori: SaaS-kandidat 

SaaS-kandidat: 

  • Vi kjenner til eller har hørt om SaaS-tjenester som kan erstatte tjenesten fullt og helt. Det ligger tjenester i skymeglerportalen som kan erstatte eksisterende tjeneste. 

Pilot 

Når dere har laget en oversikt, bør dere velge ut en til tre tjenester som dere analyserer skikkelig. Da bør dere også undesøke hvilke konsekvenser det medfører ved å flytte tjenestene ut i skyen. Tar dere tak i de tjenestene som fremstår som de tydeligeliste «skykandidatene» vil kanskje jobben bli litt enklere. Husk å se på hvilke konsekvenser flyttingen vil ha for mennesker, prosesser og kostnader. 

Det er viktig å kjøre en begrenset pilot på en til tre tjenester for å få en forståelse av de detaljene som er viktig å finne ut av når vi skal gå ut i skyen. Det kan være smart å velge piloter fra ulike kategorier: F.eks. en eller to fra kategorien «lift & shift»og ett par som er SaaS-kandidater eller klar for skyen. Dere bør vente med tjenestene som havner i kategoriene ikke ennåog krever bearbeiding til dere kjenner skyløsningene bedre. 

Målet med piloten er å starte kompetansehevingen innenfor skytjenester og finne ut hva dere trenger å lære mer om.  

Dette skal dere finne ut av i løpet av pilotperioden: 

  • Hvordan påvirker det organisasjonen vår? Hvem må informeres, hvem må kurses? 

  • Hvordan påvirker det driften vår? Hvilke prosesser og rutiner og roller trenger vi for å håndtere det? 

  • Kostnadsanalyse - hva vil det koste? Hva er kostnadsstrukturen - hva er det som genererer kostnadene? Hvordan kan vi kontrollere kostnadene? Hvem skal betale for tjenesten? 

For hver utvalgt pilottjeneste, gå gjennom følgende: 

  • Teknisk løsning  

  • Håndtering av nøkler / IAM  

  • Infra-as-code / deployment  

  • Monitorering / logging / rapportering 

  • Informasjon til sluttbrukere 

  • Kostnadsstruktur / kostnadshåndtering

  • Support

  • Helpdesk / backup  

  • Rollback / exit-strategi 

  • Prosjektplan / roadmap 

Teknisk løsning 

Spørsmålene dere må ha svar på i denne prosessen avhenger av hvilken tjeneste dere arbeider med. Lag derfor interne oversikter slik at alle i prosjektgruppa får innsyn i hvilke spørsmål som må besvares. 

Ved flytting til IaaS-tjeneste 

Er det en server som du skal flytte til en IaaS gjennom «lift & shift»  

  • Hvem skal ha tilgang? 

  • Hvor ligger brukerne? 

  • Hva slags operativsystyem er det? 

  • Hvilke imager kjører? 

  • Hvordan er imagene laget? 

  • Hvordan er den fysiske tilgangen til disse maskinene? 

  • Skal de kunne nås utenfra, eller kun fra det interne nettet? 

Ved flytting til SaaS-tjeneste 

Er det en SaaS-tjeneste må man rett og slett finne en eller flere aktuelle SaaS-kandidater for den tjenesten man ønsker å erstatte med en SaaS. Her er det andre typer spørsmål man må finne ut av, som for eksempel: 

  • Hvor mye fleksibilitet får vi i denne tjenesten? 

  • Er det tilstrekkelig i forhold til våre behov? 

  • Hva har vi behov for å skru på? 

  • Har andre vi kjenner brukt noe lignende? 

  • Har vi hørt om noe som egner seg? 

  • Finnes det noen i sektoren som har erfaringer? 

  • Ligger det informasjon i UHsky-tjenestekatalog (intern lenke), og kan vi finne aktuelle tjenester der? 

Håndtering av nøkler / IAM 

Ved flytting til IaaS-tjeneste 

  • Det er viktig å ikke ha hemmeligheter (passord/secrets) i kode eller i skript. Det finnes metoder/teknologi for å implementere kode som krever hemmeligheter uten å avsløre hemmeligheten i klartekst i koden (i koden referere til en «bank» som har hemmelighetene). Tenk gjennom: Hvordan håndterer dere dette i dag? Er det noe som må endres? 

  • Beste praksis er å opprette en eller flere management servere som en logger seg på for å nå VM’er eller annen teknologi som er deployet (kontainere, databaser osv). Dette for å ha best mulig kontroll på brukerpålogging og for å minimere antall VM’er som direkte er tilgjengelig fra internett (public IP). 
      

Ved flytting til SaaS-tjeneste 

Hvordan gjøres autentisering av brukere? Er det Feide-pålogging, eller kobles det direkte til AD?  

Utrulling / deployment 

Ved flytting til IaaS-tjeneste 

Kan etablering, installering og konfigurasjon automatiseres ved hjelp av script eller kode? 

Ved flytting til SaaS-tjeneste 

For SaaS-tjenester er ikke dette relevant. 

Monitorering / logging / rapportering 

Kartlegg hvilke behov er det for monitorering / logging / rapportering for denne tjenesten? 

Ved flytting til IaaS-tjeneste 

  • Skal lokale (on-premise) servere for monitorering/logging/rapportering benyttes? Sørg for at IaaS-tjenesten kan kommunisere med de lokale serverne. 

  • Skal servere for monitorering/logging/rapportering flyttes til en IaaS-tjeneste? Sørg for at eventuelle gjenværende lokale (on-premise) servere kan kommunisere med disse systemene. 

  • Alternativt kan man velge å ha dobbelt opp i en overgangsperiode før man får flyttet alle tjenester ut i skyen. 

  • Et annet, foretrukket alternativ er å finne SaaS-tjenester som leverer monitorering/logging/rapportering (Monitoring as a service / Logging as a service). 

Ved flytting til SaaS-tjeneste 

Undersøk hvilke muligheter som finnes for monitorering / logging / rapportering i tjenesten. Hvilke behov har dere? Hva er inkludert og hva koster ekstra? 

Informasjon til sluttbrukere 

Ved innføring av nye skytjenester er det en rekke momenter som må håndteres. Hvor, når og hvordan er de viktigste spørsmålene brukerne har knyttet til implementering av en ny tjeneste. Informasjonen bør tilpasses mottaker på overordnet nivå (studenter, akademisk og administrativt personale). 

En aktivitet dere kan gjøre, før dere begynner å tenke på hva dere skal si og hvordan dere skal si det er å lage et bilde av hvem dere skal snakke til. I markedsføringsfaget kalles dette å bygge en «personas». Personas er semi-fiktive personer basert på de brukerprofilene dere ønsker snakke med. Eksempeler på personas i utdanningssektoren kan være: «Student-Simen», «Faglærer-Frode» eller «Leder-Lise». 

Øvelsen med personas hjelper dere med å avdekke antall sluttbrukere, hvor godt dere kjenner dem og deres bruksmønster samtidig som den sier noe om hvilket informasjonsbehov de ulike brukerprofilene har. Videre kan øvelsen peke på hvilken kanal de ulike brukerprofilene benytter, som igjen sier noe om hvilken kanal som er best å benytte for informasjon om implementeringen.  

Ut ifra personas kan man stille ulike spørsmål for å gjøre kommunikasjonen til brukerne målrettet og godt tilpasset. Men en slik øvelse får man en peker på hva man bør ha et svar på før man informerer om ny tjeneste. Det er også viktig at kommunikasjonen sier det samme. Likt budskap, men i enkelte sammenhenger må det formuleres på ulike måter. 

For å gjøre kommunikasjonsarbeidet lettere er det lurt å notere de spørsmålene dere kommer over i en slik prosess, slik at listen kan brukes som en rettesnor i kommunikasjonsarbeidet. 

  • Hvilke brukere trenger å vite om denne endringen? 

  • Hva skjer? 

  • Hva må brukerne vite? 

  • Er det noe vi er lovpålagt å informere om? 

  • Kan vi flytte uten å informere sluttbrukeren? 

  • Når må brukeren informeres? 

  • Hvordan skal brukerne informeres? 

  • Møter 

  • Informasjonstavler 

  • Intranett 

  • Interne eller eksterne kampanjer   

  • Hva kommer sluttbrukerne til å lure på? 

  • Flytter dere mine data? 

  • Hva vil det koste meg? 

  • Oppstår det nye rutiner? 

  • Får vi opplæring? 

Kostnadshåndtering og -struktur 

Hvilket fakultet/avdeling skal ta kostnaden ved denne tjenesten? I første omgang - når sky er nytt for institusjonen - kan det være nyttig å synliggjøre kostnadene. Det kan bidra til å forberede resten av organisasjonen på en tid hvor kostnadene fordeles på ulike avdelinger eller faktultet, og ikke alt går gjennom IT-avdelingen. I neste omgang vil det være naturlig å fordele kostnadene mellom ulike avdelinger eller fakulteter. 

Ved flytting til IaaS-tjeneste 

  • Trenger maskinene å stå på hele tiden? Kan de slås av om natta/kvelden/helger? Man oppnår sjelden økonomiske besparelser på å flytte VM’er ut i skyen om man ikke jobber med å skalere antall maskiner etter behov. Å gjøre en vurdering på dette vil forberede dere på å i neste omgang automatisere oppstart og stopp av maskiner. 

  • Unngå overspesifikasjon! I skyen trenger du ikke å kjøpe større VM enn du trenger. 

  • Husk at dere kan merke de ulike VM'ene som spinnes opp i skyen med koststed - hvem skal betale for dem. Alle tjenester som kjøres opp i skyen bør knyttes til et bestemt kostnadssted på denne måten. Man kan vurdere å innføre automatisk sletting og shutdown av VM'er som ikke er merket med koststed. Vær OBS på at trafikkostnader ikke kan tagges og knyttes opp til et kostnadssted. 

Ved flytting til SaaS-tjeneste 

  • Hvilke faktorer er det som genererer kostnader i denne tjenesten? Antall brukere? Fast pris per måned, eller betaler vi kun når vi bruker tjenesten? 

  • Hvordan passer dette sammen med bruken vår av tjenesten? 

Backup 

Ved flytting til IaaS-tjeneste 

Ved bruk av IaaS har man mulighet til å ta snapshots av VM'ene jevnlig i løpet av dagen. Man må da spørre seg følgende: 

  • Holder det å ta snapshot én gang om dagen? (En snapshot er en klone av hele VM'en). 

  • Er det behov for automatisk kopiering til annen lokasjon? Det må i såfall settes opp spesifikt. 

  • Skal backup for en VM bestilles automatisk, eller skal man ha dialog med sluttbrukeren rundt dette? 

  • Har du backup av dataene plassert på annet datasenter eller lokalt? 

Ved flytting til SaaS-tjeneste 

De fleste SaaS-tjenester har innebygde løsninger for back-up, men ofte begrenset til et gitt antall dager og i stor grad basert på at brukerne selv foretar gjenoppretting. Har man behov for bistand gjøres dette etter «best effort»-prinsippet eller ved inngåelse av utvidede supportavtaler. Har man behov for lagring utover standard (som regel 90 til 120 dager), finnes det gode løsninger som lar deg ta back-up mot andre skytjenester eller ned til eget datasenter (hybrid). Dette er ytterligere beskrevet i veilederen for Backup og lagring

Support / helpdesk 

  • Hvor skal våre sluttbrukere henvende seg ved problemer? Vårt interne helpdesk-kontaktpunkt? 

  • Hvilken tilgang til SaaS-tjenestens support har vårt lokale supportapparat? 

  • Hva finnes av tilgjengelig selvhjelps-dokumentasjon? 

Rollback / exit-strategi 

For hver tjeneste bør dere tenke gjennom hva som er exit-strategi for tjenesten. 

  • For IaaS kan det f.eks. være å kopiere VM'ene tilbake til en lokal (on-premise) løsning. 

  • Hva er det for en SaaS-tjeneste? Dette bør dere tenke gjennom. 

Roadmap / veikart 

For hver tjeneste dere piloterer: lag en tidsplan, bestemt hva som skal gjøres og hvem som skal gjøre det. 

Ved flytting til IaaS-tjeneste 

  • Hvor lang tid vil dette ta? Er det første gang vi gjør det? Hvor lang tid setter vi av? 

  • Finnes nødvendig kompetanse? Det er viktig å beregne en periode hvor man faktisk blir "skitten på fingrene" og får prøvd seg, handson utprøving. Gjerne kombinert med kurs og målrettet opplæring. 

  • Design/arkitektur av løsningen. 

  • Hvem skal gjøre det? Navngitte personer. 

Ved flytting til SaaS-tjeneste 

  • Hvor lang tid vil det ta å komme i gang med SaaS-tjenesten? Når skal vi starte? 

  • Hvilke konsekvenser har dette? 

  • Hvem skal gjøre det (navngitt person)?  

Forvaltning 

Skytjenester er svært enkle å ta i bruk av sluttbrukerne eller institusjonens avdelinger, og krever ikke nødvendigvis involvering av IT-avdelingen. Skytjenester bør likevel tas i bruk på en styrt måte, for å beholde kontroll over kostnader, dataflyt, sikkerhet, integrasjoner, arkitektur og leverandører. I denne fasen er det viktig å få på plass en styringsmodell for skytjenestene. 

Styringsmodellen bør inneholde programgruppens tanker og meninger om 

  • IT-avdelingen som kompetansesenter 

  • Forslag til modell for skytjenester 

  • Organisering 

  • Rutiner styringsmodellen for skytjenester må ivareta  

IT-avdelingen som kompetansesenter 

Hvordan kan institusjonen legge til rette for at sluttbrukerne kan nyttiggjøre seg de økte mulighetene som ligger i skytjenester, og samtidig beholde kontrollen? Overgang til skytjenester er ikke alene et IT-prosjekt, men involverer hele organisasjonen. IT-avdelingen bør være en kompetanseenhet som fasiliterer overgang til skytjenester, og det bør oppleves som nyttig for organisasjonen å involvere IT-avdelingen i alle skyprosjekter. 

Ved å ha en god modell for styring av overgang til skytjenester kan man oppnå: 

  • Det totale tjenestetilbudet til institusjonen blir bedre 

  • Det totale IT-budsjettet brukes på en effektiv måte, unngå at hvert fakultet lager egen løsning og mindre duplisering av tjenester og/eller funksjoner 

  • Bedre beskyttelse av sensitiv og konfidensielle data 

  • Innsyn i og forutsigbarhet for beslutninger rundt skytjenester 

  • Mindre «skygge-IT» 

Forslag til modell for skytjenester 

En modell for styring av skytjenester består av: 

  • En styringsgruppe for sky/sourcing 

  • Et sky kompetanseteam 

  • Evt et utviklerteam dersom institusjonen har egenutvikling 

  • Rutiner for å ivareta: 

  1. Prosjektstyring når nye skytjenester innføres, hvilke krav stilles til skytjenester som innføres ved institusjonen. 

  1. Kostnadsstyring: Rapportering, fakturering, riktig plassering av kostnader 

  1. Support og opplæring 

  1. Sikkerhet og oppfylling av lovkrav 

  1. Sourcing (hvilke tjenester leveres sentralt fra IT-avdelingen, hvordan kobler vi til on-prem systemer) og oppfølging av leverandører 

  1. Hvordan jobber institusjonen med devops? 

Organisering 

Styringsgruppe for sky/sourcing 

AWS CAF anbefaler at man setter ned en styringsgruppe for sky. I samarbeidet med UiA diskuterte vi om denne gruppen bør være en styringsgruppe for sourcing – som ser på alle IT-leveranser, inkludert skyleveranser, interne leveranser og andre eksterne leveranser. Denne gruppen bør være bredere sammensatt enn kun fra IT-sida, her bør gjerne både brukere og ledere være representert. 

Gruppa er ansvarlig for: 

  • Budsjett og roadmap 

  • Kostnader og sourcing 

  • Sikkerhetspolicyer 

  • Skyplattform prioriteringer 

  • Godkjenninger av skyprosjekter 

  • Rapporterer på kostnader, incidenter, prosjektstatus og fremdrift, sikkerhetsincidenter, utvikling på 
      

Kompetanseteam for skytjenester 

Dette er et virtuelt team som har kunnskap om følgende: 

  • Ulike skytjenester/skykomponenter som institusjonen benytter eller kan benytte. 

  • Hvordan komme i gang med bruken av en gitt skytjeneste og support rundt dette. 

  • Verktøy for å migrere over til skyen. 

  • Verktøy for automatisering. 

  • Kunnskap om hvilke sikkerhetstiltak som er viktige og hvilke verdier som er viktige å sikre. 
      

Utviklerteam (eventuelt, hvis institusjonen har egenutvikling) 

Hvis institusjonen har en viss grad av egenutvikling av tjenester, bør man også ha et eget utviklerteam med spesielt ansvar for sky. Disse skal ha kompetanse på: 

  • Rammeverk for koding 

  • Testverktøy 

  • Byggeverktøy 

Generell informasjon og forvaltning 

  • IT-avdelingen som kompetansesenter 

  • Forslag til modell for skytjenester 

  • Organisering 

  • Rutiner styringsmodellen for skytjenester må ivareta 

Rutiner styringsmodellen for skytjenester må ivareta 

I en styringsmodell for skytjenester må man også ha på plass et sett med rutiner som ivaretar det institusjonen trenger hjelp til når den tar i bruk skytjenester. 

  • Prosjektstyring  

  • Kostandsstyring  

  • Support og opplæring  

  • Sikkerhet  

  • Soursing  

  • DevOps 

Prosjektstyring 

Institusjonen må etablere rutiner for hvordan løpet er fra et behov blir spilt inn fra en bruker og til det blir dekket gjennom en tjeneste som er realisert i skyen. Hvem godkjenner det? Hvem bidrar inn på ulike fagområder? Hvilke spørsmål må være besvart før et prosjekt godkjennes for skyen? 

Det anbefales å kjøre piloter på de tjenestene dere ønsker å ta i bruk. En pilot skal besvare følgende spørsmål: 

  • Hva vil det koste? 

  • Hvem eier tjenesten (lokal tjenesteeier)? 

  • Hvilke sikkerhetstiltak er nødvendige? 

  • Hvilke backup-rutiner trengs? 

  • Hvordan er tjenesten koblet til vårt nettverk? 

  • Hvilke behov har vi for autentisering og integrasjon? Hvordan dekkes de i denne tjenesten? 

  • Hva tilbyr tjenesten når det gjelder gjenoppretting? 

  • Dersom det i ettertid kommer opp at institusjonens funksjonelle krav ikke dekkes av den valgte løsningen, hvordan håndteres det? 

  • Når kan institusjonen avvikle tjenesten? 

OBS: Husk å skille mellom de ulike fasene en skytjeneste er i (proof of concept, pilot eller produksjon). 

Kostnadsstyring 

Ved bruk av IaaS-tjenester 

  • Alle IaaS-ressurser bør merkes (tagges) med det prosjekt/koststed som benytter ressursen. Rutinen kan f.eks. si at ressurser som ikke er tagget blir slettet. 

  • Lag en struktur for merking (tagging). OBS – det kan være smart å gå for et minimalt standardsett av merkelapper (tagger). For komplisert struktur for merking vil gjøre regningene kompliserte. 

  • Undersøk hvor lang tid det vil ta å gjenopprette en tjeneste. Dette avhenger av datamengde og linjekapasitet. 

  • Hvor ofte tas backup? 

  • Når dere flytter VM’er fra lokalt datasenter til IaaS-tjeneste bør dere se på skalering: 

  • Skru av VM-ene når de ikke trengs. 

  • Kjøp mindre ressurser (maskiner) enn dere har gjort lokalt (fordi man gjerne kjøper litt større enn behovet der og da når man har kjøpt inn til lokalt datasenter). 

  • Hold oversikt over kostnadene (f.eks. gjennom en portal): 

  • Tjenesteeier (den som bruker og har hovedansvaret for tjenestene) bør fire ganger i året ta en sjekk på hva man bruker i de ulike løsningene. 

  • IT-avdelingen bør gjennomføre en årlig gjennomgang hvor de «jakter» på ubrukte ressurser (f.eks. ubrukte snapshots).  

Ved bruk av SaaS-tjenester 

  • Hva er inkludert i SaaS-prisen? Husk å sjekk om gjenoppretting er inkludert! 

  • De fleste SaaS-løsninger har ganske enkle prismodeller og gir institusjonen stabile kostnader fra måned til måned. 

Support og opplæring 

En god, lokal supportmodell er viktig også når man bruker skytjenester! 

  • Hva slags support bør være automatisert fra sentralt hold for å gjøre det enklere for sluttbrukere? 

  • Hvilken tilgang har ditt lokale support-senter til de ulike SaaS-tjenestenes dashboard? 

  • Support-senteret må ha lett tilgang på info om hvilke tjenester dere har og hvordan de ulike tjenestene er koblet sammen. De bør også ha kontaktinfo for de ulike komponentene i porteføljen til institusjonen. 

  • OBS – husk at supportnivå og pris ofte henger sammen. Trenger dere å betale for premium support? 

  • Husk at det er deres ansatte som vet hvordan alt henger sammen fra lokal infrastruktur og ut i skyen. 

  • Typiske feilsituasjoner er bl.a. utgåtte passord, noen som ikke har lisenser, noen som ikke er med i rette grupper. 

  • Hvis det er trøbbel med ytelsen er det ofte mest hjelp i ansatte som kjenner til hvordan det lokale nettet er bygd opp, og som – i kontakt med UNINETT – vet hvordan transportnettet yter. 

Opplæring: 

  • Ved spørsmål om å ta i bruk en ny skytjeneste bør man stille seg spørsmålet: Har vi den kunnskapen vi trenger? Gjennomfør målrettet opplæring! 

  • Hele IT-avdelingen bør ha opplæring på «hva er skyen?» og «hvordan bruker vi den?» 

  • Løsningsarkitekter, sikkerhets- og nettverksfolk bør har kurs går ut på hvordan man designer en hensiktsmessig arkitektur i IaaS-tjenesten(e). 

  • Tjenesteansvarlige bør få opplæring innen kostnadshåndtering i skyen. 

  • Systemadministratorer bør også kurses. 

Sikkerhet 

Sikkerhet i skysammenheng er sammensatt og består av flere områder som tilgjengelighet (backup, disaster recovery), compliance, identitets- og tilgangskontroll, kryptering av data. 

Selv om skytjenesteleverandøren har ansvaret for deler av tjenesteleveransen (se figur 1) ved bruk av skytjenester, har kunden (institusjonen) alltid det ansvaret for å gjøre risikovurdering, vurdere hvorvidt skytjenesten oppfyller institusjonens egne krav og inngå gode nok avtaler. 

For å vite hvilke sikkerhetstiltak som er nødvendig, må man gjøre en risiko- og sårbarhetsvurdering av det å ta i bruk en gitt sky-tjeneste. 

Figur 1: Figur lånt fra saken «What Does Shared Responsibility in the Cloud Mean?»  

  • Tilgjengelighet (backup og disaster recovery): 

  • IaaS-leverandøren tilbyr en mulighet for å ta snapshots, men du må selv ta ansvar for at det blir gjort. 

  • Merk at det ikke er automatisk geo-redundans i IaaS-tjenester, og at én region betyr noe forskjellig i Amazon og Azure. 

  • Når det gjelder SaaS-tjenester bør man finne ut hvordan disaster recovery er løst, selv om man som kunde ikke er ansvarlig for å sette opp dette ved SaaS-tjenester. 

  • Compliance: 

  • Hvilke krav har institusjonen til å tilfredsstille ulike sikkerhetsstandarder? 

  • I hvilken grad påvirker det hvilke tjenester dere kan bruke og hvilke krav til compliance dere må stille til tjenester? 

  • Er det avhengig av hvilke data og hvilke tjenester det er snakk om? 

  • Identitets- og tilgangskontroll: 

  • Ved bruk av IaaS-tjenester bør man designe en struktur for subscriptions/accounts. 

  • Hvordan skal man logge seg på VM’er? 

  • Ved SaaS-tjenester: Hvilke Hvordan ønsker dere at autentisering av brukere gjøres? 

  • Kryptering: 

  • Hvordan kan institusjonen styre kryptering av data? To ulike konsepter: 

  • Encryption at rest – leverandøren krypterer dine data med sin nøkkel. 

  • Bring your own key: Institusjonen krypterer sine data med sin egen nøkkel. 

  • For SaaS-tjenester er dette applikasjons-spesifikt, så det må man undersøke med den enkelte SaaS-tjeneste.  

Sourcing 

  • Valg av IaaS-leverandør: 

  • Gjennom UNINETT har sektoren tilgang til flere rammeavtaler og sektorinterne tjenester. I saken IaaS – hvilken løsning bør du velge kan dere lese mer om disse. 

  • Når leverandør er valgt, avtale er inngått med leverandøren og tilgang til leverandørens plattform er på plass vil det være behov for å benytte tid på kurs og opplæring. Det å i en tidlig fase sette av noe tid på å kunne teste/eksperimentere med forskjellig funksjonalitet skyleverandøren tilbyr er viktig for å få nødvendig modningstid. 

  • Design i IaaS: På samme måte som man må planlegge et datarom med lagring og nettverk, må man planlegge hvordan det skal implementeres i skyen (som f.eks. nettverksarkitektur, lagring identitets- og tilgangskontroll, monitorering/logging/rapportering, VM-størrelser, backup etc.) 

DevOps 

Institusjonen bør etablere rutiner for uvikling og dift, DevOps (development and operation). Med DevOps brukes programkode eller scripting for å automatisere etablering, installasjon og konfigurering av IT-infrastruktur. 

Dere bør ha kompetanse på og verktøy for å håndtere: 

  • Verktøy for provisjonering av infrastruktur (infrastructure as a code, f.eks. Terraform, Azure ARM Templates). 

  • Verktøy for provisjonering av software/funksjonalitet på denne infrastrukturen (configuration as a code, f.eks. Puppet, MS Desired state configuration. 

  • Kontainerbaserte applikasjoner (f.eks. Docker). 

  • En release-pipeline som benytter: 

  • Et system for versjonskontroll (f.eks. GitLab) 

  • Et system for continuous integration (CI) (f.eks. GitLab CI). 

 


Del: Share to LinkedIn Share to Facebook Share by mail Share to Twitter