🥇Legacy-szolgáltatások az ön infrastruktúrájában

Helló! A nevem Pasha Csernyak, fő fejlesztő a QIWI-nél, és ma az elkerülhetetlenről szeretnék beszélni. Az Örökségről.

Kezdjük azzal a kérdéssel: mi az az Örökség-szolgáltatás? Az Örökség-szolgáltatás egy olyan szolgáltatás, amelyhez a fejlesztő egy hete/hónapja/éve nem nyúlt? Vagy egy olyan szolgáltatás, amelyet egy kevésbé tapasztalt programozó, például konkrétan te írtál, de egy éve? Mostanra viszont jobb és tapasztaltabb lettél. Vagy az Örökség-szolgáltatás az, amit úgy döntöttél, hogy soha többé nem commitálsz, és lassan készítesz neki egy cserét? Mindenesetre, egy ilyen szolgáltatást figyelmen kívül hagyni és nem frissíteni – ez egy időzített bomba, ami később felrobbanhat.

Mielőtt rátérnénk arra, hogyan dolgozunk mi a QIWI-nél az Örökség-szolgáltatásainkkal, elmondom, hogyan rendszereztük a szolgáltatásokat a Pénztárcánál. Már két éve én felelek a működéséért. Ha bármilyen probléma merül fel, mindig először hozzám telefonálnak. Általában nem elég bátornak érzem magam ahhoz, hogy 11 órakor este másnak telefonáljak, így hát le kellett ülnöm, és foglalkoznom kellett a domainünk összes szolgáltatásával.

De én, mint minden ember, szeretek éjszaka aludni, ezért próbáltam kideríteni a problémák okát: „Fiúk, miért hívjátok engem?”. Erre egy meglehetősen tömör választ kaptam: „Hát kinek másnak?”. Mert én javítom a szolgáltatásokat, és a fiúk egyszerűen nem tudják, kinek kellene telefonálniuk.

Ezért a Pénztárca backend csapatának egyik retrospektív értekezletén eldöntöttük, hogy össze kellene állítani egy táblázatot, amelyen a szolgáltatásaink, mikroszolgáltatásaink és monolitjaink listája található, valamint az ezekért felelős személyek. A táblázatok általában hasznosak, ésszerű keretek között.

A felelősségi információk mellett a táblázat válaszokat is tartalmazott a következő kérdésekre: ki a szolgáltatás birtokosa, ki felelős a fejlődéséért, az architektúráért és az életciklusáért. Azok az emberek, akik felelősek a szolgáltatásért – ők azok, akik szükség esetén meg tudják javítani. A szolgáltatás birtokosa jogosult +2-t hagyni a commitokban, a felelősöknek is kötelező részt venniük a felülvizsgálatban, mielőtt a szolgáltatás új commitot fogadna el.

Idő telt el, új gyakorlatok kezdtek teret nyerni, mint például a Kubernetes-be való migrálás, különféle ellenőrzések, spotbugs, ktlint, logok létrehozása Kibana-ban, szolgáltatások autodiscovery-ja közvetlen IP-címek megadása helyett és más hasznos dolgok. És mindenhol a táblázatunk lehetővé tette a szolgáltatásaink aktuális állapotának tartását. Számunkra ez egyfajta ellenőrző lista, amely azt mondja, hogy ez a szolgáltatás tudja ezt csinálni, de azt még nem. De tovább léptünk, megértve, hogy hiányzik az információ a szolgáltatásainkról, amiket nyomon követünk, hol találhatók a szolgáltatás forrásai, hol futnak a TeamCity-ben a build feladatok, hogyan vannak telepítve, hol tárolják a végponttól végpontig tesztek forrásait, architektúrával kapcsolatos fényképek, az elfogadott döntések. Ideális esetben szeretnénk, ha minden információ valahol elérhető lenne, amikor szükség van rá. Ezért a táblázatunk lett az információkeresés kiindulási pontja.

De a QIWI, bár megőrzi a startup szellemét, már egy nagy cég. Már 12 éve működünk, és a csapatok folyamatosan változnak: emberek távoznak, emberek érkeznek, új csapatok alakulnak. Rájöttünk, hogy a saját domainünkön több olyan szolgáltatás van, amelyeket örököltünk. Valami átkerült más csapatok fejlesztőitől, valami pedig valamilyen közvetett formában kapcsolódott a Pénztárcához, így most ez a szolgáltatás a mi birtokunkban van. Miért kellene megfejtenünk, hogy mi működik és hogyan? A szolgáltatás működik, és vannak olyan termékdolgok, amiket mindenképpen meg kell valósítani.

Ahogy lenni szokott

De egy időpontban rájövünk, hogy a szolgáltatás elveszíti a funkcióját, valami elromlott — mi a teendő ilyen helyzetben? A szolgáltatás egyszerűen leállt. Teljesen. És ezt először is véletlenül, másodsorban pedig fél év múlva tudjuk meg. Igen, ilyen előfordul. Az egyetlen dolog, amit tudtunk — milyen virtuális gépeken van telepítve a szolgáltatás, hol találhatók a forrásai, ennyi. Legyártunk egy git clone-t, és elmélyedünk annak a személynek a gondolataiban, aki ezt pár éve írta, de mit látunk? Sehol semmi ismerős Spring Boot, pedig már hozzászoktunk a dolgokhoz, hiszen full stack vagyunk meg hasonlók. Talán van ott Spring Framework? De nincs.

