Refaktoring s nulovým prostojem: Jak refaktorovat systémy bez jejich přerušení provozu

Produkční systémy se nesmí zastavit. Finanční platforma zpracovávající transakce ve 2 hodiny ráno, systém zdravotní dokumentace obsluhující lékaře napříč časovými pásmy, logistická aplikace sledující zásilky napříč kontinenty: žádný z nich nemá k dispozici údržbové okno, které by absorbovalo úsilí o refaktoring. Přesto všechny hromadí technický dluh, nesou architektonická rozhodnutí učiněná za dřívějších omezení a nakonec vyžadují strukturální změnu, aby zůstaly udržovatelné, škálovatelné a bezpečné. Refaktoring s nulovými prostoji je disciplína, která toto napětí řeší: vývoj živého systému bez přerušení služby, kterou poskytuje.

Výzva není čistě technická. Je organizační a architektonická. Refaktoring systému, který nelze přepnout do offline režimu, vyžaduje jiný mentální model než refaktoring systému ve vývoji: každá změna musí být zpětně kompatibilní, dokud není zpětně kompatibilní, každý strukturální přechod musí být reverzibilní a každé ověření musí probíhat na reálném provozu, nikoli na syntetických testech. Techniky, které to umožňují, včetně modrozelených nasazení, přepínání funkcí, vzoru „škrticí fig“, migrací databází typu „rozbalit-smlouvat“ a idempotentních událostmi řízených architektur, jsou jednotlivě dobře zdokumentovány. Méně často se řeší, jak fungují společně jako ucelená strategie pro trvalou a bezpečnou strukturální změnu v systémech, které musí sloužit uživatelům v celém procesu.

Jak musí vypadat vaše architektura pro změny s nulovými prostoji

Nejčastější otázkou, kterou si týmy kladou při zavádění refaktoringu s nulovými prostoji, je architektura: co je třeba změnit na způsobu, jakým je systém postaven, než může samotný refaktoring začít? Odpovědí není jediný vzorec, ale sada strukturálních vlastností, které musí systém vykazovat, než bude bezpečný pro spuštění refaktoringu. Pochopení těchto vlastností je předpokladem pro vše ostatní v této příručce.

První vlastností je nezávislá nasaditelnost. Každá komponenta, která bude refaktorována, musí být nasaditelná bez nutnosti současného nasazení jejích závislostí. Pokud změna služby A vyžaduje současnou změnu služby B a služby C, aby se zabránilo jejímu poškození, pak je nasazení služby A s nulovým výpadkem strukturálně nemožné: tyto tři služby jsou v podstatě jednou jednotkou nasazení bez ohledu na to, v kolika repozitářích se nacházejí. Nezávislá nasaditelnost vyžaduje zpětně kompatibilní rozhraní, verzované smlouvy a eliminaci koordinovaných požadavků na nasazení mezi službami.

Druhou vlastností je reverzibilita. Každé nasazení, které změní chování v reálném čase, musí být reverzibilní během několika minut, nikoli hodin. Reverzibilita neznamená jen zachování dostupnosti starého binárního souboru. Vyžaduje, aby stav databáze, stav mezipaměti, stav relace a jakýkoli externí stav systému upravený novou verzí byly kompatibilní se starou verzí. Pokud nová verze zapisuje data ve formátu, který stará verze nedokáže přečíst, pak je nasazení ze své podstaty nevratné a nulové prostoje jsou nemožné, protože jakékoli vrácení zpět povede k chybám.

Třetí vlastností jsou pozorovatelné přechody stavů. Refaktoringové úsilí, které přesouvá chování z jedné kódové cesty do druhé bez pozorovatelných metrik na obou cestách, probíhá naslepo. Tým nemůže vědět, zda je přechod úspěšný nebo neúspěšný, nemůže včas odhalit regrese a nemůže činit rozhodnutí na základě dat o tom, kdy migraci urychlit nebo zastavit. Pozorovatelnost musí být instrumentována před zahájením refaktoringu, nikoli přidávána až po objevení problému. Jak bylo zkoumáno v kontextu přírůstkový refaktoring a technický dluhStrukturální přehled o tom, co kód dělá a co na něm závisí, je základem pro plánování jakékoli změny, která si nemůže dovolit selhat v produkčním prostředí.

Modro-zelené nasazení: základní vzorec

Modro-zelené nasazení je základním vzorem pro vydání s nulovými prostoji. Existují dvě identická produkční prostředí: modré prostředí obsluhující živý provoz a zelené prostředí přijímající novou verzi. Nová verze je nasazena, testována a ověřena v zeleném prostředí, zatímco modré prostředí nadále bez přerušení slouží uživatelům. Po ověření zeleného prostředí se provoz přepne atomicky. Vrácení zpět je opačné: provoz se přepne zpět na modré prostředí, které zůstává dostupné po celou dobu.

Vzor zní přímočaře. Jeho obtíž spočívá ve vrstvě databáze. Pokud obě prostředí musí číst ze stejné databáze a zapisovat do ní, musí být schéma databáze kompatibilní s oběma verzemi současně. Migrace, která odstraní sloupec, přejmenuje pole nebo změní datový typ, naruší staré prostředí v okamžiku spuštění. Proto je modrozelené nasazení neoddělitelné od vzoru migrace schématu s rozšířením a smlouvou popsaného v části o databázi této příručky.

