Sdílet prostřednictvím

Strategie architektury pro postupy bezpečného nasazení

Platí pro toto doporučení kontrolního seznamu provozní efektivity architektury Azure Well-Architected Framework:

OE:11 Jasně definujte postupy bezpečného nasazení vaší úlohy. Zdůrazněte ideály malých, přírůstkových a na kvalitu zaměřených způsobů vydání. K řízení rizik používejte moderní vzory nasazení a progresivní techniky expozice. Zvažte rutinní nasazení a nouzová nasazení nebo opravu hotfix.

Tato příručka popisuje doporučení pro používání postupů bezpečného nasazení (SDP). Procesy a postupy bezpečného nasazení definují, jak bezpečně provádět a nasazovat změny vašich úloh. Implementace protokolu SDP vyžaduje, abyste se nad nasazeními zamysleli prostřednictvím správy rizik. Můžete minimalizovat riziko lidské chyby ve vašich nasazeních a omezit účinky problematických nasazení na uživatele implementací protokolu SDP.

Při implementaci postupů bezpečného nasazení je potřeba mít na paměti čtyři důležité pokyny:

  • Bezpečnost a konzistence: Všechny změny produkční úlohy jsou ze své podstaty rizikové a musí být provedeny se zaměřením na bezpečnost a konzistenci.

  • Progresivní expozice: Můžete minimalizovat potenciální dopad problémů způsobených nasazením tím, že přijmete model progresivního nasazování.

  • Modely stavu: Nasazení musí před zahájením každé fáze progresivní expozice projít kontrolami stavu.

  • Detekce problémů: Při zjištění problémů by se mělo nasazení okamžitě zastavit a zahájit obnovení.

V následujících částech najdete podrobná doporučení pro každý z těchto bodů.

Zajištění bezpečnosti a konzistence nasazení

Ať už nasazujete aktualizaci do kódu aplikace, infrastruktury jako kódu (IaC), příznaku funkce nebo aktualizace konfigurace, představujete riziko pro pracovní zátěž. Neexistují žádná nasazení s nízkým rizikem do produkčního prostředí. Každé nasazení musí dodržovat standardní vzor a mělo by být automatizované, aby bylo možné vynutit konzistenci a minimalizovat riziko lidské chyby. Je důležité, aby váš dodavatelský řetězec úloh a nasazovací pipeline byly spolehlivé a zabezpečené a aby existovaly jasně definované standardy nasazení. Zacházejte s každým nasazením jako s možným rizikem a zacházejte s každým nasazením na stejnou úroveň správy rizik. Navzdory rizikům byste měli i nadále nasazovat pravidelné změny úloh. Nepodařené nasazení pravidelných aktualizací představuje další rizika, například bezpečnostní chyby, které je nutné řešit nasazením. Další informace najdete v tématu Doporučení pro návrh dodavatelského řetězce vývoje úloh.

Časté malé nasazení je vhodnější než zřídkakdy velká nasazení. Malé změny se snadněji vyřeší, když dojde k problémům, a časté nasazování pomáhá vašemu týmu získat důvěru v proces nasazení. Je také důležité, abyste se z provozu poučili analýzou procesů pracovní zátěže, když během nasazování narazíte na anomálii. V návrhu infrastruktury nebo zavedení můžete najít slabá místa. Pokud během nasazení dojde k problémům, ujistěte se, že součástí procesu SDP jsou bezobvižné postmortemy, abyste zachytili poznatky o incidentu.

Přechod na model progresivní expozice

Pokud dojde k problémům s nasazením, cílem je co nejdříve je zachytit, aby se minimalizoval dopad na koncové uživatele. Pro dosažení tohoto cíle implementujte model postupného zavedení, označovaný také jako model progresivní expozice. Kanárková nasazení jsou běžným příkladem postupného nasazení. V tomto modelu nasazení obdrží jako první novou funkci malá skupina interních nebo externích uživatelů. Jakmile první skupina spustí novou verzi bez problému, funkce se nasadí do postupně větších skupin, dokud nebude nová verze spuštěna celá populace uživatelů. Funkční vlajky se obvykle používají k povolení nové verze pro cílové uživatele v kanárových nasazeních.

