Strategie architektury pro návrh dodavatelského řetězce vývoje úloh

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

OE:06 Sestavte a optimalizujte dodavatelský řetězec úloh s předvídatelnými automatizovanými kanály, které testují a propagují změny napříč prostředími. Navrhněte tyto kanály tak, aby konzistentně splňovaly vaše cíle pro spolehlivost, zabezpečení, nákladovou efektivitu a výkon.

Pokud chcete poskytovat předvídatelný standardizovaný způsob údržby úloh, navrhněte dodavatelský řetězec vývoje úloh kolem kontinuální integrace a průběžného doručování (CI/CD). Udržujte jeden standardizovaný dodavatelský řetězec a implementujte ho pomocí automatizovaných kanálů CI/CD; Můžete použít více kanálů, pokud všechny dodržují stejný dodavatelský řetězec.

K ochraně úloh před riziky nespravovaných změn použijte standardizovaný dodavatelský řetězec. Udržujte nepřetržitý přehled o stavu úloh, abyste se vyhnuli nepředvídatelnému chování a nákladnému odčítání nesledovaných změn při vzniku problémů. Pokud chcete tato rizika minimalizovat, standardizujte procesy a nástroje, které definují váš dodavatelský řetězec, a ujistěte se, že se váš tým úloh plně zavazuje k jejich použití.

Definice

Pojem definice
Dodavatelský řetězec V cloudových úlohách je dodavatelský řetězec standardizovanou sadou nástrojů a procesů, které používáte k ovlivnění změn infrastruktury a aplikací v různých prostředích.

Poznámka:

Doporučení v této příručce se vztahují na prostředí zatížení v řetězci propagace kódu. Sandbox nebo jiná průzkumná prostředí a prostředí pro testování konceptu vyžadují méně rigorii a strukturu.

Následující doporučení vám můžou pomoct definovat základní principy dodavatelského řetězce.

Vynucení striktních zásad automatizovaných nasazení založených na šablonách

Proveďte všechny navrhované změny úloh prostřednictvím procesů a nástrojů dodavatelského řetězce a vynucujte automatizovaná nasazení založená na šablonách. Tento přístup udržuje konfigurace standardizované, dobře definované a úzce řízené napříč prostředími. V případě prostředí v řetězu povýšení kódu zakažte ruční aktualizace nebo přímou interakci s rovinou řízení cloudu, jako je portál nebo rozhraní API. Začleňte všechny změny do prostředí prostřednictvím potrubí, které se řídí vašimi definovanými postupy nasazení. Pokud chcete tuto zásadu vynutit, omezte přístup jen pro čtení a pomocí autorizačních bran udělte přístup k zápisu v případě potřeby. 

Důležitým aspektem tohoto principu je, že všechna změny jsou považovány za navržené, dokud nejsou nasazeny do produkčního prostředí. Prostřednictvím automatizovaného testování, jako je integrace a orientační testování, umožníte dodavatelskému řetězci automaticky odmítnout změny.

Možnosti AI: Ruční diagnostika problémů při nasazení zpomaluje týmy, způsobuje frustraci a vytváří izolaci znalostí. Zvyšte produktivitu a odolnost tím, že nejprve vyhodnocujeme nástroje DevOps, které nabízejí analýzu selhání s asistencí umělé inteligence. Pokud chcete tyto možnosti rozšířit, vrstvte do existující sady nástrojů vlastního agenta, abyste identifikovali a vyřešili běžné problémy. V případě pokročilých scénářů zvažte agentské řešení, které monitoruje telemetrická data kanálu a historická data incidentů, aby detekovala vzorce opakovaného selhání a doporučila proaktivní nápravy.

Nasazení opakovatelné a neměnné infrastruktury jako kódu

Nasaďte opakovatelnou neměnnou infrastrukturu pomocí infrastruktury jako kódu (IaC). Spravujte infrastrukturu jako deklarativní definice s řízením verzí, které odrážejí zdroj aplikace. Použití stejného IaC konzistentně vytváří stejné prostředí pokaždé, stejně jako stejný zdrojový kód vytvoří stejný binární soubor při kompilaci. 

