Starsze usługi w Twojej infrastrukturze

Cześć! Nazywam się Pasha Chernyak, jestem wiodącym programistą w QIWI i dzisiaj chcę porozmawiać o tym, co nieuniknione. O Dziedzictwie.

Zacznijmy od pytania: czym jest usługa Legacy? Czy starsza usługa to usługa, z której programista nie korzystał przez tydzień/miesiąc/rok? A może jest to usługa napisana przez mniej doświadczonego programistę, np. specjalnie przez Ciebie, ale rok temu? A teraz jesteś fajniejszy i bardziej doświadczony. A może usługa Legacy jest usługą, z której postanowiłeś już nigdy więcej nie korzystać i powoli przygotowujesz jej następcę? W każdym razie pozostawienie takiej usługi bez nadzoru i brak aktualizacji to bomba zegarowa, która może później eksplodować.

Zanim przejdę do tego, jak w QIWI współpracujemy z naszymi usługami Legacy, opowiem, jak uporządkowaliśmy usługi w Portfelu. Od dwóch lat jestem odpowiedzialna za jego realizację. Jeśli jest jakiś problem, zawsze najpierw do mnie dzwonią. Zwykle nie mam śmiałości dzwonić do kogoś innego o 11:XNUMX, więc musiałem usiąść i wymyślić wszystkie usługi w naszej domenie.

Ale ja, jak każdy człowiek, lubię spać w nocy, więc próbowałem poradzić sobie z wyzyskiem: „Chłopaki, dlaczego do mnie dzwonicie?” Na co otrzymałem dość lakoniczną odpowiedź typu „Kto jeszcze?” Ponieważ naprawiam usługi, a chłopaki po prostu nie wiedzą, do kogo zadzwonić.

Dlatego też na jednej z retrospekcji zespołu backendowego Portfela uznaliśmy, że trzeba zrobić podpis z listą naszych usług, mikroserwisów i monolitów portfela oraz osób za nie odpowiedzialnych. Znaki są na ogół przydatne, w rozsądnych granicach.

Oprócz informacji o tym, kto za co odpowiada, znalazły się 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ą to naprawić, jeśli coś się stanie. Właściciel usługi ma prawo zostawić +2 w zatwierdzeniach, osoby odpowiedzialne również muszą być obecne przy przeglądzie, zanim usługa zaakceptuje nowe zatwierdzenie.

Z biegiem czasu zaczęto stosować nowe praktyki, np. migrację do Kubernetesa, wszelkiego rodzaju checkstyle, spotbugi, ktlint, obecność logów w Kibanie, usługi autodiscovery zamiast bezpośredniego podawania adresów i inne przydatne rzeczy. I wszędzie nasz stół pozwolił nam zachować aktualność naszych usług. Dla nas jest to swego rodzaju checklista, która mówi, że ta usługa może to zrobić, ale jeszcze tego nie robi.Ale ruszyliśmy dalej, zdając sobie sprawę, że brakuje nam informacji o naszych usługach, które monitorujemy, gdzie znajdują się źródła usług, gdzie uruchamiane są zadania montażowe w TeamCity, jak są wdrażane, gdzie przechowywane są źródła testów end2end, zdjęcia z sesji pielęgnacyjnych na temat architektury, podjętych decyzji. Idealnie byłoby, gdyby wszystkie te informacje gdzieś leżały i były pod ręką, gdy zajdzie taka potrzeba. Dlatego też nasz znak stał się punktem wyjścia do poszukiwania informacji.

Ale QIWI, choć zachowuje ducha startupu, jest dużą firmą. Mamy już 12 lat, a zespoły się zmieniają: ludzie odchodzą, ludzie przychodzą, powstają nowe zespoły. Odkryliśmy też kilka usług w naszej domenie, które odziedziczyliśmy. Część pochodziła od programistów z innych zespołów, część po prostu była w jakiś sposób pośrednio związana z Portfelem, dzięki czemu mamy teraz tę usługę w naszym bilansie. Zrozumienie co i jak to działa - dlaczego? Usługa działa, a my mamy funkcje produktu, które zdecydowanie wymagają ulepszenia.

Jak to się dzieje

Jednak w pewnym momencie odkrywamy, że usługa przestaje spełniać swoją funkcję, coś jest zepsute – co zrobić w takiej sytuacji? Usługa po prostu przestała działać. W ogóle. I dowiedzieliśmy się o tym, po pierwsze, przez przypadek, a po drugie, sześć miesięcy później. Zdarza się. Wiedzieliśmy jedynie, na jakich maszynach wirtualnych usługa będzie wdrożona, gdzie będą zlokalizowane jej źródła i to wszystko. Robimy klona gita i zagłębiamy się w umysł osoby, która napisała to kilka lat temu, ale co widzimy? Żadnego ze Spring Boot, który jest nam znany, chociaż jesteśmy przyzwyczajeni do wszystkiego, mamy pełny stos i tak dalej. Może jest tam Spring Framework? Ale nie.

Facet, który to wszystko napisał, był twardy i napisał wszystko w czystej Javie. Nie ma zwykłych narzędzi dla programisty i pojawia się pomysł: musimy to wszystko napisać od nowa. Mamy mikrousługi, a z każdego tostera pochodzi zwykłe „Chłopaki, mikrousługi są tym, czego potrzebujesz!” Jeśli nagle coś pójdzie nie tak, możesz spokojnie przyjąć dowolny język i wszystko będzie dobrze.

