Legacy-сэрвісы ў вашай інфраструктуры

Прывітанне! Мяне клічуць Паша Чарняк, я вядучы распрацоўшчык у QIWI, і сёння я хачу пагаварыць аб непазбежным. Аб Legacy.

Пачнём з пытання: што такое Legacy-сэрвіс? Legacy-сэрвіс — гэта сэрвіс, якога распрацоўшчык не датычыўся ўжо тыдзень/месяц/год? Ці гэта сэрвіс, які быў напісаны менш дасведчаным праграмістам, напрыклад, канкрэтна вамі, але год таму? А зараз-то вы страмчэй і дасведчаней. Ці ўсё ж такі, Legacy-сэрвіс — гэта сэрвіс, які вы вырашылі ніколі больш не камеціць і паціху рыхтуеце яму замену? У любым выпадку, пакідаць такі сэрвіс без нагляду і не абнаўляць - гэта бомба запаволенага дзеяння, якая можа падарвацца пазней.

Перш чым пераходзіць да таго, як мы ў QIWI працуем з нашымі Legacy-сэрвісамі, я раскажу, як мы навялі парадак з сэрвісамі ў кашальку. Вось ужо два гады я адказваю за яго працаздольнасць. Калі ёсць нейкая праблема, то заўсёды найперш тэлефануюць мне. Мне звычайна бракуе нахабства ў 11 гадзін вечара патэлефанаваць камусьці яшчэ, таму даводзілася садзіцца і разбірацца ва ўсіх сэрвісах нашага дамена.

Але я, як і любы чалавек, люблю спаць па начах, таму спрабаваў разабрацца з эксплуатацыяй: "Хлопцы, а чаму вы мне тэлефануеце?". На што атрымаў цалкам лаканічны адказ віду "А каму яшчэ?". Таму што я сэрвісы чыню, а яшчэ хлопцы банальна не ведаюць, каму тэлефанаваць.

Таму на адной з рэтраспектыў каманды бэкэнда кашалька мы вырашылі, што трэба скласці таблічку, на якой напісаны спіс нашых сэрвісаў, мікрасэрвісаў і маналітаў кашалька, і адказных за іх. Таблічкі гэта ўвогуле карысна, у разумных межах.

Акрамя інфармацыі аб тым, хто завошта адказвае, там былі адказы на пытанні: хто ўладальнік сэрвісу, хто адказвае за яго развіццё, за архітэктуру і жыццёвы цыкл. Людзі, адказныя за гэты сэрвіс - людзі, якія могуць у выпадку чаго яго паправіць. Уладальнік сэрвісу мае права пакінуць +2 у комітах, адказныя таксама павінны абавязкова прысутнічаць на раўью, перш чым гэты сэрвіс прыме на сябе новы коміт.

Час ішло, пачалі прымяняцца новыя практыкі, напрыклад, міграцыя ў Kubernetes, усякія checkstyle, spotbugs, ktlint, наяўнасць логаў у кібане, autodiscovery сэрвісаў замест указання напрамую адрасоў і іншыя карыснасці. І ўсюды наша табліца дазваляла падтрымліваць актуальнасць нашых сэрвісаў. Для нас гэта нейкі чэкліст, які кажа пра тое, што гэты сэрвіс вось гэта рабіць умее, а вось гэтага пакуль яшчэ няма. Але мы ішлі далей, разумеючы, што нам не хапае інфармацыі пра нашыя сэрвісы, за якімі мы сочым, дзе ляжаць зыходнікі сэрвісу. , дзе запускаюцца цягі на зборку ў TeamCity, як яны дэплоі, дзе захоўваюцца зыходнікі end2end тэстаў, фатаграфіі з грумінгаў пра архітэктуру, пра прынятыя рашэнні. У ідэале хацелася, каб уся гэтая інфармацыя недзе ляжала і была пад рукой, калі трэба. Таму наша таблічка стала пунктам адпраўлення за пошукам інфармацыі.

Але QIWI, хоць і захоўвае дух стартапу, з'яўляецца вялікай кампаніяй. Нам ужо 12 гадоў, і каманды мяняюцца: людзі сыходзяць, людзі прыходзяць, фармуюцца новыя каманды. І мы выявілі на сваім дамене некалькі сэрвісаў, якія дасталіся нам у спадчыну. Нешта прыйшло з распрацоўшчыкамі з іншых каманд, нешта проста неяк апасродкавана ставілася да кашалька, таму сэрвіс у нас цяпер на балансе. Разбірацца з тым, што і як працуе - навошта? Сэрвіс жа працуе, і ў нас ёсць прадуктовыя фічы, якія трэба абавязкова запілаваць.

Як бывае

Але ў нейкі момант часу мы выяўляем, што сэрвіс перастае выконваць сваю функцыю, нешта зламалася - як быць у такой сітуацыі? Сэрвіс проста перастаў працаваць. Зусім. А даведаліся мы пра гэта, па-першае, выпадкова, а па-другое, праз паўгода. Так бывае. Адзінае, што мы ведалі - на якіх віртуалка разгорнуты сэрвіс, дзе ляжаць яго зыходнікі, і ўсё. Мы робім git clone і апускаемся ў думкі чалавека, які пісаў гэта некалькі гадоў таму, але што мы бачым? Ніякага звыклага для нас Spring Boot, хоць абвыклі да ўсяго, у нас жа full stack і ўсё такое. Можа там ёсць Spring Framework? А вось і не.

Хлопец, які ўсё гэта пісаў, быў суровы і пісаў усё на чыстай Java. Звыклых прылад для распрацоўніка няма, і ўзнікае ідэя - трэба было б гэта ўсё перапісаць. У нас жа мікрасэрвісы ёсць, а з кожнага тостара даносіцца звыклае «Хлопцы, мікрасэрвісы – гэта тое, што вам трэба!». Калі раптам нешта не так, вы спакойна возьмеце любую мову і ўсё будзе выдатна.