Vydání pro kanárské systémy a techniky postupného zavádění

Verze Canary rozšiřují modrozelený model tím, že směrují určité procento provozu na novou verzi, místo aby se veškerý provoz přepnul najednou. Nasazení Canary může začít na jednom procentu uživatelů, sledovat míru chyb, latenci a obchodní metriky pro danou kohortu a poté toto procento postupně zvyšovat: pět, dvacet, padesát, sto. V každé fázi automatizované brány kontrolují, zda klíčové metriky neklesly pod definované prahové hodnoty. Pokud brána selže, zavádění se zastaví a procento Canary se sníží zpět na nulu.

Techniky postupného zavádění přidávají k tomuto postupu logiku cílení. Místo směrování pouze podle procenta lze provoz segmentovat podle uživatelské kohorty, geografické oblasti, úrovně předplatného nebo charakteristik relace. To umožňuje ověřit novou verzi vůči konkrétní uživatelské populaci, která ji nejvíce zatěžuje, ještě předtím, než je tato populace plně migrována. Klíčovým požadavkem je, aby infrastruktura směrování, ať už se jedná o vyrovnávač zátěže, bránu API nebo síť služeb, podporovala granularitu cílení, kterou zavádění vyžaduje.

Metriky, které řídí canary gate, musí být definovány před zahájením zavádění. Míra chyb, latence p99, doba dotazu do databáze a metriky specifické pro dané podnikání, jako je míra konverze nebo míra úspěšnosti plateb, jsou platnými kritérii pro stanovení bran. Prahové hodnoty bran by měly být kalibrovány vůči základní hodnotě měřené ze stávající verze při srovnatelné zátěži, nikoli vůči teoretickým cílům. Zavádění, které projde branou při dvou procentech provozu, ale selže při dvaceti procentech, nebylo validováno: canary byl příliš malý na to, aby byl reprezentativní. Správné postupné zavádění vyžaduje dostatečnou expozici provozu v každé fázi, aby se dosáhlo statisticky smysluplného srovnání.

Přepínače funkcí a vypínače

Přepínače funkcí oddělují nasazení kódu od aktivace chování. Refaktorovaná kódová cesta je nasazena v neaktivním stavu, ovládaná přepínačem, který určuje, kteří uživatelé nebo požadavky provedou novou logiku. Přepínač lze aktivovat postupně, cílit na konkrétní kohorty nebo okamžitě zrušit bez opětovného nasazení. Díky tomu jsou přepínače funkcí primárním mechanismem pro migraci obchodní logiky bez prostojů, na rozdíl od změn infrastruktury, kde jsou vhodnější modrozelené nebo kanárkově orientované vzory.

Kill switche jsou obranným protějškem přepínačů funkcí: přepínačů, jejichž účelem není povolit nové chování, ale okamžitě ho deaktivovat, pokud se chová špatně. Kill switch u refaktorovaného výpočtu fakturace, nového procesu ověřování nebo náhradní vrstvy přístupu k datům poskytuje technikovi na telefonu jednorázovou cestu k obnově, která nevyžaduje nasazení, vrácení databáze zpět ani koordinaci mezi týmy. Kill switch by měl být nakonfigurován v systému, který umožňuje jeho spuštění prostřednictvím volání API, konzole pro správu příznaků funkcí nebo automatizované integrace upozornění, aby latence spouštěče byla sekundy, nikoli minuty.

Hygiena přepínačů je skutečným provozním problémem. Přepínače, které nejsou nikdy vyčištěny, se hromadí v kódové základně, což ztěžuje zvažování toku řízení a vytváří implicitní závislosti mezi stavem přepínače a stavem dat. Každý přepínač by měl mít zdokumentovaného vlastníka, plánované datum vypršení platnosti a tiket na vyčištění. Dluh z přepínačů je stejně reálný jako jakákoli jiná forma technického dluhu a hromadí se rychleji, protože přepínače obvykle chrání nejaktivněji se měnící části systému.

Refaktoring databáze bez prostojů

Změny v databázi jsou nejtěžší částí refaktoringu s nulovým prostojem, protože databáze jsou stavové, sdílené a jejich úpravy ve velkém měřítku jsou pomalé. Aplikaci lze nasadit a vrátit zpět během několika minut. Migrace databáze, která změní tabulku se stovkami milionů řádků, může trvat hodiny, po potvrzení nelze snadno vrátit zpět a po celou dobu trvání migrace obsahuje zámky, které blokují čtení a zápis. Správný refaktoring databáze vyžaduje jiný přístup než refaktoring kódu aplikace a většina týmů to zjistí při prvním pokusu o změnu schématu na aktivní tabulce s vysokým provozem.

Ústředním principem je, že každá změna databáze musí být zpětně kompatibilní s předchozí verzí aplikace, dokud nebude předchozí verze ukončena. To zní zřejmě, ale má to méně zřejmé důsledky. Přejmenování sloupce vyžaduje přidání nového názvu jako aliasu nebo duplikátu, než bude možné odstranit starý název. Změna typu sloupce vyžaduje paralelní naplnění stínové sloupce nového typu, než bude možné starý sloupec vyřadit. Odstranění tabulky vyžaduje ověření, že z ní nečte žádná nasazená verze aplikace. Každá z těchto operací je vícekrokový proces rozložený na více nasazení, nikoli jediná migrace, která se spustí jednou. Jak je popsáno v širším kontextu Refaktoring COBOLu napříč staršími datovými strukturamiVýzva vyvíjejících se datových struktur, které jsou sdíleny mezi více programy a systémy bez koordinovaného přechodu, je jednou z určujících obtíží refaktoringu v podnikovém měřítku.

