Dá sa aktualizovať web bez jeho odstávky?

Mnohé aktualizácie možno nasadiť tak, aby existujúci web zostal dostupný. Často je to reálne pri zmenách obsahu a dizajnu, nových stránkach aj pri dôkladne pripravených softvérových vydaniach.

Nie je to však sľub, ktorý platí pri každej zmene. Úprava, ktorá sa týka aktuálnych objednávok, zákazníckych účtov, nekompatibilných verzií softvéru, infraštruktúry alebo externej služby, môže vyžadovať určené servisné okno. Užitočná otázka neznie iba, či bude web online. Dôležité je, čo zostane dostupné, ako zmenu skontrolujeme a čo urobíme, ak nebude fungovať podľa očakávania.

Ktoré aktualizácie webu možno urobiť počas prevádzky?

Opravy textov, výmena obrázkov, nové články a stránky či samostatné vizuálne zmeny sa často dajú pripraviť a nasadiť bez odstavenia celého webu. Podobne možno niekedy vydať aj menšie softvérové zmeny, ak to web a proces nasadzovania umožňujú.

Samotný druh aktualizácie odpoveď neurčuje. Bežná úprava obsahu môže na jednom webe ovplyvniť ponuky, vyhľadávanie, stránky uložené vo vyrovnávacej pamäti alebo generované súbory, zatiaľ čo na inom zmení iba jednu stránku. Aj známu úlohu treba posudzovať v kontexte systému, v ktorom sa vykonáva.

Aj pojem „online“ potrebuje praktický význam. To, že sa úvodná stránka úspešne načíta, ešte nedokazuje, že fungujú dopyty, platby, prihlasovanie, vyhľadávanie alebo administrácia. Časti webu, ktoré sú pre firmu dôležité, potrebujú vlastné kontroly.

Čo chráni testovací web?

Testovací web je samostatné prostredie, v ktorom možno zmenu pripraviť a skontrolovať skôr, než sa dostane k návštevníkom. Pomáha zabrániť tomu, aby sa počas práce na verejnom webe zobrazilo nedokončené rozloženie, nehotový text alebo zjavná funkčná chyba.

Testovacie prostredie znižuje neistotu, no neodstraňuje ju. Môže obsahovať iné dáta, návštevnosť, nastavenia, prihlasovacie údaje, pripojené služby alebo serverové zdroje. Úspešný test je užitočný dôkaz, nie záruka, že sa produkcia bude správať rovnako.

Plán nasadenia musí určiť aj to, čo treba skontrolovať po zmene na verejnom webe.

Ako nahradiť starú verziu novou bez prázdnej stránky?

Jednou z možností je pripraviť novú verziu samostatne, zatiaľ čo návštevníkov obsluhuje existujúca verzia. Prevádzka sa presmeruje až po otestovaní pripravenej verzie. Ak sa objaví vážny problém, prevádzku možno vrátiť k predchádzajúcej verzii.

Tento postup sa bežne nazýva nasadenie blue-green. AWS opisuje túto metódu ako presúvanie prevádzky medzi dvoma prostrediami s rôznymi verziami aplikácie. Cieľom je takmer nulový výpadok a rýchlejšia cesta späť k predchádzajúcemu prostrediu.

Blue-green nasadenie nie je jediný spôsob aktualizácie. Niektoré systémy atomicky vymenia súbory, aktualizujú vždy jeden server, nasmerujú na novú verziu iba časť prevádzky alebo zapnú hotovú funkciu až po dokončení jej podporných častí. Vhodná metóda závisí od webu, hostingu, dát a následkov prípadného zlyhania.

Prečo sú zmeny databázy iné?

Databáza môže obsahovať aktuálne objednávky, účty, rezervácie, správy z formulárov, skladové zásoby, členstvá alebo zverejnený obsah. Počas nasadzovania môže byť potrebné, aby s týmito dátami pracovala stará aj nová verzia webu.

Ak sa štruktúra databázy zmení tak, že jej rozumie iba jedna verzia softvéru, návrat k predchádzajúcej verzii už nemusí byť jednoduchý. Dlhšie trvajúce zmeny môžu tiež súperiť s bežnou aktivitou webu o zdroje. Niektoré nasadenia preto oddeľujú prípravu databázy od aktualizácie aplikácie, určitý čas zachovávajú kompatibilitu starých a nových štruktúr alebo presúvajú dáta v riadených dávkach.

Verejné pokyny GitLabu na migráciu databázy ukazujú, aké podrobné môže byť toto plánovanie. Rozlišujú bežné migrácie, migrácie po nasadení a migrácie na pozadí a venujú sa načasovaniu, možnosti návratu, transakciám aj súpereniu o zámky. Presné postupy sa nehodia pre každý web, no všeobecný princíp je užitočný: zmeny živých dát potrebujú vlastný plán nasadenia a obnovy.

