🥇Legacy-serwisy w twojej infrastrukturze

Cześć! Mam na imię Paweł Czerniak, jestem głównym programistą w QIWI i dziś chcę porozmawiać o nieuniknionym. O Legacy.

Zacznijmy od pytania: czym jest usługa Legacy? Usługa Legacy to taka, której programista nie dotykał przez tydzień/miesiąc/rok? A może to usługa napisana przez mniej doświadczonego programistę, na przykład przez Ciebie, ale rok temu? A teraz jesteś lepszy i bardziej doświadczony. Czy może jednak usługa Legacy to taka, którą postanowiłeś nigdy więcej nie rozwijać i powoli przygotowujesz jej zastępstwo? W każdym razie zostawienie takiej usługi bez opieki i nieaktualizowanie jej to bomba z opóźnionym zapłonem, która może eksplodować później.

Zanim przejdziemy do tego, jak w QIWI zajmujemy się naszymi usługami Legacy, opowiem, jak uporządkowaliśmy usługi w Portfelu. Od dwóch lat odpowiadam za jego działanie. Jeśli wystąpi jakiś problem, to zawsze w pierwszej kolejności dzwonią do mnie. Zwykle brakuje mi odwagi, aby o 23:00 dzwonić do kogoś innego, dlatego musiałem usiąść i zająć się wszystkimi usługami naszego domeny.

Ale ja, jak każdy człowiek, lubię spać w nocy, więc starałem się zrozumieć eksploatację: "Ludzie, dlaczego do mnie dzwonicie?". Na co otrzymałem dość lakoniczną odpowiedź: "A do kogo innego?". Ponieważ naprawiam usługi, a ponadto ludzie po prostu nie wiedzą, do kogo dzwonić.

Dlatego na jednym z retrospektyw zespołu backendowego Portfela postanowiliśmy stworzyć tabelę, na której napisano listę naszych usług, mikrousług i monolitów portfela oraz odpowiedzialnych za nie. Tabele są w ogóle przydatne, w rozsądnych granicach.

Oprócz informacji o tym, kto za co odpowiada, znajdowały się tam odpowiedzi na pytania: kto jest właścicielem usługi, kto odpowiada za jej rozwój, architekturę i cykl życia. Osoby odpowiedzialne za tę usługę to osoby, które mogą w razie potrzeby ją naprawić. Właściciel usługi ma prawo dodać +2 w commitach, a odpowiedzialni również muszą być obecni na przeglądzie, zanim ta usługa przyjmie nowy commit.

Czas mijał, zaczęto stosować nowe praktyki, takie jak migracja do Kubernetes, różne checkstyle, spotbugs, ktlint, obecność logów w Kibanie, autodiscovery usług zamiast bezpośredniego wskazywania adresów oraz inne przydatne rzeczy. Nasza tabela pozwalała utrzymywać aktualność naszych usług. Dla nas to coś w rodzaju checklisty, która wskazuje, co dana usługa potrafi robić, a czego jeszcze nie. Ale posuwaliśmy się dalej, zdając sobie sprawę, że brakuje nam informacji o naszych usługach, którymi się opiekujemy, gdzie znajdują się źródła usługi, gdzie uruchamiane są zadania kompilacji w TeamCity, jak są wdrażane, gdzie przechowywane są źródła testów end2end, zdjęcia architektury, dotyczące podjętych decyzji. Idealnie byłoby, gdyby te wszystkie informacje były gdzieś zgromadzone i dostępne w razie potrzeby. Dlatego nasza tabela stała się punktem wyjścia do poszukiwania informacji.

Jednak QIWI, choć zachowuje ducha startupu, jest dużą firmą. Mamy już 12 lat, a zespoły się zmieniają: ludzie odchodzą, przychodzą nowi, formują się nowe zespoły. Odkryliśmy na naszej domenie kilka usług, które odziedziczyliśmy. Niektóre przyszły od deweloperów z innych zespołów, inne po prostu w jakiś sposób były związane z Portfelem, dlatego teraz mamy je na swoim bilansie. Po co się zastanawiać, co i jak działa? Usługa działa, a my mamy funkcje produktowe, które musimy koniecznie wdrożyć.

Tak bywa.

Jednak w pewnym momencie odkrywamy, że usługa przestaje pełnić swoją funkcję, coś się zepsuło — co robić w takiej sytuacji? Usługa po prostu przestała działać. Całkowicie. A dowiedzieliśmy się o tym, po pierwsze, przypadkowo, a po drugie, po sześciu miesiącach. Tak bywa. Jedyną rzeczą, którą wiedzieliśmy, było to, na jakich wirtualnych maszynach uruchomiona jest usługa, gdzie znajdują się jej źródła i tyle. Robimy git clone i zagłębiamy się w myśli osoby, która pisała to kilka lat temu, ale co widzimy? Żadnego znajomego dla nas Spring Boot, chociaż do tego się przyzwyczailiśmy, mamy przecież full stack i tym podobne. Może jest tam Spring Framework? A gdzie tam.

