Transcript Frågor att beakta inom infrastruktur vid anskaffning

Frågor att beakta inom
infrastruktur vid anskaffning och
användning av molntjänster
RIKTLINJER
Powered by Dataföreningen
Version 1.0 - 2011-03-14
Det här dokumentet är licensierat under Creative
Commons Erkännande Dela-Lika 3.0
http://creativecommons.org/licenses/by/3.0/
Versionshantering
Ändringar
Datum
Ansvarig
Version
Referenser
2010-09-15
Bengt Höjer
0.1
Ursprunglig lista på frågeställningar (PPT)
2010-11-15
Göran Lustig
0.4
Komplettering av frågor, redigering (PPT)
2010-12-07
Göran Lustig
0.6
Redigering (PDF)
2011-01-20
Göran Lustig
0.7
Komplettering med Introduktion, redigering
2011-01-25
Bengt Höjer
0.8
Komplettering med förslag till svar
2011-01-26
Göran Lustig
0.82
Redigering och kommentarer till 0.8
2011-01-27
Tobias Blomberg
0.83
Kommentar i kap. 1
2011-01-29
Göran Lustig
0.84
Tillägg till kap. 3
2011-01-29
Bengt Höjer
0.85
Redigering av svar
2011-01-30
Göran Lustig
0.86
Formatering
2011-02-10
Stefan Görling
Tobias Blomberg, Jan Hedström
0.87
Nytt kapitel ”Att upphandla infrastruktur”
Beslutsmatris
2011-02-14
Bengt Höjer, Göran Lustig
0.88
Ändringar i listan baserat på kommentarer
2011-02-20
Bengt Höjer
0.89
Putsning av frågeställningar och svar
2011-03-09
Göran Lustig
0.9
Smärre ändringar p.g.a. kommentarer
2011-03-14
Bengt Höjer
1.0
Slutputs inför publicering
Granskning
Namn
<namn +
mejladress>
Version godkänd
Ver.nr som
godkänns
Kvalitetssäkringen
Datum
Ledningsgruppsansvarig, eller behörig utsedd av
ledningsgrupp, beskriver kortfattat processen som
dokumentet har gått igenom.
Åååå-mm-dd
Sida 1
Innehållsförteckning
1
Om Cloud Sweden ................................................................................................................. 3
2
Om molnet och arbetsprocessen ............................................................................................ 3
2.1
Molnet: en 5x3x2 Modell ............................................................................................................. 4
3
Introduktion .......................................................................................................................... 5
4
Att upphandla infrastruktur................................................................................................... 7
5
Frågor inom infrastruktur som bör beaktas ............................................................................ 9
5.1
SLA ................................................................................................................................................ 9
5.2
Teknisk miljö .............................................................................................................................. 17
5.3
Applikationsmiljö ....................................................................................................................... 20
5.4
Säkerhet ..................................................................................................................................... 23
6
Källor .................................................................................................................................. 28
7
Frågor och förslag till förbättringar ..................................................................................... 28
Sida 2
1 Om Cloud Sweden
Cloud Sweden är den naturliga, oberoende, kontaktpunkten kring kompetensfrågor i molnet. Som
sådan ska vi främja utvecklingen för en säker resa mot molnet. Vi vill sätta Sverige i ledningen för
utvecklingen och sprida vår kompetens vidare i Europa och världen.
Cloud Sweden arbetar för att ta fram kriterierna för en bra molntjänst. Vi gör det utifrån ett teknik-,
juridik-, avtals-, verksamhets- och säkerhetsperspektiv där slutkundens/-användarens intresse alltid
ligger i fokus.
Vi arbetar över alla kanaler för att skapa och tillgängliggöra kvalitativ information. Cloud Sweden är
öppet för alla att engagera sig i och allt som vi publicerar tas fram under en Creative Commons
Licens 3.0, Erkännande-dela-lika. Det innebär att allt är fritt att använda, förädla och förbättra.
2 Om molnet och arbetsprocessen
Molnet fungerar som en abstraktion för något annat. Begreppet ”molnet” har sitt ursprung ifrån
tidig Internettid då vi ritade och abstraherade nätverket som ett “moln”. I början kretsade begreppet
”molnet” kring nätverket och fungerade som en abstraktion av de tekniska protokoll man använde,
senare blev ”molnet” en abstraktion för de dokument och sidor man hämtade på Internet och idag
börjar ”molnet” bli en abstraktion för de servrar, applikationer, data och tjänster som finns över
Internet. Vi hoppas detta dokument kan bidra till att förstå denna abstraktion bättre.
Detta dokument är framtaget av Cloud Swedens arbetsgrupp Infrastruktur, som har följt det
kvalitetssäkringsarbete och guidelines för dokumentation utgiven av Cloud Sweden.
Rekommenderat är att en granskningsgrupp bestående av 3-5 personer alltid får utgöra teamet som
utför den kollegiala granskningen. Personerna skall ha gott renommé, inneha väsentlig kunskap om
området och det bör finnas en blandning av olika perspektiv i form av publik och privat sektor,
akademi och gärna om möjligt olika organisationsstorlek.
Kvalitetssäkringsgruppen utser för varje dokument som skall granskas en granskningsgrupp, som när
granskningen är klar rapporterar tillbaka varvid kvalitetssäkringsgruppen tar beslut om dokumentet
är godkänt, kräver mer arbete eller inte uppfyller kriterierna.
Sida 3
2.1 Molnet: en 5x3x2 Modell
Det finns flera olika sätt att definiera molnet och det är viktigt för Cloud Sweden att ha en koherent
beskrivning av vad molnet kan leverera för tjänster, hur den levererar dessa tjänster samt vad som
karaktäriserar en molntjänst. För att beskriva detta så använder vi en 5x3x2 modell vilket innebär att
vi använder fem olika karaktäristika, tre olika leveransmodeller samt två olika installationsmodeller.
Fem kännetecken på molnet
1. Upplevt oändliga resurser; Ifrån användaren perspektiv så kan man förutsätta att resurserna
skalar till den nivå man behöver.
2. Betalning per resursanvändande; Användare kan förutsätta att kostnaderna för resurser är
linjära och inte kräver initiala eller plötsliga kapitalinvesteringar.
3. Självbetjäning; Användare kan instansiera upp sina egna resurser i molnet utan mänsklig
inblandning.
4. Abstraherad eller icke-fysisk hårdvara; Användaren hanterar inte sina resurser via dedikerad
hårdvara utan arbetar med en abstraktion av hårdvaran.
5. Klientoberoende tillgång; tjänsterna levereras via standardprotokoll som inte ställer specifika
krav på olika formfaktorer eller speciella klienter.
Tre leveranssätt av molntjänster
1. Software as a Service (SaaS); Leverans av färdiga eller konfigurerbara applikationer över
Internet
2. Platform as a Service (PaaS); Applikationsplattformar i molnet för användare att installera
sina egna applikationer i.
3. Infrastructure as a Service (IaaS); IT-infrastrukturella tjänster i nätet såsom exempelvis
lagring, nätverk och servrar etc..
Två Installationssätt
1. Publikt moln; Molntjänsten ägs och hanteras av en tredje part som säljer resurser till flera
kunder på samma infrastruktur
2. Privat moln; Molnstjänsten levereras på en infrastruktur dedikerad åt endast en användare
och hanteras av användaren själv eller av tredje part.
Sida 4
3 Introduktion
Detta dokument behandlar aspekter på infrastruktur för alla typer av molntjänster enligt
definitionen ovan. Merparten av de i dokumentet upptagna frågeställningarna är lika viktiga att
ställa vid upphandling av SaaS (Software as a Service) som vi upphandling av IaaS (Infrastructure as a
Service) och PaaS (Platform as a Service). Likheten med outsourcing är tydlig, även om det finns
skillnader, vilket gör att de frågeställningar som blir aktuella är nästan desamma när man jämför
molntjänster och outsourcing. Dokumentet syftar inte till att ställa molntjänster mot andra typer av
externaliserade IT-tjänster.
Beslutsmatris:
Faktor
Kontroll
"ägarskap"
över ITresurser
per kund
Möjlighet
till
anpassning av
avtalsvillkor
Leverantörens
kunskap
om
respektive
kund
Kräver
"ITkunskap"
och
driftsansvar
hos
kunden
Ja, oftast Kort
Nej
Nej
Låg
Ibland
Lite
Ja, oftast Kort
Ja
Ja
Hög
Oftast inte Medel
Möjligt
Nej
Nej
Lång
Ja, oftast
Ja
Medel
Oftast inte Hög
Möjligt
Lite
Nej
Lång
Ja
Ja
Låg
Ja
Tröskel
att
komma
igång
(tid/
kostnad)
Data
replikerad
till
flera
ställen
I
realtid
skal- Rörlig
bar kostnad
Publik molntjänst
Låg
Troligt
Ja
Privat molntjänst
Medel
Möjligt
Outsourcad tjänst
Intern drift av privat
moln
Medel
Hög
Leveransform
Typisk
kontraktslängd /
investeringstid
Vikt av
välskrivet
SLA
Hög
Låg
Vid en jämförelse mellan outsourcing och molntjänster finner man att en privat molntjänst (se ovan)
oftast kan likställas med outsourcing, medan den publika varianten av molntjänster skiljer sig mest
från outsourcing. I den publika varianten har användaren liten eller ingen kontroll över vilka resurser
som finns eller hur de används i en driftsituation. Ur infrastruktursynpunkt är det därför viktigt att
det görs en kvalificerad bedömning av om de resurser molnleverantören har och hur de används
kommer att svara upp mot de krav den egna organisationen har. Samtidigt bör man vara medveten
om att, oavsett typ av molntjänst, en varierande grad av anpassning till leverantörens miljö måste
göras om man vill få ut effekter (ekonomi, kvalitet, etc.) av en molnlösning, för i grunden handlar
detta om storskalig standardisering och en förskjutning av ansvar.
Ska man som köpare av molntjänster kunna påverka leverantörens IT-arkitektur och IT-processer?
Det mesta talar emot att det ska vara möjligt -, arkitekturen och processerna är leverantörens sätt
att hantera sina samlade kunders behov på ett ekonomiskt och resurseffektivt sätt. Däremot är det
viktigt att sätta upp nyckeltal som måste uppnås för olika driftscenarier, alltså vad arkitekturen och
processerna ska kunna prestera, oavsett vilka som används.
Sida 5
Vid anskaffning av molntjänster, oavsett om det är en IaaS-, PaaS- eller SaaS-tjänst (se ovan), är det
mycket viktigt att IT-organisationen är engagerad för att framförallt hantera infrastrukturfrågorna.
Kunskapen om dessa frågor finns normalt bara i IT-organisationen, medan affärsverksamheten oftast
kan ta hand om de funktionella frågorna. Det vore helt fel om den verksamhetsansvarige (HRchefen, ekonomichefen, etc.) själv, utan IT:s hjälp, gör en molnupphandling och lika fel är det om IT
inte vill bidra med kunskaper för att molntjänster hotar IT-organisationens ansvarsområde.
Molntjänster är här för att stanna och de är en naturlig utveckling av företagens/organisationens
sätt att stödja affären. IT:s roll kommer därför att förändras men på vägen dit är IT-kunskaperna om
infrastruktur viktiga för att möjliggöra bra molnlösningar.
Infrastrukturfrågorna nedan är indelade i fyra huvudområden:




