Eliminace výpadků prostřednictvím aktualizací služby s verzí

Správci museli v minulosti převést server do offline režimu, aby mohli aktualizovat a upgradovat místní software. Výpadek je ale úplný nestartér pro globální služby 24×7. Mnoho moderních cloudových služeb je pro uživatele zásadní závislostí, aby mohli provozovat své firmy. Nikdy není vhodná doba k výpadku systému, takže jak může tým poskytovat nepřetržitou službu při instalaci důležitých aktualizací zabezpečení a funkcí?

Pomocí aktualizací s verzemi je možné tyto důležité služby bezproblémově převést z jedné verze na jinou , zatímco je zákazníci aktivně používají. Ne všechny aktualizace jsou těžké. Aktualizace rozložení nebo stylů front-endu je snadná. Změny funkcí můžou být složité, ale existují dobře známé postupy pro zmírnění rizik migrace. Změny, které pocházejí z datové vrstvy, však představují novou třídu problémů, které vyžadují zvláštní pozornost.

Aktualizace vrstev samostatně

S distribuovanou online službou v několika datacentrech a samostatným úložištěm dat se ne všechno může měnit současně. Pokud je typická služba rozdělená na kód aplikace a databáze, které jsou pravděpodobně nezávisle na sobě verze, musí jedna z těchto stran absorbovat složitost zpracování verzí.

Správa verzí je často jednodušší zpracovat v kódu aplikace. Větší systémy obvykle mají poměrně velký počet starších verzí kódu, například SQL, který se nachází ve svých databázích. Místo dalšího zdvojení tohoto SQL by kód aplikace měl zpracovávat složitost. Konkrétně můžete vytvořit sadu tříd továrny, které rozumí správě verzí SQL.

Během každého sprintu vytvořte nové rozhraní s danou verzí, takže vždy existuje kód, který odpovídá každé verzi databáze. Během nasazování můžete snadno vrátit všechny binární soubory. Pokud se po nasazení nových binárních souborů něco nepovede, vraťte se k předchozímu kódu. Pokud je binární nasazení úspěšné, spusťte údržbu databáze.

Jak to vlastně funguje? Předpokládejme například, že váš tým aktuálně nasazuje Sprint 123. Binární soubory rozumí schématu databáze Sprint 123 a rozumí schématu Sprint 122. Obecný model je pracovat s verzemi/sprinty N a N-1 schématu SQL. Binární soubory se dotazují na databázi, určete verzi schématu, se kterou komunikují, a pak načtěte příslušnou vazbu. Kód aplikace pak zpracovává případ, kdy nové schéma dat ještě není k dispozici. Jakmile bude nová verze dostupná, kód aplikace může začít využívat nové funkce, které jsou povolené nejnovější verzí databáze.

Roll forward only with the data tier

Po upgradu databází je služba v situaci, kdy dojde k problému, v postupné situaci. Online migrace databází jsou složité a často vícestupňové, takže postupný postup je obvykle nejlepším způsobem, jak problém vyřešit. Jinými slovy, pokud se upgrade nezdaří, vrácení zpět pravděpodobně selže i. Investice do úsilí o sestavení a otestování kódu vrácení zpět, který váš tým nikdy neočekává, že ho použije, je málo.

Pořadí nasazení

Představte si scénář, ve kterém potřebujete přidat sadu sloupců do databáze a transformovat některá data. Tento přechod musí být pro uživatele neviditelný, což znamená, že se vyhnete zámkům tabulek co nejvíce a pak je držíte na nejkratší dobu, aby nebyli nepochopení.

První věcí, kterou děláme, je manipulace s daty, pravděpodobně v paralelních tabulkách pomocí triggeru SQL, aby byla data synchronizovaná. Migrace a transformace velkých objemů dat někdy musí být vícekrokové přes několik nasazení napříč několika sprinty.

Jakmile se paralelně vytvoří další data nebo nové schéma, tým přejde do režimu nasazení pro kód aplikace. Když kód v režimu nasazení zavolá databázi, nejprve vezme zámek schématu a potom ho uvolní po spuštění uložené procedury. Databáze se nemůže změnit mezi dobou vydání volání databáze a spuštěním uložené procedury.

Kód upgradu funguje jako zapisovač schématu a požaduje zámek zapisovače schématu. Kód aplikace má přednost při zamknutí čtečky a kód upgradu se nachází na pozadí, který se pokouší získat zámek zapisovače. Pod zámkem zapisovače je v tabulkách povolený jen malý počet velmi rychlých operací. Pak se zámek uvolní a aplikace zaznamená novou verzi databáze, která se používá a používá rozhraní, které odpovídá nové verzi databáze.

Všechny upgrady databáze se provádějí pomocí modelu migrace. Sada kódu a skriptů se podívá na verzi databáze a pak provede přírůstkové změny migrace schématu ze starého na novou verzi. Všechny migrace se automatizují a nasadí prostřednictvím služby release management.

Webové uživatelské rozhraní musí být také aktualizováno bez narušení uživatelů. Při upgradu souborů JavaScriptu, šablon stylů nebo obrázků se vyhněte kombinování starých a nových verzí, které klient načítá. To může vést k chybám, které by mohly ztratit probíhající práci, například pole, které upravuje uživatel. Proto byste měli všechny soubory JavaScriptu, CSS a imagí používat tak, že všechny soubory přidružené k nasazení umístíte do samostatné složky s verzí. Když webové uživatelské rozhraní volá zpět do aplikační vrstvy, načtou se prostředky se zadanou verzí. Pouze když akce uživatele způsobí aktualizaci celé stránky, nové webové uživatelské rozhraní se načte do prohlížeče. Upgrade nenaruší prostředí uživatele.

Další kroky

Microsoft je jedním z největších světových společností pro vývoj softwaru po celá desetiletí. Zjistěte, jak Microsoft provozuje spolehlivé systémy s DevOps.