Acasă/Cercetare

Calitatea datelor · monitorizare

Cele mai scumpe defecțiuni de date n-au declanșat nicio alarmă

Cele mai scumpe defecțiuni de date au mers zile în șir fără eroare, fără alertă, fără vreo pagină care să se rupă. Fiecare a continuat să producă cifre la ore fixe; greșită era doar prospețimea datelor. Mecanismele cu care le-am prins se pot copia, pragurile din ele nu.

Publicat 2026-08-28

Nu s-a stricat nimic vizibil

Am căutat defecțiunile care ne-au costat cel mai mult, așteptându-ne să găsim căderi. Am găsit incidente în propria noastră infrastructură de date care n-au dat nicio eroare, n-au trezit pe nimeni și n-au încetat nicio clipă să producă cifre la ore fixe. Cifrele erau pur și simplu greșite.

Ne apărasem de tipul zgomotos de defecțiune. Un job care iese cu cod diferit de zero. O conexiune refuzată. O pagină care întoarce o stivă de erori. Astea se repară repede, fiindcă le vede cineva imediat. Defecțiunile de mai jos au mers mai departe fiindcă orice ecran la care se uita cineva era verde.

Forma comună merită spusă înainte de detalii. Fiecare dintre ele a produs rezultate. Pipeline-ul a rulat. Greșită era doar prospețimea datelor, iar prospețimea nu o verifica nimic.

Defecțiuni diferite, o singură formă

Toate cifrele de publicitate ale unei platforme treceau printr-un singur token OAuth de viață lungă, cu o durată de aproximativ șaizeci de zile, care acoperea absolut toate conturile de publicitate pe care le administrăm. Când a expirat, totul s-a oprit deodată și s-a oprit în liniște. Rapoartele se afișau în continuare. Doar că nu mai înaintau.

Tiparul merită ținut minte, fiindcă la prima citire te trimite pe pistă falsă. Ultima sincronizare a fiecărui cont era înghețată în aceeași zi, iar jurnalul de sincronizare raporta o eroare care numea un singur cont, la întâmplare, deși în realitate căzuseră toate. Dacă citești doar jurnalul, tragi concluzia că ai un cont stricat, nu un token mort sub toată platforma.

O altă defecțiune a fost o absență. Un job programat pentru o a doua platformă s-a oprit din rulat și nimeni n-a știut, pentru o perioadă pe care nici acum nu o putem preciza. Nu există nicio urmă a momentului opririi, fiindcă un job care nu pornește nu scrie nimic, nici măcar o linie de eroare.

Cea scumpă a fost un tabel de profitabilitate rămas nesincronizat 23 de zile. Cifrele lunare pe care le alimenta au fost grav greșite tot intervalul, iar nicio pagină nu a spus asta. Tabloul de bord se încărca la fel, la fel de repede, cu același aranjament, iar oamenii luau decizii de pe el.

Un job care se termină cu cod zero nu dovedește nimic

Un job care se termină cu cod zero îți spune că un proces a ajuns la capăt. Nu îți spune că datele s-au schimbat. Sunt două afirmații diferite, iar aproape toată monitorizarea noastră o susținea pe prima, în timp ce toți cei din aval se bazau pe a doua.

Cazul absenței e și mai rău. Un job care nu pornește nu are cum să-și raporteze propria cădere, așa că oricât ai citi jurnalele, tot nu-l vezi. Îl prinzi doar observând că nu a ajuns ceva ce trebuia să ajungă, ceea ce înseamnă că alarma trebuie să stea în afara jobului.

Așa că am mutat verificarea de pe job pe rezultat. Tabelul ăsta e mai proaspăt de N ore? Întrebarea are răspuns indiferent ce componentă s-a stricat, indiferent cum s-a stricat și indiferent dacă a rulat vreo componentă.

Ce am schimbat

Watchdog-urile verifică acum rezultatul față de un nivel de serviciu, nu faptul că jobul s-a terminat cu cod zero. Pentru fiecare tabel pe care se sprijină o decizie am scris vechimea maximă la care mai poate fi crezut, iar watchdog-ul compară cel mai nou rând cu acea limită. E o afirmație despre date, nu despre procese.

Fiecare job programat trimite un semnal la SUCCES, așa că lipsa semnalului devine ea însăși alarma. E singura cale de a acoperi jobul care nu pornește niciodată. Sistemul nu mai depinde de o componentă căzută ca să-și descrie singură căderea.

Sursele independente ale aceleiași mărimi se reconciliază între ele, iar istoricul abaterilor se păstrează. Mailul pleacă doar la abatere NOUĂ. Partea asta ține de atenția oamenilor, nu de inginerie: o alertă care sună zilnic e o alertă pe care n-o mai citește nimeni, iar un canal plin de zgomot cunoscut ascunde exact rândul care contează.

Expirarea tokenului se verifică din timp, nu se descoperă printr-o cădere. Acolo unde un singur token acoperă toate conturile unei platforme, data lui de expirare e un eveniment programat pe care îl vezi venind, nu un simptom pe care îl diagnostichezi după.

Ne-am înșelat chiar în privința verificatorului

Prima versiune a unuia dintre aceste verificatoare a raportat drept moartă o automatizare care funcționa. Se uita într-un tabel de istoric care se nimerise a fi gol, în timp ce efectul real se scria într-o cu totul altă coloană. Automatizarea era bună. Verificatorul, nu.

