Lekcja 5 · Dzień 5

Observability i on-call

Datadog: SLI/SLO, burn rate, alert który budzi vs alert który jest śmieciem. Historia obowiązkowa: incydent, który Ty zgasiłeś albo po którym zmieniłeś system. Bez heroics — w innych JD piszą o no-blame.

SLI, SLO, error budget — bez korpo-bełkotu

SLI — mierzona rzecz. Przykład: odsetek autoryzacji z HTTP 2xx w < 200 ms, mierzony u bramy, nie w logu aplikacji (ten kłamie przy timeoutach).
SLO — cel na oknie (30 dni). Np. 99.9% = 43 minuty niedostępności miesięcznie. 99.99% = 4 minuty. Nie stawiaj 99.99 na CI.
Error budget — 100% − SLO. Pali się przy incydentach i przy topornych deployach. Gdy budżet spalony: freeze feature, tylko reliability.

JD mówi: SLO są częścią definition of done. Serwis bez SLI nie jest „wdrożony”.

Burn rate — dlaczego to lepsze niż „CPU > 80% przez 5 min”

Google SRE / Datadog: alert na to, jak szybko spalasz error budget, nie na surowy próg.

Szybki burn (np. 14× na 1h + 2× na 5 min, multi-window) — budź człowieka. Coś umarło.
Wolny burn (np. 2× na 6h) — ticket w godzinach pracy. Degradacja, nie pożar.
Nie budź na: dysk 70%, pojedynczy 5xx, restart poda, GitHub Actions yellow, „lambda duration p99 wzrosło o 10 ms”.

W Datadog: metric monitor na SLI, albo Burn Rate monitor na SLO. Composite, żeby nie dostać 40 pagerów z tego samego fire’a. Page idzie na serwis, nie na host.

Dwa zestawy SLO, o które zapytają

Pytanie z raportu: jakie SLO na platformę CI i na API gateway?

Platforma CI (GitHub Actions + runners + artifact)

SLI dostępności: % jobów, które wystartowały w < 2 min od push (kolejka runnerów).
SLI świeżości: % pipeline’ów main, które skończyły się sukcesem albo jawnym fail testów — nie fail infra (OIDC, cache, disk).
SLO: np. 99% na 30 dni dla „infra CI działa”. 99.9 jest zwykle kłamstwem, bo GitHub.com sam nie daje 99.9 pod Twoją kontrolą.
Alert nocny: CI leży dla main i prod deploy. Nie: flaky test w feature branch o 2:00.

API gateway / autoryzacja kart

SLI: availability + latency (p99) na ścieżce autoryzacji. Osobno 5xx, osobno timeout do Visa/processora.
SLO: tu 99.9 albo 99.95 ma sens, bo to pieniądze. Dokładnej liczby nie zmyślaj — powiedz rząd i że skalibrujesz z error budgetem biznesu (utracony interchange vs. koszt multi-AZ wszędzie).
Alert: burn rate na tym SLI budzi. Dashboard: heatmap per partner (CaaS), żeby Commerzbank nie tonął razem z małym klientem.

Datadog w praktyce platformy

Monitory jako kod (Terraform provider datadog) — inaczej 20 zespołów nalepi 200 klikanych alertów.
Standard tagów: service, env, owner, pci. Bez tagów nie ma SLO multi-tenant.
APM: sampling. W CDE: nigdy payload z PAN. Scrubber zanim span wyjdzie z VPC.
Logi: PCI logi nie idą do tego samego indeksu co dev. Retention i dostęp — osobna rola.

On-call, który dopiero się formuje

JD: rotacja się kształtuje. To szansa: możesz ustawić zasady, zanim zgnije.

Page tylko to, co ma runbook i właściciela.
Hand-off: 15 minut, nie Slack o 17:58.
Incydent: severity, comms (status page wewnętrzny), timeline, decyzje.
Postmortem: blameless, 1–2 akcje z ownerem i datą. Nie 17 Jira-ghostów.

Pytaj ich: strony / tydzień, MTTR, co budzi w nocy (CI, Datadog noise, networking, IAM, Kafka).

Historia incydentu — bez heroics

Struktura (wypełnisz w STAR):

Objaw (pager, nie „zauważyłem w dashboardzie o 3:00 bo nie spałem”).
Impact (klienci, $ , partner).
Twój call (rollback, feature flag, scale, revoke klucza).
Co zmieniłeś w systemie: monitor, guardrail, runbook, limit. Nie: „byłem dostępny i ciężko pracowałem”.

Nie mów „Zalogowałem się na prod po SSH i ręcznie zrestartowałem. Potem było OK.” W PCI i w tej kulturze to czerwona flaga, chyba że opowiesz, jak ten break-glass zabiłeś następnym PR-em.

Ćwiczenie

Wypisz 5 alertów, które dziś masz w głowie. Przy każdym: budzić / nie budzić i dlaczego. Napisz SLO dla CI i dla API w jednym zdaniu każde. Opowiedz incydent na dyktafon, 2 minuty, potem wytnij heroics.

Oznacz tę stronę jako przerobioną