Pokud chcete standardizovat a automatizovat nasazení a konfiguraci infrastruktury, přijměte infrastrukturu jako kód (IaC). Nahraďte nasazení závislá na osobách plně automatizovanými pipelinami, čímž se zodpovědnost přesune od jednotlivců k nástrojům a sníží se ruční úsilí. Povolte autorizovaným členům týmu inicializovat nasazení prostřednictvím tohoto automatizovaného procesu, aby zachovali konzistenci a kvalitu napříč prostředími. 

Navrhněte úlohu jako logickou skupinu komponent, které můžete seskupit do jedné šablony, aby bylo nasazení snadné a opakovatelné. Tyto balíčky si můžete představit jako razítka nebo jednotky škálování. Další informace najdete v tématu Model razítka nasazení. Pokud potřebujete nasadit úlohu pro horizontální navýšení kapacity do jiné oblasti nebo zóny ve stejné oblasti, nasaďte razítko pomocí kanálu. V závislosti na tom, jak navrhujete razítka, můžete místo celé úlohy nasadit podmnožinu úloh. Pokud chcete zajistit, aby se vaše razítka nasazení automaticky připojila k existujícím prostředkům, zahrňte síťové komponenty do kanálů IaC.

Pokud chcete optimalizovat kanál IaC pro zajištění konzistence a efektivity, navrhněte neměnnou infrastrukturu místo proměnlivé infrastruktury. Implementujte neměnnou infrastrukturu, aby se zajistilo, že všechny systémy v oboru budou nahrazeny aktualizovanou konfigurací současně a identicky s každým nasazením.

Příležitost AI: Zjednodušte správu pipeline a snižte ruční úsilí s optimalizací nasazení poháněnou umělou inteligencí. GitHub Copilot může urychlit generování kódu v kanálech CI/CD. Integrace AI může ověřovat a vynucovat organizační standardy, doporučovat strategie vrácení zpět a zjišťovat odchylky porovnáním aktuálních a zamýšlených stavů infrastruktury. Vylepšete monitorování pomocí modelů AI, které předvídají problémy a odhalují je včas pro zásah.

Udržujte přesné, nepřetržitě monitorované inventáře prostředků napříč prostředími a zahrňte kroky schválení a záznamy auditu ke sledování všech akcí AI.

Použití stejné sady artefaktů nasazení ve všech prostředích

Použijte stejnou sadu kódových prostředků a artefaktů ve všech prostředích a pipelinách. Běžným bodem bolesti pro organizace je, že neprodukční prostředí se liší od produkčních prostředí. Ruční sestavování produkčních a neprodukčních prostředí může vést k neshodě konfigurací mezi prostředími. Tato neshoda zpomaluje testování a zvyšuje pravděpodobnost, že změny můžou poškodit produkční systém. Přístup IaC minimalizuje tyto problémy. Pokud používáte automatizaci IaC, můžete použít stejné konfigurační soubory infrastruktury pro všechna prostředí k vytváření téměř identických prostředí. Do konfiguračních souborů infrastruktury můžete přidat parametry a upravit je tak, aby splňovaly požadavky pro každé prostředí.

Pokud chcete řídit náklady, je obvykle rozdíl mezi produkčním a neprodukčním prostředím. Obvykle nepotřebujete stejnou úroveň redundance nebo výkonu v neprodukčním prostředí, takže se počty prostředků a skladové položky můžou lišit. Ujistěte se, že řídíte odchylku a rozumíte jí pomocí standardizovaných parametrů, abyste při provádění změn zachovali předvídatelnost.

Odráží organizační strukturu v dodavatelském řetězci.

