Heredaĵoj en via infrastrukturo

Saluton! Mi nomiĝas Pasha Chernyak, mi estas ĉefa programisto ĉe QIWI, kaj hodiaŭ mi volas paroli pri la neevitebla. Pri Heredaĵo.

Ni komencu kun la demando: kio estas Legacy-servo? Ĉu hereda servo estas servo, kiun la programisto ne tuŝis dum semajno/monato/jaro? Aŭ ĉu ĝi estas servo verkita de malpli sperta programisto, ekzemple, de vi specife, sed antaŭ unu jaro? Kaj nun vi estas pli malvarmeta kaj pli sperta. Aŭ ĉu la Legacy-servo estas servo, kiun vi decidis neniam fari denove kaj malrapide preparas anstataŭaĵon por ĝi? Ĉiukaze, lasi tian servon neatendita kaj ne ĝisdatigi estas horloĝbombo, kiu eble eksplodos poste.

Antaŭ ol daŭrigi kiel ni ĉe QIWI laboras kun niaj Heredaĵaj servoj, mi rakontos al vi kiel ni ordonis al la servoj en la Monujo. Jam de du jaroj mi respondecas pri ĝia agado. Se estas ia problemo, ili ĉiam vokas min unue. Mi kutime ne havas la nervon voki iun alian je la 11:XNUMX, do mi devis sidiĝi kaj eltrovi ĉiujn servojn en nia domajno.

Sed mi, kiel ĉiu homo, ŝatas dormi nokte, do mi provis trakti la ekspluaton: "Knaboj, kial vi vokas min?" Al kiu mi ricevis sufiĉe lakonan respondon kiel "Kiu alia?" Ĉar mi riparas servojn, kaj la uloj simple ne scias kiun voki.

Tial, ĉe unu el la retrospektivoj de la backend-teamo de Wallet, ni decidis, ke ni bezonas fari signon kun listo de niaj servoj, mikroservoj kaj monujoj monolitoj, kaj la respondecaj pri ili. Signoj estas ĝenerale utilaj, ene de raciaj limoj.

Krom informoj pri kiu respondecas pri kio, estis respondoj al la demandoj: kiu estas la posedanto de la servo, kiu respondecas pri ĝia evoluo, arkitekturo kaj vivociklo. La respondecaj pri ĉi tiu servo estas la homoj, kiuj povas ripari ĝin se io okazas. La posedanto de la servo rajtas lasi +2 en kommits, la respondecaj ankaŭ devas ĉeesti ĉe la revizio antaŭ ol ĉi tiu servo akceptas novan kommit.

Kun la paso de la tempo, novaj praktikoj komencis esti aplikataj, ekzemple migrado al Kubernetes, ĉiaj kontrolstiloj, spotbugs, ktlint, ĉeesto de protokoloj en Kibana, aŭtomalkovraj servoj anstataŭ rekte specifi adresojn kaj aliajn utilajn aferojn. Kaj ĉie nia tablo permesis al ni konservi la gravecon de niaj servoj. Por ni, ĉi tio estas speco de kontrolo, kiu diras, ke ĉi tiu servo povas fari tion, sed ĝi ankoraŭ ne.Sed ni pluiris, konsciante, ke mankas al ni informoj pri niaj servoj, kiujn ni kontrolas, kie troviĝas la servofontoj , kie asembleaj taskoj estas lanĉitaj en TeamCity, kiel ili estas deplojitaj, kie la fontoj de end2end-testoj estas stokitaj, fotoj de prizorgaj sesioj pri la arkitekturo, pri la decidoj faritaj. Ideale, mi ŝatus, ke ĉiuj ĉi tiuj informoj kuŝu ie kaj estu ĉe mano kiam bezonate. Tial nia signo fariĝis la deirpunkto por serĉado de informoj.

Sed QIWI, kvankam ĝi konservas la spiriton de noventrepreno, estas granda kompanio. Ni jam aĝas 12 jarojn, kaj teamoj ŝanĝiĝas: homoj foriras, homoj venas, novaj teamoj formiĝas. Kaj ni malkovris plurajn servojn en nia domajno, kiujn ni heredis. Iuj venis de programistoj de aliaj teamoj, iuj simple iel nerekte rilataj al la Monujo, do ni nun havas la servon en nia bilanco. Kompreni kio kaj kiel ĝi funkcias - kial? La servo funkcias, kaj ni havas produktajn funkciojn, kiuj certe devas esti plibonigitaj.

Kiel ĝi okazas

Sed iam ni malkovras, ke la servo ĉesas plenumi sian funkcion, io estas rompita - kion fari en tia situacio? La servo simple ĉesis funkcii. Entute. Kaj ni eksciis pri tio, unue, hazarde, kaj due, ses monatojn poste. Ĝi okazas. La nura afero, kiun ni sciis, estis sur kiuj virtualaj maŝinoj la servo estos deplojita, kie ĝiaj fontoj troviĝas, kaj jen ĉio. Ni faras git-klonon kaj plonĝas en la menson de la persono, kiu skribis ĉi tion antaŭ kelkaj jaroj, sed kion ni vidas? Neniu el la Printempa Boto, kiu estas konata al ni, kvankam ni estas kutimaj al ĉio, ni havas plenan stakon kaj ĉio tio. Eble ekzistas Printempa Kadro tie? Sed ne.

La ulo, kiu skribis ĉion ĉi, estis malmola kaj skribis ĉion en pura Java. Ne ekzistas kutimaj iloj por programisto, kaj ekestas ideo: ni devas reverki ĉion ĉi. Ni havas mikroservojn, kaj el ĉiu panrostilo venas la kutima "Knaboj, mikroservoj estas tio, kion vi bezonas!" Se subite io misfunkcias, vi povas trankvile preni ajnan lingvon kaj ĉio estos en ordo.

