{"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 vostra infrastruttura","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao! Sono Pasha Chernyak, lead developer in QIWI, e oggi voglio parlare dell'inevitabile. Di Legacy.<\/p>\n

Iniziamo con la domanda: che cos'\u00e8 un servizio Legacy? \u00c8 un servizio che non \u00e8 stato toccato da un developer per una settimana\/mese\/anno? Oppure \u00e8 un servizio scritto da un programmatore meno esperto, per esempio da te, ma un anno fa? E ora sei molto pi\u00f9 capace e esperto. O forse un servizio Legacy \u00e8 quello che hai deciso di non toccare mai pi\u00f9 e per cui 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 pi\u00f9 avanti.<\/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 nel Portafoglio. Sono gi\u00e0 due anni che sono responsabile del suo funzionamento. Se c'\u00e8 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. <\/p>\n

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

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

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\u00e0. E ovunque la nostra tabella consentiva di mantenere aggiornati i nostri servizi. Per noi \u00e8 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\u00f2 la nostra tabella \u00e8 diventata il punto di partenza per la ricerca delle informazioni.<\/p>\n

Ma QIWI, pur mantenendo lo spirito di startup, \u00e8 una grande azienda. Sono gi\u00e0 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 \u00e8 arrivato dai programmatori di altri team, qualcosa semplicemente si riferiva in qualche modo al Portafoglio, quindi ora il servizio \u00e8 nel nostro saldo. Perch\u00e9 preoccuparsi di cosa e come funziona? Il servizio \u00e8 attivo e abbiamo funzionalit\u00e0 di prodotto che devono assolutamente essere sviluppate.<\/p>\n

Come succede<\/h2>\n

\nA un certo punto, ci rendiamo conto che il servizio smette di funzionare, qualcosa si \u00e8 rotto \u2014 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\u00f2 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\u00ec via. Forse c'\u00e8 Spring Framework? No, proprio no.<\/p>\n

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 \u2014 bisognerebbe riscrivere tutto. Abbiamo microservizi, e da ogni tostapane arriva il familiare \u00abRagazzi, i microservizi sono ci\u00f2 di cui avete bisogno!\u00bb. Se per caso qualcosa non va, potete tranquillamente prendere qualsiasi linguaggio e andr\u00e0 tutto alla grande.<\/p>\n

Il problema \u00e8 che attualmente non abbiamo un cliente responsabile per questo servizio. Quali erano le sue esigenze commerciali, cosa deve fare questo servizio in realt\u00e0? Inoltre, il servizio \u00e8 strettamente integrato nei vostri processi aziendali. <\/p>\n

E ora diteci, quanto \u00e8 semplice riscrivere il servizio, senza conoscerne le esigenze commerciali? Non \u00e8 chiaro come viene effettuato il logging, se ci sono delle metriche - \u00e8 sconosciuto. Quali sono, se ci sono - ancora di pi\u00f9, non lo sappiamo. E in pi\u00f9, 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. <\/p>\n

Da dove cominciare?<\/h2>\n

\nDal punto pi\u00f9 logico: dalla presenza di test. Di solito, l\u00e0 \u00e8 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.<\/p>\n

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 \u00e8 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\u00e8 il carico sul servizio, il numero di richieste al servizio, se \u00e8 attivo o meno, come passano i controlli di salute. Almeno queste metriche possono aiutare a capire quando \u00e8 possibile dismetterlo con tranquillit\u00e0 e dimenticarlo come un brutto sogno.<\/p>\n

Cosa fare<\/h2>\n

\nQuindi aggiungiamo un servizio cos\u00ec 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 \u00e8 certo il caso di caricare file tramite FTP a mano. <\/p>\n

La cosa principale \u00e8: quanto tempo richieder\u00e0 tutta questa utile attivit\u00e0 di volontariato? Un sprint per un programmatore abbastanza esperto, ad esempio, durante il 20% del debito tecnico. E quanto tempo ci \u00e8 voluto per comprendere la logica radicata nelle comunicazioni con un certo sistema governativo e aggiornarla a tecnologie pi\u00f9 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.<\/p>\n

In questo caso, non c'\u00e8 alcun valore commerciale. Assolutamente nulla. Prendere un servizio per il supporto e dedicare un po' di tempo a questo \u00e8 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.<\/p>\n

In sintesi, 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 dovresti nemmeno pensarci. \u00c8 chiaro che ci sono desideri e si vedono alcuni vantaggi, ma di solito non serve a nessuno, incluso voi stessi.<\/p>\n

Manuale<\/b>
\nScavare 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\u00e0 occuparsi di questo dopo di voi vi ringrazier\u00e0.<\/p>\n

Comprendere il dominio<\/b>
\nSe possiedi un dominio, cerca di tenere d'occhio la situazione. Pu\u00f2 sembrare banale, ma non tutti si assicurano che i servizi siano coerenti. E lavorare con uno standard unico \u00e8 in realt\u00e0 molto pi\u00f9 facile.<\/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