Mga legacy na serbisyo sa iyong imprastraktura

Kamusta! Ang pangalan ko ay Pasha Chernyak, ako ay isang nangungunang developer sa QIWI, at ngayon gusto kong pag-usapan ang hindi maiiwasan. Tungkol sa Legacy.

Magsimula tayo sa tanong: ano ang serbisyo ng Legacy? Ang isang legacy na serbisyo ba ay isang serbisyo na hindi nahawakan ng developer sa loob ng isang linggo/buwan/taon? O ito ba ay isang serbisyo na isinulat ng isang hindi gaanong karanasan na programmer, halimbawa, sa iyo partikular, ngunit isang taon na ang nakalipas? At ngayon ikaw ay mas cool at mas karanasan. O ang serbisyo ng Legacy ay isang serbisyo na napagpasyahan mong hindi na muling gagawin at dahan-dahang naghahanda ng kapalit para dito? Sa anumang kaso, ang pag-iwan sa naturang serbisyo nang walang pag-aalaga at hindi pag-update ay isang time bomb na maaaring sumabog sa ibang pagkakataon.

Mga legacy na serbisyo sa iyong imprastraktura

Bago magpatuloy sa kung paano kami sa QIWI ay nagtatrabaho sa aming mga serbisyo sa Legacy, sasabihin ko sa iyo kung paano namin dinala ang order sa mga serbisyo sa Wallet. Dalawang taon na akong responsable sa pagganap nito. Kung may problema, lagi nila akong unang tinatawag. Karaniwang wala akong lakas ng loob na tumawag sa ibang tao sa 11 pm, kaya kailangan kong umupo at alamin ang lahat ng mga serbisyo sa aming domain.

Ngunit ako, tulad ng sinumang tao, ay gustong matulog sa gabi, kaya sinubukan kong harapin ang pagsasamantala: "Guys, bakit mo ako tinatawagan?" Kung saan nakatanggap ako ng medyo walang katuturang sagot tulad ng "Sino pa?" Dahil nag-aayos ako ng mga serbisyo, at hindi alam ng mga lalaki kung sino ang tatawagan.

Samakatuwid, sa isa sa mga retrospective ng Wallet backend team, nagpasya kaming kailangan naming gumawa ng sign na may listahan ng aming mga serbisyo, microservice at wallet monolith, at ang mga responsable para sa kanila. Ang mga palatandaan ay karaniwang kapaki-pakinabang, sa loob ng makatwirang limitasyon.

Bilang karagdagan sa impormasyon tungkol sa kung sino ang may pananagutan para sa kung ano, may mga sagot sa mga tanong: sino ang may-ari ng serbisyo, na responsable para sa pag-unlad, arkitektura at ikot ng buhay nito. Ang mga taong responsable para sa serbisyong ito ay ang mga taong maaaring ayusin ito kung may mangyari. Ang may-ari ng serbisyo ay may karapatang mag-iwan ng +2 sa mga commit, ang mga responsable ay dapat ding naroroon sa pagsusuri bago ang serbisyong ito ay tumanggap ng isang bagong pangako.

Sa paglipas ng panahon, nagsimulang ilapat ang mga bagong kasanayan, halimbawa, paglipat sa Kubernetes, lahat ng uri ng checkstyle, mga spotbug, ktlint, pagkakaroon ng mga log sa Kibana, mga serbisyo ng autodiscovery sa halip na direktang tukuyin ang mga address at iba pang kapaki-pakinabang na bagay. At kahit saan pinahintulutan kami ng aming talahanayan na mapanatili ang kaugnayan ng aming mga serbisyo. Para sa amin, ito ay isang uri ng checklist na nagsasabing magagawa ito ng serbisyong ito, ngunit hindi pa. Ngunit lumipat kami, napagtanto na kulang kami ng impormasyon tungkol sa aming mga serbisyo, na aming sinusubaybayan, kung saan matatagpuan ang mga mapagkukunan ng serbisyo , kung saan inilulunsad ang mga gawain sa pagpupulong sa TeamCity, kung paano idine-deploy ang mga ito, kung saan naka-imbak ang mga source ng end2end test, mga larawan mula sa mga sesyon ng pag-aayos tungkol sa arkitektura, tungkol sa mga desisyong ginawa. Sa isip, gusto kong ang lahat ng impormasyong ito ay nasa isang lugar at nasa kamay kung kinakailangan. Samakatuwid, ang aming tanda ay naging panimulang punto para sa paghahanap ng impormasyon.

