🥇Servizi legacy nella tua infrastruttura

Ciao! Sono Pasha Chernyak, lead developer in QIWI, e oggi voglio parlare dell'inevitabile. Di Legacy.

Iniziamo con la domanda: che cos'è un servizio Legacy? È un servizio che non è stato toccato da un developer per una settimana/mese/anno? Oppure è un servizio scritto da un programmatore meno esperto, per esempio da te, ma un anno fa? E ora sei molto più capace e esperto. O forse un servizio Legacy è quello che hai deciso di non toccare mai più e per cui 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 più avanti.

Prima di passare a come lavoriamo con i nostri servizi Legacy in QIWI, vi racconterò come abbiamo messo ordine nei servizi nel Portafoglio. Sono già due anni che sono responsabile del suo funzionamento. Se c'è qualche problema, sono sempre il primo a ricevere una chiamata. Di solito non ho il coraggio di chiamare qualcun altro alle 11 di sera, quindi mi sono dovuto sedere e capire tutti i servizi del nostro dominio.

Ma io, come qualsiasi persona, amo dormire di notte, quindi ho cercato di capire il funzionamento: 'Ragazzi, perché mi state chiamando?'. A cui ho ricevuto una risposta piuttosto concisa come 'E a chi altro?'. Perché riparo i servizi, e inoltre i ragazzi semplicemente non sanno a chi chiamare.

Pertanto, durante una delle retrospettive del team backend del Wallet, abbiamo deciso che era necessario creare una tabella con un elenco dei nostri servizi, microservizi e monoliti del wallet, e le persone responsabili per essi. Le tabelle sono davvero utili, se usate con criterio.

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

Il tempo passava e iniziavano ad essere adottate nuove pratiche, come la migrazione in Kubernetes, vari checkstyle, spotbugs, ktlint, la presenza di log in Kibana, autodiscovery dei servizi invece di specificare indirizzi direttamente e altre utilità. E ovunque la nostra tabella consentiva di mantenere aggiornati i nostri servizi. Per noi è una sorta di checklist che indica che questo servizio sa fare determinate cose, mentre altre no. Ma siamo andati oltre, rendendoci conto che ci mancava informazioni sui nostri servizi, come dove si trovano i sorgenti del servizio, dove vengono lanciati i task di build in TeamCity, come vengono deployati, dove si trovano i sorgenti dei test end2end, foto sui grooming riguardanti l'architettura e le decisioni prese. Idealmente, volevamo che tutte queste informazioni fossero conservate da qualche parte e facilmente accessibili quando necessario. Perciò la nostra tabella è diventata il punto di partenza per la ricerca delle informazioni.

Ma QIWI, pur mantenendo lo spirito di startup, è una grande azienda. Sono già passati 12 anni, e i team cambiano: le persone se ne vanno, altre arrivano, si formano nuovi gruppi. Abbiamo scoperto sul nostro dominio diversi servizi ereditati. Qualcosa è arrivato dai programmatori di altri team, qualcosa semplicemente si riferiva in qualche modo al Portafoglio, quindi ora il servizio è nel nostro saldo. Perché preoccuparsi di cosa e come funziona? Il servizio è attivo e abbiamo funzionalità di prodotto che devono assolutamente essere sviluppate.

Come succede

A un certo punto, ci rendiamo conto che il servizio smette di funzionare, qualcosa si è rotto — come comportarsi in una situazione del genere? Il servizio ha smesso di funzionare. Del tutto. E lo abbiamo scoperto, innanzitutto, per caso, e in secondo luogo, dopo sei mesi. Può succedere. L'unica cosa che sapevamo era su quali virtual machine fosse implementato il servizio, dove si trovassero i suoi sorgenti, e basta. Facciamo un git clone e ci immergiamo nei pensieri di chi scrisse tutto questo qualche anno fa, ma cosa vediamo? Nessun Spring Boot familiare, anche se ci siamo abituati a tutto, dato che abbiamo un full stack e così via. Forse c'è Spring Framework? No, proprio no.

Il ragazzo che ha scritto tutto questo era severo e ha scritto tutto in pura Java. Strumenti familiari per il sviluppatore non ci sono, e sorge un'idea — bisognerebbe riscrivere tutto. Abbiamo microservizi, e da ogni tostapane arriva il familiare «Ragazzi, i microservizi sono ciò di cui avete bisogno!». Se per caso qualcosa non va, potete tranquillamente prendere qualsiasi linguaggio e andrà tutto alla grande.

