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%Майже те саме, що й

• 10.5%У нас немає legacy, ми молодці4

• 5.2%Напишу в коментарях2

Проголосували 38 користувачів. Утрималися 20 користувачів.

Джерело: habr.com