Andreas Bergman

Igår fick jag ett offertunderlag på ett webbsystem, ett väldigt bra underlag faktiskt, tydligt och bra. Som så många andra underlag så finns det backup kravställt, offsitebackup såklart.

Men en sak man ofta missar när man kravställer backup, det är att kravställa återställningstid och att det faktiskt går att återställa backupen. Säg att du backar 100Gb data över internet, för det mesta så skickar du ju bara förändringar vilket gör att volymen på backupkontot bara ökar, vilket blir en flaskhals sen när du ska återställa det, hur lång tid tror du att det tar att återställa 100Gb över internet? Självklart så beror det på linan, men det tar sin lilla stund oavsett.

Så, en uppmaning till alla: Kravställ att din backup ska kunna återläsas och att det finns en högsta återställningstid, du kommer att tjäna på det när du väl vill göra en återställning.

Enligt Wikipedia är Network Monitoring en del av Network Management, och det beskrivs såhär: ”The term network monitoring describes the use of a system that constantly monitors a computer network for slow or failing components and that notifies the network administrator (via email, pager or other alarms) in case of outages. It is a subset of the functions involved in network management.”

Så, vet vi nu allt vi behöver veta om Network Monitoring? Inte riktigt, det låter ganska enkelt, men det är en hel vetenskap att få det rätt. Hur vet man tex att man övervakar rätt saker? Vilka saker som ska prioriteras, och hur man ska hantera det?

Att implementera network monitoring i ett litet nätverk, med få servrar och inte så avancerad topologi är inte supersvårt, allt är hyfsat straight forward och troligen så är driftsavdelningen en till tre personer som delar på uppgifterna. Men att implementera övervakning i en miljö med ett par tusen servrar, med en stor driftsavdelning och krav på SLA-mätningar. Det är inte det enklaste och kräver en hel del tankeverksamhet. Här måste man även ta hänsyn till att plattformen som övervakar kan få prestandaproblem.

När man har några hundra övervakningspunkter, det kan vara diskutnyttjande, nätutnyttjande, och att hålla koll på att ett gäng tjänster är igång, då måste man prioritera vilka mätpunkter som är viktigast, vad är så viktigt att jag kliva upp klockan 4 på morgonen en söndag och laga det och vad kan vänta till på måndag? Att göra den priroteringen är inte enkelt, och den kan och bör skilja sig beroende på vilken dag i månaden det är, tex så bör ekonomisystemet vara prio 1 mellan den 20 och 25 varje månad, medans internetanslutningen är prio1 när det är kontorsfest.

För att göra prioriteringen är det upp till it-avdelningen eller it-ansvarige att prata med resten av verksamheten för att ta reda på hur de prioriterar, vad de behöver och när de behöver det.

Sedan för att underlätta för it-avdelningen att veta vad som är prioriterat när så kan man göra en prioriteringsmatris, där varje tjänst finns uppskriven med datum och prioritet.

Horisontellt har vi Impact, och vertikalt har vi namnen på våra mätpunkter. I rutorna har vi sedan prioriteringen. Siffrorna definieras enligt nedan:

Impact
1 – Helt nere, alla drabbade
2 – Delvis nere, de flesta drabbade
3 – Delvis nere, några få drabbade
4 – Störning, inga drabbade

Prio
1 – Inställelse 30min
2 – Inställelse 2h
3 – Inställelse 4h
4 – Inställelse nästa arbetsdag

Med den här matrisen är det enkelt att utläsa vilken prio vilken mätpunkt har vid en viss impact. Den här matrisen hade varit guld värd för de som tar emot larmen från monitoringen, de hade vetat precis vad de ska göra av ärendet och hur det ska hanteras. Själva hanteringen av ärendet definieras av processen för Event Management och Incident Management enligt ITIL, mer om det senare.