Reflektujte organizační strukturu v návrhu dodavatelského řetězce a kanálu. Vaše organizace může být rozdělena mezi týmy. Týmy můžete uspořádat podle funkcí (například sítě, dat a výpočetních prostředků) nebo je integrovat jako týmy DevOps, které spravují infrastrukturu i aplikace. Existuje mnoho způsobů, jak uspořádat týmy, které jsou zapojeny do dodavatelského řetězce. Bez ohledu na strukturu se váš dodavatelský řetězec spoléhá na bezproblémovou spolupráci napříč všemi týmy. Zajistěte, aby všechny týmy dodržovaly standardní procesy a používaly standardní nástroje k zajištění co nejefektivnějšího dodavatelského řetězce.

Váš dodavatelský řetězec se může spoléhat na dodavatele třetích stran, pokud zadáváte části životního cyklu úloh. Tito dodavatelé jsou pro úspěch vašeho dodavatelského řetězce stejně důležití jako interní zdroje. Ujistěte se, že existují vzájemné dohody mezi všemi týmy o procesech a nástrojích, které používáte.

Volba správné metody nasazení

Standardizujte metodu nasazení. Promluvte si s vlastníkem produktu o přijatelném množství výpadků produkčního prostředí pro vaši úlohu. V závislosti na tom, kolik výpadků je přijatelné, můžete zvolit metodu nasazení, která odpovídá vašim požadavkům. V ideálním případě proveďte nasazení během časového období údržby, abyste snížili složitost a riziko. Pokud není žádný výpadek přijatelný, použijte metodu nasazení s modrou zelenou barvou.

Pomocí přístupu postupného nasazení (kanárských nasazení) můžete snížit riziko zavedení nezjištěných chyb pro vaše zákazníky. Nasaďte změny do malých řízených skupin ve fázích, abyste mohli zachytit problémy před širokou verzí. Počáteční skupina zavedení může být pododdílem vašich zákazníků, kteří o strategii zavedení vědí. Tento pododdíl zákazníků může tolerovat určité množství neočekávaného chování a poskytnout zpětnou vazbu. Nebo to může být skupina interních uživatelů, která pomáhá omezit dopad chyb během zavádění.

Když definujete metodu nasazení, přijměte standardní zásadu uvolnění nejmenší možné změny v každém nasazení. Určete, co se kvalifikuje jako nejmenší realizovatelná změna na základě závažnosti vaší úlohy a složitosti jejích komponent. Pokud používáte neměnnou infrastrukturu, nejmenší realizovatelná změna znovu nasazuje prostředky s nejnovější konfigurací, aby se nahradily prostředky, na kterých běží předchozí verze. Pokud používáte proměnlivou infrastrukturu, můžete se rozhodnout, že nejmenší realizovatelná změna je pouze jedna, vymezená aktualizace ve skupině prostředků.

Příležitost AI: Analýza založená na umělé inteligenci identifikuje vzory využití a doporučuje optimální časy nasazení – eliminuje opakované ruční kontroly protokolu. Vyhněte se odhadu období nízkého využití, nasazování během vysoké doby provozu nebo k narušení služeb uživatelů. Začněte s přístupem GenAI s nízkým úsilím, který propojuje modely přímo s telemetrií úloh, což umožňuje interaktivní detekci vzorů a generování přehledů. U rozsáhlých úloh s vysokými transakcemi se škálují na prediktivní modely založené na ML, které předpovídají optimální okna nasazení při vývoji trendů využití.

Sledování vícevrstvého přístupu

Postupujte podle vícevrstvého přístupu, abyste odráželi různé životní cyklus. Udržujte základní vrstvy statické pro většinu životního cyklu vaší úlohy, zatímco vrstvy aplikací se častěji mění. Pro každou vrstvu použijte samostatné kanály nasazení, abyste mohli aplikovat změny nezávisle a odpovídajícím způsobem. 

