Stabil IT-drift — sådan tænker jeg om det

Stabil IT-drift er ikke en feature man køber. Det er en sum af mange små valg taget over lang tid — og i min erfaring afhænger det mindre af teknologien end af hvor disciplineret man er omkring de kedelige ting.

Når jeg starter hos en ny kunde, er det første jeg gør at lytte. Hvor er det folk bliver irriterede i hverdagen? Hvor opstår der småstop som ingen har taget sig tid til at fikse, fordi "det går jo nogenlunde"? Det er typisk dér, den ustabile drift gemmer sig — ikke i de store nedbrud, men i de hundrede små pinligheder der koster tid hver dag.

Det her er ikke en lærebog i ITIL eller en gennemgang af alle de værktøjer der findes. Det er hvordan jeg tænker om driftstabilitet efter 30 år i branchen, og hvad jeg kigger efter når jeg overtager driften hos en ny kunde.

Stabil drift starter med at vide, hvad I har

Det lyder banalt, men det er sjældent på plads. Jeg møder ofte virksomheder hvor ingen kan svare på enkle spørgsmål: Hvor mange aktive Microsoft 365-licenser har vi? Hvilke servere kører hvad? Hvem har admin-rettigheder? Hvornår blev firewall'en sidst opdateret?

Hvis I ikke ved hvad I har, kan I ikke beskytte det, opdatere det eller skifte det ud når det fejler. Derfor er den første øvelse altid den samme — kortlæg systemerne, ejerne, afhængighederne. Det er kedeligt arbejde, men det er fundamentet under alt det andet.

Forskellen på reaktiv og proaktiv drift

De fleste IT-leverandører tjener penge på at reagere. Jo flere brande, jo flere fakturerbare timer. Det er en uheldig incitamentsstruktur — og det er en af grundene til at stabil drift sjældent prioriteres i de typiske aftaler.

Min tilgang er den modsatte: Jeg tjener penge på at I har det stabilt. Det betyder at jeg bruger den meste af min tid på det forebyggende, selvom det er reaktionen I oftest ser. En velpatchet server, en MFA-politik der virker, en backup der tester sig selv — alt det er usynligt for jer som kunde, og det er hele pointen.

"Min bedste driftsdag er den, hvor ingen ringer — ikke fordi de ikke har brug for hjælp, men fordi intet er gået galt."

Hvad skiller den stabile fra den ustabile drift

Når jeg overtager et IT-miljø der har været ustabilt, er det ofte de samme ting der viser sig:

Manglende overvågning

Fejl opdages af brugere før de opdages af systemerne. Det betyder at I altid er bagud — I reagerer på irritationer i stedet for at forebygge dem. Selv simple checks (er backuppen kørt i nat? Er disken ved at være fuld? Er der unormalt mange login-fejl?) løfter niveauet markant.

Ingen rytme på opdateringer

Patches bliver lagt på "når der er tid". Det er der aldrig. Resultatet er servere og pc'er der kører med kendte sårbarheder i månedsvis. Det er en af de største risici jeg ser, og en af de letteste at fikse — sæt en fast rytme, dokumentér den, hold den.

Manglende dokumentation

"Hvordan er det nu lige med printeren på 1. sal?" Hvis svaret bor i hovedet på én person, har I et problem den dag personen er syg, på ferie eller stopper. Dokumentation er kedeligt, men det er forskellen mellem en organisation der overlever en udskiftning og en der ikke gør.

Backup uden test

Mange har backup. Få har testet at den virker. En backup der ikke kan gendannes er ikke en backup — det er en falsk tryghed. Test af restore burde være lige så fast en disciplin som test af brand- og evakueringsplaner.

Det handler ikke om størrelse

Der er en udbredt forestilling om at stabil drift kun er noget for store virksomheder med dedikerede driftsteam. Det er forkert. En SMV med 20 medarbejdere har præcis samme afhængighed af IT som en stor virksomhed — bare i mindre skala. Når mailen er nede, kan ingen arbejde, uanset om I er 5 eller 500.

Det betyder ikke at I skal have ITIL-processer, NOC-vagter og en SLA-rapport på 40 sider. Det betyder at I skal have de få ting der gør forskellen: overblik, opdateringer, backup der virker, MFA på det vigtige, og en der ringer tilbage indenfor en time når noget driller.

Cloud løser det ikke automatisk

Microsoft 365 er en stærk platform. Men den giver ikke automatisk stabil drift, og den tager ikke automatisk backup af jeres data. Mange virksomheder har lullet sig selv i søvn med tanken om at "det er i skyen, så det er sikkert" — og opdager først efter første nedbrud, at shared responsibility-modellen betyder at en stor del af ansvaret stadig ligger hos jer.

Det jeg gør anderledes med cloud er det samme jeg gør med on-premise: dokumenterer det, overvåger det, sikrer det, og tester at jeg kan gendanne det. Værktøjerne er forskellige. Disciplinen er den samme.

De vigtigste skridt at tage først

Hvis I står med en ustabil drift og vil rykke noget, er der ikke ét magisk svar. Men her er de skridt der i min erfaring giver mest værdi for pengene, i den rækkefølge jeg ville tage dem:

1. Få overblik. Hvad har I, hvem ejer det, hvor afhænger det af hinanden.
2. Slå MFA til på alle administrator-konti. Det er gratis i M365 og fjerner den største enkeltrisiko.
3. Sæt en patch-rytme. Hver fjerde tirsdag, eller hvad der passer. Bare en rytme.
4. Test jeres restore. Tag en filfra backup. Få den hentet tilbage. Tag tid på det.
5. Indfør basal overvågning. Få en alarm når noget kritisk fejler — før brugerne opdager det.
6. Dokumentér det vigtigste. Ikke alt. Det vigtigste. Hvor logger man ind, hvem ringer man til, hvor ligger licenserne.

Det her er ikke raketvidenskab. Det er bare arbejde der skal gøres — og som typisk falder mellem stolene fordi det ikke er akut. Men det er præcis dér, den stabile drift bygges.