Starší služby ve vaší infrastruktuře

Ahoj! Jmenuji se Pasha Chernyak, jsem přední vývojář ve společnosti QIWI a dnes chci mluvit o nevyhnutelném. O Legacy.

Začněme otázkou: co je to Legacy služba? Je starší služba službou, které se vývojář týden/měsíc/rok nedotkl? Nebo je to služba, kterou napsal méně zkušený programátor, například vámi konkrétně, ale před rokem? A teď jste chladnější a zkušenější. Nebo je služba Legacy službou, kterou jste se rozhodli již nikdy nespáchat a pomalu za ni připravujete náhradu? V každém případě nechat takovou službu bez dozoru a neaktualizovat je časovaná bomba, která může později vybuchnout.

Než přejdu k tomu, jak v QIWI pracujeme s našimi staršími službami, řeknu vám, jak jsme vnesli pořádek do služeb v Peněžence. Již dva roky jsem zodpovědný za jeho výkon. Pokud je nějaký problém, vždy mi zavolají jako první. Obvykle nemám nervy volat někomu jinému ve 11 hodin, takže jsem si musel sednout a zjistit všechny služby na naší doméně.

Ale jako každý člověk rád v noci spím, a tak jsem se snažil vypořádat s vykořisťováním: "Kluci, proč mi voláte?" Na což jsem dostal docela lakonickou odpověď typu "Kdo jiný?" Protože opravuji služby a kluci prostě nevědí, komu zavolat.

Proto jsme se na jedné z retrospektiv backendového týmu Wallet rozhodli, že musíme udělat cedulku se seznamem našich služeb, mikroslužeb a peněženkových monolitů a těch, kdo za ně odpovídají. Značky jsou obecně užitečné, v rozumných mezích.

Kromě informací o tom, kdo za co zodpovídá, zazněly odpovědi na otázky: kdo je vlastníkem služby, kdo je zodpovědný za její vývoj, architekturu a životní cyklus. Lidé zodpovědní za tuto službu jsou lidé, kteří ji mohou opravit, pokud se něco stane. Vlastník služby má právo ponechat +2 v commitech, odpovědní musí být také přítomni u kontroly, než tato služba přijme nový commit.

Postupem času se začaly uplatňovat nové postupy, například migrace na Kubernetes, všemožné checkstyle, spotbugy, ktlint, přítomnost logů v Kibaně, autodiscovery služby místo přímého zadávání adres a další užitečné věci. A všude, kde nám náš stůl umožnil zachovat relevanci našich služeb. Pro nás je to jakýsi kontrolní seznam, který říká, že tato služba to umí, ale zatím ne. Ale posunuli jsme se dál, protože jsme si uvědomili, že nám chybí informace o našich službách, které sledujeme, kde se nacházejí zdroje služeb, kde jsou v TeamCity spouštěny montážní úlohy, jak jsou nasazeny, kde jsou uloženy zdroje end2end testů, fotky z přípravných sezení o architektuře, o přijatých rozhodnutích. V ideálním případě bych chtěl, aby všechny tyto informace někde ležely a byly po ruce, když je potřeba. Proto se naše znamení stalo výchozím bodem pro hledání informací.

Ale QIWI, i když si zachovává ducha startupu, je velká společnost. Už je nám 12 let a týmy se mění: lidé odcházejí, lidé přicházejí, vznikají nové týmy. A na naší doméně jsme objevili několik služeb, které jsme zdědili. Některé pocházely od vývojářů z jiných týmů, některé prostě nějak nepřímo souvisely s Peněženkou, takže nyní máme službu v naší rozvaze. Pochopení toho, co a jak to funguje – proč? Služba funguje a máme funkce produktu, které je rozhodně potřeba vylepšit.

Jak se to stane

V určitém okamžiku ale zjistíme, že služba přestává plnit svou funkci, něco je nefunkční – co v takové situaci dělat? Služba prostě přestala fungovat. Vůbec. A to jsme se dozvěděli zaprvé náhodou a zadruhé o šest měsíců později. Stalo se to. Jediné, co jsme věděli, bylo, na kterých virtuálních strojích bude služba nasazena, kde jsou umístěny její zdroje, a to je vše. Uděláme git klon a ponoříme se do mysli člověka, který to napsal před několika lety, ale co vidíme? Žádný z Spring Boot, který je nám známý, i když jsme zvyklí na všechno, máme plný stack a tak. Možná tam je Spring Framework? Ale ne.

Ten, kdo to všechno napsal, byl tvrdý a všechno napsal v čisté Javě. Pro vývojáře neexistují žádné obvyklé nástroje a vzniká nápad: musíme to všechno přepsat. Máme mikroslužby a z každého toustovače se ozývá obvyklé „Kluci, mikroslužby jsou to, co potřebujete!“ Pokud se najednou něco pokazí, můžete si klidně vzít jakýkoli jazyk a vše bude v pořádku.

