Ahoj! Jmenuji se Paša Černjak, jsem hlavní vývojář v QIWI a dnes chci mluvit o nevyhnutelném. O Legacy.
Začněme otázkou: co je to Legacy služba? Legacy služba je služba, kterou vývojář už týden/měsíc/rok neaktualizoval? Nebo je to služba napsaná méně zkušeným programátorem, například vámi, ale před rokem? A nyní jste lepší a zkušenější. Nebo snad Legacy služba je ta, kterou jste se rozhodli už nikdy neaktualizovat a postupně připravujete její náhradu? V každém případě, nechat takovou službu bez dohledu a neaktualizovat ji — to je časovaná bomba, která může v budoucnu vybuchnout.
Než se pustíme do toho, jak v QIWI pracujeme s našimi Legacy službami, povím vám, jak jsme udělali pořádek se službami v Peněžence. Jsem již dva roky odpovědný za její funkčnost. Pokud nastane nějaký problém, vždy mi zavolají jako první. Obvykle nemám odvahu volat někomu jinému ve 23 hodin, takže jsem se musel usadit a vyřídit všechny služby našeho doménového jména.
Ale já, jako každý člověk, rád spím v noci, takže jsem se snažil vyřešit provoz: „Chlapi, proč mi voláte?“. Na což jsem dostal celkem lakonickou odpověď: „A komu jinému?“. Protože já služby opravím, a navíc kluci prostě nevědí, komu zavolat.
Na jedné z retrospektiv týmu backendu Peněženky jsme se rozhodli, že potřebujeme vytvořit tabulku, která bude obsahovat seznam našich služeb, mikroslužeb a monolitů peněženky spolu s odpovědnými osobami. Tabulky jsou obecně užitečné, v rozumných mezích.
Kromě informací o tom, kdo za co odpovídá, tam byly odpovědi na otázky: kdo je vlastník služby, kdo je odpovědný za její rozvoj, architekturu a životní cyklus. Lidé, kteří jsou za tuto službu zodpovědní — to jsou lidé, kteří ji mohou v případě potřeby opravit. Vlastník služby má právo ponechat +2 v commitech, zodpovědní se také musí nutně zúčastnit revize, než tato služba přijme nový commit.
Čas plynul, začaly se uplatňovat nové praktiky, například migrace do Kubernetes, různé checkstyle, spotbugs, ktlint, existence logů v Kibana, autodiscovery služeb namísto přímého zadávání adres a další užitečnosti. A všude naše tabulka umožňovala udržovat aktuálnost našich služeb. Pro nás to byl jakýsi checklist, který říkal, že tato služba tohle umí, ale toto zatím ne. Ale šli jsme dál, uvědomujíc si, že nám chybí informace o našich službách, které sledujeme, kde leží zdrojové kódy služby, kde se spouštějí úkoly pro sestavení v TeamCity, jak se nasazují, kde se uchovávají zdrojové kódy end2end testů, fotografie o architektuře, o přijatých rozhodnutích. Ideálně bychom chtěli, aby všechny tyto informace někde ležely a byly po ruce, když je potřeba. Proto se naše tabulka stala výchozím bodem pro hledání informací.
Ale QIWI, i když si zachovává ducha startupu, je velká společnost. Už máme 12 let a týmy se mění: lidé odcházejí, lidé přicházejí, formují se nové týmy. A zjistili jsme na svém doméně několik služeb, které jsme zdědili. Něco přišlo s vývojáři z jiných týmů, něco se prostě nějak nepřímo vztahovalo k Peněžence, takže služba nyní zůstává na našem rozpočtu. Proč se zabývat tím, co a jak funguje? Služba funguje, a máme produktové funkce, které je nutné určitě implementovat.
Jak to bývá
Ale v určitém okamžiku zjistíme, že služba přestala plnit svou funkci, něco se pokazilo — co dělat v takové situaci? Služba prostě přestala fungovat. Úplně. A zjistili jsme o tom, především náhodou, a za druhé, až po šesti měsících. Tak to bývá. Jediné, co jsme věděli — na jakých virtuálních strojích je služba nasazena, kde leží její zdrojové kódy, a to je všechno. Uděláme git clone a ponoříme se do myšlenek člověka, který to psal před několika lety, ale co vidíme? Žádný nám známý Spring Boot, i když jsme si na všechno zvykli, máme přece full stack a něco podobného. Možná tam je Spring Framework? A ukazuje se, že ne.
Chlapec, který to všechno napsal, byl přísný a psal vše čistě v Javě. Pro vývojáře není obvyklých nástrojů a vzniká myšlenka — bylo by dobré to všechno přepsat. Vždyť máme mikroservisy, a z každého toasteru se ozývá povědomé "Chlapci, mikroservisy jsou to, co potřebujete!". Pokud se náhodou něco pokazí, můžete si v klidu vzít jakýkoli jazyk a všechno bude skvělé.
Zajímavé je, že teď nemáme zadavatele, který by byl zodpovědný za tuto službu. Jaké měl obchodní požadavky, co by tato služba měla vlastně dělat? A služba je úzce integrována do vašich obchodních procesů.
A teď mi řekněte, jak jednoduché je přepsat službu, když neznáte její obchodní požadavky? Jak se loguje služba, není jasné, jestli existují nějaké metriky — to také nevíme. Jaké jsou, pokud nějaké existují — tím méně víme. A přitom v službě je obrovské množství tříd s nejasnou obchodní logikou. Něco se ukládá do nějaké databáze, o které zatím také nic nevíme.
Kde začít?
Od toho nejlogičtějšího — od existence testů. Tam je obvykle napsána alespoň nějaká logika a můžeme učinit závěry o tom, co se děje. Teď je populární TDD, ale vidíme, že před pěti lety to bylo prakticky stejné jako teď: téměř žádné unit testy, a ty nám také nic neřeknou. No kromě nějaké kontroly, jak se podepisuje nějaký xml s nějakým vlastním certifikátem.
Nebylo možné pochopit nic podle kódu, a tak jsme se rozhodli podívat, co se děje na virtuálním stroji. Otevřeli jsme logy služby a našli v nich chybu http klienta; samopodepsaný certifikát, který byl zabudován do zdrojů aplikace, byl bezmocně prošlý. Spojili jsme se s našimi analytiky, požádali o nový certifikát, ten nám byl vystaven a služba znovu funguje. Zdálo by se, že je tím vše vyřešeno. Anebo ne? Služba stále funguje a plní určitou funkci, kterou potřebujeme pro naše podnikání. Máme určité standardy pro vývoj aplikací, které pravděpodobně máte také. Například, neskladovat logy na nodu v adresáři, ale ukládat je do nějakého úložiště, jako je Elastic, a sledovat je v Kibana. Můžeme zmínit také zlaté metriky. Tedy zátěž na službu, počet požadavků na službu, zda je živá či nikoliv, jak probíhá její HealthCheck. V nejlepším případě tyto metriky pomohou zjistit, kdy ji lze s klidným svědomím vyřadit z provozu a zapomenout na ni jako na zlý sen.
Co dělat
Proto přidáváme tuto starou službu do tabulky, a pak jdeme hledat mezi vývojáři dobrovolníky, kteří se té služby ujmou a uvedou ji do pořádku: napíšou alespoň nějaké informace o službě, přidají odkazy na dashboardy v Grafaně, na úkoly pro sestavení, a pochopí, jak nasadit aplikaci, nebudou přece ručně plnit soubory pomocí FTP.
Hlavní je, jak dlouho tato užitečná dobrovolnická aktivita zabere času? Jeden sprint pro více či méně zkušeného vývojáře, například, během 20% technického dluhu. A kolik času bylo potřeba k pochopení celé zakotvené logiky komunikace s nějakým státním systémem, zavést jej na novější technologie? Na to se nezaručuji, možná měsíc, možná i dva pracovní doby týmu. To říkám na základě zkušeností s integrací s nějakou novou službou v současné době.
Zároveň však žádný výstup obchodní hodnoty — vůbec žádný. Vzít službu pod podporu a utratit na to trochu času — to je v pořádku. Ale po našich standardních tancích se službou jsme ji přidali do tabulky, přidali o ní informace a možná ji někdy přepíšeme. Ale teď odpovídá našim standardům pracovních služeb.
Na závěr bych chtěl shrnout určité plány, co dělat se starými službami.
Přepisovat legacy od nuly — špatný nápad.
Opravdu, není třeba o tom přemýšlet. Je jasné, že byste chtěli, aby to mělo nějaké výhody, ale obvykle to nikdo, včetně vás samotných, nepotřebuje.
Příručka
Vykopejte zdrojové kódy svých aplikací, vytvořte příručku, ve které bude uvedeno, co a kde leží a jak funguje. Také tam zahrňte popis projektu (podmínkový readme.md), abyste rychle pochopili, kde jsou logy a metriky. Vývojář, který se s tím po vás bude zabývat, vám bude jen děkovat.
Rozumějte doméně
Pokud vlastníte nějakou doménu, snažte se mít přehled. Zní to banálně, ano, ale ne každý sleduje to, aby služby byly v jednotném stylu. A ve skutečnosti je práce v jednom standardu výrazně jednodušší.
Pouze registrovaní uživatelé se mohou účastnit ankety. , prosím.
Co děláte se svým legacy?
31.5%Přepisujeme to od nuly, to je správně12
52.6%Téměř to samé, co vy20
10.5%Nemáme žádné legacy, jsme skvělí4
5.2%Napíšu to do komentářů2
Hlasovalo 38 uživatelů. Zdrželo se 20 uživatelů.
Zdroj: habr.com
