Spuštění webu

Na konci roku 2024 přešel obchod Today's Closeout z Volusion na BigCommerce. Takových replatformingů se dělají tisíce. Tady ale po přepnutí zůstalo přes 15 000 špatných přesměrování. Část URL končila na 404, část vedla jinam, některé adresy rozbila velikost písmen a celé kategorie zmizely bez náhrady. Tisíce produktových stránek z indexu prostě vypadly. Viditelnost v Googlu spadla skoro na nulu.

Na první pohled se přitom nic dramatického nestalo. Web šel otevřít, zákazník mohl nakoupit, nové prostředí běželo.

Proto je spuštění takový malý samostatný proces. Plán spuštění existuje proto, aby nikdo nemusel za pochodu vymýšlet, co ještě zbývá udělat.

Čtyři fáze

Spuštění není bod v čase, ale čtyři fáze. U menších webů je lze rozumně spojovat/přeskakovat, u větších je fakt dobrý nápad je dodržet.

Freeze zmrazí změny před přepnutím. Cutover je sada kroků, která přepne starý stav na nový. Go-live je rozhodnutí, že nový web může začít obsluhovat reálný provoz. Hypercare je časově omezené okno zvýšené podpory, než se provoz usadí.

Praktický rámec je osa T-minus / T-zero / T-plus. T-minus je příprava, freeze a generálka. T-zero je cutover a go/no-go. T-plus je hypercare a stabilizace.

T-minus: freeze a generálka

Cutover potřebuje jasný stav, co přenášíme. Pokud se během migrace mění zdroj i cíl, nejde nic porovnat a migrovali bychom donekonečna.

Proto existuje freeze window, okno zmrazení. Zastavíš změny na aktuálním webu a finální synchronizaci uděláš až po zmrazení. Občas to může znamenat krátkou odstávku celého webu/systému a nebo omezení funkcionality. Proto se často dělají migrace v noci. Je to cena za konzistentní data a kontrolovatelnou migraci.

Druhá věc v T-minus je generálka. Dry run (tedy pokus nanečisto) odhalí víc problémů než tři týdny plánování navíc. Zjistíš, že migrace databáze trvá dvakrát déle, než někdo slíbil. Že export může spustit jen člověk, který má v den D dovolenou.

Do T-minus patří i krok z DNS kapitoly: 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ě před přepnutím, řeší DNS kapitola. Plán jen hlídá, že se to stane včas.

Stejně tak připrav TLS. Certifikát pro novou doménu musí být vystavený a ověřený před přepnutím, ne až ve chvíli, kdy resolvery začnou vodit lidi na endpoint bez platného certifikátu. Detaily invalidace a vydání certifikátu patří k hostingu a CDN.

T-zero: go/no-go a cutover

Go-live nedělejme pocitově, je dobré mít odškrtnuté věci, které musí určitě fungovat. Umíme první den zpracovat transakce? Sedí data? Vědí lidé, co dělat? Umíme škálovat servery, kdyby výkon neodpovídal očekáváním?

Často se podceňuje debata na téma o čase, kdy migraci zastavíme. Vždycky se u větších migrací něco pokazí a vědět čas, po kterém se už nepokračuje, pokud jsme to nestihli je důležité. A k tomu jméno člověka, který rozhodne. V noci pod tlakem v emocích se tyhle věci vymýšlí blbě.

Samotný cutover je u statického webu jednoduché udělat bez výpadku, přes souběžný provoz. Starý i nový web jsou v chodu, synchronizujeme obsah, přepneme DNS a starý web vypneme až po doběhnutí propagace DNS. Typicky to bývá 1 až 24 hodin. Na starém serveru po přepnutí je u větších webů dobrý nápad přesměrovávat 301 na nové URL pro prohlížeče, kteří ještě drží v cache starý DNS záznam.

Souběžný provoz funguje u webu, statiky a obsahu, který umíš synchronizovat. Nehodí se tam, kde stav žije v jedné databázi a dvě aktivní místa by ti začala vyrábět konflikty. Takže například pokud máme sekvenční čísla objednávek, musíme v nějaký moment objednávky zastavit.

A změníme DNS.

V tuhle 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á.

A pak je tu banální chyba, kterou je dobrý nápad 2x zkontrolovat: na stage jsme měliDisallow: / nebo zděděný noindex. A zapomeneme to pro produkci změnit. Proto se robots a noindex kontrolují při spuštění přes URL Inspection.

