Fagartikkel

Slik følger vi med på løsningene vi leverer

Å levere en løsning er én ting. Å vite at den fortsatt virker klokken 03:40 en søndag er noe annet. Her er hvordan vi følger med på det vi har levert – fra helsesjekker i koden til fysiske statuslamper på pulten.

De fleste driftsfeil blir ikke oppdaget av et overvåkingssystem. De blir oppdaget av en bruker som ikke får logget inn, en saksbehandler som savner filen fra nattens overføring, eller en kunde som ringer og spør om noe er galt. Da har feilen som regel stått en stund.

Vi har brukt mange år på å snu den rekkefølgen. Målet er enkelt: en feil på løsningene vi leverer skal oppdages hos oss – og helst være under arbeid – før noen hos deg merker den.

Illustrasjon: helsefunksjonen som ett samlet knutepunkt, med hver underliggende sjekk som en egen node - to grønne, én med avvik

Overvåking begynner i koden

Overvåking som settes på i etterkant fanger bare det åpenbare: at serveren svarer, at nettsiden laster. Det som faktisk går galt i en forretningskritisk løsning er mer subtilt – en nattlig synkronisering som stoppet halvveis, en kø som vokser, en integrasjon som svarer, men med feil data.

Derfor krever vi at alle systemer vi bygger har en helsefunksjon: et endepunkt som svarer OK, Warning eller Error, med detaljene bak. Den sjekker om bakgrunnsjobbene har kjørt, når siste vellykkede synkronisering var, om databasen og integrasjonene svarer, og om det hoper seg opp ventende oppgaver i en kø.

Illustrasjon: sensorverdier over tid, der ett utslag bryter terskelen og markeres

Sensorer gjør tilstanden målbar

Loggen forteller hva som skjedde. Sensorene forteller hvordan det står til akkurat nå. I løsningene våre legger vi inn målepunkter for antall API-kall per sekund, antall påloggede brukere, antall kjørende prosesser og andre verdier som sier noe om belastning. CPU- og minnebruk hentes rett fra serveren.

Poenget er ikke å samle data for datamengdens skyld. Det er å oppdage unormale verdier før de blir til nedetid, forklare hvor ressursene går når noe føles tregt, og ha et faktagrunnlag når noe skal optimaliseres.

Illustrasjon: overvåkede objekter i baner rundt monitoringsystemet, med ulikt sjekkintervall og ett objekt i alarm

Monitoringsystemet

Selve overvåkingen gjøres av et system vi har utviklet selv, og som har vært i drift og videreutvikling i over ti år. Hvert objekt har sin egen sjekk og sitt eget intervall, slik at kritiske tjenester kontrolleres tett uten at systemene belastes unødvendig.

Sjekkene dekker mer enn nettsider: ledig diskplass, HTTP og HTTPS med forventet statuskode, FTP, vilkårlige TCP-porter, at Windows-tjenester kjører, at det kommer nye data inn i en mappe i tide, og sensorverdier innenfor definerte grenser. Objekter merket som kritiske varsler også på e-post.

Illustrasjon: stream deck der hver knapp er en oppgave eller driftsalarm, fargekodet etter hva som haster

Fra varsel til pult

Et varsel har liten verdi hvis det havner i en innboks ingen ser på. Derfor ender ikke overvåkingen vår i en e-post, men i DOPS Cockpit – vår interne arbeidsplattform, som starter når maskinen slås på og henter live status.

Cockpit binder sammen oppgavene fra utviklingssystemet, statusen på byggejobbene og alarmene fra overvåkingen, og sender dem ut på fysisk maskinvare på pulten. Fargene betyr det samme for alle: rødt og blinkende krever handling nå, gult venter på svar fra deg, blått er arbeid under utvikling.

Illustrasjon: flight panel som viser en sanntidsverdi fra en overvåket server, med utslaget på vei mot gult felt

Hvorfor fysisk maskinvare

Det er et bevisst valg. Varsler på skjerm konkurrerer med alt annet på skjermen, og et system som gir for mange varsler slutter folk å reagere på. En lampe som blinker rødt ved siden av tastaturet er vanskeligere å overse, og den krever en aktiv kvittering for å slutte å blinke.

Ved siden av decken står flight panels og viser aktiv oppgave med tid til neste sjekkpunkt, sjekklisten for det som gjøres nå, hvem på teamet som er tilgjengelig – og dashbord med sanntidsverdier fra serverne og sensorene i kundeløsningene.

Illustrasjon: tiden før en feil oppdages - uten overvåking løper den til noen melder fra, med overvåking fanges den tidlig

Hva det betyr for deg

For deg som kunde er ikke maskinvaren poenget. Poenget er tre ting: at feil oppdages tidlig, at de får en eier umiddelbart, og at alt arbeid som gjøres på løsningen din dokumenteres i de samme systemene – slik at du kan se hva som er gjort, av hvem og når.

Overvåking er også en del av hvordan vi bygger, ikke bare hvordan vi drifter. Skal en løsning kunne følges opp over tid, må helsesjekk, logging og sensorer være med fra starten. Det er billigere å bygge inn enn å ettermontere.

Vil du vite mer om hvordan vi drifter og følger opp løsninger, kan du lese om vår tekniske plattform – eller ta en uforpliktende behovsprat om hva som bør overvåkes i din løsning.


Flere saker fra Aktuelt

Råd og tips

Praktiske guider for deg som vurderer eller skal fornye en IT-løsning.

Har du et prosjekt du ønsker å diskutere?

Det kan være greit å starte med en helt uforpliktende samtale for å avklare om dette er noe vi kan se videre på i fellesskap.
Daglig leder
Richard Dawson Funke
tlf. 918 70 366
richard@dops.no
Richard Dawson Funke, daglig leder i DOPS

Kontakt oss

Alle henvendelser vil bli behandlet konfidensielt.