Systémy rezervace letenek: Proč jsou stále na mainframech

Když si v roce 2026 rezervujete let na chytrém telefonu, váš požadavek projde několika vrstvami moderní technologie, mobilní aplikací, webovou službou a platebním procesorem, než se dostane k systému, který vám skutečně rezervuje sedadlo. Tento systém je ve většině případů software s kořeny v 60. letech 20. století, běžící na infrastruktuře, kterou se cestovní ruch snaží nahradit již po desetiletí, aniž by se mu to plně podařilo. Sabre, Amadeus a Travelport společně zpracovávají v podstatě každou rezervaci letecké společnosti na Zemi. Společně zpracovávají miliardy transakcí ročně napříč stovkami leteckých společností, tisíci cestovních kanceláří a v reálném čase sledují miliony kombinací sedadel. Nejstarší z nich sahá až k mainframe počítači IBM z roku 1964, jehož doba rezervace se pohybovala od 90 minut po pouhé sekundy a trvale změnil komerční letectví.

Příběh o tom, proč tyto systémy zůstávají tam, kde jsou, není příběhem o organizační setrvačnosti nebo technickém konzervatismu. Je to příběh o tom, co se stane, když se software tak hluboce zakoření v kritických provozních procesech, že náklady a riziko jeho nahrazení nelze ospravedlnit žádným realistickým časovým harmonogramem, a jak na to odvětví reagovalo modernizací v jádru, spíše než pokusem o jeho nahrazení. Pro každého, kdo pracuje na rozsáhlé modernizaci starších systémů, jsou rezervační systémy letenek nejjasnější dostupnou případovou studií toho, co v praxi znamená „příliš důležité na to, aby selhaly“.

Původ: Proč mainframy vyhrály problém s leteckými společnostmi

Původní SABRE (Semi-Automated Business Research Environment) nebyl produkt, ale řešení na míru pro konkrétní provozní krizi. Na konci 1950. let rostla společnost American Airlines rychleji, než si dokázala poradit její manuální rezervační systém. Rezervace sedadla vyžadovala telefonát, ruční kontrolu fyzické inventární karty, rezervaci, zpětné volání a papírový záznam, což byl proces, který v průměru trval 90 minut na rezervaci a nedokázal se škálovat.

Když byl systém SABRE v roce 1964 plně funkční, byl postaven na dvou sálových počítačích IBM 7090 a připojen k 1 500 terminálům po celých Spojených státech a Kanadě. Dokázal zpracovat 7 500 rezervací za hodinu s téměř nulovou chybovostí. Poprvé mohla letecká společnost udržovat informace o počtu sedadel v reálném čase, ukládat kompletní záznamy o cestujících a umožňovat okamžité rezervace v celé své síti. Doba rezervace se zkrátila z 90 minut na sekundy.

Architektonická volba, která to umožnila – centralizované zpracování transakcí na mainframe hardwaru – nebyla zvolena z filozofických důvodů. Byla zvolena proto, že to byla jediná architektura dostupná v roce 1964, která dokázala splnit požadavky na latenci, spolehlivost a souběžný přístup v oblasti správy leteckých zásob v reálném čase. A fungovala tak dobře, že se stala architektonickou šablonou, na které byl postaven každý následující systém rezervace leteckých společností.

IBM Transaction Processing Facility (TPF), původně navržený pro SABRE, se stal operačním prostředím pro celou kategorii. Podle IBM jej stále používají téměř všechny největší banky, pojišťovny, maloobchodníci a letecké společnosti. Když byl Amadeus založen v roce 1987, stavěl na TPF. Když Galileo (nyní Travelport) spustil svůj GDS, stavěl na TPF. V komerčním letectví nyní koexistují tři generace systémů pro osobní dopravu a mnohé z nich stále běží na sálových počítačích TPF, ne proto, že by tato technologie nikdy nebyla zpochybňována, ale proto, že se ukázalo, že propustnost transakcí, spolehlivost a odolnost vůči selhání, které TPF poskytuje na sálovém hardwaru, je skutečně obtížné replikovat v ekvivalentním měřítku na alternativních architekturách.

Co tyto systémy ve skutečnosti dělají ve velkém měřítku

