Provozní postupy pro klíčové úlohy v Azure

Spolehlivé a efektivní operace musí být založeny na principech automatizace všude, kde je to možné , a na konfiguraci jako kódu. Tento přístup vyžaduje značné technické investice do procesů DevOps. Automatizované kanály se používají k nasazení artefaktů kódu aplikace a infrastruktury. Mezi výhody tohoto přístupu patří konzistentní a přesné provozní výsledky s minimálními ručními provozními postupy.

Tato oblast návrhu zkoumá, jak implementovat efektivní a konzistentní provozní postupy.

Důležité

Tento článek je součástí řady klíčových úloh Azure Well-Architected Framework . Pokud tuto řadu neznáte, doporučujeme začít na co je kritická úloha?.

Procesy DevOps

DevOps kombinuje vývojové a provozní procesy a týmy do jedné technické funkce. Zahrnuje celý životní cyklus aplikace a používá nástroje pro automatizaci a DevOps k rychlému, efektivnímu a spolehlivému provádění operací nasazení. Procesy DevOps podporují a udržují kontinuální integraci a průběžné doručování (CI/CD) a zároveň podporují kulturu neustálého zlepšování.

Tým DevOps pro kritickou aplikaci musí být zodpovědný za tyto úlohy:

• Vytváření a správa prostředků aplikací a infrastruktury prostřednictvím automatizace CI/CD.
• Monitorování a pozorovatelnost aplikací.
• Řízení přístupu na základě role v Azure (RBAC) a správa identit pro komponenty aplikací.
• Správa sítě pro komponenty aplikací.
• Správa nákladů pro prostředky aplikace.

DevSecOps rozšiřuje model DevOps integrací monitorování zabezpečení, auditů aplikací a zajištění kvality s vývojem a provozem v průběhu životního cyklu aplikace. Týmy DevOps jsou potřeba pro scénáře citlivé na zabezpečení a vysoce regulované scénáře, aby se zajistilo, že se zabezpečení začleňuje do celého životního cyklu vývoje, a ne v konkrétní fázi vydání nebo bráně.

Na co dát pozor při navrhování

• Proces vydání a aktualizace. Vyhněte se ručním procesům pro jakékoli změny komponent aplikací nebo základní infrastruktury. Ruční procesy můžou vést k nekonzistentním výsledkům.

• Závislosti na centrálních IT týmech. Použití procesů DevOps může být obtížné, pokud existují pevné závislosti na centralizovaných funkcích, protože tyto závislosti brání kompletním operacím.

• Správa identit a přístupu. Týmy DevOps můžou zvážit podrobné role Azure RBAC pro různé technické funkce, například AppDataOps pro správu databází. Použití modelu nulové důvěryhodnosti napříč rolemi DevOps

Doporučení k návrhu

• Definujte nastavení konfigurace a aktualizace jako kód. Použijte správu změn prostřednictvím kódu, abyste umožnili konzistentní procesy vydávání a aktualizací, včetně úloh, jako je obměně klíčů nebo tajných kódů, a správy oprávnění. Místo integrovaných mechanismů automatických aktualizací používejte procesy aktualizace spravované kanály, jako jsou naplánovaná spuštění kanálu.

• Nepoužívejte centrální procesy ani zřizovací kanály pro vytváření instancí nebo správu prostředků aplikace. Tím se zavádějí závislosti externích aplikací a další vektory rizik, jako jsou ty, které jsou spojené se scénáři s hlučnými sousedy.

  Pokud potřebujete použít centralizované procesy zřizování, ujistěte se, že požadavky na dostupnost závislostí jsou plně v souladu s důležitými požadavky. Centrální týmy musí zajistit transparentnost, aby bylo dosaženo holistické zprovoznění komplexní aplikace.

• Vyhradit část technické kapacity během každého sprintu na podporu základních vylepšení platformy a posílení spolehlivosti. Pro tato vylepšení doporučujeme přidělit 20–40 procent kapacity.

