🥇Serveis antics a la vostra infraestructura

Hola! Em dic Pasha Chernyak, sóc un desenvolupador líder a QIWI i avui vull parlar de l'inevitable. Sobre Legacy.

Comencem amb la pregunta: què és el servei Legacy? Un servei heretat és un servei que el desenvolupador no ha tocat durant una setmana/mes/any? O és un servei que va ser escrit per un programador menys experimentat, per exemple, per tu específicament, però fa un any? I ara ets més genial i amb més experiència. O el servei Legacy és un servei que heu decidit no tornar a comprometre's i que a poc a poc esteu preparant un reemplaçament? En qualsevol cas, deixar aquest servei sense vigilància i no actualitzar és una bomba de rellotgeria que pot explotar més tard.

Abans de passar a com treballem a QIWI amb els nostres serveis Legacy, us explicaré com hem fet ordre als serveis de Wallet. Fa dos anys que sóc responsable de la seva actuació. Si hi ha algun problema, sempre em truquen primer. Normalment no tinc el valor de trucar a algú altre a les 11:XNUMX, així que vaig haver d'asseure'm i esbrinar tots els serveis del nostre domini.

Però a mi, com a qualsevol persona, m'agrada dormir a la nit, així que vaig intentar fer front a l'explotació: "Nois, per què em truqueu?" A la qual vaig rebre una resposta força lacònica com "Qui més?" Perquè arreglo serveis i els nois simplement no saben a qui trucar.

Per això, en una de les retrospectives de l'equip backend de Wallet, vam decidir que calia fer un rètol amb una llista dels nostres serveis, microserveis i monòlits de wallet, i els responsables d'ells. Els senyals són generalment útils, dins de límits raonables.

A més de la informació sobre qui és el responsable de què, hi havia respostes a les preguntes: qui és el propietari del servei, qui és el responsable del seu desenvolupament, arquitectura i cicle de vida. Els responsables d'aquest servei són les persones que poden solucionar-ho si passa alguna cosa. El propietari del servei té dret a deixar +2 en commits, els responsables també han d'estar presents a la revisió abans que aquest servei accepti un nou commit.

Amb el pas del temps, es van començar a aplicar noves pràctiques, per exemple, la migració a Kubernetes, tot tipus d'estils de verificació, errors puntuals, ktlint, la presència de registres a Kibana, serveis de descoberta automàtica en lloc d'especificar directament adreces i altres coses útils. I arreu la nostra taula ens va permetre mantenir la rellevància dels nostres serveis. Per a nosaltres, aquesta és una mena de llista de verificació que diu que aquest servei pot fer-ho, però encara no ho fa, però vam seguir endavant, adonant-nos que ens falta informació sobre els nostres serveis, que controlem, on es troben les fonts del servei. on es llancen les tasques de muntatge a TeamCity, com es despleguen, on s'emmagatzemen les fonts de les proves end2end, fotos de sessions de preparació sobre l'arquitectura, sobre les decisions preses. Idealment, m'agradaria que tota aquesta informació estigués en algun lloc i estigués a mà quan calgui. Per tant, el nostre rètol es va convertir en el punt de partida per a la recerca d'informació.

Però QIWI, tot i que conserva l'esperit d'una startup, és una gran empresa. Ja tenim 12 anys, i els equips estan canviant: la gent marxa, la gent ve, es formen nous equips. I vam descobrir diversos serveis al nostre domini que vam heretar. Alguns provenien de desenvolupadors d'altres equips, d'altres simplement d'alguna manera indirectament relacionats amb Wallet, de manera que ara tenim el servei al nostre balanç. Comprendre què i com funciona, per què? El servei funciona i tenim característiques del producte que definitivament s'han de millorar.

Com passa

Però en algun moment descobrim que el servei deixa de fer la seva funció, alguna cosa es trenca: què fer en una situació així? El servei simplement va deixar de funcionar. En absolut. I d'això ens vam assabentar, en primer lloc, per casualitat, i en segon lloc, sis mesos després. Això passa. L'únic que sabíem era en quines màquines virtuals es desplegaria el servei, on es trobaven les seves fonts, i això és tot. Fem un clon de git i ens submergim a la ment de la persona que va escriure això fa uns anys, però què veiem? Cap de la Spring Boot que ens és familiar, encara que estem acostumats a tot, tenim una pila completa i tot això. Potser hi ha un marc de primavera? Però no.