Vzor rozbalení a smlouvy

Vzor rozbalení-smlouvy formalizuje vícekrokový přístup ke změnám schématu. Ve fázi rozbalení se nové prvky schématu přidávají aditivně: nový sloupec vedle starého, nová tabulka vedle starého, nový index vedle starého. Aplikace je aktualizována tak, aby zapisovala do staré i nové struktury, ale nadále čte ze staré struktury. Nedochází ke ztrátě žádných dat, žádné existující přerušení dotazů a stará verze aplikace nadále funguje, protože staré prvky schématu jsou stále přítomny.

Ve fázi kontrakce, která probíhá v samostatném nasazení po úplném nasazení a ověření nové verze, jsou staré prvky schématu odstraněny. V tomto bodě na nich již žádná běžící verze aplikace nezávisí. Odstranění je bezpečné, protože bylo ověřeno pozorováním, nikoli předpokládáno plánováním.

Vzor rozbalení a smíšení vyžaduje disciplínu ohledně pořadí nasazení. Migrace databáze, která přidává nový sloupec, musí být nasazena před verzí aplikace, která do něj zapisuje. Migrace databáze, která odstraňuje starý sloupec, musí být nasazena až po vyřazení všech verzí aplikací, které z něj čtou. Tyto požadavky na pořadí by měly být zakódovány v kanálu nasazení, aby migrace nemohly být aplikovány v nesprávném pořadí.

Nástroje pro refaktorování starších datových kanálů bez přepisování kódu

Starší datové kanály, zejména ty postavené na frameworkech pro dávkové zpracování, nástrojích ETL nebo přesunech dat na mainframe, představují specifickou výzvu: transformují a přesouvají data nepřetržitě, nelze je zastavit po celou dobu migrace a často jsou nedostatečně zdokumentované do té míry, že plný rozsah jejich činnosti není znám, dokud nedojde k poruše. Refaktoring těchto kanálů bez úplného přepracování vyžaduje nástroje, které dokáží sledovat, co kanál aktuálně dělá, ověřit, zda refaktorovaná verze produkuje ekvivalentní výstup, a umožnit postupný přechod, nikoli náhlý.

Zachycení změn dat je nejrozšířenějším nástrojem pro refaktoring živého kanálu. CDC zachycuje každou operaci zápisu ve zdrojové tabulce jako proud událostí, což umožňuje napájet starý kanál i nový náhradní kanál ze stejného zdroje bez nutnosti úprav. Starý kanál pokračuje v provozu, nový kanál je spuštěn paralelně se stejným proudem událostí a výstupy jsou porovnávány. Nesrovnalosti identifikují transformační logiku, která nebyla správně znovu implementována. Po potvrzení parity je starý kanál vyřazen z provozu.

Nástroje pro migraci schémat, včetně Liquibase a Flyway, poskytují verzované, sekvenční migrace, které lze aplikovat inkrementálně a v kombinaci s disciplínou expand-contract je možné je vrátit zpět. Sledují, které migrace byly aplikovány na každé prostředí, a zabraňují aplikaci mimo pořadí. U starších kanálů, které běží na mainframe nebo datových úložištích založených na VSAM, je ekvivalent spravován prostřednictvím Rozšíření JCL a správa datových sad který řídí, jak programy přistupují k datům během přechodu, a zajišťuje, že ani starý, ani nový program neběží s nekompatibilním rozložením datové sady.

Jak modernizovat starší databáze bez prostojů

Specifická výzva modernizace starší databáze, přechodu ze schématu DB2 na mainframe do relační databáze v cloudovém prostředí, migrace ze struktury VSAM založené na souborech do relačního schématu nebo konsolidace více starších databází do nového sjednoceného úložiště vyžaduje postupné použití všech výše uvedených technik po delší dobu.

Přístup, který konzistentně funguje, je: začít s paritou čtení, poté dosáhnout parity zápisu, poté migrovat čtení, poté migrovat zápisy a nakonec vyřadit starší úložiště z provozu. Parita čtení znamená, že nové úložiště obsahuje všechna data, která obsahuje staré úložiště, a může obsloužit všechny dotazy, které aplikace provede. Parita zápisu znamená, že každý zápis, který aplikace provede do starého úložiště, se použije i na nové úložiště, a to buď prostřednictvím duálních zápisů v aplikaci, nebo prostřednictvím replikace CDC. Jakmile jsou obě podmínky parity potvrzeny v produkčním prostředí, lze migrovat čtení do nového úložiště (ověření výstupů), poté lze migrovat zápisy a nakonec lze starší úložiště vyřadit z provozu.

V žádné fázi této sekvence není žádná služba přerušena. V každé fázi lze předchozí stav obnovit přesunutím čtení nebo zápisů zpět do předchozího úložiště. Trvání každé fáze je určeno jistotou získanou validací, nikoli pevným kalendářním datem.

Nástroje pro refaktorování starších systémů bez přepisování kódu

