Zestawy rozmówBlog

Twoja wymarzona praca? Lets Git IT.
Interaktywna platforma przygotowująca do rozmów technicznych dla nowoczesnych programistów.

XGitHub

Platforma

  • Kategorie

Zasoby

  • Blog
  • O aplikacji
  • FAQ
  • Sugestie

Prawne

  • Polityka prywatności
  • Regulamin

© 2026 LetsGit.IT. Wszelkie prawa zastrzeżone.

LetsGit.IT/Kategorie/Obserwowalność
Obserwowalnośćhard

Jak projektujesz alerty, żeby były akcjonowalne i miały mało szumu?

Tagi
#alerting#slo#oncall
Wróć do kategoriiPrzejdź do quizu

Odpowiedź

Alertuj na symptomy widoczne dla użytkownika powiązane z SLO, używaj multi-window burn-rate, a każdy alert musi mieć właściciela i runbook. Deduplikuj i kieruj alerty do właściwego zespołu.

Odpowiedź zaawansowana

Głębiej

Akcjonowalne alerty to wpływ i jasność:

  • Alertuj na burn-rate SLO, nie na każdy błąd.
  • Używaj multi-window (szybkie + wolne) dla spike’ów i trendów.
  • Zdefiniuj poziomy severity i oczekiwane reakcje.
  • Dodaj kontekst: linki do dashboardów, trace i ostatnich deployów.

Przykłady

Koncepcja burn-rate:

Jeśli burn-rate > 14x przez 5m -> page
Jeśli burn-rate > 2x przez 1h -> ticket

Typowe pułapki

  • Alertowanie tylko na CPU (objaw, nie wpływ).
  • Zbyt wiele alertów bez deduplikacji.
  • Brak runbooka, więc reakcja trwa dłużej.

Pytania uzupełniające na rozmowie

  • Jaki próg paging o 2 w nocy?
  • Jak dostrajasz alerty po incydentach?
  • Jak zapobiegasz alert fatigue?

Powiązane pytania

Obserwowalność
Jakie dashboardy są niezbędne dla krytycznego API?
#dashboards#red#slo
Obserwowalność
Czym jest SLI i jak go definiujesz?
#sli#slo#reliability
DevOps
Wyjaśnij SLI
,
SLO
,
SLA
i error budget oraz jak wpływają na releasy.
#sli#slo#sla
DevOps
Jak projektujesz alerty, żeby zmniejszyć szum i skupić się na wpływie na użytkownika?
#alerting#slo#oncall