A srác, aki mindezt írta, kemény volt és mindent tiszta Java nyelven írt. Nincsenek megszokott eszközök a fejlesztők számára, és felmerül az ötlet — ezt mind újra kellene írni. Hiszen nekünk vannak mikroszolgáltatásaink, és minden kenyérpirítóból hallatszik a szokásos: "Fiúk, a mikroszolgáltatásokra van szükségetek!". Ha valami nem stimmel, nyugodtan elővehet bármilyen nyelvet, és minden rendben lesz.

A helyzet az, hogy jelenleg nincs megrendelőnk, aki felelős lenne ezért a szolgáltatásért. Milyen üzleti követelményei voltak, mit kellene egyáltalán tennie ennek a szolgáltatásnak? A szolgáltatás szorosan integrálva van az üzleti folyamataidba.

Most mondjátok meg, mennyire egyszerű átírni egy szolgáltatást anélkül, hogy ismernénk az üzleti követelményeket? A szolgáltatás logolása nem egyértelmű, hogy vannak-e metrikák — nem tudni. Milyenek, ha vannak — az még inkább ismeretlen. Ráadásul a szolgáltatásban hatalmas mennyiségű, homályos üzleti logikát tartalmazó osztály található. Valami bemegy egy adatbázisba, amiről szintén még nem tudunk semmit.

Honnan kezdjük?

A leglogikusabb dologgal — a tesztek meglétével. Ott általában van valamilyen logika, és levonhatók következtetések arról, hogy mi zajlik. Jelenleg divatos a TDD, de látjuk, hogy öt évvel ezelőtt minden gyakorlatilag ugyanezen a szinten állt: alig volt unit-teszt, és nem is mondanak róla sokat. Kivéve talán valami ellenőrzést, hogy hogy írunk alá egy xml-t valamilyen egyedi tanúsítvánnyal.

A kód alapján nem tudtunk sok mindent megérteni, ezért megnéztük, mi történik a virtuális gépen. Megnyitottuk a szolgáltatás naplóit, és találtunk benne egy HTTP kliens hibát, a saját aláírású tanúsítvány, amely a programban volt beépítve, sajnos lejárt. Kapcsolatba léptünk az elemzőinkkel, ők kértek egy új tanúsítványt, amit ki is adtak, és a szolgáltatás újra működik. Úgy tűnik, hogy a dolog itt véget ér, vagy mégsem? A szolgáltatás működik, ellát valamilyen funkciót, amely szükséges a vállalkozásunk számára. Vannak bizonyos alkalmazásfejlesztési sztenderdjeink, amelyek valószínűleg Önöknél is léteznek. Például nem tárolni a naplókat a noden egy mappában, hanem valamilyen tárolóban, mint az Elastic, és Kibana-n nézni őket. Említhetjük az aranymetrikákat is. Tehát a terhelés a szolgáltatáson, a szolgáltatásra érkező kérések száma, él-e még, hogyan halad a HealthCheck. Mindenesetre ezek a metrikák segítenek megtudni, mikor lehet nyugodt lelkiismerettel kivonni a forgalomból, és elfelejteni, mint egy rossz álmot.

Mi a teendő

Ezért egy ilyen régi szolgáltatást hozzáadunk a táblázathoz, majd keresünk önkéntes fejlesztőket, akik foglalkoznak a szolgáltatással és rendbe rakják: írnak róla legalább valamilyen információt, hozzáadják a Grafana-dashbordok linkjeit, a build feladatokat, és megértik, hogyan lehet telepíteni az alkalmazást, nem kézzel ftp-n keresztül feltölteni a fájlokat.

A legfontosabb — mennyi időt vesz igénybe mindez a hasznos önkéntes tevékenység? Egy sprint egy valamivel tapasztaltabb fejlesztő számára, például a 20%-os technikai adósság idején. De mennyi időbe telt megérteni az összetett logikát egy állami rendszerrel való kommunikációról, és újabb technológiákra átállítani? Erre nem vállalkozom, lehet, hogy egy hónap, de akár két hónap is a csapat munkájából. Ezt a tapasztalat alapján mondom, amikor egy új szolgáltatással integrálódtam.

Ugyanakkor a vállalkozás értékének kimenetele — semennyi. Teljesen. A szolgáltatás támogatásának átvétele és egy kis idő eltöltése rajta — normális. De a szolgáltatással végzett szokásos táncaink után felvettük a táblázatba, hozzáadtunk információt róla, és lehet, hogy egyszer átírjuk. De most már megfelel a szolgáltatások munkamódszereinek.

Összefoglalva, szeretném összefoglalni egy tervet, mit tegyünk a Legacy-szolgáltatásokkal.

A legacy újraírása a nulláról — rossz ötlet.
Komolyan, nem is érdemes ezen gondolkodni. Nyilvánvaló, hogy lenne néhány előny, de általában senkinek, még magának is, nincs szüksége rá.

Kézikönyv
Ássák elő az alkalmazásaik forráskódját, készítsenek egy kézikönyvet, amelyben meg van jelölve, hogy mi hol található és hogyan működik. Ide írják a projekt leírását (körülbelül readme.md), hogy gyorsan megértsék, hol találják a naplókat és a metrikákat. Az a fejlesztő, aki utánuk foglalkozik ezekkel, csak hálás lesz.

Értse a domént
Ha birtokol egy domaint, próbálja meg figyelemmel követni. Hangzik klisésen, igen, de nem mindenki ügyel arra, hogy a szolgáltatások egyformán működjenek. Pedig egy szabványos környezetben dolgozni sokkal egyszerűbb.

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.