Lze aktualizovat web, aniž by byl nedostupný?

Mnoho aktualizací lze nasadit, aniž by stávající web přestal fungovat. Často je to možné u úprav obsahu a designu, nových stránek i pečlivě připravených softwarových verzí.

Neplatí to ale bez výjimky. Změna, která se týká živých objednávek, zákaznických účtů, nekompatibilních verzí softwaru, infrastruktury nebo externí služby, může vyžadovat vyhrazené servisní okno. Nejde jen o to, zda bude web dostupný. Důležité je, co zůstane funkční, jak změnu ověříme a co uděláme, pokud nebude fungovat podle očekávání.

Které aktualizace webu lze provést za provozu?

Opravy textů, výměny obrázků, nové články a stránky nebo samostatné vizuální úpravy lze často připravit a nasadit bez odstavení celého webu. Stejně lze někdy vydat i menší softwarové změny, pokud tomu web a postup nasazení odpovídají.

Samotný typ aktualizace odpověď neurčuje. Běžná úprava obsahu může na jednom webu ovlivnit nabídky, vyhledávání, stránky uložené v mezipaměti nebo generované soubory, zatímco jinde změní jedinou stránku. I známý úkol je třeba posoudit v kontextu systému, ve kterém se provádí.

Také výraz „online“ potřebuje praktický význam. To, že se úvodní stránka načte, ještě neznamená, že fungují poptávky, platby, přihlášení, vyhledávání nebo administrace. Samostatně je třeba ověřit ty části webu, na kterých firmě záleží.

Co chrání testovací web?

Testovací web je oddělené prostředí, ve kterém lze změnu připravit a zkontrolovat před zpřístupněním návštěvníkům. Pomáhá zabránit tomu, aby se při práci na veřejném webu objevilo nedokončené rozvržení, nehotový text nebo zjevná funkční chyba.

Testovací prostředí snižuje nejistotu, ale neodstraňuje ji. Může mít jiná data, návštěvnost, nastavení, přístupové údaje, napojené služby nebo serverové prostředky. Úspěšný test je užitečný důkaz, nikoli záruka, že se produkční web bude chovat stejně.

Plán nasazení proto musí určit, co se po změně na veřejném webu zkontroluje.

Jak nasadit novou verzi bez prázdné stránky?

Jednou z možností je připravit novou verzi odděleně, zatímco návštěvníky dál obsluhuje stávající verze. Provoz se přesměruje až po otestování připravené verze. Pokud se objeví závažný problém, lze provoz případně vrátit k předchozí verzi.

Tento postup se běžně označuje jako nasazení blue-green. AWS popisuje tuto metodu jako přesměrování provozu mezi dvěma prostředími s různými verzemi aplikace. Cílem je téměř nulová odstávka a rychlejší návrat k předchozímu prostředí.

Blue-green nasazení není jediný způsob aktualizace. Některé systémy atomicky vymění soubory, aktualizují vždy jeden server, pošlou na novou verzi jen část provozu nebo zapnou hotovou funkci až poté, co jsou připravené všechny její podpůrné části. Vhodný postup závisí na webu, hostingu, datech a důsledcích případného selhání.

Čím se liší změny databáze?

Databáze může obsahovat aktuální objednávky, účty, rezervace, formulářové zprávy, skladové zásoby, členství nebo publikovaný obsah. Během nasazení může být nutné, aby s těmito daty pracovaly stará i nová verze webu.

Pokud se struktura databáze změní tak, že jí rozumí jen jedna verze softwaru, návrat k předchozí verzi už nemusí být jednoduchý. Dlouhotrvající změny navíc mohou soupeřit o prostředky s běžným provozem webu. Některá nasazení proto oddělují přípravu databáze od aktualizace aplikace, po určitou dobu zachovávají kompatibilitu staré i nové struktury nebo přesouvají data v řízených dávkách.

Veřejné pokyny GitLabu k migracím databáze ukazují, jak podrobné může toto plánování být. Rozlišují běžné migrace, migrace po nasazení a migrace na pozadí a věnují se načasování, možnosti návratu, transakcím i soupeření o zámky. Přesné postupy se nehodí pro každý web, obecný princip je ale užitečný: změny živých dat potřebují vlastní plán nasazení a obnovy.

Je záloha totéž co návrat k předchozí verzi?

