On-call pentru data engineering

Modulul 8 a construit partea operațională a rulării unei platforme de date. Orchestrare (lecția 57), gândire orientată pe assets (lecția 58), observability (lecția 59), SLO-uri (lecția 60), calitatea datelor (lecția 61), incident response (lecția 62). Fiecare dintre lecțiile alea presupune că un om poate fi contactat când ceva merge prost. Lecția asta e despre rotația care produce omul, regulile care o țin sustenabilă și munca de inginerie care determină dacă a fi on-call este o parte gestionabilă a job-ului sau lucrul care îi face pe oameni să demisioneze.

Un on-call bun este invizibil: pager-ul rar se aude, rotația e împărțită corect, hand-off-urile sunt curate, oamenii on-call dorm. Un on-call prost e coroziv: pager-ul se aude constant, aceiași doi oameni îl duc pe toți, alertele sunt ignorate din principiu, și în cele din urmă un incident real scapă pentru că echipa a fost antrenată să nu se uite.

Ce este on-call

On-call este o rotație în care o persoană (sau un grup mic) este responsabilă cu răspunsul la alerte într-o fereastră definită. Fereastra poate fi 24/7 pentru sisteme care au nevoie de acoperire non-stop, sau ore de program pentru sisteme unde rupturile peste noapte sunt acceptabile. Pentru data engineering, alertele sunt despre eșecuri de pipeline, regresii de calitate a datelor, burn de SLO, incidente de infrastructură și coada lungă de „platforma a făcut ceva neobișnuit și un om trebuie să se uite”.

Argumentul pentru existența on-call-ului este direct. Sistemele de date sunt prea importante ca să fie nesupravegheate. Un eșec de pipeline la 3 dimineața pe care nu-l repară nimeni până dimineața înseamnă că dashboard-ul de dimineață e greșit și ședința de dimineață e neinformată. O regresie de calitate a datelor care rămâne nedetectată o zi poluează tabele, modele și rapoarte downstream, iar costul curățeniei crește aproximativ liniar cu cât stat. Scopul on-call-ului nu este să prevină eșecurile; eșecurile se vor întâmpla. Scopul este să încadrezi timpul dintre eșec și atenția umană, ca raza de explozie să rămână mică.

Forma rotației variază. O echipă de patru persoane ar putea roti săptămânal. O echipă mai mare ar putea împărți rolurile primary și secondary. O echipă distribuită geografic ar putea urma soarele, ca nimeni să nu fie paged la 3 dimineața local. Rotația corectă este aceea care ține sarcina distribuită și timpii de răspuns rezonabili.

Cea mai importantă disciplină on-call poate fi enunțată într-o singură propoziție: fiecare alertă care se aude trebuie să fie acționabilă.

Acționabilă înseamnă că există ceva ce on-call-ul poate face chiar acum ca să repare sau să mitigheze problema. Reporni un job, scala un cluster, fail-over la o replică, page-ui un proprietar downstream, marca o tabelă ca învechită, rula un backfill. Ceva concret. Dacă o alertă se aude și singurul răspuns al on-call-ului este „am observat”, alerta nu e acționabilă, și nu ar trebui să paged-uiască un om la 3 dimineața.

Sună evident și e violat peste tot. Două antitipare comune:

Alerte informaționale. Cineva a conectat o metrică, a setat un prag și a îndreptat-o spre pager pentru că ăla a fost cel mai ușor loc unde să trimiți notificări. Metrica e interesantă; nu e acționabilă. Exemple: „adâncimea cozii a trecut peste 10.000”, „job-ul ăsta a durat cu 20 de minute mai mult decât de obicei”, „utilizarea disk-ului a depășit 60%”. Niciuna nu cere acțiune imediată. Aparțin unui dashboard, unui digest zilnic sau unui canal Slack pe care nimeni nu e obligat să-l citească noaptea. Pager-ul e o resursă rară.