• Vyvíjet běžná technická kritéria, referenční architektury a knihovny, které jsou v souladu se základními principy návrhu. Vynucujte konzistentní základní konfiguraci pro spolehlivost, zabezpečení a provoz prostřednictvím přístupu řízeného zásadami, který používá Azure Policy.

  Pro běžné vzory návrhu můžete také použít běžná technická kritéria a přidružené artefakty, jako jsou zásady Azure a prostředky Terraformu, pro další úlohy v širším ekosystému aplikací vaší organizace.

• Použití modelu nulové důvěryhodnosti v kritických aplikačních prostředích Pomocí technologií, jako je Microsoft Entra Privileged Identity Management, zajistíte, aby operace byly konzistentní a probíhaly pouze prostřednictvím procesů CI/CD nebo automatizovaných provozních postupů.

  Členové týmu by neměli mít stálý přístup k zápisu do žádného prostředí. Možná budete chtít udělat výjimky ve vývojových prostředích, abyste usnadnili testování a ladění.

• Definujte nouzové procesy pro přístup k produkčním prostředím za běhu. Ujistěte se, že v případě závažných problémů se zprostředkovatelem ověřování existují účty break glass.

• Zvažte použití AIOps k neustálému vylepšování provozních postupů a triggerů.

Operace aplikací

Provozní postupy ovlivňují návrh aplikací a doporučení platformy . Existují také provozní možnosti poskytované různými službami Azure, zejména pro zajištění vysoké dostupnosti a obnovení.

Na co dát pozor při navrhování

• Integrované operace služeb Azure. Služby Azure poskytují integrované (ve výchozím nastavení povolené) a konfigurovatelné funkce platformy, jako je zónová redundance a geografická replikace. Spolehlivost aplikace závisí na těchto operacích. Některé konfigurovatelné funkce účtují další náklady, jako je konfigurace nasazení s více zápisy pro službu Azure Cosmos DB. Vyhněte se vytváření vlastních řešení, pokud to nezbytně nepotřebujete.

• Provozní přístup a doba provádění. Většina požadovaných operací je zpřístupněná a přístupná prostřednictvím rozhraní AZURE Resource Manager API nebo Azure Portal. Některé operace ale vyžadují pomoc techniků podpory. Například obnovení z pravidelné zálohy databáze Azure Cosmos DB nebo obnovení odstraněného prostředku mohou provést pouze technici podpora Azure prostřednictvím případu podpory. Tato závislost může ovlivnit výpadek aplikace. U bezstavových prostředků doporučujeme místo čekání na techniky podpory, aby se pokusili obnovit odstraněné prostředky znovu.

• Vynucování zásad. Azure Policy poskytuje rámec pro vynucování a auditování standardních hodnot zabezpečení a spolehlivosti, aby se zajistilo dodržování běžných technických kritérií pro klíčové aplikace. Konkrétně Azure Policy tvoří klíčovou součást řídicí roviny Azure Resource Manager a doplňuje RBAC omezením akcí, které můžou provádět oprávnění uživatelé. Azure Policy můžete použít k vynucení důležitých konvencí zabezpečení a spolehlivosti napříč službami platformy.

• Úpravy a odstraňování prostředků. Prostředky Azure můžete uzamknout , abyste zabránili jejich úpravám nebo odstranění. Zámky ale zavádějí režii správy v kanálech nasazení. U většiny prostředků doporučujeme robustní proces RBAC s přísnými omezeními místo zámků prostředků.

Doporučení k návrhu

• Automatizujte postupy převzetí služeb při selhání. Pro aktivní/aktivní model použijte model stavu a automatizované operace škálování, abyste zajistili, že se nevyžaduje zásah při selhání. U aktivního/pasivního modelu se ujistěte, že jsou postupy převzetí služeb při selhání automatizované nebo alespoň kodifikované v rámci kanálů.

• Určete prioritu použití automatického škálování nativního pro Azure pro služby, které ho podporují. Pro služby, které nepodporují nativní automatické škálování, použijte ke škálování služeb automatizované provozní procesy. K dosažení škálovatelnosti použijte jednotky škálování s více službami.

• Pro zálohování a obnovení využijte funkce nativní pro platformu a ujistěte se, že jsou v souladu s požadavky na rto/cíl bodu obnovení a uchovávání dat. Podle potřeby definujte strategii pro dlouhodobé uchovávání záloh.