Presupunerea de dedesubt, pe care n-am observat că o facem, era că locul unde se înregistrează acțiunea e același cu locul unde se vede efectul. Aici nu era. Am fost la un pas să reparăm ceva ce mergea deja, pe baza unui instrument pe care tocmai îl scrisesem și nu îl testasem.

Un instrument de monitorizare poate măsura greșit exact la fel de ușor ca sistemul pe care îl supraveghează, iar când o face e mai periculos. La monitor te uiți tocmai atunci când nu mai ai încredere în restul, deci un monitor greșit nu mai are deasupra lui o a doua opinie. Confirmă întâi că măsori efectul, apoi ai încredere în monitor.

Cum faci aceeași verificare la tine

Pornește de la efecte, nu de la fișiere sau joburi. Pentru fiecare automatizare, scrie ce schimbă ea într-o înregistrare reală. Apoi caută coloana sau tabelul unde aterizează efectiv schimbarea. Ăla e lucrul de măsurat și, de multe ori, nu e jurnalul, tabelul de rulări sau istoricul la care te-ai duce din reflex.

Pentru fiecare tabel pe care se sprijină o decizie, ia cel mai recent marcaj de timp și compară-l cu momentul curent, față de o limită de prospețime scrisă dinainte. Apoi repetă comparația pe fiecare entitate, nu doar pe total. Căderea tokenului de mai sus se vede ca tipar doar dacă grupezi pe cont și observi toate conturile înghețate în aceeași zi.

Inversează o alarmă, ca experiment. Ia cel mai important job programat, pune-l să trimită un semnal la succes, apoi oprește-l intenționat și verifică dacă afli. Dacă nu afli, ai învățat ceva mai util decât un test trecut.

La final, alege o mărime pe care o poți obține din surse independente, păstrează diferența dintre ele în timp și dă alertă doar când diferența se schimbă.

Limite

Asta e infrastructura de date a unei singure firme. Mecanismele sunt generale și se pot copia ca atare. Intervalele și pragurile nu: limitele noastre de prospețime vin din cât de des rulează pipeline-urile noastre și din ritmul deciziilor noastre, iar copiate ca cifre nu spun nimic despre sistemele altcuiva.

Monitorizarea prospețimii prinde datele vechi, nu datele greșite. O valoare poate ajunge la timp, poate trece de toate watchdog-urile și poate fi totuși atribuită greșit, mapată greșit sau numărată de două ori. Nimic din ce am descris aici nu prinde asta și nu susținem nici că astea au fost singurele defecțiuni tăcute pe care le avem, nici că acum le prindem pe toate.

Nu dăm nicio cifră pentru cât a costat. Pentru jobul oprit nu știm cât timp a stat oprit. Pentru restul, socoteala onestă ar cere reconstituirea deciziilor luate de pe ecrane greșite, iar asta nu o putem verifica, deci nu publicăm un număr pentru ea.

Întrebări și răspunsuri

Cum prinzi un pipeline de date care cade fără nicio eroare?

Un pipeline de date care cade fără nicio eroare se prinde verificând rezultatul, nu starea jobului. Pentru fiecare tabel pe care se sprijină o decizie, scrii vechimea maximă la care mai poate fi crezut și compari cel mai nou rând cu ea. Fiecare job programat trimite un semnal la succes, iar lipsa lui declanșează alarma. Sursele independente se reconciliază, cu alertă doar la abatere nouă.

De ce nu ajunge codul de ieșire zero ca să monitorizezi un job programat?

Codul de ieșire zero nu ajunge ca să monitorizezi un job programat pentru că arată doar că procesul a ajuns la capăt, nu că datele s-au schimbat. Monitorizarea obișnuită susține prima afirmație, iar cei din aval se bazează pe a doua. Un job care nu pornește nu scrie nimic, nici măcar o linie de eroare. Întrebarea utilă e dacă tabelul e mai proaspăt de un anumit număr de ore.

Cum arată în jurnale expirarea unui token OAuth comun mai multor conturi?

Expirarea unui token OAuth comun mai multor conturi arată în jurnale ca un singur cont stricat, ceea ce te duce pe o pistă falsă. Ultima sincronizare a fiecărui cont îngheață în aceeași zi, iar jurnalul numește la întâmplare un singur cont drept cel căzut. Rapoartele se afișează în continuare, dar nu mai înaintează. Gruparea pe cont arată tiparul, iar verificarea din timp a expirării previne căderea.

Poate greși chiar instrumentul de monitorizare a datelor?

Instrumentul de monitorizare a datelor poate greși la fel de ușor ca sistemul pe care îl supraveghează, iar un monitor greșit e mai periculos, fiindcă nu are deasupra lui o a doua opinie. Un verificator de prospețime a raportat drept moartă o automatizare care mergea: citea un tabel de istoric gol, în timp ce efectul real se scria în altă coloană. Măsori deci locul unde aterizează efectiv schimbarea.

Prinde monitorizarea prospețimii și datele greșite?

Monitorizarea prospețimii prinde datele vechi, nu datele greșite. O valoare poate ajunge la timp, poate trece de toate watchdog-urile și poate fi totuși atribuită greșit, mapată greșit sau numărată de două ori. Mecanismele, adică limitele de prospețime, semnalul la succes și reconcilierea surselor, se pot copia ca atare. Pragurile nu, fiindcă depind de cât de des rulează pipeline-urile fiecărei firme și de ritmul deciziilor ei.

Toată cercetarea