Hallo! Myn namme is Pasha Chernyak, ik bin in liedende ûntwikkelder by QIWI, en hjoed wol ik prate oer it ûnûntkombere. Oer Legacy.
Litte wy begjinne mei de fraach: wat is Legacy-tsjinst? Is in legacy-tsjinst in tsjinst dy't de ûntwikkelder in wike / moanne / jier net hat oanrekke? Of is it in tsjinst dy't skreaun is troch in minder betûfte programmeur, bygelyks troch jo spesifyk, mar in jier lyn? En no binne jo koeler en mear erfaren. Of is de Legacy-tsjinst in tsjinst dy't jo besletten hawwe om noait wer te commit en stadichoan in ferfanger foar tariede? Yn alle gefallen, sa'n tsjinst sûnder tafersjoch litte en net bywurkje is in tiidbom dy't letter ûntploffe kin.
Foardat jo trochgean mei hoe't wy by QIWI wurkje mei ús Legacy-tsjinsten, sil ik jo fertelle hoe't wy oarder brochten oan 'e tsjinsten yn' e Wallet. Al twa jier bin ik ferantwurdlik foar de prestaasjes. As der in probleem is, belje se my altyd earst. Ik haw meastentiids net it lef om om 11 oere in oar te skiljen, dus ik moast sitte en útfine alle tsjinsten op ús domein.
Mar ik, lykas elke persoan, graach sliepe nachts, dus ik besocht om te gean mei de eksploitaasje: "Jongens, wêrom neame jo my?" Dêrop krige ik in frij lakonysk antwurd lykas "Wa oars?" Om't ik tsjinsten reparearje, en de jonges gewoan net witte wa't se moatte skilje.
Dêrom hawwe wy by ien fan 'e retrospektives fan it Wallet-backend-team besletten dat wy in teken moatte meitsje mei in list fan ús tsjinsten, mikrotsjinsten en wallet-monoliten, en dyjingen dy't ferantwurdlik binne foar har. Tekens binne oer it generaal nuttich, binnen ridlike grinzen.
Neist ynformaasje oer wa't ferantwurdlik is foar wat, wiene der antwurden op de fragen: wa is de eigner fan de tsjinst, wa is ferantwurdlik foar de ûntwikkeling, arsjitektuer en libbenssyklus. De minsken dy't ferantwurdlik binne foar dizze tsjinst binne de minsken dy't it reparearje kinne as der wat bart. De eigner fan 'e tsjinst hat it rjocht om +2 te ferlitten yn commits, de ferantwurdliken moatte ek oanwêzich wêze by de resinsje foardat dizze tsjinst in nije commit akseptearret.
Nei ferrin fan tiid, begûnen nije praktiken te wurde tapast, bygelyks migraasje nei Kubernetes, allerhanne checkstyle, spotbugs, ktlint, de oanwêzigens fan logs yn Kibana, autodiscovery tsjinsten ynstee fan direkt oantsjutte adressen en oare nuttige dingen. En oeral liet ús tafel ús de relevânsje fan ús tsjinsten behâlde. Foar ús is dit in soarte fan checklist dy't seit dat dizze tsjinst dit kin dwaan, mar it docht it noch net. Mar wy binne fierder gongen, realisearre dat wy ynformaasje misse oer ús tsjinsten, dy't wy kontrolearje, wêr't de tsjinstboarnen lizze , wêr't assemblagetaken yn TeamCity lansearre wurde, hoe't se ynset wurde, wêr't de boarnen fan end2end-tests wurde opslein, foto's fan fersoargingssesjes oer de arsjitektuer, oer de besluten dy't makke binne. It leafst soe ik graach wolle dat al dizze ynformaasje earne lizze en by de hân is as it nedich is. Dêrom waard ús teken it útgongspunt foar it sykjen nei ynformaasje.
Mar QIWI, hoewol it de geast fan in opstart behâldt, is in grut bedriuw. Wy binne al 12 jier, en teams feroarje: minsken geane, minsken komme, nije teams wurde foarme. En wy ûntdutsen ferskate tsjinsten op ús domein dy't wy erfden. Guon kamen fan ûntwikkelders fan oare teams, guon binne gewoan op ien of oare manier yndirekt relatearre oan de Wallet, dus wy hawwe no de tsjinst op ús balâns. Begripe wat en hoe't it wurket - wêrom? De tsjinst wurket, en wy hawwe produkt funksjes dy't perfoarst moatte wurde ferbettere.
Hoe't it bart
Mar op in stuit ûntdekke wy dat de tsjinst ophâldt mei it útfieren fan syn funksje, wat is brutsen - wat te dwaan yn sa'n situaasje? De tsjinst is gewoan stoppe mei wurkjen. Heulendal. En wy fûnen út oer dit, earst, by ûngelok, en twadde, seis moanne letter. It bart. It iennichste wat wy wisten wie op hokker firtuele masines de tsjinst soe wurde ynset, wêr't de boarnen wiene, en dat is alles. Wy dogge in git-kloon en dûke yn 'e geast fan' e persoan dy't dit in pear jier lyn skreau, mar wat sjogge wy? Gjin fan 'e Spring Boot dat is bekend foar ús, hoewol't wy binne wend oan alles, wy hawwe in folsleine stack en al dat. Miskien is der in Spring Framework dêr? Mar nee.
De man dy't dit alles skreau wie stoer en skreau alles yn suver Java. D'r binne gjin gewoane ark foar in ûntwikkelder, en in idee ûntstiet: wy moatte dit alles opnij skriuwe. Wy hawwe mikrotsjinsten, en fan elke broodrooster komt de gewoane "jonges, mikrotsjinsten binne wat jo nedich binne!" As der ynienen wat mis giet, kinne jo rêstich elke taal nimme en alles komt goed.
It ding is dat wy no gjin klant hawwe dy't ferantwurdlik is foar dizze tsjinst. Hokker saaklike easken hie er, wat moat dizze tsjinst dwaan? En de tsjinst is strak yntegrearre yn jo saaklike prosessen.
Fertel my no, hoe maklik is it om in tsjinst te herskriuwen sûnder de saaklike easken te kennen? It is net dúdlik hoe't de tsjinst wurdt oanmeld; oft der metriken binne is ûnbekend. Wat se binne, as ien, is des te ûnbekender. En tagelyk befettet de tsjinst in grut oantal klassen fan ûnbegryplike saaklike logika. Wat is opnommen yn in soarte fan databank, dêr't wy ek noch neat fan witte.
Wêr moat it begjinne?
Ut it meast logyske punt - de beskikberens fan tests. Der is meastentiids teminsten wat logika skreaun en kinne jo konklúzjes lûke oer wat der bart. No TDD is moade, mar wy sjogge dat 5 jierren lyn alles wie hast itselde as it is no: der binne hast gjin ienheid tests, en se sille net fertelle ús neat at all. No, útsein miskien in soarte fan ferifikaasje, hoe't guon xml is tekene mei wat oanpast sertifikaat.
Wy koene neat fan 'e koade begripe, dus wy gongen om te sjen wat der yn' e firtuele masine wie. Wy iepene de tsjinstlogboeken en fûnen in http-clientflater yn har; it sels-ûndertekene sertifikaat dat ynbêde wie yn 'e applikaasjeboarnen wie skamteleas rot. Wy hawwe kontakt mei ús analisten, se fregen om in nij sertifikaat, se hawwe it ús útjûn en de tsjinst wurket wer. It soe lykje dat dat alles is. Of net? De tsjinst wurket ommers, it docht wat funksje dy't ús bedriuw nedich is. Wy hawwe bepaalde noarmen foar applikaasjeûntwikkeling, dy't jo wierskynlik ek hawwe. Bewarje bygelyks gjin logs op it knooppunt yn in map, mar bewarje se yn in soarte fan opslach, lykas elastysk, en sjoch se yn Kibana. Jo kinne ek de gouden metriken ûnthâlde. Dat is, de lading op 'e tsjinst, it oantal oanfragen foar de tsjinst, oft hy libbet of net, hoe't syn HealthCheck giet. Op syn minst sille dizze metriken jo helpe te witten wannear't it mei in dúdlik gewisse út 'e tsjinst kin wurde nommen en fergetten as in minne dream.
Wat te dwaan
Dêrom foegje wy sa'n âlde tsjinst ta oan 'e tafel, en dan sykje wy frijwilligers út 'e ûntwikkelders dy't de tsjinst fersoargje en yn oarder sette: se sille op syn minst wat ynformaasje oer de tsjinst skriuwe, keppelings tafoegje oan dashboards yn grafana, to assembly taken, en begripe hoe't Deploy de applikaasje, net manuell upload triemmen mei help fan ftp.
It wichtichste is hoe lang sil al dizze nuttige frijwilligersaktiviteit duorje? Ien sprint foar in min of mear betûfte ûntwikkelder, bygelyks by in 20% technyske skuld. Hoe lang hat it duorre om alle yngewikkelde logika fan kommunisearjen mei in bepaald steatsysteem te begripen en it nei nijere technologyen te bringen? Ik kin net vouch foar dit, miskien in moanne of miskien twa fan it team syn wurk. Ik sis dit út ûnderfining fan hjoeddeistige yntegraasje mei wat nije tsjinst.
Tagelyk is d'r gjin frijlitting fan saaklike wearde. Heulendal. It is normaal om in tsjinst te hieren foar stipe en dêr in bytsje tiid oan te besteegjen. Mar nei ús standert dûnsen mei de tsjinst, hawwe wy it oan 'e tafel tafoege, ynformaasje deroer tafoege en, miskien, sille it ienris opnij skriuwe. Mar no foldocht it oan ús tsjinstnormen.
As gefolch, ik soe graach komme mei in plan foar wat te dwaan mei Legacy tsjinsten.
It oerskriuwen fan legacy fanôf it begjin is in min idee
Serieus, jo hoege der net iens oer nei te tinken. It is dúdlik dat ik soe graach it, en der binne guon foardielen, mar meastentiids gjinien hat it nedich, ynklusyf dysels.
Directory
Dig de boarnekoades fan jo applikaasjes út, meitsje in referinsjeboek dat sil oanjaan wat is wêr en hoe't it wurket, fier dêr in beskriuwing fan it projekt yn (conditional readme.md) om fluch te begripen wêr't de logs en metriken lizze. De ûntwikkelder dy't sil omgean mei dit nei jo sil allinne sizze tank.
Begryp it domein
As jo in domein hawwe, besykje dan jo finger oan 'e pols te hâlden. It klinkt triviaal, ja, mar net elkenien soarget derfoar dat de tsjinsten yn ien kaai binne. Mar wurkje yn ien standert is eins folle makliker.
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Wat dogge jo mei jo neilittenskip?
-
31.5%Ik skriuw fanôf it begjin, it is krekter 12
-
52.6%Hast itselde as jo20
-
10.5%Wy hawwe gjin legacy, wy binne geweldich4
-
5.2%Ik skriuw yn 'e kommentaren2
38 brûkers stimden. 20 brûkers ûntholden har.
Boarne: www.habr.com