🥇Servizi Legacy nella tua infrastruttura

Ciao! Mi chiamo Pasha Chernyak, sono uno sviluppatore senior presso QIWI, e oggi voglio parlare dell'inevitabile. Di Legacy.

Iniziamo con una domanda: cosa si intende per servizio Legacy? Un servizio Legacy è un servizio che lo sviluppatore non ha toccato per una settimana/mese/anno? O è un servizio scritto da un programmatore meno esperto, ad esempio, specificamente da te, ma un anno fa? E ora sei certamente più bravo e esperto. Oppure, un servizio Legacy è un servizio che hai deciso di non committare mai più e stai lentamente preparando una sostituzione? In ogni caso, lasciare un servizio del genere senza supervisione e non aggiornarlo è una bomba a orologeria che potrebbe esplodere in seguito.

Prima di passare a come lavoriamo con i nostri servizi Legacy in QIWI, vi racconterò come abbiamo messo ordine nei servizi del Wallet. Da due anni mi occupo della sua funzionalità. Se c'è un problema, la prima persona a cui telefonano sono sempre io. Di solito non ho il coraggio di chiamare qualcun altro alle 11 di sera, quindi ho dovuto sedermi e occupami di tutti i servizi del nostro dominio.

Ma io, come ogni persona, amo dormire di notte, quindi ho cercato di capire la situazione: "Ragazzi, perché chiamate me?". E ho ricevuto una risposta piuttosto concisa del tipo "E a chi altro?". Perché io riparo i servizi, e inoltre i ragazzi semplicemente non sanno a chi telefonare.

Pertanto, durante una delle retrospettive del team backend del Wallet, abbiamo deciso di creare un elenco con i nostri servizi, microservizi e monoliti del wallet, e le persone responsabili di ciascuno di essi. Le tabelle sono sempre utili, nei limiti del ragionevole.

Oltre alle informazioni su chi è responsabile di cosa, c'erano risposte a domande: chi è il proprietario del servizio, chi si occupa del suo sviluppo, dell'architettura e del ciclo di vita. Le persone responsabili di questo servizio sono quelle in grado di ripararlo se necessario. Il proprietario del servizio ha il diritto di lasciare +2 nei commit, anche le persone responsabili devono necessariamente essere presenti alla revisione prima che questo servizio accetti un nuovo commit.

Il tempo passava, iniziavano a essere applicate nuove pratiche, come la migrazione in Kubernetes, vari checkstyle, spotbugs, ktlint, la presenza di log in Kibana, autodiscovery dei servizi anziché indicare direttamente gli indirizzi e altre utilità. E ovunque la nostra tabella ci permetteva di mantenere attuale lo stato dei nostri servizi. Per noi è una sorta di checklist che indica cosa questo servizio può fare e cosa no. Ma ci siamo spinti oltre, rendendoci conto che ci mancavano informazioni sui nostri servizi che monitoriamo, dove si trovano i sorgenti del servizio, dove vengono eseguiti i task di build in TeamCity, come vengono deploiati, dove si trovano i sorgenti dei test end2end, foto sui grooming riguardo l'architettura e le decisioni prese. Idealmente, volevamo che tutte queste informazioni fossero sempre disponibili quando necessario. Così il nostro foglio è diventato un punto di partenza per la ricerca delle informazioni.

Ma QIWI, pur mantenendo lo spirito di startup, è una grande azienda. Abbiamo già 12 anni, e i team cambiano: le persone se ne vanno, altre arrivano, si formano nuovi gruppi. E abbiamo scoperto nel nostro dominio diversi servizi ereditati. Qualcosa è arrivato con gli sviluppatori di altri team, qualcosa era in qualche modo collegato a Wallet, quindi ora il servizio è nel nostro bilancio. Perché complicarsi con il funzionamento dei servizi? Funzionano, e abbiamo delle funzionalità di prodotto che dobbiamo assolutamente implementare.

Come spesso accade

Ma a un certo punto ci accorgiamo che il servizio smette di svolgere la sua funzione, qualcosa si è rotto — come comportarsi in questa situazione? Il servizio ha semplicemente smesso di funzionare. Del tutto. E lo abbiamo scoperto, prima di tutto, per caso, e in secondo luogo, dopo sei mesi. Può succedere. L'unica cosa che sapevamo era su quali macchine virtuali era attivato il servizio, dove si trovano i suoi sorgenti, e basta. Facciamo un git clone e ci immergiamo nei pensieri della persona che ha scritto questo alcuni anni fa, ma cosa vediamo? Nessun Spring Boot familiare, sebbene ci siamo abituati a tutto, essendo full stack e tutto il resto. Forse c’è Spring Framework? E invece no.