• Použijte integrované funkce pro správu a prodlužování platnosti certifikátů SSL, jako jsou ty, které poskytuje Služba Azure Front Door.

• Pro externí týmy vytvořte proces obnovení pro prostředky, které vyžadují pomoc. Pokud je například datová platforma nesprávně změněna nebo odstraněna, měly by být metody obnovení dobře pochopeny a měl by být zaveden proces obnovení. Podobně vytvořte postupy pro správu vyřazených imagí kontejneru v registru.

• V rámci standardních příprav na provozní kontinuitu si předem procvičte operace obnovení s neprodukčními prostředky a daty.

• Identifikujte kritická upozornění a definujte cílové skupiny a systémy. Definujte jasné kanály pro oslovení příslušných zúčastněných stran. Odesíláním pouze použitelných výstrah zabráníte bílému šumu a zabráníte provozním účastníkům v ignorování výstrah a chybějících důležitých informací. Implementujte průběžné vylepšování, abyste optimalizovali upozorňování a odstranili pozorovaný bílý šum.

• Používejte zásady správného řízení a Azure Policy, abyste zajistili vhodné využití provozních funkcí a spolehlivé standardní hodnoty konfigurace ve všech aplikačních službách.

• Vyhněte se používání zámků prostředků u dočasných místních prostředků. Místo toho se při řízení provozních aktualizací spolehněte na vhodné použití kanálů RBAC a CI/CD. Zámky prostředků můžete použít, abyste zabránili odstranění dlouhodobých globálních prostředků.

Správa aktualizací

Zásadní návrh důrazně podporuje princip dočasných bezstavových prostředků aplikací. Pokud použijete tento princip, můžete obvykle provést aktualizaci pomocí nového nasazení a standardních kanálů doručování.

Na co dát pozor při navrhování

• Sladění s plány Azure. Zarovnejte úlohy s plány Azure, aby se prostředky platformy a závislosti modulu runtime pravidelně aktualizovaly.

• Automatická detekce aktualizací. Nastavte procesy pro monitorování a automatické zjišťování aktualizací. Použijte nástroje, jako je GitHub Dependabot.

• Testování a ověřování. Otestujte a ověřte nové verze balíčků, komponent a závislostí v produkčním kontextu před jakýmkoli vydáním. Nové verze můžou obsahovat zásadní změny.

• Závislosti modulu runtime. Se závislostmi modulu runtime zacházejte stejně jako s jakoukoli jinou změnou aplikace. Starší verze můžou představovat ohrožení zabezpečení a mít negativní vliv na výkon. Monitorujte prostředí runtime aplikací a udržujte ho v aktualizovaném stavu.

• Hygiena součástí a úklid. Vyřazujte nebo odeberte prostředky, které se nepoužívají. Můžete například monitorovat registry kontejnerů a odstranit staré verze imagí, které nepoužíváte.

Doporučení k návrhu

• Monitorujte tyto prostředky a udržujte je v aktualizovaném stavu:

  • Platforma pro hostování aplikace. Musíte například pravidelně aktualizovat verzi Kubernetes v Azure Kubernetes Service (AKS), zejména s ohledem na to, že podpora starších verzí není zachována. Musíte také aktualizovat komponenty, které běží v Kubernetes, jako je cert-manager a Azure Key Vault CSI, a sladit je s verzí Kubernetes v AKS.
  • Externí knihovny a sady SDK (.NET, Java, Python)
  • Zprostředkovatelé Terraformu.

• Vyhněte se ručním provozním změnám aktualizací součástí. Použití ručních změn zvažte pouze v nouzových situacích. Ujistěte se, že máte proces pro odsouhlasení všech ručních změn zpět do zdrojového úložiště, abyste se vyhnuli posunu a opakování problému.

• Vytvořte automatizovaný postup pro odebrání starých verzí imagí z Azure Container Registry.

Správa tajných kódů

Vypršení platnosti klíče, tajného klíče a certifikátu je běžnou příčinou výpadku aplikace. Správa tajných kódů pro kritickou aplikaci musí poskytovat potřebné zabezpečení a nabízet odpovídající úroveň dostupnosti, aby odpovídala vašim požadavkům na maximální spolehlivost. Musíte pravidelně provádět obměně klíčů, tajných klíčů a certifikátů pomocí spravované služby nebo v rámci správy aktualizací a aplikovat procesy pro změny kódu a konfigurace.