Rzecz w tym, że teraz nie mamy klienta, który byłby odpowiedzialny za tę usługę. Jakie miał wymagania biznesowe, czym powinna zajmować się ta usługa? Usługa jest ściśle zintegrowana z procesami biznesowymi.

A teraz powiedz mi, jak łatwo jest przepisać usługę, nie znając jej wymagań biznesowych? Nie jest jasne, w jaki sposób usługa jest rejestrowana; nie wiadomo, czy istnieją metryki. Tym bardziej nieznane jest, czym one są, jeśli w ogóle istnieją. Jednocześnie usługa zawiera ogromną liczbę klas niezrozumiałej logiki biznesowej. Coś jest zawarte w jakiejś bazie danych, o czym też jeszcze nic nie wiemy.

Od czego zacząć?

Z najbardziej logicznego punktu - dostępność testów. Zwykle jest tam zapisana przynajmniej jakaś logika i można wyciągnąć wnioski na temat tego co się dzieje. Teraz TDD jest modne, ale widzimy, że 5 lat temu wszystko było prawie tak samo jak teraz: testów jednostkowych prawie nie ma i w ogóle nic nam nie powiedzą. Cóż, może z wyjątkiem pewnego rodzaju weryfikacji, w jaki sposób niektóre pliki XML są podpisane jakimś niestandardowym certyfikatem.

Nie mogliśmy nic zrozumieć z kodu, więc poszliśmy zobaczyć, co jest w maszynie wirtualnej. Otworzyliśmy logi usługi i znaleźliśmy w nich błąd klienta http; samopodpisany certyfikat osadzony w zasobach aplikacji był bezwstydnie zepsuty. Skontaktowaliśmy się z naszymi analitykami, poprosili o nowy certyfikat, wystawili nam go i usługa znów działa. Wydawać by się mogło, że to wszystko. Albo nie? Przecież usługa działa, pełni jakąś funkcję, której potrzebuje nasz biznes. Mamy pewne standardy tworzenia aplikacji, które najprawdopodobniej Ty też masz. Na przykład nie przechowuj dzienników w węźle w folderze, ale przechowuj je w jakimś magazynie, takim jak elastyczny, i przeglądaj je w Kibanie. Można też pamiętać o złotych metrykach. To znaczy obciążenie usługi, liczba żądań usługi, to, czy żyje, czy nie, jak przebiega jego kontrola zdrowia. Przynajmniej te wskaźniki pomogą Ci wiedzieć, kiedy można go wycofać z użytku z czystym sumieniem i zapomnieć jak zły sen.

Co robić

Dlatego dodajemy do tabeli taką starą usługę, a potem szukamy wśród programistów ochotników, którzy zajmą się usługą i ją uporządkują: napiszą chociaż trochę informacji o usłudze, dodadzą linki do dashboardy w Grafanie, do zadań montażowych i zrozumienia sposobu wdrażania aplikacji, nie przesyłaj ręcznie plików za pomocą FTP.

Najważniejsze jest to, jak długo zajmie cała ta pożyteczna działalność wolontariacka? Jeden sprint dla mniej lub bardziej doświadczonego programisty np. podczas 20% długu technicznego. Ile czasu zajęło zrozumienie całej zakorzenionej logiki komunikacji z określonym systemem państwowym i wprowadzenie jej do nowszych technologii? Nie mogę za to ręczyć, może miesiąc, może dwa pracy zespołu. Mówię to z doświadczenia obecnej integracji z jakąś nową usługą.

Jednocześnie nie następuje uwolnienie wartości biznesowej. W ogóle. To normalne, że wynajmujesz usługę wsparcia i spędzasz na niej trochę czasu. Ale po naszych standardowych tańcach z usługą, dodaliśmy go do tabeli, dodaliśmy informacje na jego temat i być może kiedyś przepiszemy. Ale teraz spełnia nasze standardy usług.

W związku z tym chciałbym opracować plan wykorzystania usług Legacy.

Pisanie wszystkiego od nowa to zły pomysł
Poważnie, nie musisz nawet o tym myśleć. Jasne, że mi się to podoba i są pewne zalety, ale zwykle nikt tego nie potrzebuje, łącznie z tobą.

Katalog
Wykop kody źródłowe swoich aplikacji, stwórz podręcznik, który wskaże co gdzie jest i jak to działa, wpisz tam opis projektu (warunkowy readme.md), aby szybko zorientować się, gdzie znajdują się logi i metryki. Deweloper, który zajmie się tym później, powie tylko dziękuję.

Zrozum domenę
Jeśli posiadasz domenę, staraj się trzymać rękę na pulsie. Brzmi banalnie, owszem, ale nie każdy dba o to, aby usługi były w jednym kluczu. Ale praca w jednym standardzie jest w rzeczywistości znacznie łatwiejsza.

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Co robisz ze swoim dziedzictwem?

• 31.5%Piszę od nowa, bardziej poprawne jest 12

• 52.6%Prawie taki sam jak ty20

• 10.5%Nie mamy dziedzictwa, jesteśmy wspaniali4

• 5.2%Napiszę w komentarzach2

Głosowało 38 użytkowników. 20 użytkowników wstrzymało się od głosu.

Źródło: www.habr.com