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

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

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

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

Но аз, като всеки човек, обичам да спя през нощта, така че се опитах да се справя с експлоатацията: „Момчета, защо ми се обаждате?“ На което получих доста лаконичен отговор от рода на "Кой друг?" Защото аз поправям услуги и момчетата просто не знаят на кого да се обадят.

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

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

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

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

Как се случва

Но в някакъв момент откриваме, че услугата спира да изпълнява функциите си, нещо е счупено - какво да правим в такава ситуация? Услугата просто спря да работи. Изобщо. И ние разбрахме за това, първо, случайно, и второ, шест месеца по-късно. Случва се. Единственото нещо, което знаехме, беше на кои виртуални машини ще бъде разгърната услугата, къде се намират нейните източници и това е всичко. Ние правим git клонинг и се потапяме в ума на човека, който е написал това преди няколко години, но какво виждаме? Нищо от Spring Boot, който ни е познат, въпреки че сме свикнали с всичко, имаме пълен стек и всичко това. Може би там има Spring Framework? Но не.

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

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

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

Къде да започнем?

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

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

Какво да правя

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

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

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

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

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

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

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

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

Какво правите с вашето наследство?

• 31.5%Преписвам от нулата, по-правилно е 12

• 52.6%Почти същото като теб20

• 10.5%Ние нямаме наследство, ние сме страхотни4

• 5.2%Ще пиша в коментарите 2

38 потребители гласуваха. 20 потребители се въздържаха.

Източник: www.habr.com