Spuštění, migrace, DNS přepnutí a rollback

Na konci roku 2024 přešel obchod Today's Closeout z Volusion na BigCommerce. Replatforming, jakých se dělají tisíce. Jenže přesměrování byla udělaná špatně: přes 15 000 URL vedlo na 404 nebo na úplně jiný cíl, URL byly rozbité na velikosti písmen, celé kategorie někdo vypnul bez jediného přesměrování. Tisíce produktových stránek z indexu prostě zmizely. Viditelnost v Googlu spadla skoro na nulu.

Nikdo přitom nestiskl špatné tlačítko. Web po spuštění normálně fungoval, šel otevřít, dal se v něm nakoupit. Rozbila se vrstva, kterou v den D není vidět: přesměrování, sitemapa, signály pro vyhledávač. A to je celý smysl plánu spuštění. Spuštění není jeden okamžik, kdy něco „pustíš do světa". Je to koordinovaná operace. Rozbije přesně to, co se hned neprojeví, a proto se musí provést podle plánu, ne podle citu.

Tahle kapitola je plán spuštění. Předpokládá, že už víš, co se mění a jakou mapu přesměrování na to potřebuješ, že máš DNS s TTL pod kontrolou a že tě pipeline zásobuje neměnnými deployi. Tohle je o tom, jak ty dílky poskládat do jednoho provedení s vlastníky a hodinami na ose.

Čtyři fáze, ne jeden okamžik

První omyl je mluvit o spuštění jako o bodu v čase. Ve skutečnosti jsou to čtyři různé věci, každá s vlastními vlastníky a vlastním koncem.

Freeze je zmrazení změn před přepnutím. Cutover je sada koordinovaných akcí, která přepne ze starého na nové. Go-live je rozhodnutí, že umíme od prvního dne fungovat. A hypercare je časově ohraničené okno zvýšené podpory, než se provoz usadí. Splývají do jednoho slova jen v hlavě člověka, který spuštění nikdy neřídil.

Praktický rámec na to je osa T-minus / T-zero / T-plus. T-minus je příprava a freeze. T-zero je samotný cutover a go/no-go. T-plus je hypercare a stabilizace. Zbytek kapitoly se téhle osy drží.

T-minus: freeze a generálka

Cutover potřebuje konzistentní snímek. Pokud se během migrace dat mění zdroj i cíl, nikdy je neporovnáš a finální rozdíl ti uteče. Proto freeze window, okno zmrazení: zmrazíš změny na obou stranách a finální synchronizaci uděláš až po zmrazení. Snímek, ne pohyblivý cíl.

Tady se ozve námitka z agilního světa: code freeze je přežitek, lepší jsou ochranná pravidla. U průběžného provozu to sedí. SRE pohled je rozumný, plné zmrazení přes celé období nedává smysl, frontend bývá relativně bezpečný a stačí zpomalit backend a API. Ale jednorázový cutover je jiný případ. Úzké okno zmrazení tady není byrokracie, je to cena za konzistentní snímek dat. Sezonní e-commerce freeze (typicky měsíc před Thanksgivingem přes Black Friday) je něco úplně jiného. Plést si je dohromady se nevyplácí.

Druhá věc v T-minus je generálka. Dry run odhalí víc problémů než tři týdny plánování navíc. ERP playbooky žádají aspoň dvě plné zkoušky před ostrým cutoverem a první naplánuj minimálně dva týdny předem. Zkouška ti řekne, co skutečný plán zamlčel: že krok 7 trvá dvakrát dýl, že na export nikdo nemá přístup, že validaci nemá kdo odklepnout.

A do T-minus patří jeden krok z DNS kapitoly, který sem časově spadá: snížit TTL. Aspoň 48 hodin předem stáhni TTL na 300 sekund. Pak resolvery zachytí přepnutí během minut, ne hodin. Proč se to musí udělat dopředu a ne těsně, řeší DNS kapitola. Plán jen hlídá, že se to stane včas. Sem patří i připravenost TLS: certifikát pro novou doménu musí být vystavený a ověřený před přepnutím, ne až resolvery začnou vodit lidi na endpoint bez platného certifikátu. Detaily invalidace a vydání certifikátu žijí u hostingu a CDN.

T-zero: go/no-go a cutover