Rozsah, v jakém fungují rezervační systémy letenek, není z pohledu softwarového inženýrství intuitivně pochopitelný. Globální distribuční systém se nezabývá jen dostupností sedadel, ale také kombinatorickým problémem zásob ohromující složitosti.

Jeden transatlantický let má stovky tarifních tříd. Každá tarifní třída má specifická pravidla: požadavky na nákup předem, minimální pobyt, data zákazu letenek, poplatky za změnu, povolené či nepovolené mezipřistání, dohody o sdílení kódů s partnerskými leteckými společnostmi. Rezervace zahrnující dvě letecké společnosti, přestup a zpáteční let vytváří matici potenciálně tisíců platných kombinací tarifů, které je nutné zkontrolovat, nacenit a porovnat s aktuálními zásobami, než je odeslána odpověď, obvykle za méně než sekundu.

Během období špičky v rezervaci zpracovávají Sabre a Amadeus společně desítky tisíc transakcí za sekundu. Ne za minutu. Za sekundu. Každá transakce zahrnuje vyhledávání v reálném čase, vyhodnocení pravidel pro tarify, vytvoření nebo úpravu záznamu PNR (Passenger Name Record) a koordinaci s řízením odletů, systémy pro časté lety a systémy doplňkových služeb. Zaručená doba odezvy se měří v milisekundách, protože cestovní kancelář nebo rezervační systém, který čeká na kontrolu tarifu déle než několik sekund, vyprší časový limit a transakci buď zopakuje, nebo ji zruší.

Technologie TPF na hardwaru mainframeů poskytuje tuto propustnost s mírou selhání, které IT profesionálové z jiných odvětví jen těžko věří. Odolnost mainframeů vůči chybám, redundantní procesory, komponenty vyměnitelné za provozu a desetiletí odolného kódu operačního systému vedou k tomu, že dostupnost „pět devítek“ je standardním provozním parametrem, nikoli ambiciózním cílem. Replikace tohoto cíle za ekvivalentní náklady na cloudovou infrastrukturu byla ústřední technickou výzvou každého programu modernizace IT leteckých společností od 90. let 20. století.

Pokusy o modernizaci: Co desetiletí trvající programy skutečně zjistily

Historie modernizace rezervačních systémů leteckých společností je historií programů, které si kladly za cíl nahradit jádro systému, a o několik let později dospěly k hybridu, který jádro systému obalil.

Projekt Jetstream společnosti American Airlines, spuštěný v roce 2000 s explicitním cílem nahradit mainframeový systém pro správu serverů Sabre, skončil přijetím nového produktu Sabre namísto výroby alternativy. Počáteční předpoklad „vybudovat vs. koupit“, že výroba náhrady interně by rychleji vyprodukovala lepší systém, narazil na stejnou realitu, s jakou se setkává téměř každý rozsáhlý program nahrazování starších systémů: stávající systém obsahoval požadavky, o kterých nikdo nevěděl, dokud je náhrada nedokázala splňovat.

Musíme se hlouběji ponořit do problematiky, změnit základní systém a oddělit pravidla, abychom je mohli rychle změnit. Toto prohlášení vedení IT společnosti American Airlines během programu Jetstream problém přesně popisuje. Pravidla zabudovaná do staršího systému, logika konstrukce tarifů, implementace dohod o sdílení kódů, výpočty souladu s předpisy, integrace správy výnosů se nahromadila v průběhu desetiletí obchodních změn a nebyla zdokumentována v žádné formě, která by umožňovala jejich extrahování bez spuštění stávajícího systému a pozorování jeho chování.

Modernizační program společnosti Sabre, který naplno začal v roce 2010, trval více než deset let a stál miliardy dolarů, než se většina kódu přesunula z místní infrastruktury mainframe. V roce 2019 zhruba 11 procent kódu společnosti Sabre stále běželo v místních datových centrech, zbytek byl migrován. V únoru 2026 společnost Sabre obnovila svou dlouhodobou dohodu o PSS se společností WestJet, což dokazuje, že i po deseti letech modernizačního úsilí a miliardových investicích zůstává PSS komerčním základem podnikání.

