Hastevarsler krever en konkret handling
Et fiktivt tilfelle skiller gjentatte feilmeldinger fra advarsler. Færre avbrytelser alene dokumenterer ikke høyere pålitelighet.
En hastemelding bør avbryte fordi en nyttig handling trengs nå. Har alle advarsler samme prioritet, må beredskapsvakten fortsatt gjøre den egentlige vurderingen. Googles SRE-bok beskriver hvordan hyppige avbrytelser kan føre til at også relevante alarmer skumleses eller ignoreres.
10 meldinger er ikke 10 hendelser
I et konstruert tilfelle melder 4 instanser om samme feil i prosjektlisten. I tillegg kommer 6 CPU-advarsler som ikke krever umiddelbar inngripen akkurat da. Beregningen 4 + 6 = 10 teller meldinger, ikke uavhengige hendelser. Teamet utformer derfor denne fordelingen:
Signal | Vurdering i eksemplet | Planlagt meldingsvei |
|---|---|---|
4 meldinger om samme portalproblem | Felles hendelseskontekst; berørte instanser er fortsatt synlige. | 1 gruppert hastemelding. |
6 CPU-advarsler | Ingen umiddelbar inngripen nødvendig nå. | Synlig arbeidsliste uten akutt avbrytelse. |
Fordelingen er et redaksjonelt eksempel, ikke et målt driftsresultat. CPU-advarslene forsvinner ikke fra overvåkingen. Undersøkelsen følger bare en annen meldingsvei.
Færre avbrytelser krever bevart sammenheng
Alertmanager støtter gruppering og videresending til konfigurerte mottakere. Lignende alarmer blir en felles varsling, men berørte instanser må fortsatt kunne identifiseres. Et felles navn er ikke nok når ulike regioner eller ansvarlige må behandles uavhengig.
Færre hastemeldinger viser verken lavere feilandel eller raskere gjenoppretting. Skjulte advarsler eller en tapt varsling gir også beredskapsvakten færre meldinger. Kvaliteten må derfor også vurderes ut fra oversette problemer og en fungerende meldingsvei.
Når et tidlig ressurssignal haster
Anbefalingen betyr ikke alltid å vente på synlige brukerfeil. Prometheus nevner kapasitetsbegrensninger som grunn til menneskelig inngripen før et avbrudd oppstår. En nært forestående kritisk lagringsmangel eller manglende nødvendig redundans kan for eksempel gjøre rettidig handling presserende.
Vurderingen endres når utsettelse gjør betydelig skade sannsynlig og teamet som kontaktes, kan handle effektivt nå. Da hører også et tidlig ressurssignal hjemme på hasteveien. Avgjørende er hvilken konkret reaksjon som ventes, og om den kan komme i tide; kategorien CPU, applikasjon eller infrastruktur avgjør ikke alene.
Kilder
Les videre
Alle artikler
Sky og drift med ASES
Hosting, utrulling, vedlikehold og oppfølging