Helló! A nevem Chernyak pasa, vezető fejlesztő vagyok a QIWI-nél, és ma az elkerülhetetlenről szeretnék beszélni. A Legacyről.
Kezdjük a kérdéssel: mi az a Legacy szolgáltatás? Az örökölt szolgáltatás olyan szolgáltatás, amelyhez a fejlesztő egy hétig/hónapig/évig nem nyúlt hozzá? Vagy ez egy olyan szolgáltatás, amit például egy kevésbé tapasztalt programozó írt konkrétan te, de egy éve? És most menőbb és tapasztaltabb vagy. Vagy a Legacy szolgáltatás egy olyan szolgáltatás, amelyet úgy döntött, hogy soha többé nem vállal el, és lassan egy cserét készít elő? Mindenesetre egy ilyen szolgáltatás felügyelet nélkül hagyása és frissítés nélkül időzített bomba, amely később felrobbanhat.
Mielőtt rátérnénk arra, hogyan dolgozunk a QIWI-nél a Legacy szolgáltatásainkkal, elmondom, hogyan hoztuk rendbe a szolgáltatásokat a Walletban. Már két éve én vagyok a felelős a teljesítményéért. Ha bármi probléma van, mindig engem hívnak először. Általában nincs bátorságom felhívni valakit este 11 órakor, ezért le kellett ülnöm, és kitalálnom a domain összes szolgáltatását.
De én, mint bárki más, szeretek aludni éjszaka, ezért megpróbáltam megbirkózni a kizsákmányolással: „Srácok, miért hívtok engem?” Erre egy meglehetősen lakonikus választ kaptam, mint például: „Ki más?” Mert én javítom a szolgáltatásokat, és a srácok egyszerűen nem tudják, kit hívjanak.
Ezért a Wallet backend csapatának egyik retrospektívjén úgy döntöttünk, hogy táblát kell készítenünk szolgáltatásainkról, mikroszolgáltatásainkról és pénztárca-monolitjainkról, valamint az ezekért felelős személyekről. A jelek általában hasznosak, ésszerű határokon belül.
Amellett, hogy kinek mi a felelőse, kaptak választ a kérdésekre: ki a szolgáltatás tulajdonosa, ki a felelős annak fejlesztéséért, építészetéért és életciklusáért. A szolgáltatásért azok az emberek felelősek, akik meg tudják javítani, ha valami történik. A szolgáltatás tulajdonosának joga van +2-t hagyni a commitokban, a felelősöknek is jelen kell lenniük a felülvizsgálaton, mielőtt ez a szolgáltatás új commitot fogadna el.
Az idő előrehaladtával új gyakorlatok kerültek alkalmazásra, például a Kubernetesre való migráció, mindenféle checkstyle, spotbugok, ktlint, naplók jelenléte a Kibanában, automatikus feltáró szolgáltatások a közvetlen címmegadás helyett és egyéb hasznos dolgok. És mindenhol, ahol asztalunk lehetővé tette, hogy fenntartsuk szolgáltatásaink relevanciáját. Számunkra ez egyfajta ellenőrző lista, amely azt mondja, hogy ez a szolgáltatás meg tudja csinálni, de még nem. De továbbmentünk, mert rájöttünk, hogy hiányoznak az információk a szolgáltatásainkról, amelyeket figyelünk, hol találhatók a szolgáltatási források, hol indítják el az összeszerelési feladatokat a TeamCityben, hogyan telepítik őket, hol tárolják az end2end tesztek forrásait, fotók a grooming ülésekről az architektúráról, a meghozott döntésekről. Ideális esetben azt szeretném, ha ezek az információk valahol elhelyezkednének, és szükség esetén kéznél legyenek. Ezért a mi jelünk lett az információkeresés kiindulópontja.
De a QIWI, bár megőrzi a startup szellemiségét, egy nagy cég. Már 12 évesek vagyunk, és változnak a csapatok: elmennek, jönnek, új csapatok alakulnak. És felfedeztünk számos szolgáltatást a domainünkben, amelyeket örököltünk. Egy részük más csapatok fejlesztőitől érkezett, némelyik egyszerűen közvetve kapcsolódik a Wallethez, így most már a mérlegünkben is szerepel a szolgáltatás. Annak megértése, hogy mi és hogyan működik – miért? A szolgáltatás működik, és vannak olyan termékjellemzőink, amelyeket mindenképpen fejleszteni kell.
Hogyan történik
De egy bizonyos időpontban rájövünk, hogy a szolgáltatás nem látja el funkcióját, valami elromlott - mit tegyünk ilyen helyzetben? A szolgáltatás egyszerűen leállt. Egyáltalán. És erről egyrészt véletlenül, másrészt hat hónappal később értesültünk. Megtörténik. Az egyetlen dolog, amit tudtunk, hogy a szolgáltatás mely virtuális gépeken lesz telepítve, hol találhatók a forrásai, és ez minden. Csinálunk egy git klónt, és belemerülünk annak a fejébe, aki ezt néhány éve írta, de mit látunk? A számunkra ismerős Spring Boot egyike sem, pedig már mindent megszoktunk, full stackünk van, meg minden. Lehet, hogy ott van a tavaszi keretrendszer? De nem.
A srác, aki mindezt írta, kemény volt, és mindent tiszta Java nyelven írt. Egy fejlesztőnek nincsenek szokásos eszközei, és felmerül egy ötlet: mindezt át kell írnunk. Vannak mikroszolgáltatásaink, és minden kenyérpirítóból jön a szokásos „Srácok, mikroszolgáltatásokra van szükséged!” Ha hirtelen valami elromlik, nyugodtan vehetsz bármilyen nyelvet, és minden rendben lesz.
A helyzet az, hogy most nincs olyan ügyfelünk, aki felelős ezért a szolgáltatásért. Milyen üzleti igényei voltak, mit kell tennie ennek a szolgáltatásnak? A szolgáltatás pedig szorosan beépül az üzleti folyamatokba.
Most mondd meg, mennyire egyszerű átírni egy szolgáltatást anélkül, hogy ismernénk az üzleti követelményeit? Nem világos, hogyan történik a szolgáltatás naplózása; nem ismert, hogy vannak-e metrikák. Hogy mik ezek, ha vannak, az annál ismeretlenebb. És ugyanakkor a szolgáltatás rengeteg érthetetlen üzleti logika osztályt tartalmaz. Valami benne van valamiféle adatbázisban, amiről szintén nem tudunk még semmit.
Hol kezdjem?
A leglogikusabb ponttól kezdve - a tesztek elérhetősége. Általában legalább valami logika van odaírva, és le lehet vonni a következtetéseket a történésekről. Manapság divatos a TDD, de azt látjuk, hogy 5 éve még szinte minden úgy volt, mint most: szinte nincs egységteszt, és nem mondanak semmit. Nos, kivéve talán valamiféle ellenőrzést, hogyan írnak alá néhány xml-t valamilyen egyedi tanúsítvánnyal.
A kódból semmit nem tudtunk megérteni, ezért elmentünk megnézni, mi van a virtuális gépben. Megnyitottuk a szolgáltatási naplókat, és http kliens hibát találtunk bennük, az alkalmazás erőforrásaiba ágyazott önaláírt tanúsítvány szemérmetlenül elromlott. Megkerestük elemzőinket, új igazolást kértek, kiállították nekünk és a szolgáltatás újra működik. Úgy tűnik, ez minden. Vagy nem? Hiszen a szolgáltatás működik, ellát valamilyen funkciót, amire vállalkozásunknak szüksége van. Vannak bizonyos szabványaink az alkalmazásfejlesztésre vonatkozóan, amelyek valószínűleg Önnek is megvannak. Például a csomóponton lévő naplókat ne egy mappában tárolja, hanem valamilyen tárolóban, például rugalmasban tárolja, és nézze meg őket a Kibanában. Emlékezhetsz az arany mérőszámokra is. Vagyis a szolgáltatás terhelése, a szolgáltatás iránti kérelmek száma, él-e vagy sem, hogyan halad az Egészségügyi ellenőrzése. Ezek a mutatók legalább segítenek megtudni, mikor lehet tiszta lelkiismerettel kivonni a szolgálatból, és elfelejteni, mint egy rossz álom.
Mi a teendő
Ezért egy ilyen régi szolgáltatást adunk a táblázathoz, majd a fejlesztők közül keresünk önkénteseket, akik ellátják a szolgáltatást és rendbe teszik: írnak legalább néhány információt a szolgáltatásról, linkeket adnak hozzá irányítópultok a grafana alkalmazásban, az összeállítási feladatokhoz, és megértsék, hogyan telepítse az alkalmazást, ne töltsön fel manuálisan fájlokat ftp használatával.
A lényeg, hogy meddig tart ez a sok hasznos önkéntes tevékenység? Egy sprint egy többé-kevésbé tapasztalt fejlesztőnek például egy 20%-os műszaki tartozás alatt. Mennyi időbe telt megérteni egy bizonyos állami rendszerrel való kommunikáció megrögzült logikáját, és átültetni az újabb technológiákba? Ezt nem tudom garantálni, lehet, hogy egy hónap vagy két hónap a csapat munkájából. Ezt néhány új szolgáltatással való jelenlegi integráció tapasztalataiból mondom.
Ugyanakkor nem szabadul fel az üzleti érték. Egyáltalán. Normális, ha felveszünk egy szolgáltatást támogatásért, és egy kis időt szánunk rá. De a szolgálattal végzett standard táncaink után hozzáadtuk a táblázathoz, hozzáadtuk az információkat, és talán majd egyszer átírjuk. De most már megfelel a szolgáltatási színvonalunknak.
Ennek eredményeként szeretnék egy tervet kidolgozni, hogy mit kezdjek a Legacy szolgáltatásokkal.
A hagyatékot a semmiből újraírni rossz ötlet
Komolyan, nem is kell rá gondolni. Egyértelmű, hogy szeretném, és van néhány előnye, de általában senkinek nincs szüksége rá, beleértve magát.
Referencia könyv
Kutasd elő az alkalmazásaid forráskódjait, készíts egy referenciakönyvet, ami megmutatja, hogy hol és hogyan működik, írd be oda a projekt leírását (conditional readme.md), hogy gyorsan megértsd, hol találhatók a naplók és a metrikák. A fejlesztő, aki ezt követően foglalkozni fog, csak köszönetet mond.
Értse meg a tartományt
Ha van domainje, próbálja meg tartani az ujját. Triviálisan hangzik, igen, de nem mindenki gondoskodik arról, hogy a szolgáltatások egyetlen kulcsban legyenek. De egy szabványban dolgozni valójában lényegesen könnyebb.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Mit csinálsz az örökségeddel?
-
31.5%Újraírom a nulláról, helyesebb a 12
-
52.6%Majdnem ugyanaz, mint te 20
-
10.5%Nincs örökségünk, nagyszerűek vagyunk4
-
5.2%Megírom kommentben 2
38 felhasználó szavazott. 20 felhasználó tartózkodott.
Forrás: will.com