Il problema è che attualmente non abbiamo un cliente responsabile per questo servizio. Quali erano le sue esigenze commerciali, cosa deve fare questo servizio in realtà? Inoltre, il servizio è strettamente integrato nei vostri processi aziendali.

E ora diteci, quanto è semplice riscrivere il servizio, senza conoscerne le esigenze commerciali? Non è chiaro come viene effettuato il logging, se ci sono delle metriche - è sconosciuto. Quali sono, se ci sono - ancora di più, non lo sappiamo. E in più, nel servizio ci sono un enorme numero di classi di logica aziendale poco chiare. Qualcosa entra in un database di cui non sappiamo ancora nulla.

Da dove cominciare?

Dal punto più logico: dalla presenza di test. Di solito, là è scritta qualche logica e si possono fare conclusioni su cosa sta accadendo. Ora va di moda il TDD, ma vediamo che anche 5 anni fa era praticamente lo stesso di ora: ci sono quasi nessun test unitari, e questi non ci diranno sostanzialmente nulla. A meno che non siano utili per verificare come venga firmato un xml con un certificato personalizzato.

Non siamo riusciti a comprendere nulla dal codice e abbiamo dovuto controllare direttamente sulla virtual machine. Abbiamo aperto i log del servizio e abbiamo trovato un errore legato al client HTTP, un certificato auto-firmato che era incorporato nelle risorse dell'applicazione e che era scaduto. Ci siamo messi in contatto con i nostri analisti, che hanno richiesto un nuovo certificato, che ci è stato fornito, e il servizio ha ripreso a funzionare. Sembrerebbe che sia tutto a posto. O invece no? Comunque il servizio funziona, svolge una funzione necessaria per il nostro business. Abbiamo degli standard di sviluppo delle applicazioni, che probabilmente hai anche tu. Ad esempio, non conservare i log sulla nodi in una cartella, ma memorizzarli in un qualche tipo di storage, come Elasticsearch, e visualizzarli in Kibana. Possiamo anche ricordare le metriche fondamentali. Cioè il carico sul servizio, il numero di richieste al servizio, se è attivo o meno, come passano i controlli di salute. Almeno queste metriche possono aiutare a capire quando è possibile dismetterlo con tranquillità e dimenticarlo come un brutto sogno.

Cosa fare

Quindi aggiungiamo un servizio così datato nella tabella, e poi andiamo a cercare tra i programmatori volontari che si occupino del servizio e lo sistemino: scriveranno almeno alcune informazioni sul servizio, aggiungeranno link ai dashboard in Grafana, agli task di build, e capiranno come distribuire l'applicazione; non è certo il caso di caricare file tramite FTP a mano.

La cosa principale è: quanto tempo richiederà tutta questa utile attività di volontariato? Un sprint per un programmatore abbastanza esperto, ad esempio, durante il 20% del debito tecnico. E quanto tempo ci è voluto per comprendere la logica radicata nelle comunicazioni con un certo sistema governativo e aggiornarla a tecnologie più moderne? Non posso garantire, potrebbe richiedere un mese, o forse due di lavoro del team. Parlo per esperienza di integrazione con qualche nuovo servizio nel contesto attuale.

In questo caso, non c'è alcun valore commerciale. Assolutamente nulla. Prendere un servizio per il supporto e dedicare un po' di tempo a questo è normale. Ma dopo i nostri standard rituali con il servizio, lo abbiamo inserito nella tabella, aggiunto informazioni su di esso e, forse, un giorno lo riscriveremo. Ma al momento, soddisfa i nostri standard per il funzionamento dei servizi.

In sintesi, vorrei arrivare a un certo piano su cosa fare con i servizi legacy.

Riscrivere il legacy da zero è una cattiva idea
Seriamente, non dovresti nemmeno pensarci. È chiaro che ci sono desideri e si vedono alcuni vantaggi, ma di solito non serve a nessuno, incluso voi stessi.

Manuale
Scavare nei codici sorgente delle vostre applicazioni, creare un manuale che indichi che cosa e dove si trova e come funziona, includere anche una descrizione del progetto (un eventuale readme.md), in modo da capire rapidamente dove si trovano i log e le metriche. Lo sviluppatore che dovrà occuparsi di questo dopo di voi vi ringrazierà.

Comprendere il dominio
Se possiedi un dominio, cerca di tenere d'occhio la situazione. Può sembrare banale, ma non tutti si assicurano che i servizi siano coerenti. E lavorare con uno standard unico è in realtà molto più facile.

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