Přepisování staršího systému od nuly je téměř vždy dražší a riskantnější než jeho postupné refaktorování. Úplné přepisy vyžadují současnou údržbu starého systému v produkčním prostředí, vytvoření náhrady srovnatelných funkcí, správu rozdílu v paritě funkcí mezi nimi a provedení přechodu na nový systém (cutover), což je v podstatě nasazení zcela jiného systému bez prostojů. Většina organizací, které se pokoušejí o úplné přepisy, v průběhu procesu zjistí, že starý systém obsahoval chování, které nezdokumentovaly, které náhrada ještě nereplikuje a na kterém jsou uživatelé závislí.

Inkrementální refaktoring se správnými nástroji se této pasti vyhne tím, že starý systém učiní čitelným ještě před jeho změnou. Výchozím bodem je strukturální analýza: pochopení toho, co každá komponenta stávajícího systému dělá, co na ní závisí a na čem závisí systém. Tuto analýzu nelze provést čtením dokumentace (která u starších systémů obvykle chybí nebo je nepřesná) ani ručním čtením kódu ve velkém měřítku. Vyžaduje automatizované nástroje, které analyzuje stávající kód, vytváří graf závislostí a umožňuje dotazování. Jak je popsáno v kontextu... řešení problémů s integrací starších systémůPrvním krokem v jakémkoli programu refaktoringu starších systémů je vytvoření strukturální viditelnosti, která neexistuje v žádném artefaktu udržovaném člověkem.

Vzor Strangler Fig pro monolity

Vzor „strangler fig“ je dominantní architektonickou strategií pro postupné nahrazování monolitu bez úplného přepisování nebo události „cutover“. Nové funkce jsou vytvářeny jako nezávislé služby vedle monolitu. Směrovací vrstva, obvykle brána API nebo reverzní proxy, zachycuje příchozí požadavky a směruje je buď do monolitu, nebo do nové služby na základě směrovacích pravidel. Monolit nadále obsluhuje veškerý provoz, který dosud nebyl migrován. Nová služba zpracovává pouze provoz, který je k ní explicitně směrován.

Postupem času se přidávají další směrovací pravidla. Více cest je směrováno k novým službám. Monolit zpracovává stále menší a menší část celkového provozu. Nakonec monolit nezpracovává nic a lze jej vyřadit z provozu. Žádné jednotlivé nasazení během tohoto procesu není dostatečně velké, aby představovalo významné riziko. Každá změna směrovacího pravidla je individuálně testovatelná a individuálně reverzibilní. Metoda „strangler fig“ (škrticí obr.) není technikou pro rychlou transformaci: je to technika pro bezpečnou transformaci v průběhu týdnů, měsíců nebo let, v závislosti na složitosti škrticího systému.

Kritickým implementačním požadavkem pro vzor strangler fig je, aby směrovací vrstva byla oddělena od monolitu i nových služeb. Směrovací vrstva, která je vložena do monolitu, nemůže směrovat provoz mimo monolit. Proxy musí být umístěn před oběma a musí být schopen směrovat provoz do kterékoli z nich na základě konfigurace, kterou lze změnit bez úpravy monolitu nebo nové služby.

Refaktorování starších API do cloudově nativních služeb bez prostojů

Migrace staršího API na cloudově nativní náhradu je specifickou aplikací vzoru Strangler Fig s dalšími omezeními: starší API může mít spotřebitele, které nelze aktualizovat současně, smlouva API musí být zachována po celou dobu přechodu a cloudově nativní náhrada může mít odlišné výkonnostní charakteristiky, které ovlivňují spotřebitele neočekávaným způsobem.

Standardní přístup spočívá v nasazení cloudové nativní náhrady za stejnou API smlouvou jako starší API, směrování určitého procenta provozu do náhrady pomocí kanárkových technik, ověření výstupní parity pro toto procento provozu a postupné zvyšování směrovaného procenta. Spotřebitelé během tohoto přechodu nemusí nic měnit, protože API smlouva je zachována. Směrovací vrstva zpracovává přechod transparentně.

Přechod z integrací základních systémů na API middlewaru s nulovým výpadkem, který se v datech Search Console pro tento článek objevuje jako dotaz s vysokým záměrem, je přesně tento scénář: okamžik, kdy je směrovací vrstva aktualizována tak, aby sto procent provozu směřovalo do nového systému, a starší API je vyřazeno z provozu. Tento přechod by nikdy neměl být jednorázovou atomickou událostí. Měl by být posledním krokem postupného zavádění, které již ověřilo nový systém při stále vyšších procentech provozu. V době, kdy dojde k finálnímu přechodu, nový systém již zvládne plný objem provozu; přechod pouze odstraní záložní cestu, která již není potřeba.

Idempotence, opakované pokusy a failover v refaktorovaných systémech

Refaktoring systému, který používá architekturu řízenou událostmi, fronty zpráv nebo distribuovaná volání služeb, přináší řadu problémů, které čistě na nasazení zaměřené vzory neřeší: co se stane s probíhajícími operacemi, když služba přejde ze staré verze na novou? Události, které byly publikovány ve staré verzi, mohou dorazit k obslužnému programu, na kterém běží nová verze. Požadavky, které byly iniciovány vůči starému API, mohou dorazit k obslužnému programu, který již byl refaktorován do nové interní struktury. Transakce, které byly částečně dokončeny podle staré logiky, může být nutné buď dokončit, nebo kompenzovat podle nové logiky.

