🥇Наследствени услуги в вашата инфраструктура

Здравейте! Аз съм Паша Черняк, главен разработчик в QIWI и днес искам да поговоря за неизбежното. За Legacy.

Нека започнем с въпроса: какво е Legacy-сервис? Legacy-сервис е услугата, до която разработчикът не се е докосвал вече седмица/месец/година? Или е услугата, написана от по-малко опитен програмист, например от вас преди година? А сега вие сте по-добри и опитни. Или все пак, Legacy-сервисът е услугата, която сте решили да не комитирате повече и бавно подготвяте замяна за нея? Във всеки случай, оставянето на такава услуга без надзор и без актуализация е бомба с часовников механизъм, която може да избухне по-късно.

Преди да премина към начина, по който в QIWI работим с нашите Legacy-сервизи, ще разкажа как подредихме услугите в Кошелек. Вече две години се грижа за неговата работоспособност. Ако има някакъв проблем, първо ми се обаждат. Обикновено нямам куража да звъня на някой друг в 11 часа вечерта, затова ми се налага да седя и да разбера всички услуги от домейна ни.

Но аз, като всеки човек, обичам да спя през нощта, така че се опитвам да разбера причината за обажданията: "Ребята, защо ми звъните?". На което получих съвсем лаконичен отговор: "А на кого друг?". Защото аз поправям услугите, а и момчетата просто не знаят на кого да звъннат.

Затова на една от ретроспективите на екипа за бекенд на Кошелек решихме, че трябва да съставим таблица, на която да е написан списък с нашите услуги, микросервизи и монолити в Кошелек, и отговорните за тях. Таблиците всъщност са полезни, в разумни граници.

Освен информацията за това, кой за какво отговаря, там имаше отговори на въпросите: кой е собственикът на услугата, кой отговаря за развитието ѝ, за архитектурата и жизнения цикъл. Хората, отговорни за тази услуга, са хората, които могат да я поправят при нужда. Собственикът на услугата има право да остави +2 в комитите, а отговорните също трябва непременно да присъстват на рецензията, преди услугата да приеме нов комит.

Времето мина, започнаха да се прилагат нови практики, като миграция в Kubernetes, различни checkstyle, spotbugs, ktlint, наличието на логове в Kibana, autodiscovery на услуги вместо директно посочване на адреси и други полезни функции. И навсякъде нашата таблица позволявала да поддържаме актуалността на нашите услуги. За нас това е вид контролен списък, който показва, че тази услуга може да прави нещо, а другото все още не. Но ние продължавахме напред, разбирайки, че ни липсва информация за нашите услуги, за които следим, къде са изходниците на услугата, къде се стартират задачите за сборка в TeamCity, как се деплоят, къде се съхраняват изходниците на end2end тестовете, снимки с архитектурни груминги, относно взетите решения. В идеалния случай, искахме цялата тази информация да бъде някъде и на разположение, когато е необходимо. Затова нашата таблица стана отправна точка за търсене на информация.

Но QIWI, макар и да запазва духа на стартап, е голяма компания. Вече сме на 12 години и екипите се променят: хората си отиват, хората идват, формират се нови екипи. И открихме на нашия домейн няколко услуги, останали ни наследство. Нещо дойде от разработчиците от други екипи, нещо просто по някакъв начин се отнасяше до Кошелека, затова услугата се оказа на нашия баланс. Защо да се разбираме с това какво и как работи? Услугата работи, и имаме продуктови функции, които задължително трябва да реализираме.

Както се случва

Но в даден момент откриваме, че услугата спира да изпълнява функцията си, нещо се е счупило — какво да правим в такава ситуация? Услугата просто е спряна. Напълно. А разбрахме за това, първо, случайно, и второ, след половин година. Така става. Единственото, което знаехме, беше на какви виртуални машини е разположена услугата, къде се намират изходниците и всичко. Правим git clone и се потапяме в мислите на човека, който е писал това преди няколко години, но какво виждаме? Няма класическия за нас Spring Boot, въпреки че сме свикнали на всичко, нашата система е full stack и всичко това. Може да има Spring Framework? А, но не.