Cílová zóna se nachází v nejnižší vrstvě vaší architektury. Jedná se o logické seskupení základních prvků, jako jsou předplatná, skupiny pro správu, skupiny prostředků, ovládací prvky zásad správného řízení a topologie sítě, která umožňuje konzistentně nasazovat a provozovat úlohy. Poskytuje centrálním provozním týmům nebo týmům platformy opakovatelnou konfiguraci prostředí. Cílové zóny Azure za účelem zajištění konzistence zahrnují společné oblasti návrhu, referenční architekturu, referenční implementaci a proces přizpůsobení nasazení vašim požadavkům na návrh. Principy návrhu doporučují postupy založené na zásadách správného řízení spolu s demokratizací předplatného. Cílová zóna by měla v průběhu životního cyklu úloh vyžadovat minimální změny. Příklad cílové zóny s doporučenými postupy pro Azure najdete v tématu Co je cílová zóna Azure.

Udržujte základní infrastrukturu – například příchozí a výchozí síťové řadiče, nástroje pro vyrovnávání zatížení, řešení směrování sítě, DNS a základní servery – stabilní s občasnými velkými změnami. Očekávejte a naplánujte častější aktualizace konfigurací těchto komponent. 

Vaše aplikační a datové vrstvy obvykle vyžadují časté aktualizace konfigurace a změny infrastruktury. Pro tyto komponenty používejte nejvýraznější kanály nasazení. 

Začlenění komplexních typů testování

Plánování holistické strategie testování Základním principem spolehlivosti systému je princip posunu doleva . Vývoj a nasazení aplikace je proces, který obsahuje kroky zleva doprava. Nečekejte na dokončení testování, přesuňte testy co nejdříve, abyste zachytili problémy, když jsou levnější opravit. Závady zjištěné v pozdější fázi životního cyklu mohou být nákladné nebo dokonce nemožné opravit.

Otestujte veškerý kód, včetně kódu aplikace, šablon infrastruktury a konfiguračních skriptů. Správa verzí prostředí, ve kterém běží aplikace, a jeho nasazení prostřednictvím stejných mechanismů, které používáte pro kód aplikace. K ověření prostředí použijte stejné přístupy k testování, které týmy používají pro kód aplikace.

Pokud je to možné, použijte automatizované testování, abyste zajistili konzistenci. Do návrhu dodavatelského řetězce zahrňte následující typy testování.

  • Testování jednotek: Testy jednotek můžete spouštět jako součást rutiny kontinuální integrace. Testy jednotek by měly být rozsáhlé a rychlé. V ideálním případě by měly pokrýt 100 procent kódu a běžet do 30 sekund.

    Implementujte testování jednotek a ověřte, že syntaxe a funkce jednotlivých modulů kódu fungují tak, jak by měly, například vytvoření definovaného výstupu pro známý vstup. Jednotkové testy můžete použít také k ověření platnosti prostředků IaC.

    Použijte jednotkové testy na všechny prostředky kódu, včetně šablon a skriptů.

  • Dýmové testování: Dýmové testy ověřují, že úloha může být v testovacím prostředí spuštěna a plní očekávané funkce. Kouřové testy neověřují interoperabilitu součástí.

    Počáteční testy ověřují, že metodologie nasazení infrastruktury a aplikace funguje a že systém reaguje podle očekávání po dokončení procesu.

  • Testování integrace: Integrační testy zajišťují, aby komponenty aplikace fungovaly jednotlivě, a pak určete, jestli spolu komponenty můžou interagovat tak, jak by měly.

    Spuštění rozsáhlé integrační sady může trvat poměrně dlouho. Z tohoto důvodu je nejlepší začlenit princip posunu doleva a otestovat v rané fázi životního cyklu vývoje softwaru. Vyhraďte integrační testy pro scénáře, které nemůžete testovat pomocí průběhového testu nebo jednotkového testu.

    V případě potřeby můžete spouštět dlouhotrvající testovací procesy v pravidelných intervalech. Pravidelný interval nabízí dobrý kompromis a detekuje problémy s interoperabilitou mezi komponentami aplikace nejpozději jeden den po jejich zavedení.

    Některé testovací scénáře využívají ruční spuštění. Ruční testování použijte, když potřebujete do testů zavést prvky lidské interaktivity.

  • Testování přijetí: V závislosti na kontextu můžete ručně provést akceptační testování. Může být částečně nebo plně automatizovaná. Testování přijetí určuje, jestli softwarový systém splňuje specifikace požadavků.

    Hlavním účelem tohoto testu je vyhodnotit dodržování obchodních požadavků systému a určit, jestli systém splňuje požadovaná kritéria pro doručování koncovým uživatelům.