Go-live není pocit. Je to rozhodnutí na základě prahů, přes čtyři čočky: řešení, data, lidé, provoz. Umíme první den zpracovat transakce? Sedí data? Vědí lidé, co dělat? Drží provoz? Nikdy „pustíme to a uvidíme".

A co se nejvíc podceňuje. Prahy pro rollback se definují před go-live, ne během něj. Minimálně dva spouštěče. Pevný stop čas, po kterém se nepokračuje, pokud validace není hotová. A práh datové chyby, nad kterým se přepnutí odvolává. A k tomu jméno člověka, který to rozhodnutí udělá. Pod tlakem v noci nikdo prahy nevymýšlí, jen je vykonává.

Samotný cutover je pro statický web nejlepší bez výpadku, přes souběžný provoz. Drž oba weby v chodu, synchronizuj obsah, přepni DNS, a starý vyřaď až po doběhnutí propagace (typicky 12 až 36 hodin, výjimečně tři dny). Na starém serveru po přepnutí servíruj 301 na nové URL pro klienty, co ještě drží v cache starý DNS záznam. Ale pozor na hranici: souběžný provoz funguje u webu a statiky, ne tam, kde stav žije v jedné databázi, kterou nejde synchronně držet na dvou místech. Tam je okno zmrazení nevyhnutelné.

V tu chvíli se vykoná to, co redesign jen rozhodl: mapa přesměrování. Serverové 301, jedna stará URL na jednu odpovídající novou, ne všechno na úvodní stránku. SEO strana cutoveru má svoje pevné kroky z Google plánu pro přesun webu:

1. Ověř v Search Console oba weby a všechny varianty (HTTP i HTTPS, www i bez www).
2. Přepni interní odkazy a sitemapy na nové URL.
3. Nasaď server-side 301.
4. Odešli novou XML sitemapu a ve staré property spusť Change of Address.
5. Přes URL Inspection ověř, že nová URL je indexovatelná. Pozor, live test není totéž co stav v indexu.

Change of Address předává signály mezi doménami a jeho zpracování může Googlu trvat až 180 dní. Proto přesměrování drž aspoň 180 dní, klidně dýl, dokud chodí návštěvnost z vyhledávače. A nezapomeň na vyčištění cache: patří do plánu jako naplánovaný krok, ne jako reakce na to, že lidem servíruješ starou verzi.

Tady číhá ta nejbanálnější a nejsmrtelnější chyba: protáhnout ze stagingu Disallow: / nebo zděděný noindex. Jeden řádek deindexuje celý web. Proto se robots a noindex kontrolují při spuštění přes URL Inspection, ne až podle propadu návštěvnosti za tři týdny.

Rollback je přepnutí na starší stav, ne stroj času

Nejnebezpečnější věta v celém spuštění zní „kdyby něco, vrátíme se a je to". Není to pravda a stojí za to vědět proč.

Rollback deploye vrátí jen to, co bylo v artefaktu. To je rychlé a čisté, ale úzké. Spuštění přepíná víc věcí, než kolik se jich dá vzít zpět. DNS rollback naráží na TTL: staré záznamy žijí v cache, dokud nevyprší. Odeslané e-maily se neodešlou zpátky. A už předané SEO signály běží dál svým tempem. Change of Address, který se jednou rozjel, i nový index si jedou dál bez ohledu na to, že jsi přepnul zpátky.

Proto rollback v praxi skoro nikdy neznamená čistý návrat. Mnohem častěji znamená odložit go-live, prodloužit souběžný provoz, nebo spustit připravené záložní postupy. Což je přesně důvod, proč prahy a rozhodující osoba musí existovat před T-zero. Rollback není záchranná brzda, kterou zatáhneš kdykoli. Je to jedna z předem promyšlených variant.

T-plus: hypercare je most, ne dohra

Po go-live nepřichází klid, ale hypercare. Časově ohraničené okno přísnější podpory, typicky jeden až osm týdnů, u velkých migrací i přes dvanáct. Běží na ostřejších SLA, často 15 minut na první odezvu místo čtyř hodin. (V ITIL světě se tomu říká Early Life Support. Je to totéž.)

Hypercare má svou řídicí místnost, takzvanou war room. Vedoucí třídění a vedoucí pro funkční, technickou, datovou a komunikační stranu. Jeden vstupní kanál pro hlášení. Závažnost popsaná byznysovým jazykem, ne technickým žargonem. První dva týdny několik třídicích schůzek denně, pak jednou denně. Sleduješ pár metrik: objem hlášení, MTTR, stáří backlogu, chybovost jednotlivých rozhraní, objem manuálních zásahů.

