Hva en grønn statusindikator faktisk kontrollerer

En grønn statusindikator forteller bare så mye som kontrollen bak den. Hvis den bare spør etter forsiden, beskriver den først sidens tilgjengelighet. Det viser ikke om en bestilling lykkes.

Jeg ville derfor tydelig navngitt oppgaven ved hver viktig indikator. «Forsiden kan nås» er mer presist for en driftsbeslutning enn et generelt «Alt fungerer».

Samme butikk, to resultater

I en hypotetisk portal leveres forsiden korrekt, mens bestillingskallet feiler. Tabellen beskriver oppdiktede resultater, uten en målt ASES-hendelse.

En indikator som bare vurderer første rad, kan forbli grønn. Målingen motsier ikke seg selv: Kontrollen undersøkte ikke den andre oppgaven. Også et teknisk vellykket svar må inneholde forventet innhold.

Kontroller forretningsoppgaven målrettet

Et separat, planlagt testtilfelle ville hjulpet her: En testkonto velger et kjent produkt og følger bestillingen frem til bekreftet resultat i målsystemet. I et isolert testmiljø kan forløpet settes opp uten virkelige bestillinger.

Prøven viser først det valgte forløpet i det miljøet. Den dekker ikke automatisk hver kundegruppe, vare eller avhengighet i produksjon. Før kontrollen kjører der, må det være bestemt hvordan ekte lagerbevegelser, fakturaer og betalinger unngås. Bare merket «test» garanterer ikke dette.

Interne målinger og logger hjelper deretter med å undersøke årsaken. En tilgjengelighetsindikator forklarer ikke om feilen skyldes bestillingsapplikasjonen eller et tilkoblet system.

Alle nettsteder trenger ikke samme prøve

For en side som bare gir informasjon, kan en enkel tilgjengelighetskontroll være en nyttig begynnelse. En bestillingstest ville ikke passet der. Innsatsen bør følge de faktisk viktige funksjonene.

Noter ved et grønt signal hvilket kall, innhold og forløp som ble kontrollert. Avgjør så hvilken informasjon som mangler for en driftsbeslutning. Signalet får dermed en forståelig forbindelse til brukernes arbeid.

Kilder

• Google SRE — Monitoring Distributed Systems