Příležitost AI: Vylepšete svou testovací strategii a najděte hraniční případy a scénáře zaměřené na zákazníky, které se obtížně detekují a často přehlédnou. Začněte tím, že použijete stávající analýzy a reporty k odhalení mezer v pokrytí, a pak použijte nástroje, jako je GitHub Copilot, k generování nových testovacích případů a skriptů. Optimalizujte sadu testů odebráním redundantních testů za účelem zvýšení rychlosti a efektivity. Zvažte agentské řešení AI, které analyzuje produkční využití, monitorování dat a historických vad, abyste našli vzory a automaticky vytvořili testy v základu kódu, které odpovídají standardům vaší organizace.

Implementace bran kvality v procesech povýšení kódu

Implementujte brány kvality v celém procesu nasazení kódu prostřednictvím testování. Zvyšte úroveň kódu prostřednictvím nižších prostředí – vývoje a testování – před tím, než přejdete na vyšší prostředí, jako je příprava a produkční prostředí. Definujte jasné brány a cíle kvality pro každou fázi a propagujte změny do produkčního prostředí až po splnění těchto kritérií. Vaše obchodní požadavky určují zaměření kontrolních bodů kvality. Zvažte také základní principy Well-Architected Framework: zabezpečení, spolehlivost a efektivita výkonu.

Integrujte schvalovací pracovní postupy do brán kvality. V případě potřeby jasně definujte a automatizujte pracovní postupy schvalování. Definujte kritéria přijetí kvality do automatizace, abyste mohli efektivně a bezpečně procházet branami.

Příležitost umělé inteligence: Eliminujte kritické body během kontrol tím, že automaticky směrují žádosti o přijetí změn do správných msp. Začněte s GitHub Copilotem a vyhodnoťte rozsah a dopad. Potom přidejte integraci CI/CD agenta, která vyhodnocuje změny kódu, konfigurace a vzory schválení. Udělte přístup s nejnižšími oprávněními jenom k požadovaným artefaktům – úložištím, kanálům, konfiguračním datům, historii incidentů a protokolům schválení – za účelem posouzení dopadu, přiřazení revidujících, kritických bodů povrchu a doporučení automatického schválení nebo dodatečné kontroly. V případě úloh s vysokou hodnotou se trénujte na historických datech, abyste mohli předpovědět rizika nasazení a výsledky schválení. Udržujte lidi zapojené a buďte opatrní při využívání automatického schvalování.

Usnadnění Azure

Azure DevOps je kolekce služeb, které vám pomůžou vytvořit efektivní a konzistentní vývojový postup pro spolupráci.

Azure Pipelines poskytuje služby sestavení a vydávání, které podporují CI/CD ve vašich aplikacích.

GitHub Actions pro Azure se integruje s Azure, aby se zjednodušilo nasazení. Pomocí GitHub Actions můžete automatizovat procesy CI/CD. Můžete vytvářet pracovní postupy, které sestavují a testují všechny žádosti o přijetí změn do úložiště nebo nasazují sloučené žádosti o přijetí změn do produkčního prostředí.

Pro nasazení IaC můžete použít Terraform, Bicep a Azure Resource Manager. V závislosti na vašich požadavcích a znalosti vašeho týmu s nástroji můžete pro nasazení a správu prostředků použít jeden nebo více těchto nástrojů.

Příklad

Příklad, který ukazuje, jak pomocí Azure Pipelines sestavit kanál CI/CD, najdete v základní architektuře Azure Pipelines.

Kontrolní seznam pro efektivitu operací

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

Kontrolní seznam pro efektivitu provozu

  • Last updated on