Servizi legacy nella tua infrastruttura

Ciao! Mi chiamo Pasha Chernyak, sono uno sviluppatore leader di QIWI e oggi voglio parlare dell'inevitabile. A proposito dell'eredità.

Cominciamo con la domanda: cos'è il servizio Legacy? Un servizio legacy è un servizio che lo sviluppatore non ha toccato per una settimana/mese/anno? Oppure è un servizio che è stato scritto da un programmatore meno esperto, ad esempio da te specificatamente, ma un anno fa? E ora sei più figo e più esperto. Oppure il servizio Legacy è un servizio che hai deciso di non impegnare mai più e stai lentamente preparando un sostituto? In ogni caso, lasciare un servizio del genere incustodito e non aggiornarlo è una bomba a orologeria che potrebbe esplodere in seguito.

Prima di passare a come noi di QIWI lavoriamo con i nostri servizi Legacy, ti dirò come abbiamo messo ordine nei servizi nel Portafoglio. Da due anni sono responsabile del suo andamento. Se c'è qualche problema mi chiamano sempre prima. Di solito non ho il coraggio di chiamare qualcun altro alle 11, quindi ho dovuto sedermi e capire tutti i servizi del nostro dominio.

Ma a me, come a tutti, piace dormire la notte, quindi ho cercato di affrontare lo sfruttamento: "Ragazzi, perché mi chiamate?" Alla quale ho ricevuto una risposta piuttosto laconica del tipo "Chi altro?" Perché aggiusto i servizi e i ragazzi semplicemente non sanno chi chiamare.

Pertanto, in una delle retrospettive del team backend di Wallet, abbiamo deciso che dovevamo creare un cartello con un elenco dei nostri servizi, microservizi e monoliti del portafoglio e dei relativi responsabili. I segnali sono generalmente utili, entro limiti ragionevoli.

Oltre alle informazioni su chi è responsabile di cosa, c'erano risposte alle domande: chi è il proprietario del servizio, chi è responsabile del suo sviluppo, architettura e ciclo di vita. Le persone responsabili di questo servizio sono le persone che possono risolverlo se succede qualcosa. Il proprietario del servizio ha il diritto di lasciare +2 nei commit, anche i responsabili devono essere presenti alla revisione prima che questo servizio accetti un nuovo commit.

Col passare del tempo, iniziarono ad essere applicate nuove pratiche, ad esempio la migrazione a Kubernetes, tutti i tipi di checkstyle, spotbug, ktlint, la presenza di log in Kibana, servizi di rilevamento automatico invece di specificare direttamente gli indirizzi e altre cose utili. E ovunque la nostra tavola ci ha permesso di mantenere l'attualità dei nostri servizi. Per noi questa è una sorta di lista di controllo che dice che questo servizio può farlo, ma non è ancora così, ma siamo andati avanti, rendendoci conto che ci mancano informazioni sui nostri servizi, che monitoriamo, dove si trovano le fonti dei servizi, dove vengono avviate le attività di assemblaggio in TeamCity, come vengono implementate, dove sono archiviate le fonti dei test end2end, le foto delle sessioni di preparazione sull'architettura, sulle decisioni prese. Idealmente, vorrei che tutte queste informazioni si trovassero da qualche parte e fossero a portata di mano quando necessario. Pertanto, il nostro segno è diventato il punto di partenza per la ricerca di informazioni.

Ma QIWI, pur conservando lo spirito di una startup, è una grande azienda. Abbiamo già 12 anni e le squadre stanno cambiando: le persone se ne vanno, le persone arrivano, si formano nuove squadre. E abbiamo scoperto diversi servizi sul nostro dominio che abbiamo ereditato. Alcuni provenivano da sviluppatori di altri team, altri semplicemente erano in qualche modo indirettamente collegati al Wallet, quindi ora abbiamo il servizio nel nostro bilancio. Capire cosa e come funziona: perché? Il servizio funziona e abbiamo caratteristiche del prodotto che devono sicuramente essere migliorate.

Come succede

Ma ad un certo punto scopriamo che il servizio smette di svolgere la sua funzione, qualcosa è rotto: cosa fare in una situazione del genere? Il servizio ha semplicemente smesso di funzionare. Affatto. E lo abbiamo scoperto, in primo luogo, per caso e, in secondo luogo, sei mesi dopo. Succede. Sapevamo solo su quali macchine virtuali sarebbe stato distribuito il servizio, dove si trovavano le sue fonti e questo è tutto. Facciamo un clone di git e ci immergiamo nella mente della persona che ha scritto questo qualche anno fa, ma cosa vediamo? Nessuno degli Spring Boot che ci sono familiari, anche se siamo abituati a tutto, abbiamo lo stack completo e tutto il resto. Forse c'è uno Spring Framework lì? Ma no.

Il ragazzo che ha scritto tutto questo era un duro e ha scritto tutto in puro Java. Non esistono gli strumenti usuali per uno sviluppatore e nasce un'idea: dobbiamo riscrivere tutto questo. Abbiamo i microservizi e da ogni tostapane arriva il solito "Ragazzi, i microservizi sono ciò di cui avete bisogno!" Se all'improvviso qualcosa va storto, puoi tranquillamente prendere qualsiasi lingua e tutto andrà bene.

