🥇Serviciile Legacy în infrastructura ta

Bună! Mă numesc Pașa Cernyak, sunt dezvoltator principal la QIWI, și astăzi vreau să discut despre inevitabil. Despre Legacy.

Să începem cu o întrebare: ce este un serviciu Legacy? Este un serviciu la care dezvoltatorul nu a mai intervenit de o săptămână/lună/an? Sau este un serviciu scris de un programator mai puțin experimentat, de exemplu, de către tine, dar acum un an? Acum ești mult mai bun și mai experimentat. Sau, de fapt, serviciul Legacy este acela pe care ai decis să nu-l mai actualizezi niciodată și, treptat, îl pregătești pentru înlocuire? În orice caz, lăsarea unui astfel de serviciu neactualizat este o bombă cu ceas care poate exploda mai târziu.

Înainte de a trece la modul în care noi, la QIWI, ne gestionăm serviciile Legacy, voi povesti cum am organizat serviciile din Portofel. De doi ani mă ocup de funcționarea acestuia. Dacă există vreo problemă, întotdeauna mă sună prima dată pe mine. De obicei, nu am îndrăzneala să sun pe altcineva la ora 11 seara, așa că a trebuit să mă așez și să îmi dau seama de toate serviciile domeniului nostru.

Dar eu, ca orice om, îmi place să dorm noaptea, așa că am încercat să înțeleg situația: „De ce mă sunați pe mine?”. La care am primit un răspuns destul de concis: „Cui altcuiva să-i spunem?”. Pentru că eu repar serviciile, iar băieții pur și simplu nu știu cui să îi telefoneze.

Prin urmare, la una dintre retrospectivele echipei de backend a Portofelului, am decis că trebuie să facem un tabel cu lista serviciilor noastre, microservicelor și monolitilor din portofel, precum și cu persoanele responsabile pentru acestea. Tabelele sunt foarte utile, în limite rezonabile.

Pe lângă informațiile despre cine este responsabil pentru ce, acolo erau și răspunsuri la întrebările: cine este proprietarul serviciului, cine răspunde de dezvoltarea acestuia, de arhitectură și de ciclul său de viață. Oamenii responsabili pentru acest serviciu sunt cei care pot să-l repare în cazul în care este nevoie. Proprietarul serviciului are dreptul de a lăsa +2 în commite, iar cei responsabili trebuie să fie prezenți la revizuire înainte ca acest serviciu să accepte un nou commit.

Timpul a trecut, au început să se aplice noi practici, cum ar fi migrarea în Kubernetes, diverse checkstyle, spotbugs, ktlint, existența logurilor în Kibana, autodiscovery al serviciilor în loc de a specifica adresele direct și alte utilități. Și peste tot, tabelul nostru a permis menținerea actualizării serviciilor noastre. Pentru noi, acesta este un fel de checklist care ne spune că acest serviciu poate face asta, dar nu poate face asta. Dar am avansat, înțelegând că ne lipsește informația despre serviciile noastre pe care le monitorizăm, unde sunt sursele serviciului, unde se desfășoară sarcinile de compilare în TeamCity, cum sunt implementate, unde sunt stocate sursele testelor end2end, fotografiile despre arhitectură, despre deciziile luate. În ideal, ne-ar plăcea ca toată această informație să fie undeva stocată și la îndemână atunci când avem nevoie. De aceea, tabelul nostru a devenit punctul de pornire pentru căutarea informațiilor.

Dar QIWI, deși păstrează spiritul unei start-up, este o companie mare. Avem deja 12 ani și echipele se schimbă: oameni pleacă, oameni vin, se formează noi echipe. Și am descoperit pe domeniul nostru câteva servicii, moștenite de la alții. Unele au venit cu dezvoltatorii din alte echipe, altele au fost indirect legate de Portofel, așa că acum serviciul este în bilanțul nostru. Să ne ocupăm de ceea ce și cum funcționează — de ce? Serviciul funcționează, iar noi avem caracteristici de produs care trebuie neapărat implementate.

Cum se întâmplă uneori

Dar, la un moment dat, descoperim că serviciul încetează să își îndeplinească funcția, ceva s-a stricat — ce să facem în această situație? Serviciul pur și simplu a încetat să funcționeze. Complet. Și am aflat despre asta, în primul rând, accidental, iar în al doilea rând, după șase luni. Așa se întâmplă. Singurul lucru pe care îl știm este pe ce virtualizări este desfășurat serviciul, unde se află sursele acestuia și cam atât. Facem git clone și ne adâncim în gândurile persoanei care a scris asta acum câțiva ani, dar ce vedem? Niciun Spring Boot cunoscut pentru noi, deși ne-am obișnuit cu toate acestea, avem full stack și toate cele. Poate că există Spring Framework? Dar nu.