Věc se má tak, že nyní nemáme zákazníka, který by za tuto službu odpovídal. Jaké měl obchodní požadavky, co by tato služba měla dělat? A služba je pevně integrována do vašich obchodních procesů.

Nyní mi řekněte, jak snadné je přepsat službu, aniž byste znali její obchodní požadavky? Není jasné, jak je služba protokolována; není známo, zda existují metriky. Jaké jsou, pokud vůbec nějaké, je o to více neznámé. A zároveň služba obsahuje obrovské množství tříd nepochopitelné obchodní logiky. Něco je zahrnuto v nějaké databázi, o které také zatím nic nevíme.

S čím začít?

Z nejlogičtějšího bodu - dostupnost testů. Tam je většinou napsána alespoň nějaká logika a dá se dělat závěry o tom, co se děje. Nyní je TDD v módě, ale vidíme, že před 5 lety bylo všechno téměř stejné jako nyní: neexistují téměř žádné testy jednotek a neřeknou nám vůbec nic. No, snad kromě nějakého ověření, jak je nějaký xml podepsán nějakým vlastním certifikátem.

Z kódu jsme ničemu nerozuměli, tak jsme se šli podívat, co je na virtuálním stroji. Otevřeli jsme protokoly služeb a našli v nich chybu http klienta, certifikát s vlastním podpisem, který byl vložen do prostředků aplikace, byl nestydatě shnilý. Oslovili jsme naše analytiky, požádali o nový certifikát, vystavili nám ho a služba opět funguje. Zdálo by se, že to je vše. Nebo ne? Koneckonců, služba funguje, plní nějakou funkci, kterou naše podnikání potřebuje. Máme určité standardy pro vývoj aplikací, které s největší pravděpodobností máte také. Například neukládejte protokoly na uzlu do složky, ale uložte je do nějakého úložiště, například elastického, a podívejte se na ně v Kibaně. Můžete si také pamatovat zlaté metriky. Tedy vytížení služby, počet požadavků na službu, zda žije nebo ne, jak mu jde HealthCheck. Tyto metriky vám přinejmenším pomohou poznat, kdy může být s čistým svědomím vyřazen z provozu a zapomenut jako ve zlém snu.

Co dělat

Do tabulky proto přidáme takovou starou službu a pak jdeme hledat dobrovolníky z řad vývojářů, kteří se o službu postarají a dají ji do pořádku: napíší alespoň nějaké informace o službě, přidají odkazy na dashboards v grafaně, k montážním úlohám a pochopení toho, jak aplikaci nasadit, nenahrávejte soubory ručně pomocí ftp.

Hlavní je, jak dlouho bude celá tato užitečná dobrovolnická činnost trvat? Jeden sprint pro více či méně zkušeného vývojáře například při 20% technickém dluhu. Jak dlouho trvalo pochopit celou tu zakořeněnou logiku komunikace s určitým státním systémem a přivést ho k novějším technologiím? Nemohu za to ručit, možná měsíc nebo možná dva z práce týmu. Říkám to ze zkušenosti současné integrace s nějakou novou službou.

Zároveň nedochází k uvolnění obchodní hodnoty. Vůbec. Je normální najmout si službu na podporu a věnovat tomu trochu času. Ale po našich standardních tancích s obsluhou jsme to přidali do tabulky, přidali o tom informace a možná to někdy přepíšeme. Nyní však splňuje naše servisní standardy.

Ve výsledku bych chtěl vymyslet plán, co dělat se službami Legacy.

Přepisovat dědictví od nuly je špatný nápad
Vážně, nemusíte o tom ani přemýšlet. Je jasné, že by se mi to líbilo a má to určité výhody, ale obvykle to nikdo nepotřebuje, včetně vás.

Příručka
Vykopejte zdrojové kódy svých aplikací, vytvořte referenční knihu, která bude uvádět, co je kde a jak to funguje, zadejte tam popis projektu (podmíněné readme.md), abyste rychle pochopili, kde se nacházejí protokoly a metriky. Vývojář, který to po vás bude řešit, jen poděkuje.

Pochopte doménu
Pokud vlastníte doménu, snažte se držet palce. Zní to triviálně, to ano, ale ne každý dbá na to, aby byly služby v jediném klíči. Práce v jednom standardu je ale ve skutečnosti výrazně jednodušší.

Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. Přihlásit se, prosím.

Co děláte se svým dědictvím?

• 31.5%Přepisuji od nuly, správnější je 12

• 52.6%Skoro stejně jako ty20

• 10.5%Nemáme dědictví, jsme skvělí4

• 5.2%Napíšu do komentářů 2

Hlasovalo 38 uživatelů. 20 uživatelů se zdrželo hlasování.

Zdroj: www.habr.com