Společnost Amadeus dosáhla komplexnějšího vyřazení mainframů z provozu a dosáhla milníku v podobě vyřazení posledních mainframů ve prospěch cloudové infrastruktury. Přístup společnosti Amadeus, který postupně nahrazuje funkční komponenty a zároveň zachovává základní datový model a architekturu transakcí, však efektivně zachoval architektonická rozhodnutí, která vznikla na mainframu, a to i při změně hardwaru. Sémantika transakcí, struktura PNR, logika správy zásob: to vše se přesunulo do moderní infrastruktury a zároveň si zachovalo svůj základní design.

Proč je výměna těžší, než se zdá: Skrytá složitost

Standardním vysvětlením, proč rezervační systémy letenek přetrvávají na mainframech, jsou náklady a riziko. Obojí je reálné. Jsou to však příznaky hlubší technické reality, kterou stojí za to přesně pochopit, protože se vztahuje na každý program modernizace starších systémů, který je kritický pro danou misi.

Obchodní pravidla, která existují pouze v kódu. Logika konstrukce tarifů v globálním distribučním systému představuje desítky let regulačních požadavků, bilaterálních dohod leteckých společností, revizí standardů IATA a změn obchodních pravidel, z nichž nic není zdokumentováno v jakékoli formě nezávislé na kódu, který je implementuje. Specifikace je implementace. Nahrazení implementace bez specifikace znamená dostatečně vyčerpávající pozorování chování stávajícího systému, aby se rekonstruovalo, co by specifikace uvedla, což je proces, který trvá roky a nikdy není úplný, protože pokrytí pozorováním nemůže být nikdy dostatečně komplexní, aby zachytilo každý okrajový případ.

Sémantika transakcí, kterou moderní architektury jen obtížně replikují. TPF poskytuje synchronní, atomické zpracování transakcí se zaručenou konzistencí napříč celým PNR, rezervací sedadel, aktualizací záznamů o cestujících, autorizací platby a potvrzovacím záznamem, vše je potvrzeno jako jedna atomická jednotka nebo vůbec ne. Replikace tohoto procesu na distribuovaných architekturách mikroslužeb vyžaduje pečlivou orchestraci, kompenzaci transakcí a distribuovanou správu zámků, která je složitá a potenciálně pomalejší než ekvivalent synchronních mainframů. Zkušenosti leteckého průmyslu ukazují, že „eventuálně konzistentní“ není tolerovatelná vlastnost pro dostupnost sedadel, přeprodaný let je konkrétní, provozně katastrofální selhání, nikoli dočasná nekonzistence, která bude později vyřešena.

Integrační plocha. Zralý systém PSS letecké společnosti je propojen se stovkami externích systémů: řízení odletů, správa výnosů, věrnostní programy, letištní systémy, připojení GDS třetích stran, partneři pro sdílení kódů, regulační reporting a další. Každé připojení má specifické smlouvy o rozhraní, formáty zpráv, časové požadavky, chování při ošetřování chyb, které stávající systém implementoval a kolem kterých byl postaven každý závislý systém. Nahrazení PSS vyžaduje buď současné zachování všech stávajících smluv o rozhraní (což omezuje nahrazující architekturu), nebo koordinaci změn s každým závislým systémem (což rozšiřuje rozsah nad rámec toho, co dokáže zvládnout jakýkoli jednotlivý program).

Problém s živými daty. Rezervace letenek jsou živá data, rezervace provedené měsíce předem, které musí být dodrženy přesně tak, jak byly rezervovány. Neexistuje žádný jasný bod přechodu, kde by data ze starého systému mohla být ponechána. Migrace musí přenést všechny živé PNR ze starého systému do nového, a to se všemi souvisejícími pravidly, tarify, omezeními a doplňkovými službami. Migrace PNR v globálním měřítku, s nulovou ztrátou dat a zárukou identického chování, se ukázala jako jeden z nejtěžších technických problémů modernizace podniků.

Architektonická odpověď: Modernizace v celém jádru

Přístup, který ve společnostech Amadeus, Sabre i jednotlivé letecké společnosti skutečně uspěl, není nahrazování, ale strategické balení a postupné odběry.

