Et grønt dashboard er ikke en frisk tjeneste

Et overvåkingspanel kan vise grønt for server, database og nettside samtidig som en kunde ikke får fullført det vedkommende kom for. Det er ikke nødvendigvis en feil i panelet. Det kan være en feil i spørsmålet vi ber det svare på.

Min påstand er at mange virksomheter overvåker det som er enkelt å måle, og kaller summen «tjenesten fungerer». Men kunden kjøper ikke en server som svarer. Kunden forventer at bestillingen blir mottatt, bekreftelsen kommer fram, og neste steg faktisk skjer.

Grønt for delene, rødt for helheten

Tenk deg en hypotetisk bestillingsflyt. Nettsiden åpnes. Skjemaet gir en kvittering. Databasen svarer. Likevel har integrasjonen som skal sende bestillingen videre sluttet å gjøre jobben sin. Ingen feilmelding vises for kunden. En teknisk kontroll som bare spør om nettsiden er tilgjengelig, vil fortsatt svare ja.

Dette er ikke et påstått kundetilfelle. Det er en måte å teste hva «tilgjengelig» faktisk betyr. En side som laster, en e-posttjeneste som tar imot en melding, og en automatisering som starter, er tre forskjellige observasjoner. Ingen av dem beviser alene at sluttresultatet er levert.

Google beskriver i sin SRE-veiledning om overvåking forskjellen mellom symptomorientert kontroll utenfra og innsyn i interne komponenter. Den ene kan vise at brukeren opplever en feil; den andre hjelper med å finne hvorfor. Det er en nyttig faglig modell også for mindre virksomheter, selv om de ikke driver systemer i Googles skala.

Begynn med løftet til kunden

Før et nytt dashboard kjøpes inn, ville jeg skrevet ned tre setninger:

1. Hva prøver brukeren å få gjort?
2. Hva må ha skjedd før vi kan si at oppgaven er fullført?
3. Hvordan oppdager vi at den ikke ble fullført, uten å vente på en sint henvendelse?

For et kontaktskjema er ikke «HTTP 200» nok. En test må også kunne bekrefte at en testhenvendelse havner der den skal, uten å bruke ekte kundeopplysninger. For en nettbutikk er ikke bare forsiden målet; en trygg test av handleflyten og en kontroll av faktiske ordrehendelser kan gi et mer relevant bilde. Testene må utformes slik at de ikke lager reelle ordrer, sender unødvendig e-post eller eksponerer persondata.

Poenget er ikke at enhver liten bedrift må bygge et avansert testlaboratorium. Poenget er at én kontroll av en kritisk sluttoppgave kan være mer verdifull enn et dusin grønne lamper for underliggende maskiner.

Ikke kast komponentmålingene

Et motsvar er rimelig: Man trenger fortsatt målinger for diskplass, svartid, køer og feilmeldinger. Ja. Når kundereisen feiler, må noen finne årsaken. Et signal om at en tjeneste ikke fungerer og et signal om hvorfor den ikke fungerer, har forskjellige jobber.

Derfor bør overvåkingen ha to nivåer. Først: en liten samling kontroller som svarer på om viktige oppgaver lykkes. Deretter: tekniske målinger som gjør det mulig å feilsøke. Hvis alt er snudd på hodet, kan organisasjonen bli flink til å forklare serveren og dårlig til å oppdage at kunden står fast.

Hvem tar imot signalet?

En test uten eier er bare en rapport. Bestem hvem som får varselet, når det krever handling, og hvem som kan sjekke om feilen faktisk er rettet. Ikke send alle varsler til alle. Da blir viktige hendelser lett borte i støyen.

Det samme prinsippet gjelder automatisering. Vi har tidligere skrevet om automatisering som krever manuell overvåking. Her er forskjellen: Denne kontrollen skal ikke be noen stirre på et dashboard hele dagen. Den skal si fra når et definert resultat mangler, og gi nok kontekst til at ansvarlig kan gjøre noe med det.

En enkel øvelse før neste innkjøp

Velg én viktig prosess, for eksempel bestilling, supporthenvendelse eller innlogging. Gå gjennom den som en bruker, helt til det lovede resultatet er synlig. Skriv ned hvert ledd der prosessen kan stoppe uten at noen oppdager det. Kontroller så hvilke ledd dagens overvåking faktisk dekker.

Hvis svaret er «vi ser at nettsiden er oppe», har dere lært noe konkret: Dere måler tilgjengelighet for nettsiden, ikke nødvendigvis for tjenesten. Min mening er at den forskjellen bør stå på bordet før flere verktøy og flere grønne indikatorer kjøpes inn.

Kilde

Google SRE: Monitoring Distributed Systems. Artikkelens bestillingsflyt er et hypotetisk eksempel og ikke en beskrivelse av en konkret kunde.