Mnoho služeb Azure podporuje ověřování Microsoft Entra místo toho, aby se spoléhaly na připojovací řetězce nebo klíče. Použití id Microsoft Entra výrazně snižuje provozní režii. Pokud používáte řešení správy tajných kódů, mělo by se integrovat s jinými službami, podporovat zónovou a regionální redundanci a poskytovat integraci s id Microsoft Entra pro ověřování a autorizaci. Key Vault poskytuje tyto funkce.

Na co dát pozor při navrhování

Existují tři běžné přístupy ke správě tajných kódů. Každý přístup čte tajné kódy z úložiště tajných kódů a vloží je do aplikace v jiném čase.

• Načtení v době nasazení Výhodou tohoto přístupu je, že řešení pro správu tajných kódů musí být dostupné jenom v době nasazení, protože po této době už nebudou k dispozici přímé závislosti. Mezi příklady patří vkládání tajných kódů jako proměnných prostředí do nasazení Kubernetes nebo do tajného klíče Kubernetes.

  Přístup k tajným kódům musí mít jenom instanční objekt nasazení, což zjednodušuje oprávnění RBAC v systému pro správu tajných kódů.

  Tento přístup však má své nevýhody. Zavádí složitost RBAC v nástrojích DevOps s ohledem na řízení přístupu k instančnímu objektu a v aplikaci s ohledem na ochranu načtených tajných kódů. Také se nepoužívají výhody zabezpečení řešení pro správu tajných kódů, protože tento přístup závisí pouze na řízení přístupu v aplikační platformě.

  Pokud chcete implementovat aktualizace tajných kódů nebo obměně, musíte provést úplné opětovné nasazení.

• Načtení spuštění aplikace. Při tomto přístupu se tajné kódy načítají a vloží při spuštění aplikace. Výhodou je, že tajné kódy můžete snadno aktualizovat nebo obměňovat. Tajné kódy nemusíte ukládat na aplikační platformě. K načtení nejnovější hodnoty se vyžaduje restartování aplikace.

  Mezi běžné možnosti úložiště patří Azure Key Vault Provider for Secrets Store CSI Driver a akv2k8s. K dispozici je také nativní řešení Azure, Key Vault nastavení aplikace, na které odkazuje.

  Nevýhodou tohoto přístupu je, že vytváří závislost modulu runtime na řešení správy tajných kódů. Pokud v řešení pro správu tajných kódů dojde k výpadku, komponenty aplikace, které už jsou spuštěné, můžou dál obsluhovat požadavky. Jakákoli operace restartování nebo horizontálního navýšení kapacity by pravděpodobně měla za následek selhání.

• Načtení za běhu Načítání tajných kódů za běhu ze samotné aplikace je nejbezpečnější přístup, protože ani aplikační platforma nikdy nemá přístup k tajným klíčům. Aplikace se musí ověřit v systému správy tajných kódů.

  Pro tento přístup však komponenty aplikací vyžadují přímou závislost a připojení k systému správy tajných kódů. To ztěžuje testování komponent jednotlivě a obvykle vyžaduje použití sady SDK.

Doporučení k návrhu

• Pokud je to možné, použijte k připojení ke službám ověřování Microsoft Entra místo připojovacích řetězců nebo klíčů. Tuto metodu ověřování použijte společně se spravovanými identitami Azure, abyste nemuseli ukládat tajné kódy na platformě aplikace.

• Využijte výhod nastavení vypršení platnosti v Key Vault a nakonfigurujte upozorňování na nadcházející vypršení platnosti. Proveďte všechny aktualizace klíčů, tajných klíčů a certifikátů pomocí standardního procesu vydání.

• Nasaďte Key Vault instance jako součást místního razítka, abyste zmírnili potenciální dopad selhání na jedno razítko nasazení. Pro globální prostředky použijte samostatnou instanci. Informace o těchto prostředcích najdete v typickém vzoru architektury pro klíčové úlohy.