Alerte zgomotoase. O alertă se aude des, e de obicei un fals pozitiv și e de rutină acknowledged-and-ignored. Echipa s-a antrenat să o trateze ca pe zgomot de fundal. În cele din urmă alerta se aude dintr-un motiv real, iar on-call-ul o ignoră la fel. Alerta în care nu are nimeni încredere e mai rea decât niciuna, pentru că absența unei alerte e cel puțin un semnal cinstit.

Soluția este să tratezi fiecare alertă fals-pozitivă ca pe un bug, cu trei rezoluții posibile: tunează pragul, repară instabilitatea subiacentă sau șterge alerta. Nu există a patra opțiune. A lăsa alerta să se aude și să fie ignorată este o coroziune lentă a disciplinei de răspuns a echipei.

O euristică practică: dacă o alertă s-a aude de mai mult de două ori fără să producă o acțiune, are nevoie de muncă. Fă din mentenanța alertelor o parte explicită a job-ului on-call-ului, nu o activitate de voluntariat după ore.

Escalation

On-call-ul nu poate repara totul singur. Escalation este calea documentată de la „on-call-ul primary are nevoie de ajutor” la „omul potrivit este angajat”. O structură tipică:

Primary on-call. Primul răspuns. Confirmă fiecare alertă, face triage, repară ce poate, escaladează ce nu poate.

Secondary on-call. Backup. Angajat când primary-ul nu e disponibil, e copleșit sau are nevoie de o a doua pereche de ochi.

Manager. Angajat când incidentul are impact de business care cere o decizie pe care on-call-ul n-o poate lua singur: comunicare cu clientul, escaladare la furnizor, autorizație pentru acțiuni care afectează producția.

Subject-matter expert. O persoană specifică ce cunoaște un sistem specific: cea care a construit ingestia în warehouse, cea care întreține pipeline-urile CDC. Nu e în rotație, dar e contactabilă pentru incidente care îi ating zona.

Calea de escalation trebuie documentată și testată. Documentată înseamnă că un runbook listează pe cine să suni și cum să-l contactezi, cu timpul de răspuns așteptat la fiecare nivel. Testată înseamnă că echipa rulează exerciții de incendiu, trimestrial e o cadență rezonabilă. Exercițiul scoate la suprafață numerele de telefon învechite, programele de on-call configurate greșit și SME-urile care sunt în concediu parental de trei luni fără ca cineva să fi actualizat rota. Mai bine afli asta într-un exercițiu decât la 4 dimineața în timpul unui incident real.

Hand-off

O rotație care nu face hand-off curat ascunde incidente. On-call-ul ieșind a acumulat context pe parcursul shift-ului: alerta care fluctuează, tichetul deschis pe care nu l-a închis nimeni, investigația pe jumătate, schimbarea de runbook care are nevoie de review. Dacă acel context nu se transferă, persoana intrând începe rece.

Hand-off-ul este o notă scrisă, o ședință scurtă sau ambele. Nota scrisă e mai de încredere pentru că supraviețuiește ședinței și e căutabilă mai târziu. O notă rezonabilă acoperă:

Incidente recente din shift, cu statusul curent.
Probleme deschise care s-ar putea page-ui în noaptea asta, cu motivul pentru care sunt deschise și mitigation-ul.
Alerte cunoscute ca fiind instabile, cu workaround-ul pe care l-a folosit on-call-ul ieșind.
Orice e programat pentru următorul shift: deploy-uri planificate, migrări în curs, ferestre de mentenanță.

Nota trăiește într-un loc partajat: o pagină de wiki, un document partajat, un canal pe care echipa îl citește. Nu în notițe private sau într-un DM.

Compensation

On-call este muncă reală, iar rotația întrerupe timpul personal și somnul. A pretinde altceva e cum produc echipele burnout.

