De fleste infrastrukturprojekter starter ikke med en plan. De starter med en fornemmelse. Noget kører langsommere end det burde, en server nærmer sig et sted mellem ”den holder nok” og ”den holder ikke”, og ingen kan helt svare på, hvad der egentlig sker, hvis den står stille en mandag morgen. Så indkalder ledelsen til et møde om budgettet, og samtalen bliver hurtigt teknisk, uden at nogen har det fulde overblik.
Det er præcis den situation, en IT infrastrukturanalyse er lavet til at komme foran. Ikke som en teknisk rapport, der ender i en mappe, men som et beslutningsgrundlag: hvad har vi, hvad er kritisk, hvor er risikoen størst, og hvad bør vi gøre først. Denne artikel gennemgår de otte områder analysen bør dække, hvordan du bruger resultatet, og hvor de typiske analyser går galt.
En IT infrastrukturanalyse er en struktureret gennemgang af de systemer, forbindelser, enheder og processer, virksomheden er afhængig af for at fungere. Den kortlægger både det tekniske og det organisatoriske: hvilke løsninger findes hvor, hvem har ansvaret, hvordan hænger de sammen, og hvor er der huller.
Det lyder banalt, men i praksis er det sjældent trivielt. Infrastruktur vokser lag på lag over år. Nye behov bliver løst enkeltvis, ofte under tidspres. Leverandører skifter. Medarbejdere skifter. Og til sidst ligger en stor del af den reelle viden om miljøet spredt i hoveder, mailtråde og dokumenter, ingen har opdateret siden sidste udskiftning.
Analysen adskiller sig fra almindelig fejlfinding ved sit formål. Fejlfinding svarer på ”hvorfor virker det ikke lige nu”. Analysen svarer på ”hvor sårbare er vi, og hvad skal vi prioritere”. Det er to forskellige spørgsmål, og de kræver to forskellige tilgange. Du kan læse mere om, hvordan de enkelte dele hænger sammen, på vores side om it infrastruktur.
Der er en praktisk grund til at starte med overblik frem for indkøb: det er svært at prissætte en løsning på et problem, man ikke har afgrænset. Uden analyse bliver beslutningerne typisk truffet ud fra det, der larmer mest – og det, der larmer, er ikke altid det, der udgør den største risiko.
Vi ser det ofte i to varianter. Den ene er overinvestering: virksomheden køber kapacitet, licenser eller udstyr, den ikke har behov for, fordi et enkelt symptom blev tolket som et strukturelt problem. Den anden er underinvestering: man løser det synlige og lader det usynlige ligge, indtil en backup viser sig ikke at kunne gendannes, eller en gammel integration bliver den flaskehals, der stopper hele driften.
Analysen giver også noget, der er svært at opnå på anden vis: et fælles sprog mellem it og ledelse. Når risici, afhængigheder og gendannelsestider står beskrevet i klartekst, bliver det muligt at tage stilling til dem på ledelsesniveau – uden at direktionen skal forholde sig til tekniske detaljer. Det gør it-risikovurdering til en beslutning i stedet for en mavefornemmelse.
Rækkefølgen nedenfor er ikke tilfældig. Den følger afhængighederne i miljøet, så du kortlægger fundamentet, før du vurderer det, der hviler på det.
Start med at kortlægge, hvad der faktisk kører, og hvad det afhænger af. Hvilke applikationer er forretningskritiske? Hvilke servere, databaser og integrationer skal være oppe, for at de fungerer? Hvor er der enkeltpunkter, hvor et enkelt nedbrud stopper flere processer?
Det er her, de fleste bliver overraskede. Ikke over antallet af systemer, men over antallet af skjulte afhængigheder – en gammel filshare et regnskabssystem trækker på, en scheduleret opgave på en enkelt maskine, en integration bygget af en medarbejder, der ikke længere er ansat.
Konkret bør du kunne svare på: hvilke tre systemer koster mest, hvis de står stille i en arbejdsdag, og hvad afhænger de hver især af?
Netværket bærer alt det andet, så det bør vurderes tidligt. Se på kapacitet i forhold til reelt forbrug, trådløs dækning på de steder, hvor der faktisk arbejdes, redundans på de forbindelser, der er kritiske, og segmentering mellem områder, der ikke behøver at kunne tale sammen.
Segmentering er et af de områder, hvor små indsatser giver stor effekt. Hvis produktionsudstyr, gæstenetværk og administrative systemer ligger i samme flade netværk, betaler du en risikopræmie, du sandsynligvis ikke har taget stilling til. Vurderingen af det fysiske lag hører også med – switche, firewalls og access points har en levetid, og netværksudstyr uden for support er en risiko, ikke en besparelse.
Mange sikkerhedsproblemer opstår ikke, fordi teknologien mangler, men fordi adgange er uklare. Gennemgå derfor, hvem der har adgang til hvad, hvordan adgangen bliver tildelt og fjernet, og hvor mange konti der har rettigheder, de ikke længere har brug for.
Tjek særligt tre ting: er multifaktorgodkendelse slået til overalt, hvor det er muligt, findes der delte konti uden klart ejerskab, og bliver adgange faktisk lukket, når en medarbejder stopper. Vores gennemgang af bedste praksis for adgangsstyring går dybere i de enkelte mekanismer.
Herefter kan du vurdere, om de enkelte arbejdsbelastninger ligger, hvor de giver mest mening. Nogle applikationer fungerer bedst i public cloud. Andre bør ligge lokalt eller hostet af hensyn til performance, integrationer eller datakrav.
Analysen skal ikke afgøre spørgsmålet på forhånd. Den skal skabe grundlaget for at afgøre det per system: hvad koster det at drifte hvor, hvilke integrationer trækker det med sig, og hvad er konsekvensen ved flytning. For mange bliver svaret en hybrid cloud-model, men kun hvis den er planlagt – ellers flytter man blot kompleksiteten fra ét sted til et andet.
Husk levetid. Hardware over fem til syv år, styresystemer uden sikkerhedsopdateringer og applikationer, der kun kører på gamle platforme, er alle poster, der bør stå i analysen med en dato.
Det vigtigste spørgsmål her er ikke, om der findes en backup. Det er, hvor lang tid det tager at komme tilbage i drift, og hvor meget data man i praksis mister undervejs.
Gennemgå derfor tre ting: hvad er dækket, hvornår er gendannelsen sidst testet, og matcher den faktiske gendannelsestid det, forretningen kan holde til. Der er ofte et gab mellem den forventede og den reelle tid, og gabet bliver først synligt i en situation, hvor ingen har tid til at opdage det. Vores tilgang til it backup og disaster recovery bygger på, at gendannelse skal være testet, ikke antaget.
Uensartet patching er en af de mest almindelige og mest undervurderede sårbarheder. Kortlæg, hvilke enheder og systemer der bliver opdateret automatisk, hvilke der kræver manuel håndtering, og hvilke der bevidst er sat på pause – og hvorfor.
Samtidig bør analysen gøre den tekniske gæld synlig. Altså de steder, hvor en midlertidig løsning er blevet permanent, hvor dokumentationen mangler, eller hvor en opgradering er blevet udskudt så længe, at den nu er blevet et projekt i sig selv. Gæld er ikke i sig selv et problem. Uoverskuelig gæld er.
En infrastruktur, der kun giver besked, når noget er gået ned, er reaktiv af design. Vurdér derfor, hvad der overvåges, hvem der får beskeden, og hvad der sker bagefter.
Se på både teknisk og sikkerhedsmæssig overvågning. Bliver kapacitetsproblemer opdaget, før de bliver driftsstop? Bliver mistænkelige logins bemærket? Findes der en aftalt proces for, hvem der gør hvad ved en hændelse, og er den skrevet ned et sted, folk kan finde den under pres? Den del hænger tæt sammen med det bredere arbejde med it sikkerhed.
Til sidst det område, der oftest bliver sprunget over, fordi det ikke er teknisk. Hvem ejer hvilke systemer? Hvad er dokumenteret, og hvor ligger dokumentationen? Hvor mange kritiske processer kan kun håndteres af én person?
Personafhængighed er en driftsrisiko på samme måde som en gammel server. Forskellen er, at den ikke står i noget inventar. En god analyse gør den synlig – og gør det muligt at reducere den, før en ferie, en sygemelding eller en opsigelse gør det for dig.
En analyse har kun værdi, hvis den fører til prioritering. Derfor bør resultatet ikke være en liste over alt, der kunne forbedres, men en sortering.
En brugbar tilgang er at placere fundene i tre grupper. Det, der udgør en akut risiko og bør håndteres nu – typisk manglende gendannelse, kritiske sårbarheder eller udstyr uden support. Det, der bør planlægges inden for et budgetår, fordi det ellers udvikler sig til akut. Og det, der er reelle forbedringer, men kan afvente, uden at risikoen stiger.
Til hvert punkt hører tre oplysninger: konsekvensen hvis intet sker, den omtrentlige indsats, og hvem der har ansvaret. Uden dem bliver analysen en ønskeseddel. Med dem bliver den en plan, der kan lægges frem for en ledelse og blive besluttet.
Det er også her, det giver mening at koble analysen til driften. Hvis de samme fund optræder ved næste gennemgang, er problemet sjældent teknisk – det er en proces, der mangler. Stabil it drift handler i høj grad om, at fundene fra én analyse bliver til faste rutiner frem for gentagne opdagelser.
Den første er at gøre analysen til en inventarliste. Et regneark med serienumre er ikke et beslutningsgrundlag. Uden en vurdering af kritikalitet og konsekvens er der ingen retning i tallene.
Den anden er at gennemføre analysen uden at inddrage dem, der bruger systemerne. Meget af den vigtigste information om, hvor infrastrukturen faktisk halter, findes hos de medarbejdere, der arbejder omkring problemerne hver dag. Deres workarounds er data.
Den tredje er at lade analysen stå alene. En gennemgang, der ikke bliver fulgt op af beslutninger, skaber sjældent andet end en bekræftelse af, at man burde gøre noget. Aftal derfor på forhånd, hvad der sker med resultatet, og hvem der tager det videre.
Den fjerde er timing. Mange venter, indtil noget er gået galt. Men analysen er lettest at gennemføre og mest værd, når der er ro – ikke midt i en hændelse, hvor alle ressourcer går til at genoprette driften.
Det kan udmærket gøres internt, hvis kompetencerne og tiden er der. Fordelen er, at ingen kender miljøet bedre. Ulempen er den samme: det er svært at se de vaner og kompromiser, man selv har været med til at træffe.
En ekstern gennemgang bidrager typisk med to ting. Et sammenligningsgrundlag på tværs af mange virksomheder, som gør det lettere at skelne mellem det, der haster, og det, der bare larmer. Og en dokumenteret metode, så analysen kan gentages og sammenlignes over tid i stedet for at starte forfra.
For virksomheder, hvor ansvaret er fordelt mellem interne ressourcer og flere leverandører, er der en tredje fordel: analysen bliver det sted, hvor snitfladerne bliver skrevet ned. Det gælder også, hvis I overvejer at flytte dele af driften – så bør analysen ligge før beslutningen om it outsourcing, ikke efter. En it konsulent kan hjælpe med at omsætte fundene til anbefalinger, der kan prissættes.
En IT infrastrukturanalyse er sjældent det mest spændende punkt på et budget. Til gengæld er den ofte det, der afgør, om resten af budgettet bliver brugt rigtigt. Den fjerner ikke risikoen, men den flytter den fra noget, man håber på, til noget, man har taget stilling til.
Hvis du er i tvivl om, hvor din virksomhed står, er den letteste vej frem en samtale om, hvad der er kritisk hos jer. Vi hjælper virksomheder i hele Danmark med at få overblik over deres it infrastruktur, inden der bliver truffet beslutninger om investeringer – og vi starter altid med analysen, aldrig med produktet.
Book et uforpligtende intro-møde
Det afhænger af miljøets størrelse og af, hvor godt det er dokumenteret i forvejen. For en mindre eller mellemstor virksomhed med et overskueligt setup kan selve gennemgangen typisk gennemføres over nogle uger, hvor hovedparten af tiden går til at samle information og tale med de rette personer – ikke til teknisk scanning.
Så meget eksisterende dokumentation som muligt: leverandøraftaler, netværkstegninger, licensoversigter og eventuelle tidligere gennemgange. Lige så vigtigt er adgang til de personer, der kender systemerne i praksis. Manglende dokumentation er i øvrigt ikke en grund til at udskyde – det er et af de fund, analysen skal afdække.
En fuld gennemgang årligt er for de fleste et fornuftigt udgangspunkt, med en kortere opfølgning ved større ændringer: nye lokationer, opkøb, systemskift eller skift af leverandør. Værdien stiger, når analyserne kan sammenlignes, fordi man så kan se udviklingen frem for kun et øjebliksbillede.
Nej. En it-revision kontrollerer typisk, om fastlagte kontroller og krav bliver efterlevet, ofte med et compliance- eller regnskabsmæssigt formål. Analysen her er bredere og fremadrettet: den vurderer driftsrisiko, kapacitet, sårbarheder og prioritering. De to kan understøtte hinanden, men de svarer på forskellige spørgsmål.
Prisen afhænger af omfang og af, hvor mange systemer og lokationer der skal gennemgås. Kontakt os for en konkret vurdering ud fra jeres setup.
Ny partner? Start her