T-plus: hypercare

Po go-live skoro nikdy nepřichází klid, přichází problémy.

Hypercare je časově ohraničené okno přísnější podpory, typicky jeden až osm týdnů. Běží na ostřejších SLA: kratší garantovaná odezva a rychlejší oprava než v běžném provozu. U velkých nebo kritických migrací to znamená první odezvu v řádu minut, třeba 15 místo čtyř hodin. U obsahového webu vaší velikosti je to spíš pár dní až týdnů, kdy se na web někdo aktivně dívá a opravuje v řádu hodin, ne dní.

Hypercare potřebuje jedno místo, kde se požadavky třídí. Jeden člověk třídí vše, jeden vstupní kanál pro hlášení. První dny mohou dávat smysl schůzky, kde se věci společně prochází. V čase by se věci měly rychle uklidňovat.

Pak přichází stabilizace. U většího systému prvních 60 až 90 dní dává smysl chránit základ: opravovat provozuschopnost, stabilitu rozhraní, správu dat, ale nové funkce moc nepřidávat. Základ si musí sednout a pokud pořád přidáváme funkcionality, můžeme být v hypercare módu velmi dlouho.

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.

Do T-plus patří ještě jedna jednoduchá věc: poznamenat spuštění v analytice. Skok nebo propad v grafu za půl roku nikdo nevysvětlí, pokud u daného data nestojí poznámka „tady jsme migrovali".

Tři typické záměny

• „Spuštění je okamžik." Ne. Jsou to fáze freeze, cutover, go-live a hypercare, každá s vlastníky a vlastním koncem. Go-live je rozhodnutí podle prahů, ne pocit.
• „Rollback vrátí všechno." Vrátí hlavně deploy artefakt. DNS naráží na TTL, odeslané e-maily a 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. Každé dočasné řešení potřebuje datum zrušení, jinak je z něj trvalý provozní režim.

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), u větších migrací ideálně dvě, první minimálně dva týdny předem.
• Okno zmrazení vytváří konzistentní snímek; finální synchronizace proběhne 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, hlavně 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í vlastníka a datum zrušení.

Zdroje

• enov8, Concentrus — plán cutoveru jako detailní plán úkolů s vlastníky a odhady, okno zmrazení, finální rozdíl po zmrazení, prahy pro rollback (pevný stop čas + práh chyby) a vlastník rozhodnutí před go-live.
• Umbrex (finance/ERP playbook) — cutover / go-live / hypercare / stabilizace jako čtyři fáze; go/no-go přes čtyři čočky připravenosti; rollback zřídka čistý; dvě zkoušky; řídicí místnost v hypercare, metriky, kritéria ukončení, správa dočasných řešení, ochrana jádra 60–90 dní.
• Google Search Central — Site move with URL changes: ověřit oba weby a varianty, serverové 301/308, odeslání sitemap, Change of Address, kontrola noindex a robots pravidel, přesměrování co nejdéle / obecně aspoň rok.
• Google Search Console Help — Change of Address tool: nástroj pracuje se 180denním oknem.
• MassiveGrid — migrace bez výpadku přes souběžný provoz, TTL 300 s, propagace 12–36 h, 301 na starém serveru pro cache.
• Helply — What Is Hypercare?: hypercare 1–8 týdnů (enterprise 12+), přísnější SLA (15 min vs. 4 h), ITIL ekvivalent Early Life Support.
• goinflow, reliably.com — sezonní code freeze v e-commerce vs. SRE pohled (ochranná pravidla místo plného zmrazení).
• Search Engine Journal — Today's Closeout (Volusion → BigCommerce, 15 000+ špatných přesměrování); ancient.eu → worldhistory.org (3M návštěv/měsíc, zotavení 3–12 měsíců).
• Numen Technology — agenturní odhad „9 z 10 migrací poškodí SEO, ~10 % zlepší".

Tady se sbíhá většina příručky do jednoho provedení. Redesign rozhodne, co se mění; tahle kapitola to vykoná. Mechanika TTL a ne-webových DNS záznamů, čištění cache u Cloudflare, připravenost TLS a invalidace na hostingu, neměnný artefakt a rollback z pipeline i URL Inspection a odeslání sitemap ze SEO žijí jinde a plán je jen poskládá. Spuštění se zároveň poznamená v analytice. Pak se režim mění na správu a údržbu, protože web není hotová věc.