🥇Servicii vechi în infrastructura dvs.

Buna ziua! Numele meu este Pasha Chernyak, sunt un dezvoltator de top la QIWI, iar astăzi vreau să vorbesc despre inevitabil. Despre Legacy.

Să începem cu întrebarea: ce este serviciul Legacy? Este un serviciu vechi un serviciu pe care dezvoltatorul nu l-a atins timp de o săptămână/lună/an? Sau este un serviciu care a fost scris de un programator mai puțin experimentat, de exemplu, de dvs. în mod specific, dar acum un an? Și acum ești mai cool și mai experimentat. Sau este serviciul Legacy un serviciu pe care ați decis să nu îl mai angajați niciodată și pregătiți încet un înlocuitor pentru acesta? În orice caz, lăsarea unui astfel de serviciu nesupravegheată și neactualizarea este o bombă cu ceas care poate exploda mai târziu.

Înainte de a trece la modul în care lucrăm noi la QIWI cu serviciile noastre Legacy, vă voi spune cum am adus ordine în serviciile din Portofel. De doi ani sunt responsabil pentru performanța sa. Dacă există vreo problemă, întotdeauna mă sună primul. De obicei nu am curajul să sun pe altcineva la ora 11:XNUMX, așa că a trebuit să mă așez și să-mi dau seama de toate serviciile de pe domeniul nostru.

Dar mie, ca orice persoană, îmi place să dorm noaptea, așa că am încercat să mă ocup de exploatare: „Băieți, de ce mă suni?” La care am primit un răspuns destul de laconic de genul „Cine altcineva?” Pentru că repar serviciile, iar băieții pur și simplu nu știu pe cine să sune.

Prin urmare, la una dintre retrospectivele echipei de backend Wallet, am decis că trebuie să facem un semn cu o listă a serviciilor noastre, microserviciilor și monoliților portofelului, precum și a responsabililor pentru acestea. Semnele sunt în general utile, în limite rezonabile.

Pe lângă informațiile despre cine este responsabil pentru ce, au existat răspunsuri la întrebări: cine este proprietarul serviciului, cine este responsabil pentru dezvoltarea, arhitectura și ciclul de viață al acestuia. Persoanele responsabile pentru acest serviciu sunt persoanele care pot repara dacă se întâmplă ceva. Proprietarul serviciului are dreptul de a lăsa +2 în comit-uri, cei responsabili trebuie să fie prezenți și la revizuire înainte ca acest serviciu să accepte un nou comit.

Odată cu trecerea timpului, au început să se aplice noi practici, de exemplu, migrarea către Kubernetes, tot felul de stiluri de verificare, bug-uri, ktlint, prezența jurnalelor în Kibana, servicii de descoperire automată în loc de a specifica direct adrese și alte lucruri utile. Și peste tot masa noastră ne-a permis să menținem relevanța serviciilor noastre. Pentru noi, acesta este un fel de listă de verificare care spune că acest serviciu poate face acest lucru, dar încă nu face asta. Dar am mers mai departe, realizând că ne lipsesc informațiile despre serviciile noastre, pe care le monitorizăm, unde se află sursele de servicii, unde sunt lansate sarcinile de asamblare în TeamCity, cum sunt implementate, unde sunt stocate sursele testelor end2end, fotografii din sesiunile de grooming despre arhitectură, despre deciziile luate. În mod ideal, aș dori ca toate aceste informații să se afle undeva și să fie la îndemână atunci când este nevoie. Prin urmare, semnul nostru a devenit punctul de plecare pentru căutarea informațiilor.

Dar QIWI, deși păstrează spiritul unui startup, este o companie mare. Avem deja 12 ani, iar echipele se schimbă: oamenii pleacă, vin oamenii, se formează echipe noi. Și am descoperit mai multe servicii pe domeniul nostru pe care le-am moștenit. Unii au venit de la dezvoltatori din alte echipe, alții pur și simplu au legătură indirect cumva cu Wallet, așa că acum avem serviciul în bilanţ. Înțelegerea ce și cum funcționează - de ce? Serviciul funcționează și avem caracteristici ale produsului care cu siguranță trebuie îmbunătățite.

Cum se întâmplă

Dar la un moment dat descoperim că serviciul încetează să-și îndeplinească funcția, ceva este stricat - ce să faci într-o astfel de situație? Serviciul pur și simplu a încetat să funcționeze. Deloc. Și am aflat despre asta, în primul rând, din întâmplare, și în al doilea rând, șase luni mai târziu. S-a întâmplat. Singurul lucru pe care îl știam era pe ce mașini virtuale va fi implementat serviciul, unde se află sursele sale și atât. Facem o clonă git și ne scufundăm în mintea celui care a scris asta acum câțiva ani, dar ce vedem? Niciunul din Spring Boot care ne este familiar, deși suntem obișnuiți cu toate, avem o stivă plină și toate astea. Poate că există un cadru de primăvară acolo? Dar nu.