• Abyste se vyhnuli nutnosti spravovat přihlašovací údaje instančního objektu nebo klíče rozhraní API, použijte pro přístup k Key Vault, kdykoli je to možné, spravované identity místo instančních objektů.

• Implementujte vzory kódování, abyste zajistili, že se tajné kódy znovu načtou, když dojde k selhání autorizace za běhu.

• Použijte plně automatizovaný proces obměně klíčů, který se v rámci řešení spouští pravidelně.

• K získání upozornění na nadcházející vypršení platnosti použijte v Azure Key Vault klíčové oznámení o blížícím se vypršení platnosti.

Aspekty specifické pro IaaS při používání virtuálních počítačů

Pokud potřebujete používat virtuální počítače IaaS, můžou se některé postupy a postupy popsané výše v tomto dokumentu lišit. Použití virtuálních počítačů poskytuje větší flexibilitu v možnostech konfigurace, operačních systémech, přístupu k ovladačům, přístupu k operačnímu systému na nízké úrovni a druhů softwaru, který můžete nainstalovat. Nevýhodou jsou zvýšené provozní náklady a odpovědnost za úlohy, které obvykle poskytovatel cloudu provádí při používání služeb PaaS.

Na co dát pozor při navrhování

• Jednotlivé virtuální počítače neposkytují vysokou dostupnost, zónovou redundanci ani geografickou redundanci.
• Jednotlivé virtuální počítače se po nasazení automaticky neaktualizují. Například nasazený SQL Server 2019 ve Windows Serveru 2019 se automaticky neaktualizuje na novější verzi.
• Služby spuštěné na virtuálním počítači vyžadují zvláštní ošetření a další nástroje, pokud je chcete nasadit a nakonfigurovat prostřednictvím infrastruktury jako kódu.
• Azure pravidelně aktualizuje svou platformu. Tyto aktualizace můžou vyžadovat restartování virtuálních počítačů. Aktualizace, které vyžadují restartování, jsou obvykle oznámeny předem. Viz Údržba virtuálních počítačů v Azure a Zpracování oznámení o plánované údržbě.

Doporučení k návrhu

• Vyhněte se ručním operacím na virtuálních počítačích a implementujte správné procesy pro nasazení a zavádění změn.

  • Automatizujte zřizování prostředků Azure pomocí řešení infrastruktury jako kódu, jako jsou šablony Azure Resource Manager (ARM), Bicep, Terraform nebo jiná řešení.

• Ujistěte se, že jsou zavedeny a správně testovány provozní procesy pro nasazení virtuálních počítačů, aktualizace a zálohování a obnovení. Pokud chcete otestovat odolnost, vložte do aplikace chyby, poznamenejte si chyby a zmírněte jejich zmírnění.

• Pokud novější verze nefunguje správně, ujistěte se, že jsou nastavené strategie pro návrat do posledního známého stavu v pořádku.

• Vytvářejte časté zálohy pro stavové úlohy, zajistěte, aby úlohy zálohování fungovaly efektivně, a implementujte upozornění na neúspěšné procesy zálohování.

• Monitorujte virtuální počítače a detekujte selhání. Nezpracovaná data pro monitorování můžou pocházet z různých zdrojů. Analyzujte příčiny problémů.

• Ujistěte se, že naplánované zálohování běží podle očekávání a že se podle potřeby vytvářejí pravidelné zálohy. K získání přehledů můžete použít Centrum zálohování .

• Upřednostněte použití Virtual Machine Scale Sets místo virtuálních počítačů, abyste umožnili funkce, jako je škálování, automatické škálování a zónová redundance.

• Upřednostnit použití standardních imagí z Azure Marketplace místo vlastních imagí, které je potřeba udržovat.

• Pomocí Nástroje Azure VM Image Builder nebo jiných nástrojů můžete podle potřeby automatizovat procesy sestavování a údržby přizpůsobených imagí.

Nad rámec těchto konkrétních doporučení použijte osvědčené postupy pro provozní postupy pro scénáře kritických aplikací podle potřeby.

Další krok

Projděte si model architektury pro klíčové scénáře aplikací:

Vzor architektury