Dalším běžným modelem nasazení je modrý-zelený přístup. V tomto modelu se nasadí dvě identické sady nebo fondy infrastruktury pracovních zátěží. Oba pooly dokážou zpracovat úplné produkční zatížení. První (modrý) bazén spouští aktuální verzi nasazení, ve které přistanou všichni uživatelé. Druhý (zelený) pool je aktualizován novou funkcí a interně testován. Po interním testování je část produkčního provozu směrována z modrého fondu do zeleného fondu. Stejně jako nasazení ve stylu kanárka je zavádění progresivní, protože přesouváte větší objem provozu do zeleného fondu v postupně větších vlnách. Po dokončení zavedení se fond aktualizací stane modrým fondem a zelený fond je připravený pro další nasazení. Oba oddíly jsou logicky odděleny, aby byly chráněny před poruchami. Variantu modrozeleného modelu můžete nasadit v úloze, která používá návrhový vzor Deployment Stamps, nasazením vždy na jedno razítko.

V obou těchto modelech by měl být čas mezi jednotlivými fázemi zavedení dostatečně dlouhý, abyste mohli monitorovat metriky stavu úlohy. Měli byste poskytnout dostatek doby na stabilizaci, čas mezi jednotlivými skupinami zavádění, abyste zajistili, že uživatelé z různých oblastí nebo uživatelé, kteří provádějí různé úlohy, mají čas použít zatížení v jejich normální kapacitě. Časy pečení by se měly měřit v hodinách a dnech, nikoli minutách. Doby nasazení by se také měly pro každou skupinu nasazení zvýšit, aby se zohlednila různá časová pásma a vzory využití v průběhu dne.

Příležitost umělé inteligence: Ruční ladění nasazení vytváří překážky a zpomaluje nasazení. AI zrychluje zavádění a snižuje incidenty nahrazením subjektivního rozhodování doporučeními řízenými daty.

Začněte s přístupem GenAI s nízkou až střední úrovní. Udělte modelům zabezpečený přístup k dokumentaci k nasazení, kontrolám kódu a historii incidentů, abyste mohli analyzovat a navrhovat strategie a parametry zavedení.

Pokročilá agentská řešení můžou předpovědět procenta kanárů, časování zavedení a cílové segmenty. Když jsou integrované s nástroji pro nasazení, automaticky aktualizují konfigurace zavedení. Tato řešení vyžadují hlubší integraci, řízení přístupu k zápisu a podporu platformy.

Vlastní prediktivní modely nabízejí vyšší přesnost, ale potřebují značné investice do trénovací infrastruktury a odborných znalostí ML. Pro většinu týmů nemusí být praktické.

Vývoj robustních modelů stavu úloh

Vytvořte robustní model stavu jako součást strategie pozorovatelnosti a spolehlivosti. Váš model stavu by měl poskytovat podrobný přehled o komponentách a celkovém stavu úlohy. Pokud během zavádění obdržíte upozornění na změnu stavu týkající se koncového uživatele, mělo by se zavedení okamžitě zastavit a provést šetření příčiny výstrahy, aby bylo možné určit další průběh akce. Pokud koncoví uživatelé neoznamují žádné problémy a všechny indikátory stavu zůstanou po celou dobu pečení zelené, mělo by zavedení pokračovat. Nezapomeňte do modelu stavu zahrnout metriky využití, abyste zajistili, že absence problémů hlášených uživateli a negativních signálů stavu nezastírá žádný problém. Další informace naleznete v tématu Sestavení modelu stavu.

Implementace mechanismů detekce selhání