Je záloha to isté ako návrat k predchádzajúcej verzii?

Nie. Záloha je uchovaná kópia dát alebo súborov, ktorú možno obnoviť. Návrat k predchádzajúcej verzii je pripravený spôsob, ako sa po neúspešnom nasadení vrátiť do známeho funkčného stavu.

Obnovenie zálohy môže chvíľu trvať a môže prepísať platné objednávky, dopyty, úpravy alebo zmeny účtov vytvorené po jej zhotovení. Kód webu možno vrátiť rýchlo, ale nemusí to zvrátiť zmenu databázy ani úkon dokončený externou platobnou, rezervačnou alebo e-mailovou službou.

Zodpovedný plán určí, čo možno vrátiť späť, čo treba opraviť ďalšou zmenou a ako sa naloží s dátami vytvorenými počas nasadzovania. Pokyny AWS pre neúspešné zmeny odporúčajú pripraviť kroky obnovy pred nasadením a pomocou monitorovania rozhodnúť, či zmena uspela.

Prečo sa niekomu po aktualizácii stále zobrazuje stará stránka?

Web môže zostať dostupný počas celej aktualizácie, no rôzni návštevníci môžu krátko dostávať rôzne verzie stránky alebo súboru. Prehliadače, siete na doručovanie obsahu, serverové vyrovnávacie pamäte a generované stránky môžu uchovávať starší obsah, kým nevyprší jeho platnosť, znova sa neoverí alebo sa cielene nevymaže.

To sa líši od výpadku. Stále na tom záleží, ak aktualizácia mení ceny, podmienky, informácie o kampani, dostupnosť alebo iné časovo citlivé údaje.

Aj čistenie vyrovnávacej pamäte má mať primeraný rozsah. Cloudflare odporúča podľa možností cielené mazanie, pretože vymazanie celej vyrovnávacej pamäte spôsobí, že ďalšie požiadavky pôjdu priamo na pôvodný server, kým sa obsah znova neuloží. Plán nasadenia má určiť zmenené stránky a súbory, namiesto toho, aby považoval každú vyrovnávaciu pamäť za jeden blok na vymazanie.

Kedy je servisné okno zodpovednou voľbou?

Servisné okno môže byť vhodné, keď by plná prevádzka webu počas aktualizácie predstavovala väčšie riziko než krátke, vopred oznámené prerušenie. Môže ísť napríklad o situácie, keď:

• živé dáta sa počas aktualizácie nedajú bezpečne meniť;
• stará a nová verzia nedokážu pracovať s rovnakou štruktúrou dát;
• infraštruktúru alebo smerovanie siete treba zmeniť v jednom riadenom kroku;
• externý poskytovateľ vyžaduje prerušenie alebo neponúka súbežnú testovaciu možnosť;
• aktuálnemu webu zatiaľ dostatočne nerozumieme na bezpečnú zmenu počas prevádzky;
• obnova by bola jasnejšia a rýchlejšia, keby sa aktivita na určený čas pozastavila.

Okno má mať dôvod, rozsah, očakávané trvanie, rozhodnutie o obnove a komunikačný plán. Pre firmu závislú od dopytov, objednávok, rezervácií alebo prístupu členov nestačí oznámenie „web bude z dôvodu údržby nedostupný“.

Na čo sa opýtať pred schválením aktualizácie?

• Ktoré stránky a funkcie sa zmenia?
• Čo budú môcť návštevníci a zamestnanci počas práce naďalej používať?
• Bude zmena pripravená mimo verejného webu?
• Ako budú chránené dopyty, platby, rezervácie, zmeny účtov a ďalšie živé dáta?
• Ktoré kontroly potvrdia úspešné nasadenie?
• Aký je plán obnovy, ak niektorá kontrola zlyhá?
• Dá sa softvér vrátiť bez straty platných nových dát?
• Ovplyvní načasovanie hosting, platby, e-mail, identita, rezervácie alebo iné externé služby?
• Kto rozhodne, či pokračovať, opraviť problém alebo sa vrátiť späť?
• Ako a kedy budú dotknutí používatelia informovaní?

Odpovede nemusia opisovať každý technický príkaz. Mali by jasne vysvetliť vplyv na firmu.

Ako pristupuje LINK-V k aktualizáciám webov?

Keď web posudzujeme alebo udržiavame, pred rozhodnutím o nasadení preveríme web, hosting, CMS, databázu, integrácie, zálohy, prístupy a prevádzkové riziká. Správny postup závisí od toho, čo sa mení, a od systému, ktorý už funguje.

Naším cieľom je, aby bežné aktualizácie prebiehali pokojne a primerane, a zároveň otvorene povieme, keď si zmena vyžaduje riadené prerušenie. Ak váš web podporuje každodenný predaj, dopyty, rezervácie, členstvá alebo publikovanie, môžeme posúdiť jeho nastavenie údržby a priebežnej starostlivosti.