Skitser til en ny opgave for sundhedsdatanettet: Totalansvar for Support, Overvågning, Netstyring, Ansvarsopfølgning og Rapportering vedr. driften af de enheder der abonnerer på denne service, herunder en beskrivelse af en Virtuel Maskinstue. Af Version 0.1, juni 2008 Side 1/20
Resumé Den samlede it-infrastruktur, der i dag betjener brugerne i sundhedssektoren består af servere i flere lag hos flere aktører med netværksforbindelser imellem. Der er gode grunde til at det er således og mange fordele ved denne opbygning, men i en fejlsituation har ingen enkelt aktør mulighed for at overskue hvor i den lange kæde fra datakilde til bruger en evt. fejl ligger og hvad der skal gøres ved den heller ikke dem, der har it-infrastrukturen som deres arbejdsområde. Det bedste vi kan gøre for at kompensere for ulemperne ved denne kompleksitet, er at give en enkelt aktør, her kaldet SONAR, ansvaret for og midlerne til at løse den opgave, der består i at opdage, diagnosticere og igangsætte korrektionen af alle slags IT-problemer i sundhedssektoren. SONAR skal også registrere og rapportere om driftssituationen. Hvorvidt SONAR skal yde slutbruger eller blot varetage det næste led, diskuteres i oplægget. SONAR er tænkt som en service, hvor man kan tilmelde de brugere, netforbindelser, firewalls/gateways og servere man ønsker omfattet af den tilbudte, overvågning, fejlopfølgning etc. Først en lille anekdote: Da jeg læste til ingeniør på DTH for snart en del år siden, gennemførte jeg også Institut for Datatekniks flagskib af et dobbeltkursus, Maskinnær Programmering, hvor opgaven var at konstruere en komplet compiler fra bunden i assembler. For at opgaven ikke skulle være mere kompleks end den allerede var, fik vi at vide at korrekt input skulle give korrekte resultater. Alle andre situationer skulle vi ikke beskæftige os med. Denne måde at se IT-infrastruktur på, er tiden heldigvis for længst løbet fra. Alligevel kan man med en vis ret sige at medens hele flowet fra bruger til server på Sundhedsdatanettet i langt de fleste situationer fungerer rigtig godt og veldefineret, er det imidlertid mere udefineret hvordan brugeroplevelsen er, når noget ikke fungerer korrekt et sted i den komplekse infrastruktur, der samlet set betjener brugeren. Side 2/20
Det går jo godt hvad er problemet? Sundhedsdatanettet (SDN) fungerer i dag godt, men den IT-infrastruktur, der samlet set betjener brugerne er kompleks alt for kompleks til at den enkelte aktør i nettet kan overskue sammenhængen mellem fejl og årsager. Det gælder ikke kun slutbrugere, men i næsten lige så høj grad de teknikere, der har denne infrastruktur som deres arbejdsområde. Se blot disse to scenarier: Scenarie 1, hvor en bruger arbejder med et lægesystem, der laver webserviceopslag som henter sine data på en central webservice, hos f.eks. en region eller en myndighed. Scenarie 2, hvor en bruger i en region skal tilgå en central service, der er et content management system i eksemplet. Scenarie 1 Scenarie 2 Lægepraksis PC Citrix klient En bruger i en region Regionsnet A PC Citrix server Lægesystemleverandør Lægesystemapplikation Sundhedsdatanettet SDN-knudepunkt Databaseapplikation Sundhedsdatanettet (f.eks. en region) Webservicekald SDN-knudepunkt Webservice frontend (f.eks. en region) Regionsnet B Webserver Teamsite Databaseapplikation Før en brugers forespørgsel når hen til sit mål, og svaret kommer tilbage igen, har den passeret rigtigt mange stykker hardware og software undervejs. Hvis svaret ikke dukker op, eller svartiderne er alt for lange, er der altså tilsvarende mange kandidater til hvor man skal sætte ind med et forsøg på at rette fejlen. Side 3/20
Når brugeren oplever en fejl, skal hun bede om hos nogen. Denne enhed vil oftest ikke være i stand til at løse problemet, da det ligger hos en netleverandør eller måske hos udbyderen af den service brugeren forsøger at tilgå. Supportenheden skal altså henvende til nogle andre, der måske igen skal henvende sig til nogle andre osv., og når man i denne kæde endelig kommer til ham, der faktisk har i sin magt at gøre noget konkret ved problemet, skal der så kanaliseres information hele vejen tilbage til brugeren, så hun ved hvornår hun kan forvente problemet løst og om der forventes datatab etc. Ser man på denne kæde for scenarie 1, ser den nogenlunde således ud: Supporttræet i scenarie 1 i dag Lægepraksis PC Citrix klient Slutbruger Netproblem Applikationsproblem WAN-leverandør 1 Citrix server Netproblem Lægesystemapplikation Lægesystemleverandør Webservicekald Lægesystem drift Applikationsproblem Lægesystem Netproblem SDN-problem WAN-leverandør 2 Serverproblem Sundhedsdatanettet SDN-knudepunkt Netproblem Netproblem SDN- WAN-leverandør 3 Netproblem Serverproblem (f.eks. en region) Webservice frontend drift Databaseapplikation Serverproblem Tyngdepunktet omkring ansvaret for opfølgningen på brugerens problem ligger i dette eksempel hos lægesystemets, der på sin side er nødt til at bruge tid på at finde ud af om det er et netproblem eller et server-problem, og hvis det er et server-problem, skal lægesystemets til enhver tid have opdaterede kontaktlister og eskaleringsplaner for samtlige services på sundhedsdatanettet som lægesystemets brugere kan finde på at tilgå. I scenarie 2 er brugeren forbundet til det interne net hos en region. Regionens net har en sådan størrelse at man (også baseret på virkelige erfaringer) må regne med dette net som en selvstændig Side 4/20
fejlkilde ud over de fejlkilder, der er vist i scenarie 1. Supporttræet i den situation ser i dag således ud: Supporttræet i scenarie 2 i dag En bruger i en region Regionsnet A Sundhedsdatanettet PC SDN-knudepunkt Slutbruger LAN-folk FW-adm WAN-leverandør 1 SDN-drift WAN-leverandør 2 Regionens SDN- ofte i to led Regionsnet B LAN-folk FW-adm (f.eks. en region) Webserver Teamsite Databaseapplikation drift Uanset at disse to scenarier er stiliserede eksempler, er det dog meningen, at de skal illustrere, at hvis brugerne i virkelighedens verden er afhængige af tjenester og data som befinder sig uden for deres egen institution, kan det være svært for den enkelte aktør at gøre noget effektivt når der er problemer. Hvis brugeren oplever at skærmbilledet bare fryser eller ting sker meget langsomt, har hun ikke en chance for at vide hvor på den lange vej, der er et problem. Det kan være alt fra hendes egen PC over firewalls og netforbindelser til serverkomponenter i den anden ende. Hun kan ikke gøre meget andet et henvende sig til den nærmeste. Denne har imidlertid oftest det samme problem, og dette kan gentage sig i flere led. Supporten henvender sig måske til SDN-en, der i uheldige tilfælde kan have svært ved at afgøre om det er WAN-leverandøren fra SDN-knudepunktet til serviceudbyderen, eller om det er den firewall/gateway, der terminerer SDN-forbindelsen, der er død eller det er selve servicen der ikke svarer. For at finde ud af det, skal mange mennesker hos de berørte parter aktiveres og jo flere parter, der er indblandet, jo længere tid vil fejlretningsproceduren i almindelighed tage. Side 5/20
Hvad er så løsningen? Kompleksiteten er kommet for at blive. Der er mange gode og rationelle grunde til at indrette ITinfrastrukturen i sundhedssektoren sådan at data og services ikke nødvendigvis befinder sig samme sted som de brugere, der skal tilgå dem. Opgaven må så i stedet være at give brugeren en service, der er lige så god som den ville være hvis der ikke var den kompleksitet, der er beskrevet ovenfor. Oplevelsen skal være sammenlignelig med den hun ville få, hvis al den IT-infrastruktur hun benytter sig af, var under direkte kontrol af den lokale driftsorganisation. Løsningen, der foreslås i denne rapport, er simpelthen at etablere en samlet enhed (her kaldet SONAR), hvis formål er at løse denne opgave og intet andet. For at det kan være realistisk, skal enheden skal selvsagt have de tilstrækkelige midler til at løse opgaven. Hvad det vil kræve, er beskrevet i et senere afsnit. Navnet på opgaven (SONAR) kommer af de hovedoverskrifter, som den tænkes at bestå af: Support, Overvågning, Netstyring, fejl- og eskalationshåndtering (som jeg har kaldt Ansvarsstyring på forsiden af denne rapport) samt Rapportering. Navnet er ikke andet end en nem arbejdstitel, og hvis man skal drage en parallel til noget maritimt, kan den måske med lidt god vilje sammenlignes med Søværnets Operative Kommando, der heller ikke selv forlader bunkeren for at hjælpe brugere i nød, men modtager henvendelsen og finder den rigtige enhed at sende til assistance på det rigtige sted, foretager opfølgning på at det virkelig sker og sørger for tilbagemelding og rapportering. Man kunne også kalde SONAR for Den Centrale SDN- eller NOC (Network Operations Center) eller SDN-SPOC (Single Point of Contact), men disse begreber dækker ikke almindeligvis over den form for rapportering, som SONAR efter dette forslag også skal beskæftige sig med. En lidt nærmere beskrivelse af opgaverne under de fem overskrifter kunne være følgende: Support Hvis visionen skal føres helt ud i livet, skal alle brugere henvende sig om alle IT-problemer, der ikke åbenbart er af lokal natur, til SONAR. Det kan imidlertid vise sig at det i nogle tilfælde vil være mere praktisk at brugerne henvender sig til deres lokale, som så sender problemet videre til SONAR. Fordelen for brugeren hhv. den lokale er at de skal aflevere deres forespørgsel et eneste sted, også selvom problemets løsning skal findes adskillige led væk fra brugeren hhv. den lokale. Sundhedssektoren består af mange forskellige enheder af varierende størrelse og med meget forskellige forudsætninger. Nogle typer institutioner vil måske være bedst tjent med at henvende sig direkte. Et ældrecenter i en kommune har måske typisk en god og velfungerende IT- placeret centralt i kommunen, men denne funktion vil typisk være uvant og utrænet i forhold til de få henvendelser, der kommer vedr. sundhedsdatanettet som ældrecenteret måske endda selv kun har en sporadisk brug af. Når der endelig opstår et problem, vil det enkleste for brugeren i det tilfælde være at henvende sig til SONAR. Man kan sammenligne det med at hvis man har en PC, en Side 6/20
printer, et kasseapparat og en dankortterminal, vil man ringe direkte til PBS, hvis der er problemer med dankortterminalen, medens man vil ringe til IT-afdelingen, hvis der er problemer med resten af udstyret også selvom IT-afdelingen i princippet også godt kunne håndtere slutbruger af dankortterminalen. I en region, derimod, vil billedet typisk være sådan at brugen af sundhedsdatanettet er en integreret del af dagligdagen for både brugere og ere, og så vil det mest naturlige nok være at brugerne henvender sig til den lokale. Endelig kan man forestille sig en kombination hvor brugerne instrueres i at henvende sig til SONAR når den lokale har lukket. Overvågning De enheder, der er tilmeldt SONAR, skal overvåges, og denne overvågning skal være tilgængelig (også historisk) for alle brugere af sundhedsdatanettet. Hvis en server er tilmeldt SONAR, skal der ikke blot (som i dag) foretages en overvågning af at der overhovedet er netforbindelse til den (ping), men også en overvågning af de services, der udbydes. Overvågningen skal teknisk foretages på en sådan måde, at man ud fra den uden for enhver rimelig tvivl kan afgøre om servicen virker over for brugerne. Tilsvarende skal der foretages overvågning af de grupper af brugere, firewalls/gateways, netforbindelser og andre enheder, der er en del af alle de veje gennem nettet som brugerne ønsker at SONAR understøtter. Denne overvågning kan selvsagt ikke foretages uden accept og involvering af de ansvarlige parter, hvorfor der skal laves aftaler om tilmelding til SONAR for hver enkelt enhed. Mere om dette i et senere afsnit. Overvågningen danner basis for at SONAR kan reagere på problemer i infrastrukturen på eget initiativ, uden at skulle sidde og vente på at en bruger får henvendt sig. Netstyring Denne overskrift markerer at hvis man ønsker at ens firewall/gateway skal kunne overvåges af SONAR, skal man tillade en begrænset adgang til den fra SONAR. Har man så denne adgang, er det nærliggende at lade den pågældende firewall/gateway blive opdateret fra aftalesystemet. Dette vil muliggøre etablering af en heterogen netinfrastruktur, hvor to parter kan vælge at lade trafikken flyde direkte mellem sig (regionsnet) uden om det centrale SDN-knudepunkt, men stadig under kontrol af aftalesystemet. Mere om dette i et senere afsnit. Fejl- og eskalationsopfølgning (ansvarsstyring) Når der konstateres et problem med en enhed, der er tilmeldt SONAR, vil SONAR også vide hvordan fejlretning igangsættes måske ved at henvende til lokalt teknisk personale, måske ved at Side 7/20
ringe til en leverandør, bestille teknikerbesøg eller hvad der ellers er aftalt om den pågældende enhed. SONAR vil også have den opgave at få en skabt en så kvalificeret prognose for fejlretningstiden som muligt og at få den kommunikeret til brugerne, og endelig vil SONAR følge op på at fejlretningen faktisk sker og evt. fremskaffe nye prognoser. Rapportering Ideen er at SONAR i videst muligt omfang giver alle på sundhedsdatanettet indsigt i sit arbejde gennem åben adgang til overvågningsdata, henvendelser til en, statistik fordelt på servere, services, institutioner og meget andet. Det er intentionen at SONAR skal dække alle de vigtigste tjenester og infrastrukturer i sundhedssektoren, og dermed vil de statistiske data om brugen udgøre et udgangspunkt for optimering af infrastrukturen som vi ikke har i dag. Side 8/20
Supportstrukturen med SONAR Ser man nu på scenarie 1 og 2 ovenfor, og prøver at forestille sig at vi havde SONAR, vil strukturen se noget enklere ud: Supporttræet i scenarie 1 med slutbruger Lægepraksis PC Citrix klient Slutbruger WAN-leverandør 1 Citrix server Lægesystemapplikation Lægesystemleverandør Webservicekald Lægesystem drift Lægesystem SONAR WAN-leverandør 2 Sundhedsdatanettet SDN-knudepunkt SDN-drift WAN-leverandør 3 (f.eks. en region) Webservice frontend drift Databaseapplikation Nu er det umiddelbare ansvar for at løse brugerens problem entydigt placeret hos SONAR, og alle aktører bliver kontaktet direkte af SONAR, hvilket har den fordel at hele forløbet bliver dokumenteret på en entydig måde og at rapportering tilbage til brugeren skal gå gennem færrest mulige led. Vælger man at lade den lokale varetage slutbrugeren, der det således ud: Side 9/20
Supporttræet i scenarie 1 uden slutbruger Lægepraksis PC Citrix klient Slutbruger WAN-leverandør 1 Lægesystemapplikation Lægesystemleverandør Citrix server Webservicekald Lægesystem drift Lægesystem SONAR WAN-leverandør 2 Sundhedsdatanettet SDN-knudepunkt SDN-drift WAN-leverandør 3 (f.eks. en region) Webservice frontend drift Databaseapplikation Denne fordeling er også nem at forstå for brugere og ere. For scenarie 2 er billedet lignende. Side 10/20
Supporttræet i scenarie 2 med slutbruger En bruger i en region Regionsnet A PC Slutbruger LAN-folk FW-adm Regionens WAN-leverandør 1 Sundhedsdatanettet SDN-knudepunkt SDN-drift SONAR Regionsnet B WAN-leverandør 2 LAN-folk FW-adm (f.eks. en region) Webserver Teamsite Databaseapplikation drift Med slutbruger ser billedet således ud. Her er der medtaget den kompleksitet, at en i mange regioner er todelt, således at der er lokale IT-folk (på et hospital, f.eks.) medens regionens firewall/gateway og regionsnettet ofte styres af en anden, centralt placeret gruppe. Side 11/20
Supporttræet i scenarie 2 uden slutbruger En bruger i en region Regionsnet A PC Slutbruger LAN-folk FW-adm WAN-leverandør 1 Regionens ofte i to led Sundhedsdatanettet SDN-knudepunkt SDN-drift SONAR Regionsnet B WAN-leverandør 2 LAN-folk FW-adm (f.eks. en region) Webserver Teamsite Databaseapplikation drift Hvilke midler skal SONAR så have? Det er kort berørt ovenfor, men hvis det skal være realistisk at SONAR kan løse den opgave, der er beskrevet her, skal SONAR have de nødvendige midler. Her tænkes i første gang teknisk og aftalemæssigt, men det er klart at der skal afsættes en selvstændig økonomi til sådan en funktion. Den virtuelle maskinstue Hvis vi starter i server-enden af de infrastruktur-kæder der er skitseret i scenarie 1 og 2 ovenfor, kan man sige at hvis SONAR skal kunne løfte sin opgave for en given server, skal SONAR sættes i stand til en række ting: Overvågning Servere, der skal eres via SONAR skal stille overvågningsdata til rådighed i et sådant omfang, at det i sig selv er nok til at afgøre om servicen fungerer tilfredsstillende, og i en fejlsituation skal overvågningen også være omfattende nok til at man med god sandsynlighed kan afgøre hvad der er en primære årsag til fejlen. Typiske eksempler på overvågningsdata, der løbende (f.eks. for hvert 10. minut) skal stilles til rådighed for SONAR kunne være Svartider for netforbindelse Svartider for en række forespørgsler til applikationen Side 12/20
CPU-belastningsgrad Diskfyldsningsgrader Hukommelsesudnyttelse Procesliste med hukommelsesforbrug Disktrafikmængder Logfiler fra centrale processer Antal brugerinitierede processer Dette skal så parres med oplysninger fra de driftsansvarlige for serveren om Tekniske informationer, herunder omkring adgang og aktuel konfiguration Servicemål Servicevinduer og anden planlagt vedligeholdelse Eskalationsprocedurer for forskellige fejlsituationer Vagt- og kontaktskemaer for alt involveret driftspersonale e skal også kunne bestemme hvor meget af denne information, der skal være tilgængeligt for alle brugere af sundhedsdatanettet, og hvor meget, der skal være tilgængeligt for det relevante driftspersonale. Dette fratager ikke den lokale drift deres opgaver, men skulle gerne give dem en række stordriftsfordele: Et overvågningsværktøj, der er mere avanceret end den lokale drift almindeligvis har investeret i En logning og information til brugerne baseret på faktiske målinger, som typisk også vil være mere udbygget end tilfældet er i dag. Den lokale drift kan koncentrere sig om deres speciale, nemlig at håndtere lokale enheder, medens de vil være fritaget alle opgaver med ekstern kommunikation og information, idet de kun skal kommunikere med SONAR. Sådan en central giver også de alle de fjerne brugere af en service adgang til information om problemer i tilfælde af at netforbindelsen hen til serviceudbyderen er nede. Det er en service som de lokale it-afdelinger ellers ville have vanskeligt ved at yde. Ideen med at man lader SONAR blande sig så meget i den lokale drift af servere og services uden dog at fratage de lokale it-folk deres opgaver er at få løst en opgave som ikke bliver løst i dag: At skabe en brugeroplevelse af at alle servere og services lige så godt kunne have været leveret ud fra den samme maskinstue her kaldet den virtuelle maskinstue. Når en server er med i den virtuelle maskinstue vil det være et signal til brugerne om at driften lever op til en række fælles mindstekrav og at den brugerrettede drifts foregår på en ensartet måde. Der vil selvfølgelig altid være servere og services, der ikke er tilmeldt SONAR, og skal man blive i billedet, vil de så bare endnu ikke være båret ind i den virtuelle maskinstue. Side 13/20
Support omkring firewalls/gateways Hvis SONAR skal kunne hjælpe i tilfælde af problemer med de firewalls/gateways, der befinder sig på brugerens vej fra PC til server, skal SONAR ikke nødvendigvis have kontrol over de firewalls men med en vis grad af sikkerhed være i stand til at afgøre om en given trafik faktisk kommer igennem den enkelte firewall eller ej. I de forskellige Alt efter den konkrete konfiguration kan det være forskellige typer adgang, der er nødvendige, og der skal arbejdes med at finde det rette niveau i de konkrete tilfælde, men eksempler kunne være adgang for SONAR til at Se regelsættet live Se trafikflows live Se logfiler live Se statistik live Se aktuelt forbrug af processor, hukommelse og andre ressourceforbrugsindikatorer på udstyret Foretage tcpdump på de forskellige interfaces Foretage automatiseret overvågning af udstyret Derimod er det ikke tanken at SONAR skal kunne opdatere regelsættet på en firewall. Det er fortsat den lokale sikkerhedsorganisation, der med udgangspunkt i en lokal sikkerhedspolitik, har den opgave. Senere i denne rapport foreslås en anden ændring af sundhedsdatanettet, der er helt uafhængig af om man etablerer SONAR eller ej, nemlig at åbne for muligheden af for at lave direkte forbindelser mellem parterne på Sundhedsdatanettet, men under kontrol af aftalesystemet, således at man tillader at aftalesystemet automatisk opdaterer en del af regelsættet i en firewall/gateway, der ønskes benyttet på denne måde. Men denne mulighed vil ikke give SONAR adgang til at opdatere nogen regelsæt. På ganske samme måde som for servere og services ovenfor, skal SONAR også for firewalls/gateways gives oplysninger om Tekniske informationer, herunder hvordan man opnår sikker adgang til udstyret Servicemål Servicevinduer og anden planlagt vedligeholdelse Eskalationsprocedurer for forskellige fejlsituationer Vagt- og kontaktskemaer for alt involveret driftspersonale Således at SONAR kan kontakt det personale, der faktisk har muligheden for at igangsætte en løsning i tilfælde af at der er problemer med udstyret. For at man kan sige at en service er i den virtuelle maskinstue, og således under fuld SONAR, er det også nødvendigt at den firewall/gateway, der sidder foran serveren også er tilmeldt SONAR. Firewall/gateway foran serveren er altså også en del af den virtuelle maskinstue. Support af r En mulig fejlkilde vil altid være de r, altså netværksforbindelser over geografiske afstande, som brugerens forespørgsel passerer. Side 14/20
Hvad enten der er tale om lejede kredsløb, MPLS-forbindelser eller man kører VPN-forbindelser over Internettet, vil proceduren omkring diagnosticering, fejlretning, rapportering osv. være stort set den samme. Hvis SONAR har adgang til udstyret i hver ende af forbindelsen, vil man med stor sandsynlighed kunne afgøre om et problem skyldes forbindelsen eller ej. For at kunne initiere en evt. fejlretning, skal SONAR også for r, have en række oplysninger: Tekniske informationer Lokale kontaktpersoner i hver ende Leverandøren Servicemål Kontakt- og eskalationsprocedurer Hvis n f.eks. er en MPLS-forbindelse fra punkt til punkt, vil den selvfølgelig have en entydig leverandør. Men for VPN-forbindelser over Internettet, vil situationen ikke være meget anderledes, da der jo er en entydig leverandør på den første strækning fra hver ende, og Danmark er ikke større end at der i praksis ikke vil være andre leverandører indimellem. SONAR skal altså ikke bare konstatere at Internettet er nede, men få driftsstatus på forbindelserne hos de to involverede internetudbydere. Sundhedsdatanet- fra SONAR Medens der fortsat skal være driftspersonale til at foretage fejlretninger på Sundhedsdatanettets centrale knudepunkt, skal SDN-en som vi kender den i dag, nedlægges som selvstændig enhed og flyttes ind som en del af SONAR. SONAR skal så følge op på driften af SDNknudepunktet på samme måde som SONAR skal det for alle andre dele af infrastrukturen. Information om trafikken i SDN-knudepunktet vil også kunne indgå i forbindelse med diagnosticering af problemer i alle andre dele af den samlede infrastruktur. Slutbruger I de tilfælde hvor SONAR evt. skal foretage slutbruger, skal SONAR have adgang til at: Etablere netforbindelser fra firewall/gateway og helt ind til brugerens PC Se al relevant opsætningsdokumentation for brugerens udstyr Have den lokale IT-afdeling til at installere en overvåningsagent på brugerens PC Have den lokale IT-afdeling til at installere en mulighed for adgang via fjernskrivebord til brugerens PC Kende kontaktdata, vagtskemaer mv for den lokale som SONAR skal arbejde sammen med. Kende - og eskalationsprocedurer omkring brugerens udstyr og opsætning Det kan synes eksotisk at SONAR skal tilbyde dette, men hvis ingen organisationer kan se nytten af det, vil det jo regulere sig selv. Det er imidlertid vurderingen at dette at have sådan en ydelse som supplement til den lokale, især i de tyndt besatte timer, vil kunne imødekomme et behov hos en del af de tilsluttede parter. Side 15/20
Support af LAN-forbindelser En sidste fejlkilde er de lokalnetforbindelser som brugerens forespørgsel passerer. Her er det vanskeligt at se en meningsfuld rolle for SONAR andet end at konstatere at der ser ud til at være et problem mellem slutbrugeren og den relevante firewall/gateway. Alle tilsluttede enheder bør lige som for firewalls/gateways angive Rudimentære tekniske informationer Servicemål Servicevinduer og anden planlagt vedligeholdelse Eskalationsprocedurer for forskellige fejlsituationer Vagt- og kontaktskemaer for alt involveret driftspersonale Ud fra tilbagemeldinger fra det lokale driftspersonale, kan der foretages information af brugere, registreringer af hændelser og LAN-driften kan således også indgå i rapporteringen. Indsamling, rapportering og information til brugerne For at alle parter kan have tillid til SONAR, er det meget vigtigt at der ofres ressourcer på at gøre al information tilgængelig på SONARs hjemmeside, der skal befinde sig på Sundhedsdatanettet. Blandt de faciliteter som sådan en hjemmeside skal indehold, kan nævnes: Indsamlingsmodul, hvor de parter, der tilmelder services, udstyr mv kan forsyne SONAR med alle de oplysninger, der er nævnt ovenfor. Information til brugerne (især de it-professionelle) omkring alle de indrapporterede stamdata Komplet driftstatusside for alle enheder, med alt udstyr og alle målte parametre (så vidt det giver mening) En åben log over alle driftsevents og de aktioner, der er taget på det, og resultaterne heraf En åben log over alle brugehenvendelser og deres resultater Driftsstatistik Værktøjer til selvdiagnose Vejledninger og FAQ Baseret på alle disse data, vil SONAR kunne udgive rapporter regelmæssigt om den samlede driftssituation i sektoren, og tilvejebringe andre former for ledelsesinformation, der vil kunne give et væsentligt bidrag til at optimere og udbygge den samlede infrastruktur i sundhedssektoren på en rationel og økonomisk forsvarlig måde. Budget Det vil være forkert at se SONAR som en konsolidering af alle de mange -funktioner, der findes rundt omkring i dag. SONAR løser først og fremmest en opgave, der ikke bliver løst noget sted i sektoren i dag nemlig drifts og driftsinformation rettet mod fjerne brugere af sundhedssektorens mange services. Man skal starte at investere i en opbygningsfase, hvor man anskaffer eller opbygger informationssystem, sagsbehandlingssystem og systemer til overvågning og adgang til de mange typer udstyr, der skal eres af SONAR. Side 16/20
Der skal også være en bemanding, og da en del af SONARs eksistensberettigelse netop er døgnberedskabet, vil dette i en fuldt udbygget version kræve en del medarbejdere. Hvad det præcise niveau bør være, vil afhænge af en nærmere kortlægning af behovet forud for et udbud om etablering af SONAR. Om finansieringen til SONAR skal findes ved at opkræve en takst pr. eret enhed, finansieres på samme måde som Sundhedsdatanettet eller have sin helt selvstændige bevilling, eller måske en kombination af disse kilder, falder uden for denne rapports rammer. Særlige emner og spørgsmål Ud over den overordnede præsentation af ideen om SONAR, er der en række mindre emner og spørgsmål, som finder plads i afsnittene herunder. Træder SONAR i stedet for IT-chefen eller lokal drift? Det kunne være en nærliggende tanke at give SONAR det egentlige driftsansvar for servere, firewalls osv, nu hvor SONAR kan se ud som om de har næsten alle de tekniske midler til også at løse den slags opgaver. Men det ville være helt ødelæggende for ideen og for den primære funktion af SONAR, hvis andre opgaver end de ovenfor beskrevne således blev udliciteret til SONAR. Det ville nemlig tage fokus væk fra den primære opgave med at være brugernes repræsentant overfor alle parter, og det ville også fjerne den neutralitet i forhold til alle sektorens mange parter, der er nødvendig for at SONAR kan løse sin opgave. Den lokale IT-chef har som altid ansvaret for sit udstyr og sit personale, og SONAR vil hjælpe med at diagnosticere problemer, hjælpe med informere alle brugere om status for driftsforstyrrelser og deres løsning, og i processen vil alle forløb omkring og fejlretning blive dokumenteret, så man efterfølgende kan blive klogere af dem. Findes der erfaringer med en konstruktion som SONAR? Mange koncern-it konstruktioner har en og problemhåndteringsfunktion, der minder meget om det, der her er foreslået som SONARs rolle. Men da ledelsen for denne funktion hhv. for driften er den samme, bliver de to ting i almindelighed ikke opfattet som uafhængige af hinanden, og derfor har man slået dem sammen. Sundhedssektoren adskiller sig også fra en traditionel koncern på den måde at det ikke er alle dele, der har samme topledelse, idet der er en række meget vigtige private aktører (praktiserende læger, uafhængige laboratorier, servicebureauer, apoteker m.fl.) hvis brugere og services indgår på lige fod med de offentlige. Side 17/20
Et af de projekter, der kommer nærmest tankerne om SONAR er det såkaldte Statens IT-net, der er et projekt i Økonomistyrelsen, som netop blandt sine formål har at etablere noget, der svarer til den her beskrevne virtuelle maskinstue. Det svenske sundhedsdatanet (Sjunet) har netop gennemført et udbud for at etablere en struktur, der minder meget om SONAR, om end den svenske ikke har nær de samme muligheder for at komme problemerne i forkøbet gennem proaktiv overvågning, men i udgangspunktet må vente til en bruger har opdaget et problem og har henvendt sig. Skal SONAR så opstille og drive overvågnings-bokse hos brugerne? For at kunne diagnosticere et evt. netværksproblem og dokumentere hvor problemets årsag sandsynligvis befinder sig, bliver det fra tid til anden foreslået at man skal supplere Sundhedsdatanettets drift med opstilling af fremskudte overvågnings-bokse hos brugerne. Driftsansvaret for disse stykker udstyr skulle så ligge hos Sundhedsdatanettet, og ideen bag er at give Sundhedsdatanettet en tilstedeværelse lokalt, samtidig med at ansvarsfordelingen er klar. Hvis SONAR gennemføres som det er beskrevet her, vil de tilsluttede institutioners udstyr træde i stedet for den slags overvågnings-bokse. De er selvfølgelig mere vidtgående end at installere en enkelt lille Sundhedsdatanet-boks inde på den tilsluttede institution, men det vil give en række klare fordele: Fejl på overvågningsboksen og forventelige lange ombytningstider er elimineret, da boksen ikke eksisterer Ansvarsfordelingen mellem SONAR og lokal drift er allerede afklaret Der måles på det udstyr, der virkelig transporterer brugernes trafik, og ikke fra noget udstyr på sidelinien Alle problemer lokalt også med overvågningsagenter på brugernes udstyr løses af den lokale drift. Det medfører hurtigere fejlretningstider. VPN over Internet versus dedikerede linier Den almindelige opfattelse er at dedikerede r som f.eks. MPLS-net fra punkt til punkt har en meget mere forudsigelig driftsstabilitet end VPN-forbindelser via Internettet. Ser man nærmere på den konkrete situation, er forskellen imidlertid ikke så stor som man skulle tro. Ser man nærmere på forretningsbetingelserne (det med småt i kontrakterne) fra leverandørerne af MPLS-forbindelserne, vil man opdage der ikke garanteres en bestemt båndbredde eller i det mindste kun en meget mindre båndbredde end forbindelsens nominelle kapacitet. Det er nemlig kutyme at overbooke de transmissionslinier, der bærer MPLS-forbindelserne, ligesom vi alle kender det fra vores egen ADSL-forbindelse til hjemmet, der godt nok er vores egen, men hvor den opnåelige båndbredde til tjenester lokalt i udbyderens netværk altså inden trafikken kommer ud på det vilde internet kan variere betydeligt over tid. Når to institutioner i Danmark sender data til hinanden via deres internetforbindelser, bevæger trafikken sig med meget få og eksotiske undtagelser gennem den samme slags MPLSforbindelser, der er leveret, drevet og overvåget af de samme leverandører, og befinder sig i præcis de samme kabler. Belastningen af Internet-trafik i leverandørernes transmissionsnet bliver endda Side 18/20
overvåget af operatørerne, der er parate til at gribe ind over for pludseligt opståede problemer, og som opgraderer kapaciteten i deres net løbende i takt med den jævne stigning i forbruget. Sammenligner man driftsstabilitet for internet-forbindelsen i forhold til dedikerede linier, kunne dette måske endda falde ud til internetforbindelsernes fordel: Internetudbyderne foretager overvågning af trafikmønsteret på internet-delen af deres transmissionsnet, medens en sådan overvågning helt er op til parterne selv på dedikerede linier Når en internetforbindelse til en institution er nede, vil mange brugere opdage dette med det samme. Man kan dårligt forestille sig nogen anden driftsbegivenhed, der bliver adresseret hurtigere og mere effektivt. Hvis der ikke er løbende trafik på en dedikeret linie, vil man først opdage at der er et problem, når man prøver at bruge den. Når det i stedet er institutionens internetforbindelse, der bærer trafikken, vil problemet i almindelighed være opdaget før forbindelsen skal bruges til sundhedsdatanettrafik. Når det alligevel kan være en rigtig god idé at bruge dedikerede linier frem for Internettet, er årsagen en helt anden: Transmissionen via Internettet kræver sikkerhed mod aflytning og forvanskning i form af VPN med tunneller og kryptering, som ikke er nødvendig på dedikerede linier. Denne kryptering skal ske i de routerne (eller tilsvarende udstyr) i hver ende og kræver en del processorressourcer, således at en router skal være meget kraftigere hvis den skal håndtere den samme VPN-trafik som en router, der ikke behøver at være dimensioneret til det. En god tommelfingerregel er at en router, der skal håndtere VPN med kryptering er 10 gange så dyr som en router, der skal håndtere den samme trafikmængde uden kryptering. Ydermere skaber indpakningen af VPN-trafikken i tunneller det problem at der for hver ethernetpakke som den originale trafik består af, skal påhæftes ekstra information, og at de resulterende ethernet-pakker kan blive større end den maksimalt tilladte pakkestørrelse (1500 bytes). Dette løser man så ved at sætte den maksimale pakkestørrelse (MTU) passende ned fra begge sider og/eller få den automatiske fragmentering og gensamling af ethernet-pakker til at virke. Begge dele kan imidlertid være komplekst at få til at virke, så fra et fejlsøgnings-synspunkt er en forbindelse uden tunneller og fragmentering bestemt at foretrække. Begge disse gode grunde til at vælge dedikerede forbindelser frem for VPN-forbindelser bliver mere vigtige jo større trafikmængde og jo flere brugere der er tale om i hver ende. Derfor må man forudse et de større institutioner på sundhedsdatanettet gradvis vil skifte til dedikerede linier og måske bevare VPN-forbindelsen som en backup. Direkte SDN-forbindelser uden om knudepunktet hvad er det nu? Efterhånden som flere store institutioner får dedikerede forbindelser til SDN-knudepunktet, opstår den tanke naturligt at slutte dem sammen til et åbent net mellem parterne frem for at al trafik nødvendigvis skal tvinges til at passere knudepunktet. Hvis man gerne vil bevare fordelene ved sundhedsdatanettet, altså aftalesystemet, kataloget over servere, dokumentationen af hvem, der er ansvarlig for enhver given forbindelse, den automatiske Side 19/20
etablering af nye forbindelser, så snart de er autoriserede, fejlsøgningsværktøjerne og de mange former for trafikstatistik, kan det sagtens lade sig gøre i et scenarie med et åbent net mellem parterne med faste opkoblinger. Man skal blot tillade aftalesystemet at opdatere regelsættet i institutionens egen firewall/gateway. Med dagens teknik kan dette lade sig gøre for de fleste typer anvendte firewalls/gateways. I dette scenarie vil SDN-knudepunktet så komme til at virke som en gateway til alle de institutioner, der fortsat er på nettet via VPN eller som ønsker at beholde en dedikeret forbindelse via SDNknudepunktet. Muligheden for teknisk at gøre dette vil snart være til stede, da aftalesystemet af forskellige årsager allerede er i gang med at blive videreudviklet i den retning. Opsummering Frem for at kompensere for at mange brugere i fremtiden henter flere og flere af deres data og øvrige IT-services via nettet, ved at indføre små, gradvise ændringer (som f.eks. små SDN-drevne overvågningsbokse ude hos de tilsluttede parter), er forslaget her at tage konsekvensen så fuldt ud som vi kan forestille os, og dermed signalere vilje til at skabe et hele for brugerne ud fra den meget fragmenterede it-infrastruktur som er virkeligheden i sundhedssektoren. Når konsekvensen ikke tages helt og fuldt i form af en egentlig samlet koncern-it konstruktion for sundhedssektoren, er det fordi der ikke er tale om en koncern med fælles topledelse især pga de mange vigtige private aktører i sektoren. Der er også redegjort for her i rapporten hvorfor SONAR ikke skal være en organisation, man kan udlicitere driftsopgaver til. På trods af dette kan forslaget alligevel virke vidtgående, og kan måske synes som en betydelig udgiftspost på et område hvor man endnu ikke har oplevet de helt store problemer. Men sammenligner man ressourceforbruget til SONAR med de projekter som SONAR skal være med til at bringe helt ud til brugerne på en enkel og effektiv måde, ser man at store projekter som fælles EPJ, Medicinkortet og tilsvarende først rigtigt er pengene værd når de opleves som tilgængelige og erede af de enkelte brugere. Alternativet til SONAR er derfor ikke at lade være med at lave, opfølgning osv, men at hvert af disse store projekter skal etablere sådan en. Hvis vi har ret i det, er det givetvis mere effektivt at etablere en forenet. Side 20/20