Architektúra review a modernizáció előtt: mit nézzünk meg egy legacy rendszeren

Az újraírás, amely elakad

A legtöbb modernizációs program ésszerűnek hangzó döntéssel kezdődik. A monolitnak mennie kell, ezért a csapat megtervezi az utódját. Elkészül a célarchitektúra szolgáltatásokkal, event busszal és új adatmodellel. Egy-két évvel később a régi rendszer még mindig kiszolgálja az ügyfeleket, az új a töredéküket, és mindkettőt karban kell tartani.

Nem a cél volt rossz, hanem a sorrend. A csapat eldöntötte, hová megy, mielőtt kiderítette volna, hol áll.

Az évek óta növekvő rendszer tele van olyan döntésekkel, amelyekre már senki nem emlékszik. A határok a szervezeti ábrán léteznek, a kódban nem. Két szolgáltatás közös adatbázist használ, mert egyszer az volt a gyorsabb. Az integráció, amelytől mindenki függ, csak egyetlen kolléga fejében van meg. Az ilyen tudás nélkül rajzolt célarchitektúra találgatás, és a találgatásra épülő migráció incidensről incidensre fedezi fel a valódi korlátokat.

Az architektúra review a feltárást teszi az első helyre. A feladata, hogy leírja a rendszert úgy, ahogy van, megtalálja, hol lassítja a csapatot vagy hol jelent üzleti kockázatot, és ezekből sorrendet állítson fel. Rövid, a legtöbb rendszerhez két hét elég, és az eredménye írásos, hogy a későbbi döntéseket hozzá lehessen mérni.

Mikor térül meg a review

A jel ritkán az, hogy valaki kimondja: rossz az architektúra. Inkább tünetek sora, amelyekkel a csapat megtanult együtt élni:

• A release napokig tart. Kézi jóváhagyások, hosszú regressziós tesztkörök vagy egyetlen deployolható egység, amely mindenkit blokkol.
• A csapatok akadályozzák egymást. Ütköző módosítások, közös adatbázis és tisztázatlan felelősségi körök miatt minden sprint egyeztetéssé válik.
• Az integrációs hibák továbbgyűrűznek. Ha egy szolgáltatás leáll, magával ránt még hármat, mert nincs circuit breaker, és nincsenek tiszta contractok.
• Az éles hibákról a felhasználóktól értesülünk. Az incidens első órája azzal telik, hogy kiderüljön, melyik szolgáltatás a hibás.
• Az új kollégák lassan kapcsolódnak be. A kódbázis csak a régi kollégák fejében lévő tudással érthető, a dokumentáció hiányos vagy elavult.
• A skálázás mindent érint. A leginkább terhelt részeket nem lehet külön skálázni, az egész monolitnak együtt kell nőnie.

Ha ezek közül kettő-három egyszerre igaz, akkor a rendszer szabja meg a csapat delivery-jét, és a csapat reagál ahelyett, hogy döntene. Ilyenkor van szükség független nézőpontra.

Vannak helyzetek, ahová a review nem való. Az egyszerű rendszernek, ahol nincs architekturális nyomás, backlog kell, nem review. Annak a csapatnak, amelyik csak plusz fejlesztői kapacitást keres, fejlesztők kellenek. És ahol a legalacsonyabb ár dönt, a review veszít az újraírást ígérő árajánlattal szemben.

Négy kérdés, amelyre a review válaszol

A használható review kérdések köré épül, nem dokumentumok köré. A legtöbb legacy rendszert négy kérdés lefedi.

Hol vannak a határok valójában?

Az első napok a rendszerről szólnak úgy, ahogy van: a kódról, az infrastruktúráról, a data flow-król és azokról, akik ismerik. Az eredmény rendszertérkép a szolgáltatásokkal és modulokkal, a köztük lévő függőségekkel, a közös adattárakkal és a hibák terjedési útjaival.

A térkép bizonyítékból készül, nem a wikin lévő ábrából. A hívási gráfok, a deployment-manifestek, az adatbázissémák és az üzenetsorok topicjai megmondják, hol vannak a határok. Az interjúk megmondják, miért. A kettő közti különbség rendszerint az első megállapítás.

Hol lassul le a delivery?

A második kérdés egy módosítást követ a fejlesztő branchétől az éles üzemig. Hol várakozik? Review-ra, környezetre, kézi tesztkörre, release-ablakra? Mely lépések automatizáltak, és melyek függenek egyetlen embertől? Az eredmény a delivery pipeline folyamattérképe azokkal a pontokkal, ahol a release-ek lelassulnak vagy elakadnak.

A review-ból gyakran ez a rész hasznosítható a leggyorsabban. Egy szűk keresztmetszetet a pipeline-ban hetek alatt meg lehet szüntetni, egy service boundary áthelyezése negyedévekig tart.

Melyik adósság hordoz üzleti kockázatot?

Minden legacy rendszerben van technikai adósság, és a nagy része ártalmatlan. A review-nak szét kell választania azt az adósságot, amelyik pénzbe kerül, attól, amelyik csak a mérnököket zavarja. Az első csoportba tartoznak az egyetlen hibaponttól függő részek, a dokumentálatlan integrációk, a rendszerek közti adatkonzisztencia-hiányok és azok a komponensek, amelyeket már senki nem tud frissíteni. A másodikba az a modul, amelyik régebbi mintát követ, de működik, és ritkán változik.

