On-call a NIP-en

A NIP-et 5 fos on-call csapat tartja eletben. Az on-call nem egy mernoki kityu; emberek elhetnek vagy nem el bele. Itt van, ahogy strukturaljuk: ki van bent, milyen budget-tel, milyen severity-vel, es milyen runbook-fegyelemmel.

A rotacio: primary + secondary, 1 hetes shift

Ot mernok, parba osztva: primary (elso a hivasok cimzettje) es secondary (15 perc mulva eszkalalt, plusz nappal review-z a primaryt). Egy hetes shift, hetfoi atadassal.

• Primary: hetente egyszer, kb. 7 hetente.
• Secondary: hetente egyszer, mas heten, kb. 5 hetente.

Ez azt jelenti, hogy egy mernok atlagosan havonta egyszer van primary on-call. Az ev nagy reszeben nem nem on-call.

A pager budget

A legfontosabb metrika: heti pager-szam.

• Cel: ≤3 pages/het primary on-callre.
• Retro trigger: ≥5 pages/het — automatikus root-cause ulest tartunk a kovetkezo hetfon.
• Sev3+ pages szombat/vasarnap: barmilyen szam → retro (a hetvegen alvas fontosabb a sebesseg-fokozatnal).

A budget nem buntetes — egy szignal arra, hogy az infrastruktura zajos. Ha rendszeresen 5+ a szam, valami architekturalis valtoztatas kell (jobb riasztasi kuszob, deduplikacio, vagy egy egesz alert szet kell szedni).

Tenyleges szamok az utolso negyedevben: median 0.7 pages/het, max 4 pages/het (egyszer, egy DB upgrade utan), 7 hetbol 9 zero-page het.

Severity szintek

Harom szint:

• Sev1 (Critical) — production-affecting outage, ugyfel felhasznalo iro vagy hiv. Pelda: a nortinia.com 500-asat dob. Reakcio: 5 percen belul. Pager hangos, secondary egyszerre kap szol.
• Sev2 (Major) — partial degradation, vagy egy non-customer-facing serviceben hiba. Pelda: a NIP UI lassu, a deploy-ok mukodnek. Reakcio: 30 percen belul. Pager rezeg, secondary 15 perc mulva eszkalal.
• Sev3 / FYI — informacios, nem szuksegszeruen on-call. Pelda: "a Postgres replikalas elmaradt 2 percet", "a backup retention 80%-on". Reakcio: kovetkezo munkanapon. Slack uzenetkent erkezik, nem pager.

A pager budget csak Sev1-2-t szamol. A Sev3 vegtelen sokat kuldhet, mert nem ebreszt fel senkit.

A runbook fegyelem

A fo szabaly: minden alert egy runbookra mutat. Kivetel nincs.

Ha egy alert tuzelne, de nincs runbook hozza, akkor:

1. Az alert nem mehet pagerre. Csak Slackbe.
2. Az on-call mernok 1 hetes hatarido alatt runbookot ir hozza, vagy:
3. Az alertet toroljuk.

A logika: ha az alert nem ele eleg fontos, hogy valakinek erdemes legyen leirni mit kell tenni, akkor nem ele eleg fontos hogy felebredjen erte. Ez a szabaly 2025 vegen lett, es azota a pager budget medianja 2.1-rol 0.7-re csokkent.

A runbook formatum:

# Alert: <alert name>

## Mit jelent
<1-2 mondat>

## Elso diagnosztikai parancs
<egy kubectl/sql/curl parancs, copy-pastolhato>

## Tipikus okok (top 3)
1. ...
2. ...
3. ...

## Eszkalalas
<mikor hivd a secondary-t, mikor a CTO-t>

Hasznos? Nem mindig. De a 80-as Pareto eleg sok esetben jol mukodik: az on-call ranez az elso diagnosztikai parancsra, a kimenetet osszehasonlitja a top 3 okkal, es legtobbszor megvan a megoldas.

A torolt alertek

Egy ev sorend toroltunk 23 alertet. Tipikus okok:

• A metrika nem ele megbizhato (false positive arany >10%).
• A problemat egy automatikus heal mar megoldja (pl. pod restart-ja).
• A problema nem actionable on-call ido alatt ("nezz utana munkaidoben").

Az alert-torles is fegyelem: nem nehez egy uj alertet hozzaadni, de az on-call lemerul, ha mindig minden bekapcsolva van.

On-call kompenzacio

• 5% fix shift bonusz (eltol fuggetlen a pagerek szama).
• Sev1 page-encent +50 EUR (eltol fuggetlen, hogy on-call vagy nem).
• Hetvege multiplikator: 1.5x mindenre.

Ez nem kell, hogy elcsabit, de fontos, hogy az on-call ne legyen ingyen munka.

Mit tanultunk

A legfontosabb szabaly: runbookok, nem hosok. Egy on-call mernoknek nem szabad rejtetten ismeretek alapjan dolgoznia. Ha valami nem dokumentalt, akkor valaki holnap nem fogja tudni kezelni. Ez minden mast felulir.