La afero estas, ke nun ni ne havas klienton, kiu respondecas pri ĉi tiu servo. Kiajn komercajn postulojn li havis, kion faru ĉi tiu servo? Kaj la servo estas forte integrita en viajn komercajn procezojn.

Nun diru al mi, kiom facile estas reverki servon sen scii ĝiajn komercajn postulojn? Ne estas klare kiel la servo estas registrita; ĉu ekzistas metrikoj estas nekonata. Kio ili estas, se ekzistas, estas des pli nekonata. Kaj samtempe, la servo enhavas grandegan nombron da klasoj de nekomprenebla komerca logiko. Io estas inkluzivita en ia datumbazo, pri kio ni ankaŭ ankoraŭ nenion scias.

Kie komenci?

De la plej logika punkto - la havebleco de testoj. Estas kutime almenaŭ iom da logiko skribita tie kaj vi povas tiri konkludojn pri kio okazas. Nun TDD estas moda, sed ni vidas, ke antaŭ 5 jaroj ĉio estis preskaŭ sama kiel nun: preskaŭ ne ekzistas unutestoj, kaj ili nenion diros al ni. Nu, krom eble ia konfirmo, kiel iu xml estas subskribita per iu kutima atestilo.

Ni povis kompreni ion ajn el la kodo, do ni iris por vidi kio estas en la virtuala maŝino. Ni malfermis la servajn protokolojn kaj trovis en ili http-klient-eraron; la memsubskribita atestilo, kiu estis enigita en la aplikaĵaj rimedoj, estis senhonte putra. Ni kontaktis niajn analizistojn, ili petis novan atestilon, ili elsendis ĝin al ni kaj la servo denove funkcias. Ŝajnus, ke tio estas ĉio. Aŭ ne? Post ĉio, la servo funkcias, ĝi plenumas iun funkcion, kiun nia komerco bezonas. Ni havas iujn normojn por disvolvo de aplikaĵoj, kiujn plej verŝajne ankaŭ vi havas. Ekzemple, ne stoku protokolojn sur la nodo en dosierujo, sed konservu ilin en ia stokado, kiel elasta, kaj rigardu ilin en Kibana. Vi ankaŭ povas memori la orajn metrikojn. Tio estas, la ŝarĝo de la servo, la nombro da petoj por la servo, ĉu li vivas aŭ ne, kiel iras lia HealthCheck. Almenaŭ, ĉi tiuj metrikoj helpos vin scii, kiam ĝi povas esti forigita kun pura konscienco kaj forgesita kiel malbona sonĝo.

Kion fari?

Tial ni aldonas tian malnovan servon al la tablo, kaj poste ni serĉas volontulojn inter la programistoj, kiuj prizorgos la servon kaj ordigos ĝin: ili skribos almenaŭ kelkajn informojn pri la servo, aldonos ligilojn al paneloj en grafana, por kunvenigi taskojn, kaj kompreni kiel Deploji la aplikaĵon, ne mane alŝutu dosierojn per ftp.

La ĉefa afero estas kiom longe daŭros ĉi tiu utila volontula agado? Unu sprint por pli-malpli sperta programisto, ekzemple, dum 20% teknika ŝuldo. Kiom da tempo daŭris por kompreni la tutan enradikiĝintan logikon de komunikado kun certa ŝtata sistemo kaj alporti ĝin al pli novaj teknologioj? Mi ne povas garantii pri tio, eble monaton aŭ eble du el la laboro de la teamo. Mi diras tion pro sperto pri nuna integriĝo kun iu nova servo.

Samtempe, ne estas liberigo de komerca valoro. Entute. Estas normale dungi servon por subteno kaj pasigi iom da tempo por ĝi. Sed post niaj normaj dancoj kun la servo, ni aldonis ĝin al la tablo, aldonis informojn pri ĝi kaj, eble, reverkos ĝin iam. Sed nun ĝi plenumas niajn servajn normojn.

Kiel rezulto, mi ŝatus elpensi planon pri tio, kion fari kun Heredaĵaj servoj.

Reskribi heredaĵon de nulo estas malbona ideo
Serioze, vi eĉ ne devas pensi pri tio. Estas klare, ke mi ŝatus ĝin, kaj estas kelkaj avantaĝoj, sed kutime neniu bezonas ĝin, inkluzive de vi mem.

Adresaro
Elfosu la fontkodojn de viaj aplikaĵoj, faru konsultlibron, kiu indikos kio estas kie kaj kiel ĝi funkcias, enigu priskribon de la projekto tie (kondiĉa readme.md) por rapide kompreni kie troviĝas la protokoloj kaj metrikoj. La programisto, kiu traktos ĉi tion post vi, nur diros dankon.

Komprenu la domajnon
Se vi posedas domajnon, provu teni vian fingron sur la pulso. Sonas bagatela, jes, sed ne ĉiuj certigas, ke la servoj estas en ununura ŝlosilo. Sed labori en unu normo efektive estas signife pli facila.

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Kion vi faras kun via heredaĵo?

• 31.5%Mi reverkas de nulo, estas pli ĝusta 12

• 52.6%Preskaŭ same kiel vi20

• 10.5%Ni ne havas heredaĵon, ni estas bonegaj4

• 5.2%Mi skribos en la komentoj2

38 uzantoj voĉdonis. 20 uzantoj sindetenis.

fonto: www.habr.com