Acasă/Cercetare

Post-mortem de migrare

Testul era verde. Efectul lipsea.

Am oprit un sistem automat vechi după ce am confirmat că cel nou face corect etichetele de expediție. Un modul rămăsese în modul shadow, iar 114 comenzi au plecat în trei zile fără un cadou pe care clientul îl plătise deja.

Publicat 2026-08-20

Un test verde și un efect absent

Am oprit un sistem automat vechi și i-am dat locul celui nou. Înainte de comutare am verificat lucrul cel mai vizibil pe care îl făcea sistemul vechi: producea etichete de expediție. Sistemul nou le producea corect. Am bifat migrarea drept verificată.

Un modul din sistemul nou rămăsese în modul shadow. Scria un rând în care nota ce ar fi adăugat pe comandă și nu făcea nimic altceva. Acel modul răspundea de adăugarea unui cadou mic, pe care clientul îl plătise deja ca parte a ofertei.

114 comenzi au plecat în trei zile fără el. Funcția care decidea ce se adaugă era corectă și era testată. Lipsea execuția.

În aceeași zi am găsit același tipar de încă două ori: o rutină care doar sugera o corecție în loc să o aplice și o funcționalitate marcată într-un comentariu din cod drept neportată încă.

De ce nu avea cum să prindă asta testarea codului

Un test unitar întreabă dacă o funcție întoarce răspunsul corect. Rularea în modul shadow nu schimbă răspunsul. Schimbă altceva: dacă se mai întâmplă ceva cu răspunsul, mai departe.

Din interiorul suitei de teste, cele două întrebări arată identic. Aserțiunea se face pe valoarea returnată, iar valoarea era corectă indiferent ce se întâmpla cu ea mai departe. Nimic din suită nu întreba dacă cineva a luat valoarea aceea și a scris-o pe comandă.

Toate testele verzi spuneau adevărul. Spuneau adevărul despre calcul, nu despre lume. Distanța dintre un răspuns corect și un răspuns aplicat e invizibilă pentru un test care vede doar răspunsul.

Ipoteza la care am renunțat

Presupuneam că o migrare se poate verifica prin eșantion: iei efectul cel mai vizibil, confirmi că merge, generalizezi. Ipoteza a fost infirmată în aceeași zi. Traseul etichetelor era viu, traseul cadoului nu. Un eșantion verde nu spunea nimic despre celelalte.

O ipoteză mai discretă a costat mai mult: că un modul care există în sistemul nou este un modul care rulează. Prezența în repo, importurile care se rezolvă, un apel care chiar ajunge acolo — nimic din toate astea nu înseamnă că efectul s-a produs. Shadow e exact starea în care un modul e prezent, apelat, corect — și inert.

Acum credem ceva mai restrâns. Unitatea de verificare nu e modulul și nu e testul. E efectul asupra unei comenzi.

Regula pe care am adoptat-o: enumeri acțiunile, nu fișierele

Scrie fiecare efect pe care sistemul vechi îl avea asupra unei comenzi. Nu module, nu fișiere, nu servicii. Efecte — lucrurile care ar arăta altfel pentru client dacă s-ar opri.

Pentru fiecare, spune cine îl execută după oprire. Dacă răspunsul e „nimeni”, migrarea nu e terminată, oricât de verzi ar fi testele. Ăsta e pasul care ne-ar fi prins greșeala și nu cere niciun tool.

Caută în codul nou cuvintele care marchează lucrul amânat: shadow, would, log-only, dry run, „not ported”, „apply at cutover”. Fiecare potrivire e o datorie scadentă chiar în ziua în care oprești sistemul vechi — adică exact ziua în care nimeni nu mai citește comentarii din cod.

Confirmă cu oamenii de la capătul lanțului — depozitul, serviciul de asistență — nu doar cu baza de date. Ei umblă cu rezultatul fizic. Baza de date răspunde doar la întrebarea pe care te-ai gândit s-o pui.

Monitorizarea zilnică, și cum a greșit și ea

Acum rulăm zilnic o comparație între candidați și efecte, pentru fiecare automatizare: câte comenzi îndeplineau condiția și pe câte s-a produs efectul. Trimite mail doar când ceva e mort sau a scăzut sub prag, așa că tăcerea e starea normală și un mesaj înseamnă ceva.

Prima ei versiune a raportat drept moartă o automatizare care funcționa. Se uita într-un tabel de istoric care era gol, în timp ce efectul real se scria pe altă coloană. Automatizarea era în regulă. Verificatorul nu.

Un monitor poate măsura greșit exact la fel de ușor ca sistemul pe care îl supraveghează, și nu moștenește nimic din atenția cu care e privit sistemul. Confirmă întâi că măsori efectul corect și abia apoi ai încredere în monitor. O alarmă roșie pe un traseu sănătos și una verde pe un traseu mort sunt același defect, în culori diferite.