Tipul care a scris toate acestea a fost sever și a scris totul în Java pur. Nu există instrumente obișnuite pentru dezvoltatori, iar ideea este că ar trebui să refacem totul. Avem microservicii, iar din fiecare prăjitor de pâine se aude familiarul „Băieți, microserviciile sunt ceea ce aveți nevoie!”. Dacă ceva nu e în regulă, poți lua oricare limbaj și totul va fi bine.

Problema este că acum nu avem un client care să fie responsabil pentru acest serviciu. Care au fost cerințele de afaceri ale acestuia, ce ar trebui să facă acest serviciu? Și acest serviciu este integrat strâns în procesele voastre de afaceri.

Și acum spuneți-mi, cât de simplu este să refaci un serviciu fără a cunoaște cerințele sale de afaceri? Nu se știe cum se loghează serviciul, dacă există metrici - nu se știe. Care sunt ele, dacă există - cu atât mai puțin se știe. Și în același timp, în serviciu există o mulțime de clase cu o logică de afaceri neclară. Ceva ajunge într-o bază de date despre care nu știm nimic deocamdată.

Cu ce ar trebui să începem?

Cu cel mai logic lucru - cu disponibilitatea testelor. Acolo de obicei se scrie o oarecare logică și se pot trasa concluzii despre ce se întâmplă. Acum este la mod TDD, dar vedem că acum 5 ani era aproape la fel ca acum: unit-testele sunt aproape inexistente, iar acestea nu ne vor spune nimic semnificativ. Poate doar să verifice cum se semnează un xml cu un certificat personalizat.

Din cod nu am putut înțelege nimic, așa că am decis să ne uităm în virtuală. Am deschis logurile serviciului și am găsit o eroare a clientului http: certificatul auto-semnat, care fusese inclus în resursele aplicației, era complet expirat. Ne-am contactat cu analiștii noștri, ei ne-au cerut un certificat nou, ne-a fost emis și serviciul funcționează din nou. Ar părea că asta e tot. Dar nu? Totuși, serviciul funcționează, îndeplinește o anumită funcție care este necesară pentru afacerea noastră. Avem anumite standarde de dezvoltare a aplicațiilor, care, probabil, sunt și la voi. De exemplu, să nu stocăm loguri pe nod în folder, ci să le păstrăm într-un fel de depozit, precum Elasticsearch, și să ne uităm la ele în Kibana. Putem aminti și de metricile de aur. Adică, încărcarea serviciului, numărul de solicitări către serviciu, dacă este activ sau nu, cum trece testul HealthCheck. Cel puțin, aceste metrici ne vor ajuta să știm când să-l scoatem din exploatare cu conștiința liniștită și să-l uităm ca pe un coșmar.

Ce să fac

Așa că adăugăm acest vechi serviciu în tabel, iar apoi căutăm printre dezvoltatori voluntari care să se ocupe de serviciu și să-l aducă în ordine: să scrie câteva informații despre serviciu, să adauge linkuri către dashboard-uri în Grafana, sarcini de construcție, să înțeleagă cum să desfășoare aplicația, nu să arunce manual fișiere prin FTP.

Cel mai important — cât timp va dura toată această activitate utilă a voluntarilor? O sprint pentru un dezvoltator mai mult sau mai puțin experimentat, de exemplu, în timpul celor 20% din datoria tehnică. Și cât timp a fost necesar pentru a înțelege toată logica înrădăcinată în comunicarea cu un anumit sistem guvernamental, pentru a o aduce la tehnologii mai noi? Nu mă angajez pe acest subiect, poate o lună, poate chiar două luni de muncă a echipei. Asta spun din experiența integrării actuale cu un nou serviciu.

În același timp, nu există nicio valoare de afaceri generată — deloc. Să preiei un serviciu în suport și să aloci puțin timp pentru asta — e normal. Dar după dansurile noastre standard cu serviciul, l-am adăugat în tabel, am adăugat informații despre el și, poate, cândva, îl vom rescrie. Dar acum acoperă standardele noastre de operare a serviciilor.

Ca rezultat, aș dori să ajung la un plan, ce să facem cu serviciile legacy.

Rescrierea legacy-ului de la zero — o idee proastă
Serios, nu trebuie să te gândești prea mult la asta. E clar că ar fi plăcut, și se pot observa unele avantaje, dar de obicei nu este necesar nimănui, inclusiv ție.

Manual
Scoateți la iveală codurile sursă ale aplicațiilor voastre, creați un manual în care să fie specificat ce se află și unde, precum și cum funcționează, adăugați acolo o descriere a proiectului (un fel de readme.md), astfel încât să înțelegeți rapid unde se află jurnalele și metricile. Dezvoltatorul care va lucra la acestea după voi vă va mulțumi.

Înțelegeți domeniul
Dacă dețineți un domeniu, încercați să fiți la curent. Sună banal, da, dar nu toată lumea se asigură că serviciile sunt uniforme. A lucra conform unui singur standard este de fapt mult mai simplu.

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.