Pokud vaše nasazení způsobí problém v některé ze skupin zavedení, musí se zavedení okamžitě zastavit. Šetření příčiny problému a závažnost účinků se musí provést ihned po přijetí výstrahy. Obnovení z problému může zahrnovat:

  • Vrácení nasazení zpět tím, že se zruší změny provedené v nasazení a návrat k poslední známé funkční konfiguraci.

  • Vyřešte problém uprostřed zavádění. Během zavádění můžete problémy řešit použitím opravy hotfix nebo jinými způsoby minimalizovat problém.

  • Nasazení nové infrastruktury pomocí poslední známé pracovní konfigurace

Vrácení změn zpět, zejména změn databáze, schématu nebo jiných stavových změn součástí, může být složité. Pokyny pro SDP by měly poskytovat jasné pokyny, jak řešit změny dat v závislosti na návrhu datových aktiv pro vaši úlohu. Podobně je nutné postupovat opatrně při dalším vývoji, aby se zajistilo, že se protokol SDP nezanedbává a opravy hotfix či další minimalizační úsilí jsou prováděny bezpečně.

Vytvoření protokolů pro tísňová nasazení

  • Implementujte správu verzí napříč artefakty sestavení, abyste měli jistotu, že se v případě potřeby můžete vrátit zpět a pokračovat dopředu.

  • Použijte tok vydávání verzí nebo strukturu větvení na základě kmenů, která vynucuje úzce synchronizovanou spolupráci napříč vývojovým týmem místo struktury větvení založené na Gitflowu nebo prostředí.

  • Automatizujte co nejvíce vašeho SDP. Podrobné pokyny k automatizaci procesů kontinuální integrace a průběžného doručování aplikací (CI/CD) a IaC najdete v tématu Doporučení pro implementaci automatizace.

  • Používejte postupy CI k pravidelné integraci změn kódu do úložišť. Postupy CI vám můžou pomoct identifikovat konflikty integrace a snížit pravděpodobnost velkých a rizikových sloučení. Další informace najdete v průvodci kontinuální integrací.

  • Pomocí příznaků funkcí můžete selektivně povolit nebo zakázat nové funkce nebo změny v produkčním prostředí. Příznaky funkcí vám můžou pomoct řídit vystavení nového kódu a rychle vrátit zpět nasazení, pokud dojde k problémům.

  • Nasaďte změny do přípravných prostředí, která zrcadlí vaše produkční prostředí. Praktická prostředí umožňují otestovat změny v řízeném nastavení před nasazením do živého prostředí.

  • Vytvořte kontroly předběžného nasazení, včetně kontroly kódu, kontrol zabezpečení a kontrol dodržování předpisů, které vám pomůžou zajistit bezpečné nasazení změn.

  • Implementujte jističe, které automaticky zastaví provoz do služby, u které dochází k problémům. To může pomoct předejít dalšímu snížení výkonu systému.

Nouzové protokoly SDP

Vytvořte preskriptivní protokoly, které definují, jak lze protokol SDP upravit pro opravu hotfix nebo pro nouzové problémy, jako je porušení zabezpečení nebo ohrožení zabezpečení. Například vaše protokoly SDP pro tísňové volání můžou zahrnovat:

  • Akcelerace fáze povýšení a schválení

  • Orientační testování a zrychlení integračního testování

  • Zkrácení doby pečení.

V některých případech může nouzový stav omezit kvalitu a testovací brány, ale brány by měly být stále spuštěny co nejrychleji jako mimořádné opatření. Ujistěte se, že definujete, kdo může schválit akceleraci protokolu SDP v nouzovém stavu, a kritéria, která musí být splněna pro schválení akcelerace. Srovnejte protokoly SDP tísňového volání s plánem reakce na tísňové volání, abyste zajistili, že se všechny mimořádné situace zpracovávají podle stejných protokolů.

Naplánovat a provést bezpečné vyřazení z provozu