Момчето, което написа всичко това, беше строг и пишеше всичко на чист Java. Няма обичайни инструменти за разработчик и идва идеята - трябва да го пренапишем. Нали имаме микросервизи, а от всяка тостерчета се чува познатото "Хора, микросервизите са точно това, от което се нуждаете!". Ако нещо не е наред, спокойно можете да вземете всеки език и всичко ще бъде отлично.

Работата е там, че в момента нямаме клиент, който да отговаря за този сървис. Какви бизнес изисквания имаше, какво точно трябва да прави този сървис? А сървисът е дълбоко интегриран в вашите бизнес процеси.

А сега кажете колко лесно е да пренапишете сървис, без да знаете неговите бизнес изисквания? Сървисът не е логирован ясно, дали има метрики - неизвестно. Какви са те, ако ги има - още по-неизвестно. И в същото време в сървиса има огромно количество класове с неясна бизнес логика. Нещо влиза в някаква база данни, за която също засега нищо не знаем.

С какво да започнем?

С най-логичното - наличието на тестове. Там обикновено е написана поне някаква логика и можем да направим изводи за това, което се случва. В момента е на мода TDD, но виждаме, че преди 5 години всичко беше практически така, както е сега: почти няма unit тестове, а и те няма да ни кажат нищо. Освен може би някаква проверка как се подписва някакъв xml с някакъв кастом сертификат.

По коду нищо не можахме да разберем и решихме да погледнем какво става на виртуалната машина. Отворихме логовете на услугата и намерихме в тях грешка на http-клиента – самоподписан сертификат, който беше вграден в ресурсите на приложението, беше изтекъл. Свързахме се с нашите анализатори, които поискаха нов сертификат, издадоха ни такъв и услугата отново заработи. Темата би трябвало да приключи тук. Или не? Услугата работи и изпълнява някаква функция, която е необходима за нашия бизнес. Имаме определени стандарти за разработка на приложения, които вероятно имате и вие. Например, да не съхраняваме логовете на нода в папка, а да ги съхраняваме в хранилище, като Elasticsearch, и да ги наблюдаваме в Kibana. Можем да си припомним и златните метрики. Тоест натоварването на услугата, брой заявки към услугата, дали е активна или не, как преминава HealthCheck. Най-малкото тези метрики ще помогнат да разберем кога спокойно можем да я извадим от експлоатация и да забравим за нея като за лош сън.

Какво да правим

Затова добавяме такава стара услуга в таблицата и след това търсим сред разработчиците доброволци, които да се заемат с услугата и да я приведат в ред: да напишат някаква информация за услугата, да добавят линкове към дашбордовете в Grafana, към задачите за изграждане, да разберат как да разгръщат приложението, нали не трябва да презареждат файловете ръчно с ftp.

Важно е — колко време ще отнеме тази полезна доброволческа активност? Един спринт за по-или-малко опитен разработчик, например, по време на 20%-ния технически дълг. А колко време е нужно, за да се разбере цялата закореняла логика на взаимодействие с някаква държавна система и да я приведем към по-нови технологии? Не мога да гарантирам за това – може да отнеме месец, а може и два работа на екипа. Казвам това от опит с интеграцията в текущото време с някаква нова услуга.

В същото време нищо от бизнес стойността не се получава. Абсолютно нищо. Да поемеш услуга за поддръжка и да прекараш малко време за това е нормално. Но след нашите стандартни танци с услугата, добавихме я в таблицата, добавихме информация за нея и, може би, някой ден ще я препишем. Но в момента тя отговаря на нашите стандарти за работа с услуги.

Като заключение, бих искал да подведа към някакъв план какво да правим с Legacy услугите.

Да презапишем легаси услуги от нулата — лоша идея
Наистина, можете дори да не мислите за това. Ясно е, че би било хубаво, и се виждат някои плюсове, но обикновено това не е нужно на никого, включително и на вас самите.

Наръчник
Изкопайте изходните кодове на вашите приложения, направете наръчник, в който да е посочено какво и къде се намира и как работи. Там също така напишете описание на проекта (условен readme.md), за да разбирате бързо къде се намират логовете и метриките. Разработчикът, който ще се занимава с това след вас, само ще ви благодари.

Разбирайте домейна
Ако притежавате някакъв домейн, опитайте се да държите ръка на пулса. Звучи банално, да, но не всички следят за това, за да са услугите в един и същи стил. А наистина е много по-лесно да работите в един стандарт.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.