Tipul care a scris toate astea a fost dur și a scris totul în Java pur. Nu există instrumente obișnuite pentru un dezvoltator și apare o idee: trebuie să rescriem toate acestea. Avem microservicii, iar din fiecare prăjitor de pâine vine obișnuitul „Băieți, microservicii sunt ceea ce aveți nevoie!” Dacă dintr-o dată ceva nu merge bine, poți lua calm orice limbă și totul va fi bine.

Chestia este că acum nu avem un client care să fie responsabil de acest serviciu. Ce cerințe de business avea, ce ar trebui să facă acest serviciu? Și serviciul este strâns integrat în procesele dvs. de afaceri.

Acum spune-mi, cât de ușor este să rescrii un serviciu fără să cunoști cerințele sale de afaceri? Nu este clar cum este înregistrat serviciul; nu se știe dacă există valori. Care sunt acestea, dacă există, este cu atât mai necunoscut. Și, în același timp, serviciul conține un număr mare de clase de logică de afaceri de neînțeles. Ceva este inclus într-un fel de bază de date, despre care, de asemenea, nu știm nimic încă.

De unde să încep?

Din punctul cel mai logic - disponibilitatea testelor. De obicei, există cel puțin ceva logică scrisă acolo și poți trage concluzii despre ceea ce se întâmplă. Acum TDD este la modă, dar vedem că acum 5 ani totul era aproape la fel ca acum: aproape nu există teste unitare și nu ne vor spune nimic. Ei bine, cu excepția, poate, a unui fel de verificare, cum se semnează unele xml cu un certificat personalizat.

Nu am putut înțelege nimic din cod, așa că ne-am dus să vedem ce era în mașina virtuală. Am deschis jurnalele de serviciu și am găsit o eroare de client http în ele; certificatul autosemnat care a fost încorporat în resursele aplicației era stricat de rușine. Am luat legătura cu analiștii noștri, au cerut un nou certificat, ni l-au eliberat și serviciul funcționează din nou. S-ar părea că asta-i tot. Sau nu? La urma urmei, serviciul funcționează, îndeplinește o funcție de care are nevoie afacerea noastră. Avem anumite standarde pentru dezvoltarea aplicațiilor, pe care cel mai probabil le aveți și dumneavoastră. De exemplu, nu stocați jurnalele pe nod într-un folder, ci stocați-le într-un fel de stocare, cum ar fi elastic, și priviți-le în Kibana. Vă puteți aminti și valorile de aur. Adică, încărcarea serviciului, numărul de solicitări pentru serviciu, dacă este în viață sau nu, cum merge HealthCheck-ul său. Cel puțin, aceste valori vă vor ajuta să știți când poate fi scos din serviciu cu conștiința curată și uitat ca un vis urât.

Ce trebuie să faceți

Prin urmare, adăugăm pe tabel un serviciu atât de vechi, iar apoi mergem să căutăm voluntari dintre dezvoltatori care se vor ocupa de serviciu și îl vor pune în ordine: vor scrie măcar câteva informații despre serviciu, vor adăuga link-uri către tablouri de bord în grafana, pentru sarcini de asamblare și înțelegeți cum Implementați aplicația, nu încărcați manual fișiere folosind ftp.

Principalul lucru este cât timp va dura toată această activitate utilă de voluntariat? Un sprint pentru un dezvoltator mai mult sau mai puțin experimentat, de exemplu, în timpul unei datorii tehnice de 20%. Cât timp a durat pentru a înțelege toată logica înrădăcinată a comunicării cu un anumit sistem de stat și a-l aduce la tehnologiile mai noi? Nu pot garanta pentru asta, poate o lună sau poate două din munca echipei. Spun asta din experiența integrării actuale cu un serviciu nou.

În același timp, nu există nicio eliberare a valorii afacerii. Deloc. Este normal să angajezi un serviciu pentru asistență și să petreci puțin timp cu el. Dar după dansurile noastre standard cu serviciul, l-am adăugat la masă, am adăugat informații despre el și, poate, îl vom rescrie cândva. Dar acum îndeplinește standardele noastre de servicii.

Ca urmare, aș dori să vin cu un plan pentru ce să fac cu serviciile Legacy.

Rescrierea moștenirii de la zero este o idee proastă
Serios, nici nu trebuie să te gândești la asta. Este clar că mi-ar plăcea și există câteva avantaje, dar de obicei nimeni nu are nevoie de el, inclusiv dvs.

Cartea de referință
Descoperiți codurile sursă ale aplicațiilor dvs., faceți o carte de referință care să indice ce este unde și cum funcționează, introduceți acolo o descriere a proiectului (readme.md condiționat) pentru a înțelege rapid unde se află jurnalele și valorile. Dezvoltatorul care se va ocupa de asta după tine va spune doar mulțumesc.

Înțelegeți domeniul
Dacă dețineți un domeniu, încercați să țineți degetul pe puls. Sună banal, da, dar nu toată lumea se asigură că serviciile sunt într-o singură cheie. Dar lucrul într-un singur standard este de fapt semnificativ mai ușor.

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.