Staršie služby vo vašej infraštruktúre

Ahoj! Volám sa Pasha Chernyak, som popredným vývojárom v QIWI a dnes chcem hovoriť o nevyhnutnom. O Legacy.

Začnime otázkou: čo je to Legacy služba? Je staršia služba službou, ktorej sa vývojár nedotkol týždeň/mesiac/rok? Alebo je to služba, ktorú napísal menej skúsený programátor, napríklad vy konkrétne, ale pred rokom? A teraz ste chladnejší a skúsenejší. Alebo je služba Legacy službou, ktorú ste sa rozhodli už nikdy nespáchať a pomaly za ňu pripravujete náhradu? V každom prípade, nechať takúto službu bez dozoru a neaktualizovať je časovaná bomba, ktorá môže neskôr vybuchnúť.

Staršie služby vo vašej infraštruktúre

Predtým, ako prejdeme k tomu, ako v QIWI pracujeme s našimi staršími službami, poviem vám, ako sme vniesli poriadok do služieb v Peňaženke. Už dva roky som zodpovedný za jeho výkon. Ak je nejaký problém, vždy mi najprv zavolajú. Zvyčajne nemám nervy na to, aby som o 11:XNUMX zavolal niekomu inému, takže som si musel sadnúť a zistiť všetky služby na našej doméne.

Ale ja, ako každý človek, rád v noci spím, a tak som sa snažil vyrovnať s vykorisťovaním: "Chlapci, prečo mi voláš?" Na čo som dostal celkom lakonickú odpoveď typu "Kto iný?" Pretože opravujem služby a chlapci jednoducho nevedia, komu zavolať.

Preto sme sa na jednej z retrospektív backend tímu Wallet rozhodli, že musíme urobiť ceduľku so zoznamom našich služieb, mikroslužieb a peňaženkových monolitov a tých, ktorí sú za ne zodpovední. Značky sú vo všeobecnosti užitočné, v rozumných medziach.

Okrem informácií o tom, kto je za čo zodpovedný, zazneli odpovede na otázky: kto je vlastníkom služby, kto je zodpovedný za jej rozvoj, architektúru a životný cyklus. Ľudia zodpovední za túto službu sú ľudia, ktorí ju dokážu opraviť, ak sa niečo stane. Vlastník služby má právo ponechať +2 v potvrdeniach, zodpovední musia byť tiež prítomní pri kontrole predtým, ako táto služba prijme nové potvrdenia.

Postupom času sa začali uplatňovať nové praktiky, napríklad migrácia na Kubernetes, všelijaké checkstyle, spotbugy, ktlint, prítomnosť logov v Kibane, autodiscovery služby namiesto priameho zadávania adries a iné užitočné veci. A všade nám náš stôl umožnil zachovať relevantnosť našich služieb. Pre nás je to akýsi kontrolný zoznam, ktorý hovorí, že táto služba to dokáže, ale zatiaľ nie. Pohli sme sa však ďalej a uvedomili sme si, že nám chýbajú informácie o našich službách, ktoré monitorujeme, kde sa nachádzajú zdroje služieb, kde sa v TeamCity spúšťajú montážne úlohy, ako sú nasadené, kde sú uložené zdroje end2end testov, fotografie z prípravných stretnutí o architektúre, o prijatých rozhodnutiach. Ideálne by bolo, keby všetky tieto informácie niekde ležali a boli po ruke, keď treba. Preto sa naše znamenie stalo východiskom hľadania informácií.

Ale QIWI, hoci si zachováva ducha startupu, je veľká spoločnosť. Máme už 12 rokov a tímy sa menia: ľudia odchádzajú, ľudia prichádzajú, vytvárajú sa nové tímy. A na našej doméne sme objavili niekoľko služieb, ktoré sme zdedili. Niektoré pochádzajú od vývojárov z iných tímov, niektoré jednoducho nejako nepriamo súvisia s Peňaženkou, takže teraz máme službu v našej súvahe. Pochopenie toho, čo a ako to funguje – prečo? Služba funguje a máme funkcie produktu, ktoré je určite potrebné zlepšiť.

Ako sa to stane

V určitom okamihu však zistíme, že služba prestáva plniť svoju funkciu, niečo je pokazené – čo robiť v takejto situácii? Služba jednoducho prestala fungovať. Vôbec. A dozvedeli sme sa o tom, po prvé, náhodou a po druhé, o šesť mesiacov neskôr. To sa stáva. Jediné, čo sme vedeli, bolo, na ktorých virtuálnych strojoch bude služba nasadená, kde sa nachádzajú jej zdroje, a to je všetko. Urobíme git klon a ponoríme sa do mysle človeka, ktorý to napísal pred niekoľkými rokmi, ale čo vidíme? Žiadna z Spring Boot, ktorá je nám známa, hoci sme zvyknutí na všetko, máme plný stack a tak ďalej. Možno tam je Spring Framework? Ale nie.

Chlapík, ktorý to všetko napísal, bol tvrdý a všetko napísal v čistej Jave. Neexistujú žiadne obvyklé nástroje pre vývojárov a vzniká nápad: toto všetko musíme prepísať. Máme mikroslužby a z každého hriankovača prichádza obvyklé „Chlapci, mikroslužby sú to, čo potrebujete!“ Ak sa zrazu niečo pokazí, pokojne si môžete vziať akýkoľvek jazyk a všetko bude v poriadku.

