De unde știi că sistemul tău chiar funcționează
Dashboard-ul verde și absența reclamațiilor nu dovedesc nimic. Ce să întrebi, ca decident, ca să afli dacă rezultatul chiar ajunge unde trebuie.
Verde nu e dovadă
De unde știi că sistemul tău chiar funcționează, dacă nimeni nu s-a plâns și dashboard-ul e verde? Din liniștea asta, nu știi nimic. Absența unui semnal rămâne doar o absență, nu dovada că ceva funcționează. Ce demonstrează că un sistem funcționează e altceva: traseul pe care se bazează rezultatul de business, urmărit până la capăt, nu componentele din care e făcut.
Confuzia e ușor de făcut, pentru că din exterior arată identic. Procesele rulează, API-ul răspunde, nimeni nu deschide un tichet. Dar „rulează” și „face treaba pentru care a fost cumpărat” sunt două afirmații diferite. Prima nu o dovedește pe a doua.
Ce măsori, de fapt
Un serviciu poate răspunde corect din punct de vedere tehnic și tot să livreze rezultatul greșit. Un răspuns HTTP 200 poate veni cu un conținut greșit, iar doar testele care parcurg tot drumul, de la capăt la capăt, pot detecta asta[1]. Codul 200 indică succesul cererii la nivel HTTP, dar nu garantează că răspunsul are conținutul corect pentru utilizator.
O verificare automată de tip liveness - care testează doar dacă un endpoint sau un proces răspunde - confirmă exact componenta pe care o cheamă, nu tranzacția pe care se bazează afacerea. E o verificare validă, doar limitată: dovedește că procesul e în viață, nu că rezultatul ajunge unde trebuie. Alte verificări automate, mai complete, pot valida dependențe sau trasee end-to-end, dar pot rămâne verzi dacă folosesc un drum diferit de cel pe care intră cererile reale, indiferent ce se întâmplă pe drumul real.
Traseul, nu componenta
Ce ar trebui măsurat, în loc de „e sus” sau „e jos”, e traseul critic: succesiunea de pași prin care trece o cerere reală, de la intrare până la rezultatul pe care se bazează decizia sau plata. Google numește acest concept „critical user journey”: o succesiune de sarcini esențială deopotrivă pentru experiența utilizatorului și pentru serviciu - ceea ce numim aici traseu critic. Odată identificate, evenimentele de pe un asemenea traseu pot deveni un SLI, un indicator de nivel de serviciu, exprimat de regulă ca raport între evenimentele bune și totalul evenimentelor[2].
Diferența practică: „serverul răspunde” e o afirmație despre componentă. „Comanda a ajuns la plată, plata a ajuns la confirmare, confirmarea a ajuns la client” e o afirmație despre traseu. A doua este măsurătoarea care leagă starea tehnică de rezultatul pentru care sistemul a fost cumpărat.
Un tipar ilustrativ: verde și blocat în același timp
Ca ilustrare a tiparului, nu ca relatare a unui sistem anume: o verificare automată poate raporta verde în timp ce testul ei folosește o ramură specială care ocolește exact condiția care blochează traseul real. Componentele răspund; rezultatul de business nu ajunge la destinație.
Cine se uită la un asemenea dashboard poate să nu aibă un motiv vizibil să întrebe mai mult. Verificarea există, rulează, răspunde „ok”. Doar că verifică o cale pe care niciun client real n-o parcurge. E genul de gol care nu se vede din interiorul sistemului, pentru că sistemul însuși raportează că totul e în regulă.
Cele trei întrebări
Ca decident care operează un sistem, nu trebuie să configurezi observabilitate. Trebuie să știi ce să ceri. Trei întrebări separă un sistem verificat de unul doar liniștit.
Care e traseul critic? Numește-l explicit: pasul de intrare, pasul de decizie, pasul de rezultat. Dacă nimeni nu poate numi traseul, nimeni nu poate spune ce anume se verifică.
Ce eveniment dovedește că s-a încheiat corect? Nu „a răspuns serverul”, ci rezultatul concret: plata confirmată, cererea procesată, contractul semnat. Sonde care urmăresc aceleași rute și acțiuni ca un client real pot verifica experiența chiar și fără trafic real și pot descoperi unele probleme înainte ca ele să ajungă la clienți[3].
Cine sau ce află și acționează când dovada lipsește? Un semnal fără niciun răspuns, automat sau uman, rămâne decor. Un răspuns automat poate rezolva o parte din cazuri, dar tot e nevoie de un om care intervine când automatizarea nu remediază. Dacă răspunsul e „nimeni și nimic, momentan”, ai găsit exact golul pe care liniștea îl ascundea.
Ce ceri, nu ce configurezi
Data viitoare când evaluezi o platformă, un upgrade sau propriul tău sistem, nu întreba dacă are monitorizare. Simpla existență a monitorizării nu arată ce anume verifică. Întreabă ce anume verifică: componenta sau rezultatul, drumul de confort sau tranzacția reală. Cere traseul critic numit, evenimentul care dovedește finalul corect și numele persoanei care acționează când semnalul lipsește.
Nu e o listă exhaustivă și nu detectează orice defect posibil. E testul minim care separă un sistem care pare sănătos de unul care chiar e verificat.