Ne. Záloha je uchovaná kopie dat nebo souborů, kterou lze obnovit. Návrat k předchozí verzi je připravený postup, jak po neúspěšném nasazení přejít do známého funkčního stavu.

Obnova zálohy může nějakou dobu trvat a může přepsat platné objednávky, poptávky, úpravy nebo změny účtů vzniklé po jejím vytvoření. Kód webu lze vrátit rychle, ale nemusí to zvrátit změnu databáze ani akci, kterou provedla externí platební, rezervační nebo e-mailová služba.

Odpovědný plán určí, co lze vrátit zpět, co je nutné opravit novou změnou a jak naložíme s daty vytvořenými během nasazení. Pokyny AWS pro neúspěšné změny doporučují připravit postup obnovy před nasazením a pomocí monitorování vyhodnotit, zda se změna povedla.

Proč se někomu po aktualizaci může stále zobrazovat stará stránka?

Web může zůstat dostupný po celou dobu aktualizace, ale různí návštěvníci mohou krátce dostávat různé verze stránky nebo souboru. Prohlížeče, sítě pro doručování obsahu, serverové mezipaměti a generované stránky mohou uchovávat předchozí obsah, dokud nevyprší jeho platnost, nebude znovu ověřen nebo záměrně odstraněn.

To se liší od odstávky. Přesto na tom záleží, pokud aktualizace mění ceny, podmínky, informace o kampani, dostupnost nebo jiné časově citlivé údaje.

I mazání mezipaměti má mít přiměřený rozsah. Cloudflare doporučuje, pokud je to možné, cílené mazání, protože vymazání celé mezipaměti vede k tomu, že následující požadavky zamíří přímo na původní server, dokud se obsah znovu neuloží. Plán nasazení by měl určit změněné stránky a soubory, ne považovat každou mezipaměť za jeden celek k odstranění.

Kdy je servisní okno odpovědnou volbou?

Servisní okno může být vhodné, pokud by plný provoz webu během aktualizace představoval větší riziko než krátké, předem oznámené přerušení. Může jít například o situace, kdy:

• živá data nelze během aktualizace bezpečně měnit;
• stará a nová verze nemohou pracovat se stejnou strukturou dat;
• infrastrukturu nebo síťové směrování je třeba změnit v jednom řízeném kroku;
• externí poskytovatel vyžaduje přerušení nebo nenabízí paralelní testovací cestu;
• současnému webu zatím nerozumíme natolik, abychom mohli bezpečně měnit systém za provozu;
• obnova by byla přehlednější a rychlejší, kdyby se činnost na vymezenou dobu pozastavila.

Okno má mít jasný důvod, rozsah, předpokládanou délku, rozhodnutí o obnově a komunikační plán. Pro firmu závislou na poptávkách, objednávkách, rezervacích nebo přístupu členů nestačí oznámit „web bude z důvodu údržby nedostupný“.

Na co se zeptat před schválením aktualizace?

• Které stránky a funkce se změní?
• Co budou návštěvníci a zaměstnanci moci během práce dál používat?
• Bude změna připravena mimo veřejný web?
• Jak budou chráněny poptávky, platby, rezervace, změny účtů a další živá data?
• Jaké kontroly potvrdí, že nasazení proběhlo úspěšně?
• Jaký je plán obnovy, pokud některá kontrola selže?
• Lze software vrátit, aniž bychom zrušili platná nová data?
• Ovlivní načasování hosting, platby, e-mail, identita, rezervace nebo jiné externí služby?
• Kdo rozhodne, zda pokračovat, opravit problém, nebo se vrátit?
• Jak a kdy budou informováni dotčení uživatelé?

Odpovědi nemusí popisovat každý technický příkaz. Měly by jasně vysvětlit dopad na firmu.

Jak k aktualizacím webů přistupuje LINK-V?

Když web posuzujeme nebo udržujeme, před rozhodnutím o nasazení kontrolujeme web, hosting, CMS, databázi, integrace, zálohy, přístupy a provozní rizika. Správný postup závisí na tom, co se mění, a na systému, který už je zavedený.

Chceme, aby běžné aktualizace probíhaly klidně a přiměřeně, a zároveň otevřeně řekneme, když změna vyžaduje řízené přerušení. Pokud váš web zajišťuje každodenní prodej, poptávky, rezervace, členství nebo publikování, můžeme posoudit jeho nastavení údržby a průběžné péče.