Compensarea ia mai multe forme: bani în plus pe shift de on-call plătiți indiferent dacă se aude pager-ul sau nu, comp time după un shift dificil, sau ambele. Structura variază pe regiune și angajator, iar constrângerile de drept al muncii diferă pe jurisdicții: unele țări tratează on-call-ul ca timp de muncă plătit by default. Practica minim acceptabilă este ca on-call-ul să fie recunoscut ca muncă și compensat într-o anumită formă.

Ideea nu e doar corectitudinea. Compensarea e un mecanism de feedback. Dacă on-call-ul e plătit, fiecare shift cu page-uri are un cost pe care organizația îl poate vedea, iar argumentul pentru a repara alertele zgomotoase are un număr pe el. On-call-ul gratuit n-are un astfel de feedback, ceea ce e unul dintre motivele pentru care rotațiile gratuite rămân zgomotoase.

Semnale de burnout

O rotație sustenabilă produce puține semnale de stres. Una nesustenabilă produce mai multe, iar un manager atent le poate observa devreme.

Prea multe alerte pe shift. Un shift care paged-ește on-call-ul de zece ori pe noapte e o urgență. On-call-ul unei echipe de date sănătoase ar trebui să fie paged cel mult de câteva ori pe săptămână, nu pe noapte, iar multe shift-uri ar trebui să treacă fără page-uri peste noapte deloc.

Alerte în timpul familiei. Un pager care se aude consistent în timpul cinei, la weekend sau în vacanțe taxează viața on-call-ului dincolo de ce contractează rotația.

Sarcină disproporționată. O persoană care duce de două ori mai multe incidente decât celelalte indică de obicei că sistemul are un singur punct de eșec uman: un subsistem pe care îl înțelege un singur om. Soluția e documentația și transferul gradual de expertiză, nu pedepsirea persoanei care duce sarcina acum.

Reticență la rotație. Oameni care se înscriu la concediu în săptămânile lor de on-call. Oameni care cer să schimbe în mod repetat. Oameni care menționează on-call-ul în conversațiile de plecare. Până când semnalele astea sunt vizibile, situația e deja serioasă.

Job-ul managerului e să observe semnalele astea și să acționeze. Acțiunea rareori e despre rotație în sine. E despre sistemul care o conduce: care alerte se aud, de ce, și ce investiții ar face platforma mai ușor de operat. Calitatea on-call-ului e un simptom downstream al calității platformei. A repara doar simptomul nu funcționează.

Argumentul pentru mai puține alerte

Dacă on-call-ul e paged de două ori pe noapte, platforma a fost proiectată prost. Afirmația e neconfortabilă și e adevărată. Sistemele sănătoase paged-esc on-call-ul rar. Page-urile rare sunt pentru incidente reale.

Calea de la multe alerte la puține este trecerea de la alerting bazat pe prag la alerting bazat pe SLO (lecția 60). Alerting-ul bazat pe prag se aude de fiecare dată când o metrică trece o valoare, indiferent dacă trecerea contează. CPU la 80%, adâncime de coadă la 1.000, runtime de job la 30 de minute: fiecare e un număr, niciunul nu e inerent o problemă. Alerting-ul bazat pe SLO se aude când SLO-ul e în pericol: când rata de ardere a bugetului de erori peste o fereastră semnificativă sugerează că promisiunea către client se va rupe. Semnalele sunt cuplate la ce s-a angajat echipa să livreze, nu la mecanica internă a felului în care livrează.

Trecerea cere investiție. Echipa trebuie să aleagă SLO-uri care capturează ce contează. Metricile trebuie să fie de încredere și cu zgomot mic. Regulile de alerting trebuie să se audă pe ardere reală de buget, nu pe treceri cosmetice de prag. Majoritatea echipelor ajung aici gradual, retrăgând alertele de prag zgomotoase pe măsură ce le înlocuiesc cu cele bazate pe SLO mai bune.

Răsplata e un pager mai liniștit, mai cinstit. Un pager care se aude pentru ardere de SLO se aude când ceva la care echipa ține e în pericol. Încrederea dintre echipă și pager este restaurată.

