Πώς επιλέγετε όρια ειδοποίησης για να αποφύγετε την κόπωση ειδοποιήσεων και τα ψευδώς θετικά αποτελέσματα;

Question

Accepted Answer

Ο βασικός κανόνας: **ειδοποίηση για συμπτώματα, όχι αιτίες**, και **σελίδα μόνο σε αυτό που είναι δυνατό και επείγον**. Μια δυνατή ειδοποίηση που ενεργοποιείται κάθε νύχτα θα σιωπηθεί ή θα αγνοηθεί — αז το πραγματικό κίνδυνο δεν είναι μια χαμένη ειδοποίηση, είναι ένας αναισθητοποιημένος on-call που κοιμάται στη μέση του πραγματικού.

## Συμπτώματα πάνω από αιτίες

Ειδοποίηση στα **SLOs που στοχεύουν στον χρήστη** (ποσοστό σφάλματος, λανθάνουσα κατάσταση, διαθεσιμότητα), όχι σε εσωτερικές αιτίες όπως "CPU > 80%". Υψηλή CPU μπορεί να είναι αβλαβής; αυτό που σημαίνει είναι αν οι χρήστες επηρεάζονται.

```text
BAD  (cause)     CPU > 80% for 5m            → fires constantly, often no impact
GOOD (symptom)   error-rate SLO burn is fast → fires only when users hurt
```

## Ειδοποιήσεις ρυθμού καύσης πολλών παραθύρων

Ένα μόνο στατικό όριο είναι είτε πολύ ευαίσθητο είτε πολύ αργό. Αντίθετα, ειδοποίηση για το πόσο γρήγορα καίτε το **προϋπολογισμό σφάλματος**, χρησιμοποιώντας δύο παράθυρα, ώστε μια γρήγορη καύση να σελιδοποιείται αμέσως και μια αργή καύση να σελιδοποιείται μόνο αν διατηρηθεί.

```yaml
# Page: 2% of monthly budget burned in 1h AND still burning over 5m
- alert: HighErrorBudgetBurn
  expr: |
    (slo:error_ratio_1h > 14.4 * 0.001)   # fast window: catch big outages
    and
    (slo:error_ratio_5m > 14.4 * 0.001)   # short window: confirm it's still happening
  for: 2m
  labels: { severity: page }
```

Το σύντομο παράθυρο αποτρέπει τη σελιδοποίηση για ένα πρόβλημα που έχει ήδη αυτο-επιλυθεί. το μεγάλο παράθυρο αποτρέπει τη σελιδοποίηση σε ένα σύντομο τίναγμα.

## Σελίδα εναντίον εισιτηρίου εναντίον πίνακα ελέγχου

```text
PAGE       actionable + urgent  → wake a human now (SLO at risk, checkout down)
TICKET     actionable, not urgent → fix in business hours (disk 70%, cert in 20 days)
DASHBOARD  informational         → no alert, just visible (per-endpoint traffic)
```

Αν μια ειδοποίηση δεν είναι ενεργοποιήσιμη, δεν πρέπει να σελιδοποιείται — μετατρέψτε την σε εισιτήριο ή πάνελ πίνακα ελέγχου. Στη συνέχεια **ρύθμιση με την πάροδο του χρόνου**: ελέγξτε κάθε σελίδα, διαγράψτε αυτές που κανείς δεν ενήργησε.

## Γιατί έχει σημασία

Η κόπωση ειδοποιήσεων είναι κίνδυνος αξιοπιστίας, όχι μόνο ενόχληση: οι άνθρωποι φιλτράρουν διανοητικά τα δυνατά κανάλια, επομένως όσο περισσότερα ψευδώς θετικά στέλνετε, τόσο πιο πιθανό είναι ότι μια γνήσια διακοπή θα χαθεί. Ειδοποίηση για συμπτώματα με παράθυρα ρυθμού καύσης και δέσμευση της σελίδας για ενεργοποιήσιμη επείγοντα, διατηρεί κάθε σελίδα νοήματα — αυτό είναι αυτό που κρατά το on-call ανταποκρίσιμο.