Cum faci singur aceeași verificare

Ia o comandă care a trecut prin sistemul vechi și scrie ce i s-a întâmplat, de la un capăt la altul, în limbajul rezultatelor, nu al componentelor. Apoi urmărește fiecare rezultat prin sistemul nou, pe o comandă reală și recentă, în sistemul viu care ține evidența — nu pe date de test, nu pe un mediu de probă cu date puse acolo de noi.

Caută în codul nou vocabularul lucrului amânat de mai sus. Tratează fiecare potrivire ca lucru neplătit până când poți arăta ce anume îl execută. Nu e de ajuns să citești comentariul; caută codul care produce efectul.

Apoi întreabă oamenii de la capătul lanțului ce văd. Unde coletul și baza de date nu sunt de acord, câștigă coletul. Baza noastră de date a fost consecventă cu ea însăși tot timpul — consemna, corect, că nu se adăugase nimic.

Limitări

E o singură migrare, pe sistemele unei singure firme. Arată că un modul lăsat în shadow poate supraviețui unei comutări cu suita de teste complet verde; nu stabilește cât de des se întâmplă asta în altă parte sau pe ce fel de arhitecturi.

Cifra de 114 e cât am putut atribui cu încredere rezonabilă. Nu am încercat să reconstituim nimic dincolo de cele trei zile, deci e o limită de jos pentru fereastra pe care am analizat-o, nu un total.

Regula e o listă de verificări (un checklist), nu o demonstrație. Enumerarea efectelor unui sistem vechi e muncă manuală și poate rata un efect de care nu-și mai amintește nimeni. Comparația zilnică reduce expunerea ulterioară, dar nu rezolvă problema enumerării — iar prima ei versiune a arătat că se poate înșela chiar în privința lucrului pe care ar trebui să-l supravegheze.

Întrebări și răspunsuri

De ce pot testele unitare verzi să rateze o migrare stricată?

Testele unitare verzi pot rata o migrare stricată pentru că aserțiunea se face pe valoarea returnată, nu pe ce se întâmplă cu ea după aceea. Un modul în modul shadow întoarce răspunsul corect, dar nu îl scrie pe comandă. Testele spun adevărul despre calcul, iar efectul asupra clientului lipsește, deci distanța dintre un răspuns corect și unul aplicat rămâne invizibilă.

Ce este modul shadow și de ce e riscant la o comutare de sistem?

Modul shadow este starea în care un modul notează ce ar fi făcut și nu face nimic altceva. Modul shadow e riscant la o comutare pentru că modulul e prezent în repo, importurile se rezolvă și apelul chiar ajunge acolo, dar efectul nu se produce. Când sistemul vechi e oprit, tot ce a rămas în shadow încetează în tăcere să se mai întâmple pe comenzile reale.

Cum verific că o migrare de sistem e completă?

O migrare de sistem se verifică enumerând fiecare efect pe care sistemul vechi îl avea asupra unei comenzi și numind cine execută fiecare efect după oprire. Dacă la vreun efect răspunsul e „nimeni”, migrarea nu e terminată, oricât de verzi ar fi testele. Urmărești apoi fiecare efect pe o comandă reală și recentă, în sistemul viu, nu pe date de test.

Ce cuvinte din cod semnalează o migrare neterminată?

Cuvintele care semnalează o migrare neterminată sunt shadow, would, log-only, dry run, „not ported” și „apply at cutover”. Fiecare potrivire în codul nou e o datorie scadentă chiar în ziua în care oprești sistemul vechi. Tratezi fiecare potrivire ca lucru neplătit până poți arăta codul care produce efectul; nu e de ajuns să citești comentariul.

De ce să întreb depozitul și asistența când verific o migrare?

Depozitul și serviciul de asistență trebuie întrebate pentru că ei umblă cu rezultatul fizic, iar baza de date răspunde doar la întrebarea pe care te-ai gândit s-o pui. O bază de date poate rămâne consecventă cu ea însăși și poate consemna corect că nu s-a adăugat nimic pe comandă. Unde coletul și baza de date nu sunt de acord, câștigă coletul.

Poate o verificare zilnică să raporteze greșit o automatizare sănătoasă?

O verificare zilnică poate raporta greșit o automatizare sănătoasă dacă se uită în locul greșit. Într-un caz, prima versiune a raportat drept moartă o automatizare funcțională, fiindcă citea un tabel de istoric gol, în timp ce efectul real se scria pe altă coloană. O alarmă roșie pe un traseu sănătos și una verde pe un traseu mort sunt același defect.

Toată cercetarea