Il ragazzo che ha scritto tutto questo era severo e scriveva tutto in puro Java. Non ci sono strumenti familiari per lo sviluppatore, e nasce l'idea: sarebbe opportuno riscrivere tutto. Abbiamo dei microservizi, e da ogni tostapane arriva il consueto "Ragazzi, i microservizi sono ciò che vi serve!". Se qualcosa non va, potrete tranquillamente prendere un linguaggio a scelta e andrà tutto bene.

Il punto è che ora non abbiamo un committente responsabile di questo servizio. Quali erano le sue esigenze di business, cosa dovrebbe fare questo servizio? E il servizio è strettamente integrato nei vostri processi aziendali.

E ora ditemi, quanto è facile riscrivere un servizio senza conoscere le sue esigenze di business? Non è chiaro come viene effettuato il logging del servizio, se ci sono metriche — non lo sappiamo. Quali siano, se ci sono — ancor meno lo sappiamo. E nel servizio ci sono un gran numero di classi con una logica aziendale poco chiara. Qualcosa entra in un qualche database, di cui per ora non sappiamo nulla.

Da dove iniziare?

Dal più logico — dalla presenza di test. Di solito lì è scritta almeno un po' di logica e si possono trarre conclusioni su ciò che sta accadendo. Ora va di moda il TDD, ma vediamo che anche 5 anni fa era praticamente tutto come adesso: quasi niente test unitari, e comunque non ci diranno nulla di significativo. A meno che non sia qualche verifica su come venga firmato un qualche xml con un certificato personalizzato.

Non siamo riusciti a capire nulla dal codice e abbiamo deciso di guardare cosa c'era sulla virtual machine. Abbiamo aperto i log del servizio e trovato un errore del client http, il certificato autofirmato che era integrato nelle risorse dell'applicazione era già scaduto. Abbiamo contattato i nostri analisti che hanno richiesto un nuovo certificato, ci è stato rilasciato e il servizio ha ricominciato a funzionare. Sembrerebbe che tutto sia finito qui. O no? Tuttavia, il servizio funziona, esegue una funzione che è necessaria per il nostro business. Abbiamo degli standard di sviluppo delle applicazioni, che probabilmente avete anche voi. Ad esempio, non conservare i log sulla node in una cartella, ma conservarli in qualche tipo di archiviazione, tipo Elastic, e verificarli in Kibana. Possiamo anche ricordare le metriche d'oro. Cioè, il carico sul servizio, il numero di richieste al servizio, se è attivo o meno, come passa il suo HealthCheck. Almeno queste metriche aiuteranno a capire quando è possibile ritirarlo dall'uso in tutta tranquillità e dimenticarlo come un brutto sogno.

Cosa fare

Perciò aggiungiamo questo vecchio servizio nella tabella e poi andiamo a cercare tra gli sviluppatori volontari che si occupino del servizio e lo sistemino: scrivano almeno qualche informazione sul servizio, aggiungano collegamenti ai dashboard in Grafana, alle task di costruzione, capiscano come distribuire l'applicazione, non è certo possibile caricare file tramite ftp a mano.

La cosa principale è: quanto tempo richiederà tutta questa utile attività volontaria? Un sprint per uno sviluppatore più o meno esperto, ad esempio, durante il 20% del debito tecnico. E quanto tempo è necessario per comprendere tutta la logica radicata nella comunicazione con un certo sistema governativo e portarlo su tecnologie più moderne? Di questo non mi prendo responsabilità, potrebbe richiedere un mese, o forse due, con il lavoro del team. Parlo per esperienza di integrazione attuale con qualche nuovo servizio.

Tuttavia, non ci sono risultati di valore per il business. Affidare il servizio al supporto e spendere un po' di tempo per questo è normale. Ma dopo le nostre danze standard con il servizio, lo abbiamo aggiunto alla tabella, abbiamo aggiunto informazioni su di esso e, forse, un giorno lo riscriveremo. Ma attualmente soddisfa i nostri standard di funzionamento dei servizi.

Come risultato, vorrei arrivare a un certo piano su cosa fare con i servizi Legacy.

Riscrivere il legacy da zero è una cattiva idea
Seriamente, non c'è nemmeno bisogno di pensarci. È chiaro che ci sarebbe piaciuto, e ci sono dei vantaggi, ma di solito non serve a nessuno, nemmeno a voi stessi.

Riferimento
Scava nei codici sorgente delle tue applicazioni, crea un riferimento in cui sia indicato cosa c'è e dove si trova e come funziona, inserisci anche una descrizione del progetto (una sorta di readme.md), in modo da capire rapidamente dove si trovano i log e le metriche. Lo sviluppatore che si occuperà di questo dopo di te ti ringrazierà.

Comprendi il dominio
Se possiedi un dominio, cerca di tenere sotto controllo la situazione. Suona banale, sì, ma non tutti si assicurano che i servizi seguano un unico standard. E lavorare in un unico standard è davvero molto più semplice.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.