Migrace mainframů selhávají z předvídatelného důvodu. Ne proto, že by cílová cloudová architektura byla špatná. Ne proto, že by nástroje pro převod COBOLu do Javy byly nedostatečné. Ne proto, že by týmu chyběl záměr nebo rozpočet. Selhávají, protože tým začíná s přesuny dříve, než zjistí, o co jde, než může odpovědět s důkazy, spíše než s předpoklady, co každý program dělá, které programy jsou závislé na kterých ostatních, jak data proudí systémem a co se pokazí, když se něco změní. Způsob selhání je téměř vždy stejný: závislost objevená uprostřed migrace, o jejíž existenci nikdo nevěděl, obchodní pravidlo pohřbené v sešitě, které je součástí 400 programů, dávková úloha, která napájí dvanáct navazujících systémů souborem, který nikdo nepomyslel na zdokumentování.
Proces migrace mainframe vyžaduje pečlivé plánování a provedení, aby se minimalizovalo riziko a zajistila kontinuita podnikání. Toto tvrzení je pravdivé, ale neúplné. Pečlivé plánování, na kterém záleží, není plán, výběr dodavatele ani fázovaný časový harmonogram. Je to strukturální analýza, která probíhá před přijetím jakéhokoli z těchto rozhodnutí, analýza, která vám řekne, co systém skutečně obsahuje a jak skutečně funguje, na rozdíl od toho, co uvádí dokumentace a jak byl původně navržen. Tyto dva popisy se v každém velkém prostředí mainframe liší, často o rozdíl, který určuje, zda migrace proběhne úspěšně, nebo se zastaví.
Namapujte celý svůj mainframe
SMART TS XL analyzuje každý program v COBOLu, úlohu JCL, sešit a schéma SQL ve vašem prostředí sálových počítačů.
Zjistěte VÍCEProč migrace sálových počítačů selhávají: Analytická mezera
Migrace sálových počítačů neselhávají proto, že je kód starý, ale proto, že nikdo doopravdy neví, co kód dělá, dokud není příliš pozdě. Skrytá logika. Nedokumentované okrajové případy. Zapomenuté toky. To nejsou teoretická rizika, ale praktické překážky, které brzdí projekty, spouštějí produkční problémy a tiše narušují důvěru v migrační plán.
Analytická mezera má specifickou strukturu. Organizace, které provozují mainframové systémy dvacet nebo třicet let, nashromáždily změny, které se nikdy neprojevily v dokumentaci, závislosti, které se organicky formovaly, když byly programy propojovány prostřednictvím sdílených souborů, nikoli explicitních rozhraní, a obchodní logiku, která existuje pouze v myslích vývojářů, kteří odešli do důchodu. Týmy, které zacházejí s daty mainframů jako se standardními soubory, se během migrace setkávají s nepříjemnými překvapeními, když si uvědomí, že „data“ zahrnují desítky let obchodní logiky roztroušené v podmíněných příkazech a názvech podmínek na úrovni 88 úrovní.
Existují čtyři specifické mezery ve znalostech, které brání migracím. Každá z nich má analytickou techniku, která ji uzavírá. Žádnou z nich nelze uzavřít pouze kontrolou dokumentace nebo pohovory s vývojáři.
Mezera 1: Neznámý inventář programů. Organizace běžně zjišťují, že skutečný počet jejich programů je výrazně vyšší než jejich zdokumentovaný počet. Programy napsané pro specifické obchodní potřeby, testovací programy, které se staly produkčními programy, obslužné programy, na jejichž vytvoření si nikdo nevzpomene, to vše je v knihovně načítání a mohou být vyvolány úlohami JCL, které se objevují v produkčních plánech.
Mezera 2: Nedokumentované závislosti. Sálové počítače zásobují desítky systémů prostřednictvím komplexních sítí middlewaru, jako je WebSphere, CICS Transaction Gateway, Enterprise Service Bus, a dále sdílených utilit, plánovačů a obchodních procesů. Chybou je příliš dlouhé čekání na mapování všech těchto propojení, zejména následných datových kanálů a vzorců spotřeby.
Mezera 3: Vložená obchodní logika. Programy v COBOLu hromadí obchodní pravidla po celá desetiletí. Výpočet, který byl v roce 1985 přímočarý, byl od té doby upraven dvanácti vývojáři, přičemž každý z nich přidal podmíněnou logiku, která odráží změnu obchodního pravidla, jež nebyla nikde jinde zdokumentována. Přesun programu bez pochopení logiky vede k migrovanému systému, který počítá jiné výsledky než originál, a to správně z pohledu kódu, ale nesprávně z pohledu obchodu.
Mezera 4: Propojení formátu dat a schématu. Programy, které sdílejí data prostřednictvím souborů, nikoli API, jsou propojeny prostřednictvím kontraktů formátu dat, které neexistují nikde jinde než v jejich příkazech FD a COPY. Změna rozvržení záznamu sdíleného souboru naruší funkčnost všech programů, které jej čte, což může zahrnovat programy v rozsahu migrace a programy, které zůstanou na sálovém počítači, což vede k tichému selhání integrace.
Osm analýz, které je nutné provést před migrací
Následující analýzy by měly být provedeny před jakýmkoli rozhodnutím o migraci a před jakýmkoli zásahem do kódu. Nejedná se o předběžné kroky, které je třeba provést rychle, ale o základ, na kterém spočívá každé následné rozhodnutí.
1. Kompletní inventář programu
První analýza je soupis: jaké programy, pracovní postupy, sešity, procedury a definice dat skutečně v daném prostředí existují. Nejedná se o kontrolu dokumentace. Jde o analýzu skutečných načítacích knihoven, zdrojových knihoven a knihoven procedur za účelem vytvoření autoritativního inventáře.
Inventář by měl zahrnovat: každý zdrojový program s jeho jazykem a přibližnou velikostí; každou sešitovou práci a programy, které ji obsahují; každou katalogizovanou proceduru a úlohy, které ji volají; každou datovou sadu, která se objevuje v příkazech DD, a programy, které ji vytvářejí nebo spotřebovávají; každou tabulku, pohled a uloženou proceduru DB2, na které se odkazuje ve vloženém SQL.
Ve většině velkých prostředí sálových počítačů tato inventarizace odhalí programy, které tým plánující migraci neznal, někdy s rozdílem 20–30 % z celkového počtu. Migrační plány zaměřené na neúplné inventáře vedou k překročení nákladů, pokud jsou chybějící programy objeveny uprostřed projektu.
2. Mapování závislostí napříč všemi jazyky
Jakmile je inventář vytvořen, mapování závislostí sleduje, jak se každá komponenta propojuje s každou další komponentou. Mapa závislostí je nejdůležitější analýzou před migrací, protože definuje rozsah každé následné změny.
Kompletní mapa závislostí zahrnuje:
- Volání mezi programyCALL, PERFORM, LINK, ATTACH a dynamická volání, která se řeší za běhu
- Volání z JCL do programukaždý příkaz EXEC PGM= v každém proudu úloh JCL, včetně volání PROC s vyřešenou symbolickou substitucí parametrů
- Řetězce pro začlenění do sešitůkteré programy obsahují které sešity, včetně vnořených sešitů obsažených v jiných sešitech
- Vztahy mezi producentem a spotřebitelem datových sadkteré programy zapisují do kterých datových sad, které programy z těchto datových sad čtou a závislosti v sekvenčním řetězci úloh, které to vytváří
- Reference schémat DB2které programy čtou nebo zapisují do kterých tabulek, které tabulky sdílejí schéma s kterými dalšími tabulkami
Výstupem je orientovaný graf. Dopad jakékoli navrhované změny libovolného uzlu v tomto grafu lze analyzovat procházením hran a výčtem všech ostatních uzlů, které na něm závisí. Bez tohoto grafu je analýza dopadu pouhou dohady.
Než se dotkneme jakéhokoli kódu, je prvořadý důkladný přehled. Spoléhání se na zastaralou dokumentaci je fatální chyba; automatizované nástroje musí automaticky mapovat aktuální stav prohledáváním JCL, COBOL a PL/I a mapovat všechny aplikace, datové toky, závislosti a skryté úlohy.
3. Extrakce a dokumentace obchodní logiky
Programy v COBOLu obsahují obchodní logiku, která nikde jinde v organizaci neexistuje. Jedná se o nejvíce přehlíženou analýzu při plánování migrace a zároveň o tu, která způsobuje nejnákladnější selhání po migraci.
Extrakce obchodní logiky vytváří dokumentaci: rozhodovacích pravidel kódovaných ve strukturách IF/THEN/ELSE a EVALUATE; výpočetních vzorců v příkazech COMPUTE; pravidel validace dat v odstavcích PROCEDURE DIVISION; cest ošetření chyb a jejich obchodního významu; a logiky závislé na sekvenci, kde pořadí operací hraje roli pro správnost výstupu.
Tato analýza nevyžaduje ruční čtení každého řádku každého programu. Nástroje pro statickou analýzu, které rozumí jazyku COBOL, dokáží identifikovat rozhodovací struktury, extrahovat podmíněnou logiku a vytvořit strukturovanou dokumentaci pravidel, která kódují. Tento výstup slouží dvěma účelům: poskytuje migračnímu týmu specifikaci, kterou potřebuje k ověření, zda migrovaný systém produkuje správné výsledky, a poskytuje firmě první systematickou dokumentaci obchodních pravidel, která mohla po celá desetiletí existovat pouze v kódu.
4. Identifikace mrtvého kódu
Ne všechno v mainframu je třeba migrovat. Programy, které nejsou nikdy volány žádným streamem úloh, odstavce, které nejsou nikdy spuštěny žádnou volající cestou, členy sešitu úloh, na které se nikdy neodkazuje, to vše představuje migrační úsilí, které nepřináší žádnou obchodní hodnotu.
Identifikace mrtvého kódu analyzuje graf závislostí a vyhledává komponenty bez vstupních odkazů z žádného produkčního toku úloh. Tyto komponenty lze vyloučit z rozsahu migrace, což snižuje náklady bez omezení funkčnosti. V rozsáhlých starších prostředích představuje mrtvý kód obvykle 10–25 % celkového inventáře, což představuje významné snížení rozsahu, pokud je identifikován systematicky, a nikoli objeven náhodně.
Analýza musí rozlišovat mezi skutečně mrtvým kódem (nikdy nedosažitelným z žádné produkční cesty) a zřídka spouštěným kódem (dosažitelným, ale zřídka spouštěným). Zřídka spouštěný kód, jako jsou rutiny zpracování na konci roku, programy pro regulační reporting nebo postupy pro zotavení po havárii, může být kritický i přes jeho nepravidelné spouštění. Jeho vyloučení z migrace vede k systému, který funguje správně v 99 % případů a selhává přesně tehdy, když je nejvíce potřeba.
5. Složitost a klasifikace rizik
Jakmile existuje inventář programů a mapa závislostí, lze každý program klasifikovat podle složitosti a rizika migrace. Klasifikace řídí pořadí: programy s nízkou složitostí a nízkou závislostí se migrují jako první; programy s vysokou složitostí a vysokou závislostí se migrují jako poslední, s nejdůkladnějším testováním.
Metriky složitosti pro riziko migrace COBOLu:
| Faktor složitosti | Co měřit | Prahová hodnota vysokého rizika |
|---|---|---|
| Cyklomatická složitost | Počet rozhodovacích větví na program | Nad 50 na program |
| Počet závislostí v sešitě | Počet zahrnutých sešitů | Více než 20 sešitů |
| Počet volání | Počet programů, které volají tento program | Více než 15 volajících |
| Reference datových sad | Počet přečtených nebo zapsaných datových sad | Více než 30 datových sad |
| Vestavěný SQL | Počet SQL příkazů | Více než 100 výpisů |
| Volání EXEC CICS | Propojení transakčních serverů | Jakákoli závislost na CICS |
| Dynamická volání | Volání vyřešena za běhu | Jakýkoli dynamický hovor |
| Volání assembleru | Vložená logika jiná než COBOL | Jakékoli volání Assembleru |
Programy s vysokým skóre v několika faktorech představují migrační komponenty s nejvyšším rizikem. Vyžadují nejdůkladnější analýzu, nejzkušenější migrační inženýry a nejkomplexnější testování.
6. Analýza závislostí dávkového okna a plánování
Dávkové úlohy sálových počítačů běží v plánovaných oknech se složitými řetězci závislostí: Úloha B nemůže být spuštěna, dokud není úloha A úspěšně dokončena; Úloha C běží pouze poslední pracovní den v měsíci; Úloha D má maximální omezení doby běhu, které ovlivňuje čas zahájení úlohy E. Tyto závislosti plánování jsou součástí provozního chování systému a musí být replikovány v cílovém prostředí.
Analýza dávkového okna dokumentuje: celý řetězec provádění pro každé běhové dávkové produkce; časová omezení pro každý krok; logiku podmíněného provádění (co se stane, když krok selže nebo vygeneruje nenulový návratový kód); datové sady, které proudí mezi kroky; a externí spouštěče a oznámení, které dávkový systém generuje.
V cloudově nativních cílech se to promítá do: ekvivalentní konfigurace kanálu CI/CD nebo orchestrace pracovních postupů; nastavení zpracování chyb a upozornění; konfigurace monitorování a SLA; a integrace s navazujícími systémy, které přijímají dávkové výstupy.
7. Posouzení kvality a formátu dat
Starší systémy často obsahují tisíce řádků kódu napsaného v COBOLu, PL/I nebo assembleru, z nichž velká část může být špatně zdokumentovaná nebo úzce propojená. Použijte nástroje statické analýzy k detekci technického dluhu, redundantního kódu a modulů, které lze modularizovat nebo vyřadit.
Hodnocení kvality dat porovnává skutečná data v produkčních datových sadách s definicemi formátů v COBOL FD a definicemi v copybooku. Nesrovnalosti jsou běžné: balená dekadická pole, která obsahují neplatné bitové vzory pro určité typy záznamů, pole s proměnnou délkou, kde je indikátor délky mimo rozsah pro podmnožinu záznamů, znaková pole EBCDIC, která obsahují nezobrazitelné hodnoty na určitých pozicích.
Tyto nesrovnalosti musí být identifikovány a vyřešeny před migrací, nikoli odhaleny během testování migrace. Migrace dat, která přesune 500 milionů záznamů a poté zjistí, že 0.1 % z nich má neplatné formáty, má vadu ovlivňující produkční prostředí, která byla přítomna ve zdrojových datech a nebyla známa až do kroku validace.
8. Integrace a mapování externích systémů
Vaše datová linie musí zachycovat všechny systémy spotřebovávající data z mainframů, od nástrojů pro tvorbu sestav až po integrace s partnery, protože modernizační projekty nemohou být spuštěny, když týmy v pozdní fázi vývoje zjistí, že zachování těchto datových kanálů bylo nezbytné, ale neplánované.
Mapování integrace identifikuje každý systém mimo mainframe, který z něj přijímá data nebo do něj odesílá data: následné aplikace, které využívají dávkové výstupy prostřednictvím přenosu souborů; rozhraní v reálném čase prostřednictvím volání MQ, CICS nebo API; integrace partnerů, které se spoléhají na specifické formáty souborů a plány přenosu; systémy pro vytváření sestav, které se přímo dotazují na tabulky DB2; a datové sklady, které přijímají transformovaná data mainframe.
Každý bod integrace představuje potenciální riziko přechodu: migrovaný systém, který produkuje data ve formátu, který následný systém neočekává, způsobí tiché selhání, které nemusí být detekováno, dokud následný uživatel nenahlásí anomálii. Mapování integrace je analýza, která činí plánování přechodu komplexním, nikoli optimistickým.
Výběr migrační strategie na základě výsledků analýzy
Analýza před migrací nejen snižuje rizika spojená s migrací, ale také určuje, která migrační strategie je pro každou komponentu vhodná. Týmy migrují úlohy mainframe různými způsoby v závislosti na tom, kolik změn zvládnou. Výsledky analýzy přímo ovlivňují toto rozhodnutí.
| Analýza zjištění | Doporučená strategie | zdůvodnění |
|---|---|---|
| Nízká složitost, málo závislostí, žádná dynamická volání | Přemístění (zvedání a posun) | Nejnižší riziko; behaviorální ekvivalence dosažitelná rychle |
| Střední složitost, dobře zdokumentovaná obchodní logika | Replatforming | Některé úpravy jsou přijatelné; logika je pochopitelná |
| Vysoká složitost, hustý graf závislostí | Fázovaný škrtič-obrázek | Postupně extrahovat; ponechat mainframe pro jádro a modernizovat kolem něj |
| Kritický sdílený program, více než 100 volajících | Obalení API | Zveřejnit jako službu; migrovat uživatele bez zásahu do programu |
| Programy s neplatnými daty nebo problémy s formátováním | Nejprve oprava dat | Migrace nemůže být úspěšná, dokud nebudou data čistá. |
| Analýza potvrdila nefunkční kód | Odejít | Není nutná migrace; odebrat z rozsahu |
| Nedokumentovaná obchodní logika, žádné malé a střední podniky k dispozici | Vyžaduje se hloubková analýza | Nelze bezpečně migrovat, dokud není logika extrahována a zdokumentována. |
Vytvoření migrační sekvence z grafu závislostí
Graf závislostí, jakmile je dokončen, přímo definuje sekvenci migrace. Komponenty, které nemají žádné závislosti na jiných komponentách sálového počítače, lze migrovat nezávisle a včas. Komponenty, na kterých závisí mnoho dalších, musí být migrovány jako poslední, až poté, co jsou připraveny všechny jejich závislé komponenty.
Praktický přístup k sekvenování:
Fáze 1: Obslužné programy a samostatné dávkové úlohy. Programy bez volajících programů a sdílených datových sad. Tyto programy lze migrovat izolovaně bez požadavků na koordinaci.
Fáze 2: Oddělení programů ve stromu závislostí. Programy, které volají jiné, ale nejsou volány mnoha dalšími programy. Migrace těchto programů je odstraní z rozsahu závislostí pro zbývající programy.
Fáze 3: Datově propojené programy. Skupiny programů, které sdílejí datové sady, lze migrovat společně jako jeden celek, čímž se vyřeší kontrakt na formát dat v rámci migrované skupiny.
Fáze 4: Programy sdílených služeb. Programy s mnoha volajícími, uzly s vysokým podílem fan-in v grafu závislostí, migrovaly až poté, co byly všechny volající ověřeny oproti migrované implementaci.
Fáze 5: Základní transakční programy. Nejrizikovější komponenty migrované jako poslední s nejkomplexnějším testováním a nejkontrolovanějším procesem přechodu na novější platformy.
Tato sekvence není obecnou heuristikou, je odvozena ze specifického grafu závislostí migrovaného systému. Dvě prostředí mainframe se stejným počtem programů budou mít zcela odlišné optimální migrační sekvence, protože se liší jejich struktury závislostí.
Jak SMART TS XL Provádí analýzu před migrací
SMART TS XL provádí všech osm analýz popsaných v tomto článku automaticky, a to analýzou skutečného zdrojového kódu každé komponenty v prostředí. Nespoléhá se na dokumentaci, rozhovory s vývojáři ani existující diagramy, ale odvozuje strukturální model ze samotného kódu, takže model je přesný i pro programy, které nikdy nebyly zdokumentovány, a závislosti, které vznikly bez jakéhokoli záměru.
Analýza modernizace starších systémů začíná kompletním vygenerováním inventáře: každý program v COBOLu, tok úloh JCL, sešit úloh, PROC a schéma SQL je katalogizován s umístěním zdroje, velikostí, jazykovou verzí a předběžným skóre složitosti. Mapování závislostí aplikací vytváří kompletní graf závislostí, přičemž pomocí funkce rozšíření JCL řeší symbolické parametry JCL a zobrazuje skutečně vyvolané programy, nikoli nevyřešené odkazy na šablony.
Díky analýze dopadů je graf závislostí dotazovatelný: před migrací jakékoli komponenty se tým může zeptat, co bude ovlivněno jejím odebráním z mainframu, a obdržet výčtový, strukturovaný seznam všech závislých komponent, které vyžadují ověření nebo koordinaci. Funkce podnikového vyhledávání umožňuje prohledávat celý inventář ve všech jazycích současně, najít každý program, který čte konkrétní datovou sadu, každý sešit, který definuje konkrétní pole, každý příkaz SQL, který odkazuje na konkrétní sloupec, a to během několika sekund v kódové základně o milionech řádků.
Výstupem analýzy před migrací není projektový plán. Jsou to strukturální důkazy: graf závislostí, klasifikace složitosti, inventář mrtvého kódu, dokumentace obchodní logiky a mapa integrace, které společně sdělují migračnímu týmu přesně, s čím pracuje. Tyto důkazy rozlišují mezi migrací, která odhalí překvapení v produkčním prostředí, a migrací, která je odhalí v analýze, kdy náklady na jejich nalezení a řešení činí týdny, nikoli měsíce.
Analýza není režie, je to migrace
Nejčastější námitkou proti komplexní předmigrační analýze je časový harmonogram: organizace se zavázala k datu zahájení migrace, tlak na vedení je vysoký a strávit šest až osm týdnů analýzou předtím, než se dotknete jakéhokoli kódu, se jeví jako zpoždění. Toto zdůvodnění obrací kalkul rizik naruby. Jakmile jsou pravidla viditelná a postupy zmapovány, projekt se přesouvá od spekulací k inženýrství. Automatizační nástroje zviditelňují neviditelné a to je to, na čem záleží.
Migrace, která začíná bez kompletní analýzy, nezačne rychleji, ale s neznámým rozsahem. Neznámý rozsah vede k překvapivým výsledkům v harmonogramu, překročení rozpočtu a produkčním incidentům, když se odhalí neobjevené závislosti. Fáze analýzy nezpožďuje migraci; je to migrace. Každá závislost zjištěná během analýzy, nikoli během přechodu na jiný kód, je produkční incident, který se nestal. Každý program identifikovaný jako mrtvý kód před migrací představuje úsilí, které nebylo vynaloženo. Každé obchodní pravidlo zdokumentované před konverzí je validační kritérium, které lze testovat, nikoli odhadovat.
Uspějí ty organizace, které proaktivně řeší složitost, včas mapují závislosti, demokratizují znalosti, zaměřují se na obchodní hodnotu a od prvního dne se shodují na jasných cílech. Nejde jen o osvědčené postupy, ale o rozdíl mezi transformačními projekty, které přinášejí měřitelnou návratnost investic, a těmi, které se stanou varovnými příběhy.
