Formålet med dette indlæg er at anbefale kunder i hostingbranchen tilsikre leverandøren ikke kun kører ITIL processer på det papir kontrakten skrives på.

Stil krav til jeres hostingpartner:
Sørg for det konkret fremgår at kontrakten hvor ofte systemet gennemgås for fejl og hvordan man sikre et system ikke sander til, ved at have definerede kvalitetsmål for ydelsen på serveren. Der skal foreligge detaljeret beskrivelse af Capacity Management og Continual Service Improvement procedure.

Med en fortid som både senior-tekniker og driftschef i en anerkendt hostingvirksomhed, samt mange år som enten leverandør eller kunde i top10 inden for hosting i danmark, skal jeg være en af de første der lægger sig fladt ned og erkender mit medansvar. For de fleste kunder der betaler for Managed Service, ofte står tilbage med en løsning der ligger tættere på Infrastructure as a service (IaaS), efter systemet først er leveret og ibrugtaget.

Problem #1: Hovedparten af kundernes forventning til leverancer inden for hosting, står ikke mål med det de ønsker at betale – så hvor skal pengene til continual service improvement komme fra?
Problem #2: Leverandøren tør ikke bede om det beløb det koster at drive et dynamisk og frugtbart samarbejde med kunden.

ITIL hosting

En Continual Service Improvement Plan er en procedure der sikre services man køber hos leverandøren, løbende tilpasses kundes behov. En leverandør slår sig ofte på at være dynamisk, agil og skalerbar. I hverdagen sker det oftest kun på kundens opfordring, eller efter kundens installation er revideret af ekstern konsulent.

Eksempel #1
I 2017 henvendte en tidligere kunde sig personligt over Linkedin, for at få mig til at revidere deres nuværende MS-SQL løsning. En Løsning de fik leveret som en Managed Service hos en hostingpartner der slog sig på at køre på højeste klinge inden for ITIL og best-practice. Kundens oplevelse var at især at deres Navision var langsom. Ofte var det den første time om dagen der var værst, hvor selv de mest basale oprettelser eller kørsler tvang serveren i knæ. Leverandøren påstod der ikke var noget at komme efter, for der var massere af RAM, CPU og Disk kapacitet.

Efter en hurtig gennemgang af serveren viser det sig at opsætningen er 100% default. Det betyder bla.
– Autogrowth er sat til 1MB
– Temp database ligger på samme volume som OS, Data og Logfiler
– Max degree of parallelism var sat til 1, på trods af serveren havde 16 CPU cores tilgængeligt

Med under 10 minutters arbejde (ikke automatiseret) blev ydelsen i Navision hævet med over 180% – resultat = glad men uforstående kunde.

Eksempel #2
En kunde vil gerne bede mig kigge på en IIS løsning med ca. 2500 samtidige brugere i dagtimerne. Serveren løb hele tiden tør for plads, og løsningen blev mere og mere omkostningstung at holde kørende. Årsagen var IIS-logs ikke blev slettet, selv om kunden kun skulle bruge de sidste 30 dage. I stedet for at leverandøren brugte 10 minutter på at finde årsagen til det voksende behov for plads, blev kunden blodt bedt om at købe mere kapacitet. Kunden har købt en Managed Service, men hostingleverandøren skubber vedligeholdet retur på kunden. Hvorfor så opsige sin egen driftafdeling, og betale dyrt for ISO certificeret hosting efter de bedste ITIL principper?

Mit spørgsmål til jer:
– Hvordan skal de to partner kunne mødes, hvis kunden ikke ved hvad “continual service improvement” er, men leverandøren i øvrigt ikke mener kunden betaler for det og derfor ikke bringer det på banen?
– Hvordan får vi forankret ITIL i den daglige drift og ikke kun benytter det til at slå pressede driftstekniker i hovedet når de har lave udokumenterede ændringer?

Omkring hosting er min anbefaling til danske virksomheder er stadig den samme; Benyt altid en dansk hosting-leverandør, der som minimum er ISO27001 certificeret og gør kontrakten betinget af en gyldig ISAE 3402-erklæring

Flere benytter i dag cloud-hosting giganter som Amazon AWS, Google og Azure. Men samme flertal glemmer ofte at læse det der står med småt i betingelserne. Et eksempel på dette er Amazon AWS, som de fleste tror er sikker og at man som kunde overholder den EU-retsligt gældende persondataforordning – der tolker jeg betingelserne hos Amazon AWS anderledes!

Kilde: Amazon AWS betingelser
Opdateret 2017-12-08: AWS har opdateret deres betingelser. Men AWS er et amerikansk selskab, og skal derfor efterleve pågældende statslige retsplejelov, der i sidste ende diktere hvor meget slutkunden informeres og hvad der sker med data. (ie: FISC or FISA Court)

Access: We do not access or use customer content for any purpose other than as legally required and for maintaining the AWS services.

Storage: We will not move or replicate customer content outside of the customer’s chosen region(s), except as legally required and as necessary to maintain the AWS services.

Disclosure of customer content: We do not disclose customer content unless we’re required to do so to comply with the law or a valid and binding order of a governmental or regulatory body. Unless prohibited from doing so or there is clear indication of illegal conduct in connection with the use of Amazon products or services, Amazon notifies customers before disclosing customer content so they can seek protection from disclosure.

Med andre ord; Vi garantere dine data ligger sikkert hos os, der hvor du har bedt os om at placere det, indtil en domstol eller et efterretningsvæsen beder os om at udlevere det, eller vi har behov for at genskabe dine servere i et andet datacenter, hvis det du ligger i nu bryder sammen. Og vi har mulighed for at gøre det uden at informere dig.

Nyt EU rubber stamp:
Det nye tiltag kaldet “EU-US Privacy Shield” er en måde hvorpå man kan sende data fra EU til en lokation i USA, men samtidigt på papiret overholde EU’s persondataforordning – som sagt; “på papiret”. For i det sekundt data lander i USA, er det deres regler der gælder, og det kræver ikke at kunden er informeret omkring udleveringen af data. Personligt opfatter jeg det udelukkende som en skrivebordsmanøvre der skal sikre kunder stadig kan benytte services som Amazon AWS, Azure og Google.

Ikke et personligt vendetta:
Amazon AWS, Azure og Google er fantastiske services, og jeg er sikker på en stor del af fremtiden bliver baseret på ryggen af deres services, da komplexiteten i at opretholde en robust it-infrastruktur har overhalet den hastighed og de budgetter man tidligere har driftet lokale servere og services. Men det ændre ikke ved, at lovgivningen konflikter med services der er tilgængeligt i dag. Valget er derfor om man ændre eller bryde loven. Historisk set kan jeg ikke få øje på hvornår menneskeheden har været i stand til at stoppe udviklingen pga. juridiske bump på vejen… dvs. lige bortset fra Über og deleøkonomi 🙂