Hypercare stojí na dvou věcech. Jednak končí podle kritérií ukončení, ne podle data v kalendáři. „Skončí to za měsíc" je přání, ne kritérium. A pak správa dočasných řešení. Každé dočasné řešení má vlastníka, dokumentaci a explicitní datum, kdy se zruší. Dočasné řešení bez data se stane trvalým, vždycky.

Pak přichází stabilizace. Prvních 60 až 90 dní platí „ochrana jádra". Priorita jsou opravy provozuschopnosti (správa dat, stabilita rozhraní, rekonciliace), nové funkce se odkládají, ať nerozhoušeš základ, který se právě usazuje. A tady se plán spuštění rozpouští do běžné správy a údržby. Hypercare je most z režimu spuštění do běžného provozu. Protože web není hotová věc, spuštěním nic nekončí, jen se mění režim péče.

Mimochodem, jeden krok do hypercare a stabilizace patří taky: poznamenat spuštění v analytice. Skok nebo propad v grafu za půl roku nikdo nevysvětlí, pokud u toho data nestojí poznámka „tady jsme migrovali". A spuštění je první distribuční moment, takže kalendář spuštění a sdílené podklady řeší marketing a distribuce, patří k cutoveru, ne až dlouho po něm.

„Statický web na spravovaném hostingu, žádný plán netřeba"

Pravda na půl. Deploy samotný plán nepotřebuje, atomické přepnutí i okamžitý rollback dostaneš zadarmo z pipeline. Ale spuštění není deploy.

Změna domény, provedení mapy přesměrování, ne-webové DNS záznamy, odeslání sitemap, Change of Address, vyčištění cache a hypercare, nic z toho není „merge do main". Plán se škáluje s velikostí migrace. Otázka „mít plán přepnutí?" se neškáluje, odpověď je vždycky ano. Jen u malého webu je plán kratší.

Co se stane, když se na to vykašleš, ukazují čísla. Agenturní analýza odhaduje, že 9 z 10 migrací SEO poškodí a jen asi 10 % zlepší. Ber to jako řád, ne zákon. Ale směr potvrzují konkrétní případy. ancient.eu po migraci na worldhistory.org, web s přes 3 miliony návštěv měsíčně, se podle reportů zotavoval 3 až 12 měsíců. Today's Closeout z úvodu téhle kapitoly skoro úplně zmizel z Googlu. To není „migraci zvládneme za večer". To je řízená operace, nebo riziko měřené v měsících návratu.

Tři typické záměny

• „Spuštění je okamžik." Jsou to čtyři fáze (freeze, cutover, go-live, hypercare), každá s vlastními vlastníky a vlastním koncem. Go-live je rozhodnutí na základě prahů, ne pocit.
• „Rollback vrátí všechno." Vrátí jen obsah artefaktu. DNS naráží na TTL, odeslané maily a předané SEO signály se nevrátí. Prahy a rozhodující osoba musí být dané před go-live.
• „Hypercare skončí za měsíc." Hypercare končí podle kritérií ukončení, ne podle kalendáře. A každé dočasné řešení potřebuje datum zrušení, jinak je trvalé.

Praktický checklist

• Existuje plán spuštění s vlastníky a časy na ose T-minus / T-zero / T-plus, ne jen seznam kroků.
• Proběhla aspoň jedna generálka (dry run), ideálně dvě, první minimálně dva týdny předem.
• Okno zmrazení vytváří konzistentní snímek; finální synchronizace je až po zmrazení obou stran.
• TTL je snížené na 300 s aspoň 48 hodin předem; TLS certifikát pro novou doménu je vystavený a ověřený před přepnutím.
• Prahy pro rollback (pevný stop čas a práh datové chyby) i rozhodující osoba jsou definované před go-live.
• Mapa přesměrování, sitemapa, Change of Address, ověření obou webů v Search Console a kontrola robots/noindex přes URL Inspection jsou součástí cutoveru.
• Vyčištění cache je naplánovaný krok plánu, ne reakce na incident.
• Hypercare má řídicí místnost, jeden vstupní kanál, denní metriky a kritéria ukončení; dočasná řešení mají datum zrušení.