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

Здравейте! Аз съм Паша Черняк, главен разработчик в 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-клиента, самоподписаният сертификат, който беше вграден в ресурсите на приложението, изтече. Свързахме се с нашите анализатори, те поискаха нов сертификат, който ни издадоха, и услугата отново заработи. Беше ни казано, че това е всичко. Или не? Все пак услугата работи, изпълнява определена функция, от която имаме нужда в бизнеса. Имаме определени стандарти за разработка на приложения, които вероятно имате и вие. Например, не да се съхраняват логовете на нода в папката, а в някакво хранилище, подобно на еластичност, да се гледат в Kibana. Можем да споменем и златните метрики. Тоест натоварването на услугата, броя на заявките към услугата, жив ли е или не, как минава HealthCheck. Най-малкото, тези метрики ще помогнат да разберем, кога спокойно можем да изключим услугата и да забравим за нея като за лош сън.

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

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

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

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

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

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

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

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

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