El tipus que va escriure tot això era dur i ho va escriure tot en Java pur. No hi ha eines habituals per a un desenvolupador, i sorgeix una idea: hem de reescriure tot això. Tenim microserveis, i de cada torradora surt l'habitual "Nois, els microserveis són el que necessiteu!" Si de sobte alguna cosa va malament, pots prendre qualsevol idioma amb calma i tot anirà bé.

El cas és que ara no tenim cap client responsable d'aquest servei. Quins requisits empresarials tenia, què hauria de fer aquest servei? I el servei està estretament integrat als vostres processos empresarials.

Ara digueu-me, què tan fàcil és reescriure un servei sense conèixer els seus requisits empresarials? No està clar com es registra el servei, es desconeix si hi ha mètriques. Quins són, si n'hi ha, és encara més desconegut. I al mateix temps, el servei conté un gran nombre de classes de lògica empresarial incomprensible. Alguna cosa s'inclou en algun tipus de base de dades, de la qual encara no sabem res.

On començar?

Des del punt més lògic: la disponibilitat de proves. Normalment hi ha almenys una mica de lògica escrita allà i pots treure conclusions sobre el que està passant. Ara el TDD està de moda, però veiem que fa 5 anys tot era gairebé igual que ara: gairebé no hi ha proves unitàries, i no ens diuen res. Bé, excepte potser algun tipus de verificació, com alguns xml estan signats amb algun certificat personalitzat.

No vam poder entendre res del codi, així que vam anar a veure què hi havia a la màquina virtual. Vam obrir els registres del servei i vam trobar-hi un error de client http que el certificat autofirmat que estava incrustat als recursos de l'aplicació estava descaradament podrit. Ens vam posar en contacte amb els nostres analistes, ens van demanar un nou certificat, ens el van emetre i el servei torna a funcionar. Sembla que això és tot. O no? Al cap i a la fi, el servei funciona, realitza alguna funció que el nostre negoci necessita. Tenim certs estàndards per al desenvolupament d'aplicacions, que probablement també tingueu. Per exemple, no deseu els registres al node en una carpeta, sinó que els emmagatzemeu en algun tipus d'emmagatzematge, com ara elàstic, i mireu-los a Kibana. També podeu recordar les mètriques daurades. És a dir, la càrrega del servei, el nombre de peticions del servei, si està viu o no, com va el seu HealthCheck. Com a mínim, aquestes mètriques us ajudaran a saber quan es pot treure del servei amb la consciència tranquil·la i oblidar-lo com un mal somni.

Què fer

Per tant, afegim un servei tan antic a la taula, i després anem a buscar voluntaris entre els desenvolupadors que s'encarregaran del servei i el posaran en ordre: escriuran almenys una mica d'informació sobre el servei, afegiran enllaços a taulers de control a grafana, per a les tasques de muntatge i entendre com Desplegar l'aplicació, no carregueu fitxers manualment mitjançant ftp.

El més important és quant de temps durarà tota aquesta útil activitat de voluntariat? Un sprint per a un desenvolupador més o menys experimentat, per exemple, durant un deute tècnic del 20%. Quant de temps va trigar a comprendre tota la lògica arrelada de comunicar-se amb un determinat sistema estatal i portar-lo a les noves tecnologies? No puc garantir això, potser un mes o potser dos del treball de l'equip. Ho dic per experiència d'integració actual amb algun servei nou.

Al mateix temps, no hi ha cap alliberament de valor comercial. En absolut. És normal contractar un servei de suport i dedicar-hi una mica de temps. Però després dels nostres balls estàndard amb el servei, el vam afegir a la taula, vam afegir informació sobre ell i, potser, el reescriurem algun dia. Però ara compleix els nostres estàndards de servei.

Com a resultat, m'agradaria elaborar un pla sobre què fer amb els serveis Legacy.

Reescriure el llegat des de zero és una mala idea
De debò, no cal ni pensar-hi. Està clar que m'agradaria, i hi ha alguns avantatges, però normalment ningú ho necessita, ni tu mateix.

Manual
Descobriu els codis font de les vostres aplicacions, feu un llibre de referència que indiqui què és on i com funciona, introduïu-hi una descripció del projecte (readme.md condicional) per entendre ràpidament on es troben els registres i les mètriques. El desenvolupador que s'ocuparà d'això després de vosaltres només us donarà les gràcies.

Entendre el domini
Si teniu un domini, proveu de mantenir el dit al pols. Sembla trivial, sí, però no tothom s'assegura que els serveis estiguin en una sola clau. Però treballar en un estàndard és realment molt més fàcil.

Només els usuaris registrats poden participar en l'enquesta. Inicia sessiósi us plau.