SLA
Teknisk miljö
Applikationsmiljö
Säkerhet
Dessa huvudområden är sedan uppdelade i ett antal delområden som var och en består av en eller
flera frågor. Till varje fråga finns en rekommendation till svar/ansats samt ett förslag vilken roll i
företaget/organisationen som bör vara huvudintressent. Frågeställningarna utgår ifrån att
infrastrukturen inte bara består av grundläggande teknik (maskinvara, nätverk och programvara),
utan även grundläggande IT-processer och grundläggande säkerhetsfunktioner. Vissa av
frågeställningarna överlappar därför frågeställningar som tagits upp i andra Cloud Swedendokument, t.ex. om säkerhet, men hanteras här på ett lite annat sätt.
SLA (Service Level Agreement) har fått relativt stort utrymme i detta dokument. Detta beror på att
det är med hjälp av ett SLA blivande molnanvändare kan och bör reglera viktiga
infrastrukturnyckeltal. Framförallt gäller det de icke-funktionella kraven (exempelvis prestanda och
kvalitet, som ofta kan bli bortglömda i den stora mängden funktionella krav).
Dokumentet anger ”förslag till ansats” för frågeställningarna för att det helt enkelt inte går att
formulera absoluta svar som skulle kunna stämma in på alla företag och organisationer. De svar som
slutligen blir formulerade på frågeställningarna nedan kommer att vara beroende av de eventuella
branschregler som företaget eller organisationen lyder under, men framför allt av de interna policys
som bör finnas. Om de saknas så är det hög tid att formulera sådana innan diskussioner förs med en
molnleverantör.
Detta dokument utger sig inte för att vara en komplett samling av frågeställningar om infrastruktur
vid anskaffning och användning av molntjänster, utan ska ses som en stomme att bygga vidare på
när infrastrukturfrågorna ska hanteras.
Sida 6
4 Att upphandla infrastruktur
Inledningsvis noterades att det finns stora likheter mellan beslut att använda molnbaserad infrastruktur
och traditionella outsourcingbeslut. Den lista över frågor att beakta som presenteras I följande avsnitt är
därför bekanta för den som tidigare utkontrakterat delar av sin infrastruktur till andra aktörer.
Har organisationen inte tidigare arbetat med utkontraktering är det viktigt att ta till sig de lärdomar som
finns inom detta område för att undvika problem i processen. Outsourcing är komplicerat och många
projekt att utkontraktera IT-infrastruktur har betraktas som misslyckanden av flera olika anledningar.
Denna lista innehåller många riskmoment, men det är viktigt att väga dessa mot verksamhetens nuvarande
risker. En stor del av en utkontraktering av en tjänst handlar om att göra både implicita risker och kostnader
explicita.
Att sänka kostnaden är därför inte nödvändigtvis den främsta målsättningen med en molnbaserad
infrastruktur. Högre tillgänglighet, bättre skalbarhet eller möjligheter till snabbare anpassningar kan t.ex.
vara minst lika viktiga mål. Innan en molnsatsning inleds bör verksamheten därför skapa en tydlig bild kring
vilka mål som eftersträvas.
En annan förutsättning för en lyckad affär är att klargöra vad som faktiskt behövs. Förändringar av avtalet
kommer alltid innebära merkostnader. En bra försäkring mot framtida problem är att innan processen
inleds ha en tydlig förståelse för vad det är för funktioner som faktiskt efterfrågas. Ju bättre kunskap om
den interna infrastrukturen som finns, desto mindre risk att affären misslyckas. Ett första steg kan därför
vara att försöka beskriva verksamheten utifrån en uppsättning av tjänster som levereras till övriga
organisationen.
Den största skillnaden mellan intern verksamhet och utkontrakterade tjänster är förändringen från en chefanställd-relation till en avtalsrelation. I situationer där diskussioner om problem eller utveckling av
verksamheten tidigare skett i interna möten mellan anställda med samma organisations mål i sker de nu i
en affärsjuridisk kontext av avtalsförhandlingar. Det är i denna kontext listan över frågor att beakta bör
betraktas.
Denna förändring innebär även att det kan komma att behövas en annan typ av kompetens för att förvalta
en avtalsrelation än den som tidigare krävdes för att leverera infrastrukturtjänsterna. Den långsiktiga
kompetensförsörjningen i organisationen bör därför beaktas. Speciell bör vikten av att ha tillgång till
juridisk kompetens betonas.
Är organisationen ovan vid denna typ av upphandlingar bör det betraktas som en läroprocess, där mindre
kritiska tjänster utkontrakteras först för att sedan gradvis, när organisationen har mer erfarenhet utvärdera
allt mer avancerade tjänster.
Mer än bara ett inköp, en leverantörsrelation: - Gradvis, löpande process – upphandling, val av leverantör.
För att bygga upp erfarenhet kring molntjänster inom organisationen är det bra att se detta som en
läroprocess och börja med mindre kritiska tjänster.
Sida 7
Att utkontraktera infrastrukturtjänster är inte att jämföra med ett inköpsbeslut utan snarare en del av en
kontinuerlig förvaltningsprocess. Övergripande kan arbetet organiseras som följer:
1. Förstudie – Vilka tjänster levererar IT till resten av organisationen? Vilka tjänster kan vara aktuella
att ersätta med molntjänster, och vad bör vi tänka på om dessa upphandlas?
2. Strategibeslut - Utifrån förstudien kan ett strategibeslut tas kring hur organisationen bör förhålla
sig till molnet. Beslutet bör svara på frågor som: Varför ska vi använda molnet? Vad bör vi lägga i
molnet? Hur ska vi gå till väga?
3. Upphandlingsfas - Ett fullständigt upphandlingsunderlag sammanställs utifrån de tips som finns i
detta dokument. Leverantörer kontaktas och kontrakt upprättas. Eftersom kontrakt med
leverantörer i andra länder kan vara svåra att upprätthålla. Därför är det viktigt att inte enbart
utvärdera leverantörer efter vad de säger sig kunna leverera utan väga in flera dimensioner. Vi kan
tala om fyra C:n som är viktiga i utvärderingen:
o Capable – Kan de leverera den tjänst som efterfrågas.
o Compatible –
 Kan organisationerna arbeta tillsammans?
 Kan vi kommunicera?
 Förstår vi varandra i diskussioner?