Odpovědí na všechny tyto problémy je idempotence: návrh každé operace tak, aby produkovala stejný výsledek, ať už se provede jednou nebo vícekrát. Idempotentní obslužná rutina, která obdrží duplicitní událost během přechodu mezi nasazeními, vygeneruje stejný výstup jako ta, která událost obdrží přesně jednou. Idempotentní operace zápisu, která je přehrána jako součást rollbacku, vygeneruje stejný stav databáze jako původní zápis. Idempotence není jen záležitostí refaktoringu: je obecnou vlastností odolných distribuovaných systémů. Právě během přechodů mezi refaktoringem však její absence způsobuje nejviditelnější selhání.

Přidání opakovaných pokusů a převzetí služeb při selhání poskytovatele bez rozsáhlého refaktorování

Jednou z nejčastějších otázek v datech Search Console pro tento článek je, jak přidat možnosti opakování a failoveru do existující aplikace, zejména do aplikace Rails nebo podobného frameworku, bez nutnosti komplexního refaktoringu. Odpověď zní, že opakování a failover lze přidat jako průřezový aspekt na úrovni infrastruktury bez nutnosti úpravy jednotlivých implementací služeb.

Na vrstvě infrastruktury lze nakonfigurovat servisní síť, jako je Istio nebo Linkerd, tak, aby automaticky opakovala neúspěšné požadavky až do definovaného počtu opakování s exponenciálním odkladem a jitterem, aby se zabránilo chování typu „hromové stádo“. To nevyžaduje žádné změny v kódu aplikace, protože chování opakování je implementováno v postranní proxy, která zachycuje všechny příchozí i odchozí požadavky. Failover poskytovatele lze implementovat podobně: pokud primární poskytovatel vrátí chybu nad prahovou hodnotou, síť směruje následné požadavky k sekundárnímu poskytovateli, dokud se primární neobnoví.

Na aplikační vrstvě, když počet opakovaných pokusů na úrovni infrastruktury není dostatečný, protože logika opakovaných pokusů musí být informována o stavu podniku, lze na hranici mezi aplikací a externími závislostmi zavést odlehčenou knihovnu pro opakované pokusy nebo frontu úloh, aniž by se interně restrukturalizovala aplikace. Klíčem je izolace logiky opakovaných pokusů a převzetí služeb při selhání na hranici integrace, spíše než její distribuce po celé vrstvě obchodní logiky. Díky tomu je chování opakovaných pokusů viditelné, testovatelné a konfigurovatelné, aniž by se muselo dotýkat základní struktury aplikace. Jak bylo diskutováno v kontextu agilní refaktoringové postupyZavedení vzorů spolehlivosti na úrovni infrastruktury před refaktoringem obchodní logiky snižuje plochu toho, co je nutné po každé změně validovat.

Idempotence v událostmi řízených architekturách s Redis streamy

Architektury řízené událostmi s nízkou latencí, které používají Redis Streams nebo podobné technologie, čelí během refaktoringu specifickému problému idempotence: skupiny uživatelů mohou zpracovávat události různou rychlostí, uživatelé čtoucí události v nové verzi již mohli zpracovat události, které stará verze nezpracovala, a operace přehrávání nebo obnovy mohou stejnou událost doručit vícekrát obslužným rutinám, které nebyly navrženy pro zpracování duplikátů.

Standardní přístup spočívá v přiřazení jedinečného identifikátoru každé události v okamžiku publikace a sledování zpracovaných identifikátorů událostí v perzistentním úložišti. Před zpracováním události obslužná rutina zkontroluje, zda již byl identifikátor zpracován. Pokud ano, událost je potvrzena a zahozena bez opětovného zpracování. Pokud ne, událost je zpracována a identifikátor je zaznamenán. Tato logika deduplikace musí být atomická: pokud obslužná rutina zpracuje událost, ale selže před zaznamenáním identifikátoru, bude událost znovu zpracována při dalším doručení. Použití atomických operací Redis nebo transakčních zápisů k zaznamenání identifikátoru jako součásti operace zpracování tomuto stavu souboje zabraňuje.

Během refaktoringového přechodu, při kterém se mění logika spotřebitele, poskytují identifikátory idempotence další výhodu: umožňují přehrát proud událostí s novou logikou spotřebitele a porovnat výstupy se zaznamenanými výstupy staré logiky spotřebitele, což umožňuje porovnávací testování, aniž by uživatelé byli vystaveni nové logice.

Automatizace refaktoringu v CI/CD pipelinech

Disciplína refaktoringu s nulovými prostoji nemůže být udržitelná manuálními procesy. Každé nasazení v programu s nulovými prostoji vyžaduje posloupnost validací: před nasazením se kontroluje, zda je nová verze kompatibilní s aktuálním stavem databáze, vyhodnocení pomocí canary gate při každém procentuálním přírůstku provozu, automatické porovnání výstupů mezi starými a novými kódovými cestami a po nasazení se ověří, zda nedošlo ke zhoršení klíčových metrik. Ruční provádění těchto kroků pro každou změnu není provozně udržitelné a zavádí lidskou chybu v nejkritičtějších bodech procesu.