Ciclul de viață al alertei

Fluxul mecanic de la o metrică în afara limitelor la un incident închis merită văzut ca o singură imagine.

flowchart LR
    M[Monitoring<br/>metrics, logs, checks]
    AM[Alert manager<br/>routing, dedup, suppression]
    P[Primary on-call<br/>pager]
    A{Acknowledge}
    T{Triage}
    R[Resolve]
    E[Escalate<br/>secondary, manager, SME]
    PIR[Post-incident review<br/>lesson 62]
    M --> AM
    AM --> P
    P --> A
    A --> T
    T --> R
    T --> E
    E --> R
    R --> PIR

Diagramă de creat: un flowchart polished al ciclului de viață al alertei. Monitoring-ul în extrema stângă alimentează alert manager-ul, care rutează către pager-ul on-call-ului primary. On-call-ul confirmă, face triage și fie rezolvă direct, fie escaladează la secondary, manager sau subject-matter expert. Resolution-ul alimentează procesul de post-incident review din lecția 62. Punctul vizual este că fiecare alertă are o buclă închisă: se termină fie în resolution, fie în hand-off către cineva care o poate rezolva.

Alert manager-ul dintre monitoring și pager face muncă reală: deduplichează, suprimă alerte în ferestre cunoscute de mentenanță, rutează categorii către oameni diferiți. O echipă fără alert manager se va îneca în cele din urmă în duplicate. Pasul de acknowledge e cum știe echipa că alerta a fost văzută, și cum oprește sistemul să re-page-uiască până când situația e gestionată.

Conexiunea cu tot restul din Modulul 8

Fiecare altă lecție din modul plătește un tribut on-call-ului. Orchestrarea (lecția 57) determină care job-uri page-uiesc când eșuează. Gândirea orientată pe assets (lecția 58) determină dacă on-call-ul vede un singur asset eșuat sau o cascadă de job-uri confuze. Observability (lecția 59) determină dacă on-call-ul găsește cauza rădăcină în cinci minute sau în cincizeci. SLO-urile (lecția 60) determină dacă pager-ul se aude pentru lucruri care contează. Calitatea datelor (lecția 61) determină dacă on-call-ul debug-uiește eșecuri reale sau urmărește fals-pozitive. Incident response (lecția 62) determină dacă fiecare incident produce învățare sau aceleași incidente se repetă.

Când toate funcționează, on-call-ul e o parte gestionabilă a faptului că ești în echipă. Când oricare dintre ele lipsește, on-call-ul e locul unde se vede primul.

Modulul 8 se termină aici

Asta e ultima lecție a Modulului 8. Următoarea lecție e studiul de caz al modulului: cum își rulează Airbnb platforma de date. Modulul 9 deschide apoi cu optimizarea costurilor, fratele natural al fiabilității operaționale și următoarea pârghie mare pe care o echipă de date matură o are de tras.

Citări și lecturi suplimentare

Google SRE Book, capitolul „Being On-Call”, https://sre.google/sre-book/being-on-call/ (consultat 2026-05-01). Descrierea scrisă canonică a practicii de on-call sănătos, de la echipa care a inventat probabil forma modernă a ei.
Google SRE Workbook, capitolul „On-Call”, https://sre.google/workbook/on-call/ (consultat 2026-05-01). Companionul practic al cărții SRE, cu sfaturi concrete despre rotații, hand-off-uri și burnout.
PagerDuty, „Incident Response Documentation”, https://response.pagerduty.com/ (consultat 2026-05-01). Ghidul open-source de incident response al PagerDuty, inclusiv pattern-uri de rotație on-call și playbook-uri de escalation.
Atlassian, „On-call best practices”, https://www.atlassian.com/incident-management/on-call (consultat 2026-05-01). Îndrumare practică de la un furnizor a cărui tooling stă pe exact problema asta.