Az eredmény rangsorolt kockázati lista, minden tételnél az üzleti hatással: leállás alatt kieső bevétel, szabályozói kitettség, release, amelyet nem lehet kiadni. Attól lesz a lista használható azoknak is, akik nem olvasnak kódot, hogy a hatás rangsorolja, nem a mérnöki ízlés.

Mi legyen az első?

Az utolsó kérdés sorrendbe állítja a megállapításokat. Az eredmény a következő 90 nap roadmapje, prioritás, függőség és végrehajtási kockázat szerint sorba állítva. Minden tétel megnevezi a tünetet, amelyet megszüntet, és azt, mire van szüksége az előtte lévő tételektől.

A 90 nap szándékos. A hosszabb terv úti célt ír le. A 90 napos terv olyan munkát ír le, amelyet hétfőn el lehet kezdeni, és a negyedév végén ellenőrizni lehet.

Vizuál: a tünetektől a sorba állított tervig

flowchart LR
    S[Tünetek, amelyekkel a csapat együtt él] --> A[Az architektúra átvilágítása<br/>rendszertérkép]
    A --> B[A szűk keresztmetszetek feltérképezése<br/>a delivery folyamattérképe]
    B --> R[Kockázatértékelés<br/>üzleti hatás szerint rangsorolva]
    R --> P[Rangsorolt 90 napos roadmap]
    P --> D{Mi a következő?}
    D -->|házon belül| T[A csapat végrehajtja]
    D -->|segítséggel| E[Fejlesztési megbízás]

Hogyan telik a két hét

A módszer hétköznapi. Attól működik, hogy minden lépését elvégezzük, sorrendben, és leírjuk.

Először interjút készítünk a kulcsfejlesztőkkel. Mindegyikben ugyanazok a kérdések hangzanak el: mit kellene először megváltoztatni, mi romlik el a leggyakrabban, mihez nem nyúl senki szívesen. A válaszok hamarabb mutatnak egy irányba, mint várnánk, és ahol eltérnek, ott érdemes közelebbről megnézni a rendszert.

Ezt követi a rendszerbejárás: a kritikus szolgáltatások kódja, az infrastruktúra definíciói, a CI/CD-konfiguráció és a data flow-k. A célzott code review azokban a szolgáltatásokban, amelyekre az interjúk mutattak, ellenőrzi, hogy a probléma tényleg ott van-e, ahol gondolják.

A delivery pipeline áttekintése a CI/CD-t, a környezeteket és a csapatok közti átadásokat nézi, és egy módosítást követ végig mindegyiken.

A megállapításokat azonnal leírjuk, ahogy előkerülnek, hogy a második hetet arra fordíthassuk, hogy ellenőrizzük őket azokkal, akik ismerik a rendszert, és felépítsük a roadmapet. Az eredmény írásos review anyag és záró vezetői összefoglaló.

A csapattól három dolog kell: olvasási hozzáférés a repókhoz, az infrastruktúrához és a pipeline-okhoz; néhány óra a kulcsfejlesztők idejéből; és valaki, aki meg tudja mondani, melyik üzleti következmény számít a legjobban. Az a review, amelyik ezeket nem kapja meg, a wikiről ír jelentést.

Milyen a használható roadmap

Mielőtt elfogadnánk egy roadmapet, olvassuk végig négy szempont szerint.

1. Minden tétel megnevezi a tünetet, amelyet megszüntet. Az „Event bus bevezetése” megoldás, amely problémát keres magának. A „Ne bukjon el a rendelés frissítése, ha a készletszolgáltatás lassú” megállapítás.
2. Az első tétel kicsi és mérhető. Heteket vesz igénybe, és a végén a csapat meg tudja mondani, működött-e.
3. A függőségek explicitek: mely contractokat kell formalizálni, mielőtt egy szolgáltatást le lehet választani, és hol kell observability, mielőtt egy migrációt mérni lehet.
4. A ráfordítást tételenként becsüljük, és minden becslés megmondja, mit feltételez.

A legacy rendszer roadmapje ritkán kezdődik azzal, hogy leválasztunk egy szolgáltatást. Azzal kezdődik, ami a leválasztást biztonságossá teszi: explicit contract azon a határon, amelyik mozogni fog, tracing a határon át, hogy a migrációt mérni lehessen, és pipeline, amely az új részt önállóan tudja release-elni. A strangler fig minta azért működik, mert minden lépés visszafordítható, és a régi rendszer addig szolgál ki, amíg az új be nem bizonyította, hogy működik.

Ha magunk csináljuk

A csapat a saját rendszerén is elvégezheti ezt a review-t, és a fenti kérdések adják a napirendet. Belülről két dolog nehezíti. Akik a rendszert építették, ismerik a történetét, és a történet minden döntést olyan jól megmagyaráz, hogy a probléma eltűnik. És aki a review-t vezeti, annak a kollégáinak kell megmondania, hogy a munkájuk melyik része lett kockázat.

A külső szakértőnek nincs története, és nem érintett a korábbi döntésekben. Az érték nagy része ebből jön. A módszer mindkét esetben ugyanaz: bizonyítékból térképezzük fel a rendszert, kövessünk végig egy módosítást a pipeline-on, rangsoroljuk az adósságot üzleti hatás szerint, és írjunk 90 napos tervet, amelynek az első tétele kicsi.

Mi ezt kéthetes, előre rögzített feladatú megbízásként végezzük: ez az architektúra review. A módszer nem attól függ, ki végzi.