Kanál CI/CD pro refaktoring s nulovými prostoji není jen kanál sestavení a nasazení. Je to validační kanál: sekvence automatizovaných bran, kterými musí všechny projít, než změna postoupí do další fáze nasazení. Každá brána je specifickým, měřitelným kritériem. Neprojití brány zastaví kanál a spustí upozornění. Průchod všemi branami automaticky posune nasazení do další fáze. Jak je popsáno v širší diskusi o Postupy CI/CD pro mainframe a podniková prostředíZákladním požadavkem je, aby kanál vynucoval stejnou disciplínu nasazení pro každou změnu bez ohledu na její velikost a aby vynucování bylo automatizované, a ne závislé na pozornosti jednotlivých inženýrů.

Brány fáze pipeline pro živý refaktoring

Brány fáze jsou kontrolní body ověření, kterými musí nasazení projít před dalším postupem. Pro refaktoringový kanál s nulovými prostoji je minimální sada bran následující.

Před nasazením: kontrola kompatibility schématu potvrzuje, že migrace databáze je zpětně kompatibilní s aktuální verzí aplikace, automatizované testy smluv ověřují, že odpovědi API nové verze jsou kompatibilní se smlouvou předchozí verze, a statická analýza závislostí potvrzuje, že žádná závislost, kterou nová verze zavádí, nebude v konfliktu se závislostí, kterou vyžaduje stávající prostředí.

Po nasazení do systému Canary: porovnání míry chyb mezi provozem v systému Canary a základním provozem, porovnání latence na str. 50, str. 95 a str. 99, porovnání obchodních metrik pro všechny metriky, které ovlivňuje změněná kódová cesta, a minimální pozorovací okno, během kterého musí systém Canary zůstat stabilní, než se zvýší procento provozu.

Po úplném nasazení: sada regresních testů proti produkčním koncovým bodům, kontroly konzistence databáze potvrzující, že jakákoli migrace s duálním zápisem nebo migrací s rozšířením kontraktu si zachovala konzistenci, a potvrzení, že předchozí artefakt nasazení je stále k dispozici pro vrácení zpět.

Refaktoring a vynucování řízené dodržováním předpisů

Refaktoring řízený shodou s předpisy zavádí další omezení, které musí brány nasazení vynucovat: každá změna musí být prokazatelně v souladu s platnými regulačními nebo organizačními požadavky. V regulovaných odvětvích to znamená, že nasazení musí vytvořit auditní stopu, která ukazuje, co bylo změněno, kdy bylo nasazeno, jaké ověření bylo provedeno a kdo to schválil. Automatizované brány nasazení, které zaznamenávají své vlastní provedení, včetně stavu vstupu, kritérií brány a výsledku pass/false, poskytují tuto auditní stopu bez nutnosti ruční dokumentace.

Inteligentní refaktoringové platformy s funkcemi vynucování v celém týmu, které se v datech Search Console pro tento článek zobrazují jako dotaz, jsou nástroje, které integrují ověřování shody s předpisy do pracovního postupu refaktoringu: vynucují, aby vzory refaktoringu byly konzistentně používány napříč týmy, aby zastaralá rozhraní nebyla znovu zavedena a aby strukturální změny splňovaly architektonické standardy definované na organizační úrovni. Tyto funkce jdou nad rámec toho, co poskytuje samotný kanál CI/CD, protože vyžadují pochopení sémantiky měněného kódu, nejen to, zda se sestaví a projde testy.

Refaktoring mainframeů a CICS bez prostojů

Prostředí sálových počítačů představuje nejnáročnější verzi refaktoringu s nulovým prostojem, protože omezení jsou spíše strukturální než konfigurovatelná. Transakční program CICS nelze nahradit nasazením nového obrazu kontejneru a přepnutím nástroje pro vyrovnávání zátěže. Nahrazení programu v CICS vyžaduje příkaz NEWCOPY nebo PHASEIN, který načte novou verzi programu do paměti. NEWCOPY okamžitě nahradí starou verzi a ovlivní všechny transakce, které spustí po provedení příkazu. PHASEIN čeká na dokončení všech aktuálně aktivních transakcí používajících starou verzi, než ji nahradí, což zajišťuje čistší přechod pro dlouhodobě běžící transakce.

Ani jeden z těchto mechanismů neposkytuje okamžité vrácení zpět. Pokud má nová verze programu chybu, návrat ke staré verzi vyžaduje opětovné vydání NEWCOPY nebo PHASEIN s předchozím načítacím modulem. To vyžaduje, aby předchozí načítací modul byl zachován v knihovně načítání a aby procedura vrácení zpět byla zdokumentována, nacvičena a spustitelné týmem na pohotovosti bez nutnosti původního vývojáře.

Sdílené soubory VSAM přidávají další omezení. Více transakcí CICS a dávkových programů může současně přistupovat ke stejnému souboru VSAM. Strukturální změna rozvržení souboru, jako je přidání nebo rozšíření segmentu záznamu, vyžaduje, aby všechny programy přistupující k souboru byly aktualizovány před změnou rozvržení nebo současně se změnou, nebo aby soubor během přechodného období podporoval více formátů záznamů. Toto je ekvivalent vzoru rozbalení a zmenšení pro mainframy: nové rozvržení musí být během přechodu kompatibilní se starými programy a staré programy musí být aktualizovány předtím, než bude staré rozvržení vyřazeno. Řízené rozšiřování rozvržení datových sad a parametrů přístupu k programům je mechanismus, který umožňuje tuto kompatibilní koexistenci bez nahrazování souborů.