o Comitted – Är de intresserade av oss som kund?
o Control – Kan vi styra/hantera leveransen
4. Övergång – Att flytta över verksamheten till den nya leverantören utan störningar kan vara
komplicerat och kräver noggrann planering.
5. Förvaltning – När verksamheten väl flyttats tilltar förvaltningsprocessen där vi löpande följer upp
hur väl avtalet fungerar, hanterar problem som dyker upp och diskuterar hur processen kan
förbättras ytterligare.
6. Omförhandling eller avslut – När avtalsperioden börjar löpa ut måste vi planera för omförhandling
av avtalet, byte av leverantör eller återtagande av verksamheten. Det kan vara mycket komplicerat
att lyfta tillbaka en molntjänst till den egna organisationen
Sida 8
5 Frågor inom infrastruktur som bör beaktas
5.1 SLA
Ett Service Level Agreement ska innehålla alla viktiga mätetal för de kontrollpunkter som användaren av molntjänsten behöver, för att molntjänsten ska
kunna stödja verksamheten på ett tillräckligt bra sätt.
5.1.1 Prestanda
Prestandafrågorna är de som påverkar slutanvändarna mest I vardagen. Var extra noggrann när de formuleras i ett SLA.
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Hur beräknas tillgänglighet? (Formel resp. över hur lång
tid: månad, kvartal, år)
Formeln som bl.a. återfinns i ”IT & Telekomföretagens” standardavtal är
branschstandard och bör användas så att man kan jämföra olika leverantörer.
AS – TB – AB
Tillgänglighet (%) = ------------------------ x 100
AS – TB
AS = Avtalad Servicetid, TB = Tillåtna avbrott i tid,
AB = Avbrottstid
Fyller man i siffror så finner man att 2 timmars avbrott (per månad) ger en
tillgänglighet på c:a 99,7% räknat på servicetiden 24/7. 2 timmars avbrott
räknat på servicetid under kontorstid (8-17 vardagar) ger en tillgänglighet på
c:a 98,9% (också räknat per månad). En högre tillgänglighetssiffra för 24/7 är
m.a.o. inte automatiskt bättre än en lägre för kontorstid, om det verkliga
tillgänglighetsbehovet inskränker sig till kontorstid eller annan delmängd av
24/7.
Sida 9
Hur mäts svarstider?
Bör ske på leverantörens anslutning till Internet och m.h.a. ett program som
efterliknar olika handgrepp som en användare förväntas utföra.
Behandlingstiderna för de olika handgreppen mäts, sparas och kan visas
statistik på. Cykeln bör upprepas t.ex. var 10:e minut och loggas. En ”virtuell
användare” är också den enda övervakningsmetoden som täcker in alla
felsituationer, det är m.a.o. viktigt att larm kan genereras om de ”virtuella
handgreppen” inte kan genomföras. Behövs bättre (t.ex. multipla mätpunkter
externt från Internet) kan man överväga att köpa den tjänsten från en annan
leverantör.
Kan tillgänglighets- och svarstidsstatistik enkelt tas
fram?
Kräv att siffror redovisas med den periodicitet som överenskommet SLA
stipulerar. En seriös leverantör har heller inga problem med att visa upp
historiska siffror på tillgänglighet och svarstider FÖRE att avtal signeras.
SLA för Internetanslutningen?
En av de vanligaste störningsorsakerna är avgrävda kablar. Kräv därför multipla
anslutningar som går fysiskt separerade vägar. Viktigt också att leverantören
använder ISP:er med hög tillgänglighet och prestanda samt har köpt tillräcklig
bandbredd. Multipla ISP:er på leverantörssidan minskar också störningsrisken.
Hur mäts SLA:n (t.ex. vill man kunna ha specifika krav på
SLA från de i Sverige största ISP:erna)?
Viktigt är att svarstiderna/tillgängligheten är god för den/de ISP:er som du som
kund använder.
Uppstarts- och stopptider – elasticitet?
Alla molnleverantörer har en viss fördröjning innan mera resurser är allokerade
(t.ex. antal virtuella servrar). Tiderna varierar stort mellan leverantörerna, tillse
att tiden är tillräckligt kort för just ditt behov. Också viktigt att mängden
resurser skalas ned tillräckligt fort när behovet inte längre finns, annars kan det
bli onödigt dyrt.
Sida 10
Servicefönster?
Alla system behöver underhållas. Säkerställ att det sker på fasta tider som Du
kan planera din verksamhet runt.
Undantag: ”tillåten avbrottstid”, ”mjukvarufel”?
Se upp med undantag i SLA-kalkylen som i praktiken sätter avtalet ur spel. T.ex.
”avbrott kortare än 5 minuter” räknas inte, men vare sig antal eller frekvens är
maximerad. Att ”Mjukvarufel” inte räknas in är ett annat vanligt undantag,
vilket ju rimligen inte borde exkluderas när man köper en mjukvara som tjänst.
Akut service?
Bra om nyupptäckta säkerhetshål kan åtgärdas snabbt, men hur informeras Du
som kund om kommande avbrott? Hur snabbt kan leverantören garantera att
akuta felrättningar appliceras?
Viten?
Det skall göra ont för leverantören om man inte klarar av sin leverans enligt
kontrakt, men de skall givetvis inte drivas i konkurs. Vem har bevisbördan? Om
leverantören är liten så bör vitet täckas av en försäkring.
5.1.2 Support
När fel inträffar och användarna behöver hjälp så ska det vara tydligt vilken hjälp de kan få och när.
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Vad kostar support?
Inget är gratis, bra med fasta priser.
Vad ingår?
Den nivå som ingår kanske inte täcker dina behov.
Begränsningar?
Leverantören ska redogöra för alla begränsningar. Se upp med undantag och
ev. (dyra) merfaktureringar.
Kanaler för support?
Kan Du få support på det vis Du önskar? (webb, email, telefon etc.)
Sida 11
Språk?
Se även upp med att varifrån supporten tillhandahålls. Engelska med brytning
kan vara svårbegriplig och skilda kulturbakgrunder kan ge upphov till
missförstånd.
Tillgänglighet och svarstid på supporten?
Garanterade svarstider och historisk statistik på utfall bör kunna presenteras.
Att sitta i telefonkö i en timme eller vara tvungen att vänta på mailsvar i ett
dygn kanske inte räcker när man får problem.
Prioriteringsgrader?
Vem avgör om mitt problem prioriteras eller inte och hur, på vilka grunder?
Eskalering
Hur går eskalering till ifall inte erforderlig support kan ges av den instans som
man har kontakt med? Arbetar leverantören proaktivt eller måste Du själv
eskalera?
Informationsspridning
Kan Du som kund bli informerad om störning via en kanal som passar dig
(email, SMS, webb etc.)
5.1.3 Övervakning
Det är viktigt att veta vilken nivå av övervakning som tillhandahålls för att kunna avgöra om den kommer att vara tillräcklig för mina behov.
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Vad är möjligt att övervaka?
Vilka verktyg tillhandahåller leverantören? Kostnad? Hur kan jag få larm?
Statistik?
Kan jag gå tillbaka i tiden och jämföra när jag behöver?
Integration med andra övervakningsverktyg?
Ofta är en samlad bild av funktionen i olika system viktig när problem skall
upptäckas och lösas. Kan jag installera egna övervakningsprogram och/eller
exportera (i realtid) siffror till andra system?
Sida 12
Tillgång till loggar?
Jag kanske inte har rätt till att få se loggar på trafiken då den även omfattar
andra kunders data. Kan leverantören extrahera ut kundunika loggar, kan
annan påverkande trafik anonymiseras och inkluderas? Loggtillgången behövs
inte bara för att lösa problem utan kan även vara en viktig fråga ur ett juridiskt
perspektiv om skada har åsamkats (mig eller min kund) och loggen är ett bevis
som behövs i ett civilmål.
5.1.4 Vad ingår i priset?
Att få klart för sig vad en molntjänst kostar är naturligtvis grundläggande och en avgörande faktor för om man utnyttjar den.
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Fast pris eller volymbaserat?
Om priset är volymbaserat är det viktigt att förstå beräkningsmodellen och att
det hänger ihop med den nytta jag får ut.
Hur beräknas det?
Inte helt ovanligt med beräkningsformler som är näst intill obegripliga för
kunden. Om inte leverantören kan räkna ut vad det kommer att kosta i förväg
så lär inte Du heller klara av det.
Kostar något extra?
MYCKET vanligt med extra avgifter för diverse (t.ex. backup) som man kan
tycka rimligtvis bör ingå. Kräv att leverantören tydligt anger vad som INTE ingår
och se till att en prislista på extratjänster finns med i avtalet.
Faktura eller korttransaktion?
Det är enligt svensk bokföringslag egentligen inte ens tillåtet att betala för
molntjänster via kreditkort, räkna åtminstone med att ekonomiavdelningen
inte gillar det.
Sida 13
Larm vid takpris?
Om automatisk uppskalning av behövda resurser tillämpas så kan det lätt bli
dyrt om man av misstag ställer t.ex. en alltför beräkningsintensiv fråga. Bra om
det finns ett tak som stoppar. Detta tak kan också vara negativt om det slår till
vid fel tillfälle och den normala funktionen därmed förhindras, någon form av
trendanalys för att beräkna ett mera rättvisande takvärde kan behövas.
Specifikation av kostnader?
Kräv en begriplig faktura, bra om man löpande kan se upplupna kostnader.
Prisutveckling – låst mot index?
Välj i så fall (om möjligt) index som kan Du kan förutse utvecklingen av. Bra om
leverantören kan lova ett fast pris över en längre tidsperiod så att Du inte
drabbas av höjningar när Du gjort dig beroende av systemet.
Avtal och kontraktstider
Hur lång tid gäller avtal, kanske kortare än ”vanliga” avtal? Se, som vanligt,
också upp med krav på abnormt långa varseltider för uppsägning (innan avtalet
automatiskt förlängs med en längre tid).
5.1.5 Disaster Recovery
Behovet av disaster recovery kan vara frågan om ett företags överlevnad eller inte när ett system blir obrukbart.
FRÅGETÄLLNING(AR)
FÖRSLAG TILL ANSATS
Finns det en plan för att hantera en fullskalig katastrof?
Bomber som slår ut datacenter är inte vanliga, men vattenläckor kan ställa till
med nästan lika stor skada och är inte alls lika ovanliga. Kräv att leverantören
har en plan och reservutrustning på annan ort, helst i form av en detaljerad
checklista som arbetet med återställningen kan utföras utifrån (när det är
skarpt läge så finns det inte tid att tänka ut hur man skall göra).
Hur snabbt är tjänsten åter tillgänglig?
Hur länge kan Du vara utan tjänsten?
Sida 14
Finns kompetensen för att hantera en återstart
tillgänglig?
Detta gäller även den egna organisationen och övriga leverantörer. I dagens
högintegrerade värld är det viktigt att man i förväg definierar återstartspunkter
mellan de olika systemen och dokumenterar hur det går till.
Testas det?
Erfarenheten visar att man bör testa skarpt med jämna mellanrum för att
verkligen lyckas om den stora katastrofen inträffar. Kräv att leverantören
redovisar hur det senaste testet avlöpte, med tidsangivelser och när det
gjordes. Kolla också att arkitekturen inte har ändrats på någon viktig punkt sen
senaste testen.
Hur mycket data förlorar jag?
Att ha reservsystem som är tillgängliga inom minutrar är dyrt. Många kan ofta
klara sig utan tillgång till systemen längre än så (dag) bara man vet att en
mindre mängd data gick förlorad (timme).
5.1.6 Inlåsning
För att kunna avsluta eller byta en molntjänst är det viktigt att veta vad som krävs av mig som köpare.
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Äger jag mitt data?
Inte så självklart som man skulle kunna tro. Kan jag på ett enkelt och snabbt
sätt få hem mitt data den dagen jag vill avbryta leveransen?
Är applikationer utvecklade för plattformen körbara
någon annanstans?
Kort sagt är mitt data användbart utan leverantörens applikation och drift?
Kan jag flytta med min behörighetsinformation?
Om jag inte kan få med mig alla användares behörighetsprofiler så kan det bli
en tidskrävande mardröm att få till en användbar tjänst någon annanstans.
Sida 15
Kan jag välja att ta hem driften om jag så önskar?
Kan jag köpa en licens på programvaran (pris?) Eller finns det någon alternativ
leverantör av samma tjänst som kan använda mitt data i samma form?
Finns erfarenhet av flytt i praktiken?
Har leverantören genomfört någon flytt in och/eller ut? (Kan visa sig vara
svårare i praktiken än man kan tro.) Vad kostar en flytt och hur lång tid tar det?
Vilka standarder följs?
Viktigt att data kan exporteras i elektroniskt läsbara standardformat som kan
läsas av andra system i andra driftcenter.
Uppsägningstid?
Vill jag ha full flexibilitet så bör uppsägningstiden vara kort. Står vanligen i
motsatsförhållande till priset.
Vad händer om leverantören går i konkurs?
Bör tas upp i avtalet. Bra om leverantören tillämpar ett ”Escrow”-förfarande
(deponering av kritisk information hos en oberoende tredje part) så att jag
alltid kan få tillgång till mitt data, denna hantering är dock typiskt kostsam.
Sida 16
5.2 Teknisk miljö
Att skaffa sig insikter om den tekniska miljön (teknik och processer) är framför allt viktigt för att kunna göra en bedömning om en molnetablering är
realistisk. IT:s roll i denna process är avgörande.
5.2.1 Drift och underhåll av Operativsystem, plattform och/eller applikation
Vilket underhåll ingår i tjänsten? Vad behöver jag själv göra?
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Vad ingår?
Ingår något eller kostar allt extra?
Finns kompetensen?
Har leverantören tillräcklig kompetens för att effektivt kunna sätta upp och
underhålla hela systemet?
Vem sköter patchning och kostar det i så fall extra?
Är det leverantören eller kunden som bevakar behovet och initierar
utförandet? Vad kostar det?
Vem ansvarar för underhåll av OS och plattformar?
Det är inte ovanligt med specialversioner som endast kan underhållas av
leverantören. Jag kanske inte heller vill ha ansvaret själv.
Uppsättning och underhåll av applikationen (-erna)
För att en applikation skall leverera optimalt så krävs typiskt djup kunskap om
den interna tekniska funktionen (och dess påverkan på plattformen) för att
kunna utföra ett adekvat underhåll. Vem bevakar, initierar och utför detta?
Finns kompetensen och vad kostar det?
Löpande integritetskontroll resp. optimering av
databas?
Alla databaser kräver underhåll för att vara stabila och prestera bra. Vem
bevakar och utför det? Finns tillräcklig kompetens hos leverantören kring den
aktuella applikationen för att kunna optimera databasen utifrån applikationens
krav?
Sida 17
5.2.2 Internetanslutning
I och med att man flyttar ut sitt system på nätet så tillkommer några nya viktiga frågeställningar jämfört med den interna IT-miljön.
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Vilka ISP:er utnyttjas?
Se 5.1.1 ovan
Hur är anslutningen utformad avseende redundans?
Se 5.1.1 ovan
Kapacitet, risk för flaskhalsar?
Se 5.1.1 ovan
IPv6?
Leverantören bör vara IPv6 certifierad. Kanske inte avgörande i nuläget, men
stöd för IPv6 kommer att bli nödvändigt för alla. Bra om Du då inte behöver
byta leverantör eller betala extra för att klara av det.
IPv4, adresstilldelning – fast eller dynamisk?
I många säkerhetssammanhang är det inte ens möjligt att använda dynamiska
adresser. Kan jag använda egna IP-adresser eller är jag begränsad till
leverantörens? I.o.m. att IPv4-adresserna håller på att ta slut kan det också
vara bra att säkerställa att leverantören har tillräckligt många IPv4-adresser att
dela ut.
Filtreringsmöjligheter (brandvägg)?
Vad har jag för möjligheter att själv sätta upp och underhålla brandväggsregler?
Hur snabbt kan jag få igenom förändringar? Vem ändrar och vad kostar det?
Kan jag få ut en lista på alla regler som är uppsatta?
Loggning och statistik på IP-nivå?
Kan leverantören tillhandahålla loggar/statistik på just min trafik? Kan vara
viktigt för att lösa integrationsproblem och/eller prestandaproblem.
Krypterad kommunikation?
Stödjer leverantören SSL, IPSec och/eller andra skyddade kommunikationssätt
som jag vill använda?
Sida 18
5.2.3 DNS
Hur ser min webbplats ut på nätet? Blir det några förändringar?
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Möjlighet till egen NS?
Kan eget domännamn väljas i egen Name Server eller montjänstleverantörens
Name Server? Är det enkelt?
Tillgång till baklängesuppslagning av ”mina” IP-adresser?
Kan molntjänstleverantören hantera kundens egna domännamn i
baklängesuppslagningsfilen för DNS?
5.2.4 Miljön jmf. lokal installation
Vilka blir förändringarna? Kan jag hantera dessa?
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Är det en fullversion av OS resp. DB som levereras?
Specialversioner är vanligt, de applikationer som Du har tänkt att köra kanske
inte fungerar tillsammans med dessa specialversioner.
Vad är annorlunda eller saknas?
Viktigt att känna till begränsningarna i förväg.
Kan leveransen kompletteras?
Om jag behöver mera av något: Är det möjligt? Hur snabbt kan jag få tillgång till
det och vad kostar det?
Hur enkelt är det att installera resp. flytta en applikation
mellan molntjänsten och annat driftställe?
I första hand en kostnadsfråga (som kan variera STORT), men
applikationen/tjänsten är ju också otillgänglig under flytten.
Hur vet jag om jag skall investera i en insourcad
molnlösning eller outsourcad molnlösning?
Integrationer, kompetens och kostnad är här avgörande.
Sida 19
5.3 Applikationsmiljö
Vid utnyttjandet av en SaaS-tjänst måste en köpare ta reda på eventuella skillnader jämfört med sin tidigare miljö.
5.3.1 Tillväxt
Vad händer när mina behov växer och min egen IT-organisation inte har kontrollen?
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Hur hanteras utökade maskinvaru/resurskrav?
Vid SaaS-leverans kan det vara svårt (omöjligt) för kunden att förutspå och
hantera. Kräver utökningen avbrott i tjänsten? När man expanderar/skalar upp
resurserna så har den bakomliggande tekniska lösningen alltid vissa
begränsningar och tröskelvärden, ta reda på var de gränserna går för just din
leverans och vad de kan innebära för dig (avbrott och kostnadskrävande
applikationsanpassningar kan bli aktuella). En del leverantörer kallar klassisk
outsourcing för molntjänst utan att egentligen har implementerat några
molnteknologier och har därigenom flera (och mera kostnadskrävande)
begränsningar än andra.
Vem märker behovet och när?
Detta bör leverantören ta på sig att förutspå via trender i
övervakningsstatistiken.
Resursutnyttjande
Viktigt att kunna ta del av statistik över resursutnyttjandet och att leverantören
också håller ett öga på den. Se även övervakning.
Kostnad?
Vem står för det? Rekommendation är att kräva prissättning i förväg efter en
variabel som är begriplig för kunden, t.ex. fast pris per användare.
Fasta priser?
Se upp med variabla priser baserat på variabler som är obegripliga. Kräv tydliga
prislistor.
Sida 20
5.3.2 Integrationer
De flesta applikationer kräver integration med andra för att få en effektiv verksamhetsmiljö. Hur fungerar det i en molnmiljö?
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Kan jag integrera med andra applikationer på andra
ställen?
Integrationer kan vara dyra att få till eller kanske t.o.m. helt ogenomförbara
med mindre än att samma leverantör även tar hand om de andra systemen.
Integrera med andra tjänste- eller molnleverantörer?
Tillse att molnleverantören har den nödvändiga kompetensen och
erfarenheten samt att det är ett standardtillägg, annars kan det bli oerhört
kostsamt att sätta upp och inte minst att underhålla.
Hur fördelas ansvaret mellan olika aktuella
molnleverantörer?
Vem tar ansvaret när det inte fungerar mellan två olika leverantörer? Viktigt
att reglera detta i avtal före signering.
Hur hanteras felsituationer?
Är det ens möjligt för kunden att felsöka? Viktigt att ansvarsfrågan är utredd
och vem som ansvarar för felsökningen innan det händer.
Säkerhet?
Vissa integrationer ställer stora krav på säkerhet (t.ex. personuppgifter och
ekonomiska transaktioner). Erbjuds möjlighet till krypterade och signerade
överföringar? För full säkerhet skall den avlämnande applikationen kryptera
och signera informationen innan den hamnar i ett filsystem för överföring samt
dekrypteras och sigillkontrolleras inne i den mottagande applikationen.
Kostnad?
Fasta priser eller per timme. Se särskilt upp med felsökning som kan bli dyrbar.
SLA?
Vem tar ansvar och ser till att t.ex. löneutbetalningar (och andra betalningar)
kommer iväg i tid?
Sida 21
5.3.3 Kompetens
Var finns kompetensen om min applikation? Är det tillräckligt bra?
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Är all kompetens spridd på flera personer?
Mycket vanligt problem även hos riktigt stora leverantörer är att viss
specialkompetens endast finns hos en person, vad händer då när den personen
är sjuk och man råkar ut för en störning? Ta denna fråga på allvar, många av de
allra mest omskrivna och dyrbara störningarna har sin grund i denna
problemställning.
Underleverantörer?
Om leverantören är beroende av underkonsulter så kanske de inte finns
tillgängliga när de behövs. Bäst är om leverantören är självförsörjande på
kompetens. Observera att en av underleverantörerna kan vara min egen
organisation, kan vi leva upp till kompetens- och tillgänglighetskraven?
Sida 22
5.4 Säkerhet
I samband med en molntjänstetablering så flyttas hantering av säkerhetsfrågor över från min egen organisation till molnleverantörens. Ansvaret för
säkerheten flyttas däremot inte. Kan molntjänstleverantören klara de krav min organisation har? Det är viktigt att köparen har klart för sig vilka krav han
måste ställa.
5.4.1 Backup
Hantering av backup är givetvis väsentlig för att överhuvud taget kunna säkra driften.
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Hur ofta tas backup?
Komplett backup skall tas minst en gång per dygn, för snabbrörligt data gärna
oftare (timme).
Var lagras den?
Om backuperna inte flyttas från driftstället omgående så riskerar även de att
brinna upp vid en eldsvåda eller skadas av ett elfel.
Är den krypterad?
Viktigt att data är krypterade så att de inte riskerar att exponeras bakvägen via
backuperna.
Multipla kopior?
Backupband och diskar kan skadas, multipla kopior är ett krav.
Är det enkelt att få till stånd en restore?
Den vanligaste orsaken till att man behöver återställa en backup är inte ”den
stora katastrofen” utan att man som användare råkat radera lite mera än man
hade tänkt sig. Det är då viktigt att snabbt kunna få till stånd en återläsning.
Kräv att leverantören har en teknisk lösning som möjliggör det och en
tillhörande rutin.
Sida 23
Återläsningstester?
Det är mycket vanligt att backuper är skadade eller ofullständiga när man
behöver dem, enda sättet att försäkra sig mot detta är att regelbundet utföra
återläsningstester. Kräv att leverantören gör detta regelbundet och helst utan
att din egen organisation behöver blandas in.
Hur länge finns backuperna kvar?
Det finns lagkrav på att vissa backuper finns kvar under lång tid.
Bokföringslagen kräver 10 år. Inom läkmedelsindustrin krävs 40 år för vissa
data.
Vad händer med backuperna om jag byter
driftställe/leverantör?
Finns det någon rutin för hur de kan bevaras och i framtiden återställas vid
behov alternativt flyttas till det nya driftstället. Kostnad?
Kostnad för backup:er?
Många leverantörer tar extra betalt för backuper, så se till att detta ingår i
avtalet (till fast pris).
SLA?
Det viktigaste är egentligen att leverantören kan svara på: hur lång tid tar det
att få tillbaka funktionen i applikationen, dess data och hur mycket data har
gått förlorad (tiden mellan senaste backup och ”kraschen”)?
Sida 24
5.4.2 Dataintegritet
Att på olika sätt säkra sin information - på samma sätt i en molnmiljö som i min egen lokala miljö är ett måste. Hur görs det i molnmiljön?
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Är mitt data säkert (lagrat och transport)?
Leverantören skall beskriva hur det skyddas inom dessa områden:




Åtkomst
Manipulation
Förlust
Spårbarhet (av förändringar)
Vem har tillgång till mitt data?
Risken att någon av totalt 10 administratörer hos en mindre leverantör i
närområdet skall göra något dumt är avsevärt lägre än att en av tusentals
administratörer hos en leverantör i fjärran land gör det.
Var finns mitt data?
Det finns regulatoriska och juridiska krav på att vissa data bara får lagras i vissa
länder. Säkerställ att dessa krav uppfylls. Problem kan också uppstå när
lagstiftningen i det land där driftstället finns kolliderar med svensk lagstiftning.
Kan jag skriva personliga sekretessförbindelser med de
personer som hanterar mitt data?
Den som personligen har skrivit under ett sekretessavtal med en utpekad kund
är givetvis mera försiktig.
Vad finns det för övervakning av priviligierade konton?
Administratörers konton skall vara personliga och alla händelser loggas samt i
möjligaste mån minimeras till antalet. Observera att detta även bör omfatta
mina egna administratörskonton.
Revision?
Tillåter leverantören en revision? Är det ens möjligt att, till en rimlig kostnad,
revidera en större leverantörs driftcenter för en mindre kunds räkning? Alla
data/funktioner är givetvis inte lika revisionskritiska, undersök också lagkrav.
Sida 25
5.4.3 Stöd för ”User provisioning” resp. SSO (Single Sign On)
Administration av användare måste kunna skötas smidigt och snabbt och det är värdefullt att slippa göra ”onödiga” inloggningar.
FRÅGESTÄLLNING(AR)
FÖRSLAG TILL ANSATS
Hur hanteras uppläggning och underhåll av användare?
Måste vara enkelt och snabbt. Vem lägger upp och administrerar
identitetsinformation, leverantören eller kunden? Kan man om leverantören
gör det leverera en (elektroniskt läsbar) lista för uppläggning?
Katalogtjänstintegration?
Det är värt mycket om man slipper lägga upp och underhålla användaruppgifter
på flera ställen. Vad för standard stöds? Behöver kunden göra en speciell
lösning på sin sida för att integrera?
Måste min personal lära sig en ny inloggning och ett nytt
lösenord för varje ny tjänst som köps?
Det går i praktiken inte att kräva att användarna skall minnas många olika
inloggningar och underhåll av lösenord. Kräv någon form av Single Sign On.
Standarder?
Se till att lösningar för användarinformation (user provisioning) och inloggning
är baserade på standarder så att de kan samexistera med andra system utan
att man skall behöva uppfinna hjulet på nytt varje gång (dyrt) .
SAML 2.0 och federation?
Den standard som vinner allt mera terräng i dagsläget och som
rekommenderas både av svenska staten och EU.
Säkerhet?
Begär att leverantören redovisar hur säkerheten upprätthålls. Ta hjälp av
expertis vid eventuella tveksamheter.
Flerfaktorsautenticering?
Viktigt med möjlighet till ”bankdosa”/smart card/engångslösen vid
inloggningen när personuppgifter, sekretessbelagda och/eller ekonomiska data
hanteras.
Sida 26
Åtkomst för system management?
Hur säkerställer man identiteten på den/de hos kunden som administrerar
systemet och loggar vad som görs? Ofta en bortglömd säkerhetsrisk.
Flerfaktorsinloggning bör stödjas.
Sida 27
6 Källor
Huvudsakligen information från marknadens större molnleverantörer ställd mot egen erfarenhet av
hur en tjänsteleverans kan och bör gå till.
7 Frågor och förslag till förbättringar
Om du har några frågor eller förslag till förbättringar är du välkommen att kontakta någon av nedan:




Bengt Höjer – [email protected]
Göran Lustig – [email protected]
Staffan Hagnell – [email protected]
Stefan Görling – [email protected]
Sida 28