Facet, który to wszystko napisał, był surowy i wszystko pisał w czystym Javie. Nie ma znanych narzędzi dla programisty, i pojawia się pomysł — trzeba to wszystko przepisać. Mamy mikroserwisy, a z każdego tostera dociera znane „Ludzie, mikroserwisy to to, czego potrzebujecie!”. Jeśli coś pójdzie nie tak, spokojnie weźmiecie dowolny język, a wszystko będzie w porządku.

Sprawa w tym, że teraz nie mamy klienta, który odpowiada za tę usługę. Jakie były jego wymagania biznesowe, co w ogóle ta usługa powinna robić? A usługa jest mocno zintegrowana z waszymi procesami biznesowymi.

A teraz powiedzcie, jak łatwo przepisać usługę, nie znając jej wymagań biznesowych? Nie wiadomo, jak usługa jest logowana, czy są jakieś metryki — nie wiadomo. Jakie one są, jeśli w ogóle istnieją — tym bardziej nie wiadomo. A w samej usłudze znajduje się ogromna liczba klas niezrozumiałej logiki biznesowej. Coś trafia do jakiejś bazy danych, o której też na razie nic nie wiemy.

Od czego zacząć?

Od najbardziej logicznej rzeczy — od obecności testów. Tam zazwyczaj jest napisana jakaś logika i można wyciągnąć wnioski o tym, co się dzieje. Obecnie modne jest TDD, ale widzimy, że te same 5 lat temu wszystko wyglądało praktycznie tak samo jak teraz: prawie nie ma testów jednostkowych, a one tak naprawdę nie powiedzą nam nic. No, może poza jakąś kontrolą, jak podpisuje się jakiś xml z jakimś niestandardowym certyfikatem.

Nie udało się nic zrozumieć z kodu, więc poszliśmy sprawdzić, co tam na wirtualce. Otworzyliśmy logi usługi i znaleźliśmy w nich błąd klienta http — samopodpisany certyfikat, który został wbudowany w zasoby aplikacji, całkowicie wygasł. Skontaktowaliśmy się z naszymi analitykami, poprosili o nowy certyfikat, który nam wystawiono, i usługa znowu działa. Można by pomyśleć, że na tym koniec. A jednak? Usługa działa, wykonuje jakąś funkcję, która jest potrzebna naszemu biznesowi. Mamy pewne standardy dotyczące rozwoju aplikacji, które najprawdopodobniej macie i wy. Na przykład, nie przechowywać logów na węźle w folderze, tylko w jakimś magazynie, np. w Elasticsearch, i przeglądać je w Kibanie. Można też wspomnieć o złotych metrykach. Czyli obciążenie usługi, liczba zapytań do usługi, czy działa, czy nie, jak przechodzi HealthCheck. Przynajmniej te metryki pomogą ustalić, kiedy można go spokojnie wycofać z eksploatacji i zapomnieć jak zły sen.

Co robić

Dlatego dodajemy tę starą usługę do tabeli, a potem idziemy szukać wśród programistów ochotników, którzy zajmą się tą usługą i doprowadzą ją do porządku: napiszą jakąś informację o usłudze, dodadzą linki do dashboardów w Grafanie, do zadań budowy, zrozumieją, jak uruchamiać aplikację, nie rzucajmy plików za pomocą FTP.

Najważniejsze — ile czasu zajmie ta cała użyteczna aktywność ochotnicza? Jeden sprint dla bardziej lub mniej doświadczonego programisty, na przykład, w czasie 20% długu technicznego. A ile czasu zajmie zrozumienie całej zakorzenionej logiki komunikacji z jakimś systemem rządowym, przekształcenie jej w nowocześniejsze technologie? Nie gwarantuję tego, może miesiąc, a może dwa pr Ace zespołu. Mówię to z doświadczenia integracji w obecnym czasie z jakąś nową usługą.

Przy tym nie ma żadnej wartości biznesowej — zupełnie. Wzięcie usługi pod wsparcie i poświęcenie na to trochę czasu — to normalne. Ale po naszych standardowych tańcach z usługą dodaliśmy ją do tabeli, dodaliśmy informacje o niej, a może kiedyś ją przepiszemy. Ale teraz odpowiada naszym standardom pracy z usługami.

W rezultacie chciałbym podsumować plan, co robić z usługami Legacy.

Przepisywanie legacy od zera — to zły pomysł
Na serio, nie ma co o tym myśleć. Jasne, że byłyby jakieś korzyści, ale zazwyczaj nikt tego nie potrzebuje, w tym wy sami.

Wskaźnik
Odkopcie źródłowe kody swoich aplikacji, zróbcie wskaźnik, w którym będzie wskazane, co i gdzie leży oraz jak działa, dodajcie opis projektu (analogiczne do readme.md), aby szybko zrozumieć, gdzie znajdują się logi i metryki. Programista, który będzie się tym zajmował po was, tylko podziękuje.

Rozumiejcie domenę
Jeśli posiadacie jakąś domenę, starajcie się mieć oko na sytuację. Brzmi banalnie, prawda, ale nie wszyscy pilnują, aby usługi były w jednolitym stylu. A praca w jednym standardzie jest naprawdę znacznie prostsza.

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.