Il fatto è che ora non abbiamo un cliente responsabile di questo servizio. Quali requisiti aziendali aveva, cosa dovrebbe fare questo servizio? E il servizio è strettamente integrato nei vostri processi aziendali.

Ora ditemi, quanto è facile riscrivere un servizio senza conoscerne i requisiti aziendali? Non è chiaro come venga registrato il servizio; non è noto se siano presenti metriche. Cosa siano, se ce ne sono, è ancora più sconosciuto. E allo stesso tempo, il servizio contiene un numero enorme di classi di logica aziendale incomprensibile. Qualcosa è incluso in una sorta di database, di cui non sappiamo ancora nulla.

Con che cosa iniziare?

Dal punto più logico: la disponibilità dei test. Di solito c'è almeno una logica scritta lì e puoi trarre conclusioni su ciò che sta accadendo. Adesso il TDD è di moda, ma vediamo che 5 anni fa tutto era quasi uguale a adesso: non ci sono quasi test unitari e non ci diranno nulla. Bene, tranne forse qualche tipo di verifica, come alcuni XML sono firmati con un certificato personalizzato.

Non siamo riusciti a capire nulla dal codice, quindi siamo andati a vedere cosa c'era nella macchina virtuale. Abbiamo aperto i log del servizio e abbiamo trovato un errore del client http; il certificato autofirmato incorporato nelle risorse dell'applicazione era spudoratamente marcio. Abbiamo contattato i nostri analisti, hanno chiesto un nuovo certificato, ce lo hanno rilasciato e il servizio funziona di nuovo. Sembrerebbe che questo sia tutto. O no? Dopotutto, il servizio funziona, svolge alcune funzioni di cui la nostra azienda ha bisogno. Abbiamo determinati standard per lo sviluppo delle applicazioni, che molto probabilmente hai anche tu. Ad esempio, non archiviare i log sul nodo in una cartella, ma archiviarli in qualche tipo di archivio, come elastico, e guardarli in Kibana. Puoi anche ricordare le metriche d'oro. Cioè il carico sul servizio, il numero di richieste per il servizio, se è vivo o no, come sta andando il suo HealthCheck. Per lo meno, questi parametri ti aiuteranno a sapere quando può essere messo fuori servizio con la coscienza pulita e dimenticato come un brutto sogno.

Cosa fare

Pertanto, aggiungiamo al tavolo un servizio così vecchio, e poi andiamo a cercare volontari tra gli sviluppatori che si prenderanno cura del servizio e lo metteranno in ordine: scriveranno almeno alcune informazioni sul servizio, aggiungeranno collegamenti a dashboard in Grafana, alle attività di assemblaggio e alla comprensione di come distribuire l'applicazione, non caricare manualmente i file utilizzando ftp.

La cosa principale è: quanto tempo durerà tutta questa utile attività di volontariato? Uno sprint per uno sviluppatore più o meno esperto, ad esempio, durante un debito tecnico del 20%. Quanto tempo ci è voluto per comprendere tutta la logica radicata della comunicazione con un determinato sistema statale e portarla alle nuove tecnologie? Non posso garantire per questo, forse un mese o forse due di lavoro del team. Lo dico per esperienza di attuale integrazione con qualche nuovo servizio.

Allo stesso tempo, non vi è alcun rilascio di valore aziendale. Affatto. È normale assumere un servizio di supporto e dedicargli un po’ di tempo. Ma dopo che i nostri standard hanno ballato con il servizio, lo abbiamo aggiunto alla tabella, abbiamo aggiunto informazioni al riguardo e, forse, un giorno lo riscriveremo. Ma ora soddisfa i nostri standard di servizio.

Di conseguenza, vorrei elaborare un piano su cosa fare con i servizi Legacy.

Riscrivere l’eredità da zero è una cattiva idea
Sul serio, non devi nemmeno pensarci. È chiaro che mi piacerebbe e ci sono alcuni vantaggi, ma di solito nessuno ne ha bisogno, incluso te stesso.

Elenco
Estrai i codici sorgente delle tue applicazioni, crea un libro di consultazione che indichi cosa è dove e come funziona, inserisci lì una descrizione del progetto (readme.md condizionale) per capire rapidamente dove si trovano i log e le metriche. Lo sviluppatore che si occuperà di questo dopo di te ti dirà solo grazie.

Comprendere il dominio
Se possiedi un dominio, cerca di tenere il passo con il polso. Sembra banale, sì, ma non tutti fanno in modo che i servizi siano in un’unica chiave. Ma lavorare secondo uno standard è in realtà molto più semplice.

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Cosa fai con la tua eredità?

• 31.5%Lo riscrivo da zero, è più corretto 12

• 52.6%Quasi uguale a te20

• 10.5%Non abbiamo eredità, siamo fantastici4

• 5.2%Scriverò nei commenti2

38 utenti hanno votato. 20 utenti si sono astenuti.

Fonte: habr.com