Otte anbefalinger til hvordan I finder jeres sweet spot for systemovervågning
Allerede når man begynder at udvikle software, og den første kode skrives, er der fokus på hele tiden at teste for fejl. Men for udvikleren stopper fokus på fejlsøgning ikke, når den færdige kode er sat i drift.
I godt it-udviklingsarbejde tager udvikleren også højde for den efterfølgende overvågning og vedligeholdelse af softwaren, så systemet kan holdes kørende, og fejl og uregelmæssigheder bliver opdaget og håndteret.
Det værste der kan ske i driftsfasen, er nemlig, at man begynder at ignorere sine alarmer, fordi systemet fejlmelder forkert og råber ’ulven kommer’ – det er virkeligt skadeligt. Alle alarmer skal man forholde sig til – eller sørge for at de ikke sker igen.
Hvordan gør man så det? Her findes ingen facitliste – i stedet handler det om at finde det sweet spot, hvor I overvåger på det rigtige niveau.
- Alarmer og fejl defineres, når man udvikler, men opgaven er ikke løst dér. Man starter med et niveau, men det skal justeres løbende i driften. Støjer man for meget med alarmer, skal man fjerne de ligegyldige, og støjer man ikke nok, må man tilføje alarmer. At forstå hvordan et system fungerer i praksis, er en iterativ proces, hvor man med tiden bliver klogere. Man skal derfor lære systemet at kende, før man for alvor ved, hvad der skal holdes øje med og gives alarm på – og hvad der ikke skal reageres på. Det er vigtigt at huske, når skåltalerne og fejringen af den succesfulde implementering af et nyt system er afholdt.
- Det er ikke nok at kigge efter de ’rigtige’ fejl, man skal også kigge de rigtige steder. Ellers står man i den situation, hvor man undrer sig over, hvorfor der ikke var nogen der opdagede fejlen – det burde man da havde gjort…? Men der hvor der skete en hel masse, var der ingen der kiggede – og der hvor alle kiggede, var der ikke noget at holde øje med.
- Så er der jo oplagt at tænke: Hellere for meget overvågning end for lidt – så overser vi da i det mindste ikke noget! Men bliver man vant til at se en blinkende skærm med masser af alarmer, der alligevel ikke betyder noget, så bliver man immun. Og det er farligt. Hvis en alarm blinker, og det alligevel ikke var noget, så skal den ikke stå og blinke næste gang – så skal den fjernes.
- De fejl der kommer alarm på, skal man reagere på. Der findes ikke acceptable fejl. Enten er det noget, ’nogen’ skal gøre noget ved, ellers er det ikke en fejl. Fejl skal løses og håndteres. Jeg skriver med vilje begge dele, for det er ikke nok bare at løse fejlen, den skal også håndteres: En del af løsningen er nemlig at forebygge, at fejlen sker igen. Ellers kommer du til at løse det samme problem igen og igen.
- Sørg for at skelne mellem driftsfejl og brugerfejl i stedet for bare at lade alle alarmer slå ud hos driftsfolkene. Driftsfolk skal tage sig af tekniske og driftsmæssige fejl. Skyldes en fejl derimod brugerfejl, altså at der er tale om dårlige data, så skal fejlen rapporteres på en to do-liste til de medarbejdere, der hælder data ind i systemet, og som kan rette op på det. Der er en verden til forskel på, om der mangler et hul i en firewall, og på om vi mangler data på en kunde for at kunne fuldende en proces. Der er også stor forskel på, hvem der skal håndtere det. Sørg for at de rigtige mennesker får de rigtige alarmer.
- Vær specifik, når fejl gives videre. Fortæl noget, som modtageren kan bruge til noget. Skal man have mulighed for at reagere fornuftigt på en fejl, skal man kunne forstå den fejl, man får – og ikke bare få at vide, at ’noget gik galt’. Det gælder for mennesker, og det gælder for maskiner, systemer og services.
- Tag aktiv læring af de fejl, der opstår. Ret fejlen første gang, den opstår – og vurder om den kan opstå igen. En bombe i serverrummet sker nok ikke igen, men fejl der opstår gentagne gange, kan det nok godt svare sig at se nærmere på for at rette.
Alt i alt handler overvågning og fejlhåndtering om at bruge kræfterne de rigtige steder. Brug ikke 80 % af kræfterne på 20 % af problemerne, men læg indsatsen der hvor den gør en forskel. Og husk, at både udviklere, bruger og driftsfolk spiller en aktiv i rolle at opbygge en sund kultur omkring fejlhåndtering – for alle parter bliver trætte af systemer, der fejler.