API obalení zpřístupňuje základní rezervační funkce jako moderní REST nebo SOAP API, což umožňuje novým aplikacím interagovat se starším systémem prostřednictvím moderního rozhraní, aniž by se dotýkaly základní transakční logiky. Letecké společnosti vytvořily mobilní aplikace, webové rezervační systémy a nástroje pro zákaznický servis nad vrstvami API, které převádějí moderní požadavky na transakční volání TPF a vracejí strukturované odpovědi. Terminál se zelenou obrazovkou je nahrazen moderním grafickým uživatelským rozhraním; základní zpracování transakcí zůstává nezměněno.

Strangler Fig pro neklíčové funkce. Funkce, které sousedí s jádrem, správa výnosů, správa věrnostních programů, reporting a analytika, plánování posádky, jsou extrahovány jedna po druhé a znovu implementovány na moderní infrastruktuře. Každá extrakce snižuje zatížení staršího systému, aniž by se dotkla transakčního jádra, které představuje nejvyšší riziko. Během deseti let postupné extrakce se role staršího systému zužuje z komplexní aplikační platformy na specializovaný transakční engine.

Cloudová infrastruktura se zachovanou architekturou. Vyřazení mainframe serverů Amadeus z provozu přesunulo pracovní zátěže do cloudové infrastruktury a zároveň zachovalo architekturu transakcí, která vznikla na mainframe serveru. Změnil se hardware, návrh softwaru, datový model, sémantika transakcí, struktura PNR a zachovala architektonická rozhodnutí, která se po celá desetiletí osvědčila.

Nová správa nabídek a objednávek vedle staršího systému PNR. Standard IATA ONE Order, který nahrazuje záznamy založené na PNR moderním modelem správy objednávek, zavádějí letecké společnosti jako vrstvu vedle stávajícího systému založeného na PNR. Technologie Sabre nové generace Offer and Order, na které se odkazuje v obnově smlouvy s WestJet v roce 2026, to prezentují jako cestu vpřed, nikoli jako nahrazení PSS, ale jako přidání moderní komerční vrstvy, která se nakonec rozroste a zvládne rostoucí podíl rezervací, zatímco jádro PNR se postará o zbytek.

Co to znamená pro jakoukoli kriticky důležitou modernizaci starších systémů

Příběh rezervačních systémů pro letecké společnosti není specifický jen pro letectví. Je to nejviditelnější příklad vzorce, který se objevuje v základních bankovních systémech, správě pojistných smluv, fakturaci telekomunikací a zpracování vládních dávek: software, který se stává autoritativní specifikací obchodních pravidel, slouží jako integrační centrum pro desítky závislých systémů a pracuje s požadavky na rozsah a spolehlivost, které činí nahrazení velkým třeskem skutečně neproveditelným.

Ponaučení jsou jednotná napříč všemi odvětvími:

Extrakce obchodních pravidel z kódu před zahájením jakékoli modernizace není volitelná. Programy COBOL a TPF, které implementují konstrukci tarifů, logiku smluv o sdílení kódu a pravidla pro dodržování předpisů, jsou jedinou dochovanou dokumentací těchto pravidel. Modernizace, která nejprve neextrahuje a neověřuje tuto logiku, nemůže vytvořit náhradu, která se chová správně ve všech případech, protože nemůže znát všechny případy bez analýzy celého kódu.

Mapa závislostí určuje posloupnost migrace. Žádná letecká společnost úspěšně nenahradila svůj systém zabezpečení (PSS) tím, že by začala s nejdůležitější a nejvíce integrovanou komponentou. Každá úspěšná modernizace začala na okrajích sítě, v systémech hlášení, pomocných službách, nekritických administrativních funkcích, a postupně se směřovala dovnitř. Tato posloupnost je odvozena z grafu závislostí: komponenty s nejméně závislostmi na vstupu jsou nejbezpečnější pro řešení jako první.

Provozní validace v každém kroku je nedílnou součástí. Přístup dvojího validace, kdy se nový systém spustí paralelně se starým, porovnají se výstupy a ověří se ekvivalence před jakýmkoli přesunem provozu, je jediný přístup, který splňuje požadavky na spolehlivost systémů, kde selhání mají fyzické, finanční a regulační důsledky.