Odebrání nebo vyřazení komponenty je jednou z nejvyšších rizikových změn, které můžete provést. Po odstranění je prostředek často pryč a obnovení může být obtížné. I něco, co se zdá být nečinné nebo nevýznamné, může stále podporovat kritickou skrytou závislost. Zacházet s každým odstraněním jako s nevratným přístupem a postupovat podle záměrného, bezpečnostního přístupu, například:

  • Ověřte nečinnost. Ověřte, že se prostředek skutečně nepoužívá. Definujte jasné indikátory nečinnosti v celém uživatelském nebo obchodním cyklu. Pokud se zobrazí nějaká aktivita, jako jsou požadavky, dosažení tras, změny hloubky fronty, vyhodnocení příznaků funkcí nebo dotazy DNS, prošetření a potvrzení, že je před pokračováním legitimní.

  • Zachovat stav před odebráním Pořiďte snímek, export nebo zálohu prostředku a označte ho datem odstranění nebo datumem kontroly.

  • Před odstraněním zakažte. Pokud je to možné, přesuňte komponentu do zakázaného nebo offline režimu místo okamžitého odstranění. To pomáhá bezpečně odhalit skryté závislosti. Tento krok přeskočte pouze v případě, že požadavky na dodržování předpisů nebo požadavky na zabezpečení vyžadují okamžité odebrání.

  • Sledujte sledovací okno. Podívejte se na sledovací okno, které pokrývá běžné a špičkové vzorce používání. Jakákoli neočekávaná aktivita během tohoto období by měla resetovat proces vyřazení z provozu.

  • Vyčistěte reziduální odkazy. Jakmile si budete jisti, že je systém plně nečinný, vyčistěte veškeré související odkazy k odstraněné komponentě.

Úvahy

Vytváření a udržování postupů bezpečného nasazení je složité. Váš úspěch při plném implementaci robustních standardů závisí na vyspělosti vašich postupů v mnoha oblastech vývoje softwaru. Použití automatizace, pouze IaC pro změny infrastruktury, konzistence ve strategiích větvení, použití příznaků funkcionalit a mnoho dalších postupů může pomoci zajistit bezpečné nasazení. Tento průvodce vám pomůže optimalizovat úlohy a informovat vaše plány o vylepšení při vývoji vašich postupů.

Usnadnění Azure

  • Azure Pipelines a GitHub Actions podporují vícefázová nasazení pomocí schvalovacích bran, které vám můžou pomoct při návrhu postupného zavedení expozice pro nasazení.

  • Pomocí přípravných slotů služby Aplikace Azure můžete snadno přepínat mezi verzemi kódu. Přípravné sloty jsou užitečné pro testování v přípravných prostředích a je možné je použít pro nasazení s modrou zelenou barvou.

  • Ukládejte a spravujte příznaky funkcí webové aplikace v konfiguraci Aplikace Azure. Pomocí této služby můžete vytvářet, měnit a nasazovat funkce v jednotné rovině správy.

  • Nasaďte aplikace úloh ve virtuálním počítači pomocí aplikací virtuálních počítačů.

  • Pomocí nástrojů pro vyrovnávání zatížení Azure implementujte strategie nasazení a zpřístupněte stav aplikací úloh pomocí nativních prostředků.

  • Pomocí Application Health extension můžete hlásit stav aplikace z instance škálovací sady virtuálních počítačů. Rozšíření testuje místní koncový bod aplikace a aktualizuje stav na základě odpovědí TCP/HTTP(S) přijatých z aplikace.

  • Pomocí Azure Logic Apps můžete vytvořit novou verzi aplikace při každé aktualizaci. Azure udržuje historii verzí aplikací a může se vrátit k jakékoli předchozí verzi nebo ji zvýšit.

  • Mnoho služeb Azure Database poskytuje funkci obnovení k určitému bodu v čase, která vám může pomoci provést návrat do předchozího stavu. Mezi služby, které podporují obnovení k určitému bodu v čase, patří:

Příklad

Podívejte se na průvodce architekturou pro modře zelené nasazení klastrů Azure Kubernetes Service (AKS) jako příklad, jak použít tento model nasazení.

Kontrolní seznam pro efektivitu provozu

Projděte si kompletní sadu doporučení.

Kontrolní seznam pro efektivitu provozu

  • Last updated on