Штука ў тым, што зараз у нас няма заказчыка, які адказвае за гэты сэрвіс. Якія ў яго былі бізнес-патрабаванні, што ўвогуле павінен рабіць гэты сэрвіс? А сэрвіс шчыльна інтэграваны ў вашыя бізнес-працэсы.

А зараз скажыце, наколькі проста перапісаць сэрвіс, не ведаючы яго бізнэс-патрабаванняў? Сэрвіс незразумела як лагіруецца, ці ёсць метрыкі - невядома. Якія яны, калі ёсць - тым больш невядома. І пры гэтым у сэрвісе вялізная колькасць класаў незразумелай бізнес-логікі. Нешта ўваходзіць у нейкую базу дадзеных, пра якую мы таксама пакуль нічога ня ведаем.

З чаго ж пачаць?

З самага лагічнага - з наяўнасці тэстаў. Там звычайна напісана хоць нейкая логіка і можна зрабіць высновы аб тым, што адбываецца. Цяпер жа модна TDD, але мы бачым, што тыя ж 5 гадоў таму ўсё было практычна гэтак жа, як цяпер: unit-тэстаў амаль няма, ды і не скажуць яны нам зусім нічога. Ну апрача хіба што нейкай праверкі, як падпісваецца які-небудзь xml з якім-небудзь кастамным сертыфікатам.

Па кодзе нічога зразумець не ўдалося, і мы пашліць глядзець, чаго там на віртуалцы. Адкрылі логі сэрвісу, знайшлі ў іх памылку http-кліента, самападпісаны сертыфікат, які быў ушыты ў рэсурсы прыкладання, бессаромна пратух. Мы звязаліся з нашымі аналітыкамі, яны папрасілі новы сертыфікат, нам яго выпусцілі і сервіс зноў працуе. Здавалася б, што на гэтым усё. Ці не? Усё ж сэрвіс працуе, ён выконвае нейкую функцыю, якая патрэбна нашаму бізнэсу. У нас ёсць нейкія стандарты распрацоўкі прыкладанняў, якія хутчэй за ўсё ёсць і ў вас. Напрыклад, не захоўваць логі на нодзе ў тэчцы, а захоўваць у нейкім сховішчы, тыпу эластыка, глядзець на іх у кібане. Можна ўзгадаць і залатыя метрыкі. Гэта значыць нагрузка на сэрвіс, колькасць запытаў на сэрвіс, жывы ён ці не, як у яго HealthCheck праходзіць. Прынамсі, гэтыя метрыкі дапамогуць даведацца, калі яго са спакойным сумленнем можна вывесці з эксплуатацыі і забыцца як страшны сон.

Што рабіць

Таму мы дадаем такі стары сэрвіс у таблічку, а потым ідзем шукаць з ліку распрацоўшчыкаў добраахвотнікаў, якія зоймуцца сэрвісам і прывядуць яго ў парадак: напішуць хоць нейкую інфармацыю аб сэрвісе, дададуць спасылкі на дашборды ў графане, на цягі зборкі, зразумеюць, як разгортваць дадатак, не рукамі ж накідваць з дапамогай ftp файлікі.

Галоўнае - колькі ўся гэтая карысная добраахвотніцкая актыўнасць зойме часу? Адзін спрынт для больш-менш дасведчанага распрацоўніка, напрыклад, падчас 20%-га тэхдоўгу. А колькі часу пайшло на тое, каб зразумець усю закаранелую логіку па зносінам з нейкай дзяржсістэмай, прывесці яе на навейшыя тэхналогіі? Я за гэта не ручаюся, можа, месяц, а можа, і дзве працы каманды. Гэта я кажу па вопыце інтэграцыі ў цяперашні час з якім-небудзь новым сэрвісам.

Пры гэтым выхлапу бізнес-каштоўнасці - ніякага. Зусім. Узяць сэрвіс на падтрымку і выдаткаваць на гэта крыху часу - нармальна. Але пасля нашых стандартных танцаў з сэрвісам мы дадалі яго ў табліцу, дадалі інфармацыі аб ім і, магчыма, калі-небудзь перапішам. Але зараз ён адпавядае нашым стандартам працы сэрвісаў.

Як вынік, хацелася б падвесці да нейкага плана, што рабіць з Legacy-сэрвісамі.

Перапісваць legacy з нуля — дрэнная задума
Сур'ёзна, можна нават не думаць аб гэтым. Зразумела, што хацелася б, і бачацца нейкія плюсы, але звычайна гэта не трэба нікому, у тым ліку вас саміх.

Даведнік
Адкапайце зыходныя коды вашых прыкладанняў, зрабіце даведнік, у якім будзе паказана, што і дзе ляжыць і як працуе, туды ж упішыце апісанне праекту (умоўны readme.md), каб хутка разумець, дзе ляжаць логі і метрыкі. Распрацоўнік, які будзе разбірацца з гэтым пасля вас, толькі дзякуй скажа.

Разумейце дамен
Калі вам прыналежыць нейкі дамен, імкніцеся трымаць руку на пульсе. Гучыць банальна, так, але не ўсё сочаць за тым, каб сэрвісы былі ў адзіным ключы. Хоць працаваць у адным стандарце насамрэч адчувальна прасцей.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Што вы робіце са сваім legacy?

• 31.5%Перапісваю з нуля, так правільней12

• 52.6%Амаль тое ж самае, што і вы20

• 10.5%У нас няма legacy, мы малайцы4

• 5.2%Напішу ў каментарах2

Прагаласавалі 38 карыстальнікаў. Устрымаліся 20 карыстальнікаў.

Крыніца: habr.com