Strategie eliminace dávkového okna

Tradiční dávkové zpracování na mainframech předpokládá existenci dávkového okna: období, během kterého je online zpracování transakcí pozastaveno, dávkové úlohy běží bez konfliktů a výsledná data jsou připravena pro další období online zpracování. Eliminace dávkového okna, které je nezbytné pro skutečně nulový provoz, znamená přepracování modelu dávkového zpracování tak, aby dávkové úlohy mohly běžet souběžně s online transakcemi, aniž by došlo k poškození sdílených dat.

Standardní přístupy zahrnují zamykání na úrovni zdrojů na úrovni záznamu, nikoli na úrovni souboru, minidávkové zpracování řízené událostmi, které zpracovává malé úlohy nepřetržitě, nikoli velké úlohy periodicky, a databáze pro čtení a replikaci, které obsluhují dávkové úlohy sestavování, aniž by konkurovaly online zpracování transakcí o přístup pro zápis. Každý z těchto přístupů vyžaduje změny jak v programech, tak ve vzorcích přístupu k datům, ale žádný z nich nevyžaduje, aby dávkové okno zůstalo během přechodu v platnosti: samotný přechod lze provést pomocí stejného přístupu k validaci s dvojitým spuštěním, jaký se používá pro jakýkoli jiný refaktoring živého systému.

Refaktoring programů v COBOLu s využitím analýzy dopadů

Bezpečný refaktoring programu v COBOLu vyžaduje před provedením jakékoli změny vědět, které programy jej volají, které sešity sdílí s ostatními programy, které datové sady čte a zapisuje a které následné systémy závisí na datech, která vytváří. Bez této strukturální znalosti s sebou jakákoli změna programu nese neznámé riziko: refaktorovaný program může narušit volající program, který nebyl identifikován, vytvořit výstup ve formátu, který následný systém nedokáže analyzovat, nebo upravit sdílenou datovou strukturu způsobem, který ovlivní ostatní programy, které obsahují stejný sešit.

Automatizovaná analýza dopadu řeší tento problém vytvořením kompletního grafu závislostí programu v COBOLu před zahájením refaktoringu. Graf zobrazuje každého volajícího, každou sdílenou sešitovou šablónu, každý přístup k datové sadě a každého následného příjemce, uspořádaného podle typu vztahu a konkrétního referenčního umístění. Plán refaktoringu je poté odvozen z grafu dopadu: programy, které volají změněný program, musí být testovány oproti nové verzi, upravené sešity musí být validovány oproti všem programům, které je obsahují, a rozvržení datové sady, která se mění, musí být validována vůči všem programům, které přistupují ke stejným datovým sadám. Jak je popsáno v řešení pro analýzu dopadů Tato schopnost, kterou IN-COM poskytuje, představuje rozdíl mezi refaktoringovým programem, který odhaluje své důsledky až po nasazení, a programem, který je kvantifikuje předtím.

Ověření, vrácení zpět a pozorovatelnost

Refaktoring s nulovým prostojem produkuje nepřetržitý výstup, který je nutné průběžně monitorovat. Monitorování není post-hoc kontrolou, zda vše fungovalo: je to aktivní brána v každé fázi procesu nasazení a je primárním mechanismem, jehož prostřednictvím jsou problémy detekovány dostatečně včas, aby se zabránilo dopadu na uživatele.

Verifikační model pro refaktoring s nulovým prostojem má tři vrstvy. První je syntetické monitorování: skriptované transakce, které simulují chování uživatelů a průběžně běží v produkčním prostředí, čímž ověřují, zda jsou klíčové toky úspěšně dokončeny. Syntetické monitory zachycují selhání, ke kterým dochází v určitých kódových cestách, které skuteční uživatelé nemusí používat během období s nízkým provozem, a poskytují základní úroveň chování, s níž lze porovnávat nekonzistentní výsledky.

Druhou vrstvou je diferenciální monitorování: porovnávání metrik mezi nasazením Canary a základním nasazením v reálném čase, včetně míry chyb, rozdělení latence, obchodních metrik a spotřeby zdrojů. Diferenciální monitorování nevyžaduje absolutní prahové hodnoty: vyžaduje relativní srovnání. Nasazení Canary, které vykazuje o dvě procenta vyšší míru chyb než základní nasazení, je problém bez ohledu na to, zda absolutní míra chyb překračuje jakoukoli individuálně definovanou prahovou hodnotu.

Třetí vrstvou je ověřování konzistence dat. Při jakémkoli refaktoringu, který zahrnuje duální zápisy, migrace schémat nebo paralelní běhy systémů, musí být konzistence dat mezi starou a novou reprezentací průběžně ověřována. Porovnání kontrolních součtů, porovnání počtu záznamů a namátkové kontrolní dotazy, které ověřují hodnoty konkrétních polí oproti očekávaným transformacím, přispívají k jistotě, že datová vrstva se během přechodu chová správně. Jak bylo zkoumáno v kontextu Co je analýza dopadů a proč je důležitáSchopnost ověřit důsledky změny oproti definovanému souboru očekávání je to, co odlišuje strukturovaný refaktoring od spekulativní změny.

Mechanismy okamžitého vrácení zpět

