{"id":53442,"date":"2019-12-02T00:00:00","date_gmt":"2019-12-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/legacy-servisy-v-vashej-infrastrukture"},"modified":"2020-02-18T14:01:20","modified_gmt":"2020-02-18T11:01:20","slug":"legacy-servisy-v-vashej-infrastrukture","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/legacy-servisy-v-vashej-infrastrukture","title":{"rendered":"Servizi legacy nella tua infrastruttura","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao! Mi chiamo Pasha Chernyak, sono uno sviluppatore senior presso QIWI, e oggi voglio parlare dell'inevitabile. Di Legacy.<\/p>\n

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

\"Servizi<\/a><\/noindex><\/p>\n

Prima di passare a come lavoriamo con i nostri servizi Legacy in QIWI, vi racconter\u00f2 come abbiamo messo ordine nei servizi del Wallet. Da due anni mi occupo della sua funzionalit\u00e0. Se c'\u00e8 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. <\/p>\n

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

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.
\n<\/a><\/noindex>
\nOltre alle informazioni su chi \u00e8 responsabile di cosa, c'erano risposte a domande: chi \u00e8 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.<\/p>\n

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\u00e9 indicare direttamente gli indirizzi e altre utilit\u00e0. E ovunque la nostra tabella ci permetteva di mantenere attuale lo stato dei nostri servizi. Per noi \u00e8 una sorta di checklist che indica cosa questo servizio pu\u00f2 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\u00ec il nostro foglio \u00e8 diventato un punto di partenza per la ricerca delle informazioni.<\/p>\n

Ma QIWI, pur mantenendo lo spirito di startup, \u00e8 una grande azienda. Abbiamo gi\u00e0 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 \u00e8 arrivato con gli sviluppatori di altri team, qualcosa era in qualche modo collegato a Wallet, quindi ora il servizio \u00e8 nel nostro bilancio. Perch\u00e9 complicarsi con il funzionamento dei servizi? Funzionano, e abbiamo delle funzionalit\u00e0 di prodotto che dobbiamo assolutamente implementare.<\/p>\n

Come spesso accade<\/h2>\n

\nMa a un certo punto ci accorgiamo che il servizio smette di svolgere la sua funzione, qualcosa si \u00e8 rotto \u2014 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\u00f2 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\u2019\u00e8 Spring Framework? E invece no.<\/p>\n

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\u00f2 che vi serve!\". Se qualcosa non va, potrete tranquillamente prendere un linguaggio a scelta e andr\u00e0 tutto bene.<\/p>\n

Il punto \u00e8 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 \u00e8 strettamente integrato nei vostri processi aziendali. <\/p>\n

E ora ditemi, quanto \u00e8 facile riscrivere un servizio senza conoscere le sue esigenze di business? Non \u00e8 chiaro come viene effettuato il logging del servizio, se ci sono metriche \u2014 non lo sappiamo. Quali siano, se ci sono \u2014 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. <\/p>\n

Da dove iniziare?<\/h2>\n

\nDal pi\u00f9 logico \u2014 dalla presenza di test. Di solito l\u00ec \u00e8 scritta almeno un po' di logica e si possono trarre conclusioni su ci\u00f2 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.<\/p>\n

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\u00e0 scaduto. Abbiamo contattato i nostri analisti che hanno richiesto un nuovo certificato, ci \u00e8 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 \u00e8 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\u00e8, il carico sul servizio, il numero di richieste al servizio, se \u00e8 attivo o meno, come passa il suo HealthCheck. Almeno queste metriche aiuteranno a capire quando \u00e8 possibile ritirarlo dall'uso in tutta tranquillit\u00e0 e dimenticarlo come un brutto sogno.<\/p>\n

Cosa fare<\/h2>\n

\nPerci\u00f2 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 \u00e8 certo possibile caricare file tramite ftp a mano. <\/p>\n

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

Tuttavia, non ci sono risultati di valore per il business. Affidare il servizio al supporto e spendere un po' di tempo per questo \u00e8 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.<\/p>\n

Come risultato, vorrei arrivare a un certo piano su cosa fare con i servizi Legacy. <\/p>\n

Riscrivere il legacy da zero \u00e8 una cattiva idea<\/b>
\nSeriamente, non c'\u00e8 nemmeno bisogno di pensarci. \u00c8 chiaro che ci sarebbe piaciuto, e ci sono dei vantaggi, ma di solito non serve a nessuno, nemmeno a voi stessi.<\/p>\n

Riferimento<\/b>
\nScava nei codici sorgente delle tue applicazioni, crea un riferimento in cui sia indicato cosa c'\u00e8 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\u00e0 di questo dopo di te ti ringrazier\u00e0.<\/p>\n

Comprendi il dominio<\/b>
\nSe possiedi un dominio, cerca di tenere sotto controllo la situazione. Suona banale, s\u00ec, ma non tutti si assicurano che i servizi seguano un unico standard. E lavorare in un unico standard \u00e8 davvero molto pi\u00f9 semplice.<\/p>\n

Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n

Cosa fai con il tuo legacy?<\/h2>\n