Ide o to, že teraz nemáme zákazníka, ktorý by bol za túto službu zodpovedný. Aké mal obchodné požiadavky, čo by mala táto služba robiť? A služba je pevne integrovaná do vašich obchodných procesov.

Teraz mi povedzte, aké ľahké je prepísať službu bez toho, aby ste poznali jej obchodné požiadavky? Nie je jasné, ako sa služba zaznamenáva; nie je známe, či existujú metriky. O to viac neznáme, aké sú, ak vôbec nejaké sú. A zároveň služba obsahuje obrovské množstvo tried nepochopiteľnej obchodnej logiky. Niečo je zahrnuté v nejakej databáze, o ktorej tiež zatiaľ nič nevieme.

Kde začať?

Z najlogickejšieho bodu - dostupnosť testov. Väčšinou je tam napísaná aspoň nejaká logika a dá sa vyvodiť závery o tom, čo sa deje. Teraz je TDD módne, ale vidíme, že pred 5 rokmi bolo všetko takmer rovnaké ako teraz: neexistujú takmer žiadne jednotkové testy a nepovedia nám vôbec nič. No, snáď okrem nejakého overenia, ako je nejaký xml podpísaný nejakým vlastným certifikátom.

Z kódu sme ničomu nerozumeli, tak sme sa išli pozrieť, čo je vo virtuálnom stroji. Otvorili sme denníky služieb a našli sme v nich chybu http klienta, certifikát s vlastným podpisom, ktorý bol vložený do prostriedkov aplikácie, bol nehanebne zhnitý. Oslovili sme našich analytikov, požiadali o nový certifikát, vystavili nám ho a služba opäť funguje. Zdalo by sa, že to je všetko. Alebo nie? Služba predsa funguje, plní nejakú funkciu, ktorú náš biznis potrebuje. Máme určité štandardy pre vývoj aplikácií, ktoré s najväčšou pravdepodobnosťou máte aj vy. Logy na uzle napríklad neukladajte do priečinka, ale uložte ich do nejakého úložiska, napríklad elastického, a pozrite si ich v Kibane. Môžete si tiež spomenúť na zlaté metriky. Teda vyťaženie služby, počet žiadostí o službu, či žije alebo nie, ako mu ide HealthCheck. Tieto metriky vám prinajmenšom pomôžu zistiť, kedy môže byť s čistým svedomím vyradený z prevádzky a zabudnutý ako na zlý sen.

Čo robiť

Do tabuľky preto pridávame takú starú službu a potom ideme hľadať dobrovoľníkov z radov vývojárov, ktorí sa o službu postarajú a dajú ju do poriadku: napíšu aspoň nejaké informácie o službe, pridajú odkazy na dashboardy v grafane, na montážne úlohy a pochopte, ako nasadzujte aplikáciu, neodovzdávajte súbory manuálne pomocou ftp.

Hlavné je, ako dlho bude celá táto užitočná dobrovoľnícka činnosť trvať? Jeden šprint pre viac či menej skúseného vývojára napríklad počas 20% technického dlhu. Ako dlho trvalo pochopiť celú zakorenenú logiku komunikácie s určitým štátnym systémom a priviesť ho k novším technológiám? Nemôžem za to ručiť, možno mesiac alebo možno dva z práce tímu. Hovorím to zo skúsenosti súčasnej integrácie s nejakou novou službou.

Zároveň nedochádza k uvoľneniu obchodnej hodnoty. Vôbec. Je normálne najať si službu na podporu a stráviť na nej trochu času. Ale po našich štandardných tancoch s obsluhou sme to pridali do tabuľky, pridali o tom informácie a možno to niekedy prepíšeme. Teraz však spĺňa štandardy našich služieb.

V dôsledku toho by som chcel prísť s plánom, čo robiť so službami Legacy.

Prepisovanie dedičstva od nuly je zlý nápad
Vážne, nemusíte na to ani myslieť. Je jasné, že by sa mi to páčilo a má to niekoľko výhod, ale zvyčajne to nikto nepotrebuje, vrátane vás.

Príručka
Vykopajte zdrojové kódy svojich aplikácií, vytvorte referenčnú knihu, ktorá bude uvádzať, čo je kde a ako to funguje, zadajte tam popis projektu (podmienené readme.md), aby ste rýchlo pochopili, kde sa nachádzajú protokoly a metriky. Vývojár, ktorý sa tým bude zaoberať po vás, povie iba poďakovanie.

Pochopte doménu
Ak vlastníte doménu, snažte sa držať palce. Znie to triviálne, to áno, no nie každý dbá na to, aby boli služby v jednom kľúči. Ale práca v jednom štandarde je v skutočnosti podstatne jednoduchšia.

Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prihlásiť saProsím.

Čo robíte so svojím dedičstvom?

  • 31.5%Prepisujem od nuly, správnejšie je 12

  • 52.6%Takmer to isté ako ty20

  • 10.5%Nemáme dedičstvo, sme skvelí4

  • 5.2%Napíšem do komentárov 2

Hlasovalo 38 užívateľov. 20 užívateľov sa zdržalo hlasovania.

Zdroj: hab.com

Pridať komentár