Plán vrácení zpět, jehož provedení trvá třicet minut, není plánem vrácení zpět pro systém s nulovými prostoji. V době jeho dokončení je uživatelům již poskytnuto třicet minut degradovaného provozu. Okamžité vrácení zpět vyžaduje, aby každé nasazení bylo od začátku navrženo s ohledem na vratnost, a nikoli dodatečné úpravy po vzniku problému.

Pro nasazení aplikací znamená okamžité vrácení zpět předchozí verze zachování dostupnosti artefaktu předchozího nasazení, jeho předpřipravenosti a zaměření na stejný stav databáze. Přepnutí provozu pomocí nástroje pro vyrovnávání zátěže nebo změny pravidla brány API by mělo být jedinou akcí potřebnou k návratu k předchozí verzi. Toho je možné dosáhnout, pokud je stav databáze zpětně kompatibilní s předchozí verzí, což je zaručeno disciplínou expand-contract v migrační vrstvě databáze.

U migrací databází vyžaduje okamžité vrácení zpět, aby každá migrace provedená ve fázi rozšíření byla vratná bez ztráty dat. Sloupec přidaný ve fázi rozšíření lze při vrácení zpět odstranit. Sloupec upravený destruktivním způsobem nelze obnovit bez zálohy. Proto by se destruktivní změny schématu, tedy ty, které odstraňují sloupce, mění typy nekompatibilním způsobem nebo snižují přesnost, nikdy neměly provádět, dokud nebude nová verze plně nasazena a ověřena a stará verze nebude zcela vyřazena.

Jak SMART TS XL Podporuje programy refaktoringu s nulovým prostojem

SMART TS XL řeší problém strukturální viditelnosti, který je základem každého selhání refaktoringu s nulovým prostojem: týmy se pokoušejí refaktorovat živé systémy bez úplného obrazu o tom, co tyto systémy obsahují, co na čem závisí a jaké budou důsledky každé plánované změny. Platforma přijímá zdrojový kód ze všech jazyků a platforem v prostředí, včetně COBOL, JCL, Java, .NET, Python, JavaScript a SQL, a vytváří jednotný model křížových odkazů, který reprezentuje strukturální vztahy celého systému.

Než je provedena změna refaktoringu, SMART TS XLAnalýza dopadů sleduje graf závislostí od měněné komponenty směrem ven přes každého volajícího, každou sdílenou datovou strukturu, každého následného příjemce a každý program, který bude změnou ovlivněn. Výsledkem je specifický, vyjmenovaný seznam důsledků uspořádaných podle závažnosti a komponenty, nikoli obecné posouzení rizika. Tento seznam umožňuje správně naplánovat sekvenci refaktoringu s nulovými prostoji: znalost toho, kteří příjemci musí být aktualizováni před nasazením změněné komponenty, které migrace databáze musí být seřazeny před nasazením kterých aplikací a které následné systémy musí být validovány před vyřazením staré verze.

SMART TS XLDíky vizualizaci kódu je graf závislostí snadno ovladatelný i pro týmy, které nemají hluboké znalosti o každé vrstvě refaktorovaného systému. Architekti mohou vidět, jak se komponenty propojují, ještě předtím, než přepracují strukturu propojení. Vývojáři mohou vidět, co volá funkci, ještě před změnou její signatury. Provozní týmy mohou vidět, k čemu je datová sada používána, ještě před úpravou jejího rozvržení. Tato viditelnost je předpokladem pro strukturovaný, reverzibilní, fázově řízený refaktorovací program, který vyžaduje provoz s nulovými prostoji.

Refaktoring s nulovým prostojem jako kontinuální praxe

Techniky v této příručce nejsou jednorázovými zásahy. Jsou operačním slovníkem vývojové organizace, která se rozhodla považovat produkční systémy za neustále se vyvíjející, nikoli za periodicky nahrazované. Modrozelené nasazení, kanárková vydání, přepínání funkcí, migrace typu expand-contract, extrakce strangler fig, zpracování idempotentních událostí a pipeline-enforced deployment gate nejsou nouzové postupy: jsou to standardní operační postupy týmu, který bezpečně a s vysokou frekvencí zavádí strukturální změny.

Dosažení tohoto stavu vyžaduje investice do nástrojů, infrastruktury a organizačních postupů, které jdou nad rámec jakékoli individuální iniciativy refaktoringu. Nástroje musí podporovat nezávislé nasazení, pozorovatelné přechody mezi stavy a okamžité vrácení zpět. Infrastruktura musí podporovat rozdělení provozu, modro-zelená prostředí a synchronizaci dat založenou na CDC. Organizační postupy musí zahrnovat analýzu dopadu před nasazením, monitorování rozdílů po nasazení a pravidelné testování vrácení zpět, které potvrdí, že cesta vrácení zpět funguje za realistických podmínek.

Organizace, které do této investice investují, zjišťují, že náklady na změnu se s postupným zráním postupu snižují: každý následující refaktoring je méně rizikový než ten předchozí, protože podpůrná infrastruktura je již zavedena, tým si vytvořil úsudek o tom, které prahové hodnoty brány jsou vhodné pro které změny, a nashromážděné strukturální znalosti v nástrojích, jako je SMART TS XL umožňuje přesněji vymezit rozsah každé plánované změny než u předchozí. Cílem refaktoringu s nulovými prostoji není bezpečně provést jedinou změnu. Jde o to, provést každou změnu bezpečně, průběžně, aniž by se od uživatelů kdykoli vyžadovalo přijetí okna údržby.