Ngunit ang QIWI, bagama't pinapanatili nito ang diwa ng isang startup, ay isang malaking kumpanya. Kami ay 12 taong gulang na, at ang mga koponan ay nagbabago: ang mga tao ay umalis, ang mga tao ay darating, ang mga bagong koponan ay nabuo. At natuklasan namin ang ilang serbisyo sa aming domain na minana namin. Ang ilan ay nagmula sa mga developer mula sa ibang mga koponan, ang ilan ay hindi direktang nauugnay sa Wallet, kaya mayroon na kaming serbisyo sa aming balanse. Pag-unawa sa kung ano at paano ito gumagana - bakit? Gumagana ang serbisyo, at mayroon kaming mga feature ng produkto na tiyak na kailangang pagbutihin.

Paano ito nangyayari

Ngunit sa ilang mga punto sa oras na natuklasan namin na ang serbisyo ay huminto sa pagsasagawa nito, may nasira - ano ang gagawin sa ganoong sitwasyon? Ang serbisyo ay tumigil lamang sa paggana. Sa lahat. At nalaman namin ang tungkol dito, una, nang hindi sinasadya, at pangalawa, makalipas ang anim na buwan. Nangyayari ito. Ang tanging alam lang namin ay kung saang mga virtual machine ipapakalat ang serbisyo, kung saan matatagpuan ang mga source nito, at iyon lang. Gumagawa kami ng git clone at sumisid sa isip ng taong sumulat nito ilang taon na ang nakakaraan, ngunit ano ang nakikita natin? Wala sa Spring Boot na pamilyar sa amin, bagama't nakasanayan na namin ang lahat, mayroon kaming isang buong stack at lahat ng iyon. Baka may Spring Framework doon? Pero hindi.

Ang taong sumulat ng lahat ng ito ay matigas at isinulat ang lahat sa purong Java. Walang karaniwang mga tool para sa isang developer, at isang ideya ang lumitaw: kailangan nating muling isulat ang lahat ng ito. Mayroon kaming mga microservice, at mula sa bawat toaster ay nagmumula ang karaniwang "Guys, microservices ang kailangan mo!" Kung biglang may mali, maaari mong mahinahon na kumuha ng anumang wika at magiging maayos ang lahat.

Ang bagay ay ngayon wala kaming customer na responsable para sa serbisyong ito. Anong mga kinakailangan sa negosyo ang mayroon siya, ano ang dapat gawin ng serbisyong ito? At mahigpit na isinama ang serbisyo sa mga proseso ng iyong negosyo.

Ngayon sabihin sa akin, gaano kadaling isulat muli ang isang serbisyo nang hindi nalalaman ang mga kinakailangan sa negosyo nito? Hindi malinaw kung paano naka-log ang serbisyo; kung mayroong mga sukatan ay hindi alam. Kung ano sila, kung mayroon man, ay higit na hindi kilala. At sa parehong oras, ang serbisyo ay naglalaman ng isang malaking bilang ng mga klase ng hindi maintindihan na lohika ng negosyo. May kasama sa ilang uri ng database, na wala pa rin kaming nalalaman tungkol dito.

Saan magsisimula?

Mula sa pinaka-lohikal na punto - ang pagkakaroon ng mga pagsubok. Kadalasan mayroong kahit ilang logic na nakasulat doon at maaari kang gumawa ng mga konklusyon tungkol sa kung ano ang nangyayari. Ngayon ang TDD ay naka-istilong, ngunit nakita namin na 5 taon na ang nakaraan ang lahat ay halos pareho sa ngayon: halos walang mga pagsubok sa yunit, at hindi nila sasabihin sa amin ang anumang bagay. Well, maliban sa ilang uri ng pag-verify, kung paano nilalagdaan ang ilang xml gamit ang ilang custom na certificate.