Jak SMART TS XL Platí pro analýzu starších systémů v blízkosti leteckých společností

Letecké společnosti, které provozují Sabre nebo Amadeus PSS spolu s vlastními programy v COBOLu, systémy pro výpočet sazeb, účetnictví tržeb, výpočet věrnostních bodů a regulační reporting, čelí přesně stejné analytické výzvě, které čelí každý program modernizace podnikových mainframů: pochopit, co kód skutečně obsahuje, než se rozhodne, co s ním udělá.

SMART TS XLJe statická analýza kódu extrahuje logiku obchodních pravidel zabudovanou v programech v COBOLu, pravidla pro ověřování tarifů, výpočty výnosů a logiku způsobilosti pro věrnostní programy, která neexistuje nikde jinde než v programovém kódu. Pro letecké společnosti, které plánují modernizovat sousední systémy bez zásahu do jádra PSS, tato extrakce vytváří specifikaci, které musí náhrada odpovídat.

Mapování závislostí aplikací vytváří graf závislostí, který určuje posloupnost migrace: které programy na straně leteckých společností závisí na kterých datových zdrojích z PSS, které reportovací programy závisí na kterých dávkových výstupech COBOLu a které následné systémy musí být aktualizovány při změně jakékoli komponenty. Graf závislostí umožňuje postupnou a bezpečnou modernizaci, stejný přístup, jaký Sabre a Amadeus použily pro základní systémy, aplikovaný na kód na straně leteckých společností, který je obklopuje.

Schopnost analýzy dopadů odpovídá na otázku, která předchází každému rozhodnutí o modernizaci: pokud se tento program změní, co dalšího bude ovlivněno? U systémů leteckých společností, kde změna výpočtu v programu pro účetnictví výnosů může současně ovlivnit regulační výkaznictví, vypořádání partnerů a finanční konsolidaci, je znalost rozsahu dopadu před provedením jakékoli změny předpokladem pro řízení změn, které splňuje požadavky letecké společnosti na spolehlivost.

Analýza modernizace starších programů poskytuje kompletní inventář před modernizací: každý program v rozsahu, jeho složitost, závislosti, procento mrtvého kódu a klasifikaci rizika migrace. Poučení z každého programu modernizace leteckých společností – začít na okrajích, postupovat dovnitř a ověřovat v každém kroku – vyžaduje znalost toho, kde se okraje nacházejí a jak vypadá struktura závislostí. Tato znalost pochází ze strukturální analýzy skutečného kódu, nikoli z dokumentace, která byla napsána předtím, než se z něj kód vyvinul.

Geologické vrstvy softwaru kritického významu

Když si v roce 2026 rezervujete let na chytrém telefonu, dotýkáte se softwaru s několika odlišnými geologickými vrstvami. Moderní rozhraní na povrchu. Vrstva API pod ní. Transakční engine PSS pod tím, běžící na infrastruktuře, která se od 1960. let podstatně změnila, ale zachovává transakční sémantiku a datové modely, které byly správné v době svého návrhu a ukázaly se jako příliš spolehlivé na to, aby se od nich dalo upustit.

Systém rezervací letenek není selháním modernizace. Je výsledkem šesti desetiletí racionálních rozhodnutí inženýrů a manažerů, kteří pokaždé, když byla navržena náhrada, chápali, že riziko chybného provedení převyšuje náklady na udržení fungujícího systému. Systémy, které přežívají tak dlouho, si to zaslouží, transakci za transakcí, let za letem, rezervační sezónu za rezervační sezónou.

Praktickým ponaučením pro jakýkoli modernizační tým není, že staré systémy by se nikdy neměly nahrazovat. Jde o to, že rozhodnutí o jejich nahrazení by mělo být učiněno s úplnou znalostí toho, co obsahují, co na nich závisí a jaký je skutečný rozsah změn, nikoli s optimistickými odhady učiněnými před změřením složitosti. Letecký průmysl se to naučil drahou cestou. Analytické nástroje, které produkují kompletní strukturální znalosti ještě před napsáním prvního řádku nového kódu, umožňují naučit se to levnější cestou.