Wala kaming maintindihan mula sa code, kaya pumunta kami upang makita kung ano ang nasa virtual machine. Binuksan namin ang mga log ng serbisyo at nakakita ng error sa http client sa mga ito; walang kahihiyang bulok ang self-signed certificate na naka-embed sa mga mapagkukunan ng application. Nakipag-ugnayan kami sa aming mga analyst, humingi sila ng isang bagong sertipiko, inisyu nila ito sa amin at gumagana muli ang serbisyo. Mukhang iyon lang. O hindi? Pagkatapos ng lahat, gumagana ang serbisyo, gumaganap ito ng ilang function na kailangan ng aming negosyo. Mayroon kaming ilang mga pamantayan para sa pagbuo ng application, na malamang na mayroon ka rin. Halimbawa, huwag mag-imbak ng mga log sa node sa isang folder, ngunit itabi ang mga ito sa ilang uri ng imbakan, tulad ng elastic, at tingnan ang mga ito sa Kibana. Maaalala mo rin ang mga gintong sukatan. Iyon ay, ang load sa serbisyo, ang bilang ng mga kahilingan para sa serbisyo, kung siya ay buhay o hindi, kung paano ang kanyang HealthCheck ay nangyayari. Hindi bababa sa, ang mga sukatan na ito ay makakatulong sa iyo na malaman kung kailan ito maaaring alisin sa serbisyo nang may malinis na budhi at nakalimutan tulad ng isang masamang panaginip.

Ano ang dapat gawin

Samakatuwid, nagdaragdag kami ng isang lumang serbisyo sa talahanayan, at pagkatapos ay naghahanap kami ng mga boluntaryo mula sa mga developer na mag-aalaga sa serbisyo at ayusin ito: magsusulat sila ng hindi bababa sa ilang impormasyon tungkol sa serbisyo, magdagdag ng mga link sa dashboard sa grafana, sa mga gawain sa pagpupulong, at unawain kung paano I-deploy ang application, huwag manu-manong mag-upload ng mga file gamit ang ftp.

Ang pangunahing bagay ay kung gaano katagal ang lahat ng kapaki-pakinabang na aktibidad ng boluntaryong ito? Isang sprint para sa mas marami o mas kaunting karanasang developer, halimbawa, sa panahon ng 20% ​​teknikal na utang. Gaano katagal bago maunawaan ang lahat ng nakatanim na lohika ng pakikipag-usap sa isang tiyak na sistema ng estado at dalhin ito sa mga mas bagong teknolohiya? I can’t vouch for this, maybe a month or maybe two of the team’s work. Sinasabi ko ito mula sa karanasan ng kasalukuyang pagsasama sa ilang bagong serbisyo.

Kasabay nito, walang paglabas ng halaga ng negosyo. Sa lahat. Normal na umarkila ng serbisyo para sa suporta at gumugol ng kaunting oras dito. Ngunit pagkatapos ng aming karaniwang sayaw kasama ang serbisyo, idinagdag namin ito sa talahanayan, nagdagdag ng impormasyon tungkol dito at, marahil, muling isusulat ito balang araw. Ngunit ngayon ay nakakatugon ito sa aming mga pamantayan ng serbisyo.

Bilang resulta, gusto kong makabuo ng isang plano para sa kung ano ang gagawin sa mga serbisyo ng Legacy.

Ang muling pagsusulat ng legacy mula sa simula ay isang masamang ideya
Seryoso, hindi mo na kailangang isipin ito. Malinaw na gusto ko ito, at may ilang mga pakinabang, ngunit kadalasan walang nangangailangan nito, kasama ang iyong sarili.

Sanggunian libro
Hukayin ang mga source code ng iyong mga application, gumawa ng reference book na magsasaad kung ano ang nasaan at kung paano ito gumagana, maglagay ng paglalarawan ng proyekto doon (conditional readme.md) upang mabilis na maunawaan kung saan matatagpuan ang mga log at sukatan. Ang developer na haharap dito pagkatapos mong magpasalamat lang.

Unawain ang domain
Kung nagmamay-ari ka ng isang domain, subukang panatilihin ang iyong daliri sa pulso. Mukhang walang kuwenta, oo, ngunit hindi lahat ay tinitiyak na ang mga serbisyo ay nasa isang solong susi. Ngunit ang pagtatrabaho sa isang pamantayan ay talagang mas madali.

Ang mga rehistradong user lamang ang maaaring lumahok sa survey. Mag-sign in, pakiusap

Ano ang ginagawa mo sa iyong legacy?

  • 31.5%Nagsusulat ako mula sa simula, mas tama ito 12

  • 52.6%Halos kapareho mo20

  • 10.5%Wala kaming legacy, magaling kami4

  • 5.2%Isusulat ko sa comments2

38 user ang bumoto. 20 na user ang umiwas.

Pinagmulan: www.habr.com

Magdagdag ng komento