Plánování řešení nativních pro cloud

Cloudové nativní řešení vytváří obchodní hodnotu tím, že vytváří nové úlohy nebo vylepšuje stávající úlohy. Bez ohledu na to, jestli vyvíjíte novou aplikaci nebo přidáváte nové funkce do existujícího systému, je vývoj nativní pro cloud cestu k plánování, sestavování, nasazování a optimalizaci úloh. Tato architektura poskytuje pokyny pro sladění vaší aplikace s obchodními cíli, osvědčenými postupy architektury a správou rizik.

Požadavky:Cílová zóna Azure

Na levé straně jsou tři pole s popisky, Startupy, Podniky a Existující úlohy seskupené pod nadpisem Vytvořit novou obchodní hodnotu. Šipky vedou z těchto polí ke svislé sekvenci čtyř kroků: 1 Plánování cloud-native, 2 Sestavení cloud-native, 3 Nasazení cloud-native a 4 Optimalizace cloud-native. Poslední šipka ukazuje na ikonu Azure, což naznačuje, že zde sídlí cloudově nativní aplikace, pracovní úlohy a funkce.

Definování obchodních cílů pro řešení nativní pro cloud

1. Začněte jasnými obchodními cíli. Definujte konkrétní výsledky, které by vaše řešení mělo dosáhnout, jako je například povolení nového digitálního produktu, vstup na nový trh, zlepšení zkušeností zákazníků nebo snížení provozních nákladů. Kvantifikujte úspěch pomocí měřitelných ukazatelů, jako je růst výnosů, snížení časového limitu na trh nebo objem lístků podpory. U nových funkcí definujte cíle, jako je zlepšení zkušeností zákazníků, snížení provozních nákladů nebo zvýšení škálovatelnosti systému.

2. Identifikujte omezení a kritéria úspěchu. Zdokumentovat všechna obchodní omezení, jako jsou rozpočet, dodržování předpisů nebo časové osy doručení. Definujte, jak vypadá úspěch pro každý cíl. Například "spuštění nového zákaznického portálu do Q4" nebo "snížení zpoždění při platbě o 40 %." Tato kritéria řídí stanovení priorit a pomáhají vyhodnotit kompromisy během plánování.

3. Ověřte sladění zainteresovaných stran. Potvrďte, že všichni účastníci (obchodní a technická) souhlasí s cíli, omezeními a tím, jak úspěch vypadá. Toto sladění může zahrnovat workshopy nebo formální podpisy. Včasné sladění brání pozdější nesprávné komunikaci a zabraňuje nákladnému přepracování, což zajišťuje, aby všichni od začátku sdílí stejná očekávání.

Definování požadavků pro nativní cloudová řešení

1. Zdokumentovat funkční požadavky. Zdokumentujte možnosti a funkce, které musí systém poskytovat, aby vyhovoval potřebám uživatelů. Každý požadavek by se měl svázat s obchodním cílem a zajistit, aby úsilí o vývoj přímo podporovalo požadované výsledky. K identifikaci vysoce hodnotných výsledků využijte rozhovory se zúčastněnými stranami a dokumenty obchodní strategie. Určete prioritu funkcí na základě obchodní hodnoty a technické proveditelnosti. Sledujte každý požadavek na měřitelný obchodní cíl, který by odůvodnil jeho zahrnutí.

2. Stanovte nefunkční požadavky. Nefunkční požadavky definují technické požadavky pro splnění funkčních požadavků a zásad správného řízení. Vytvořte atributy kvality a technické cíle potřebné k podpoře těchto funkcí. Definujte cílové metriky spolehlivosti , jako jsou cíle úrovně služeb (SLO) pro dobu provozu, cíle bodu obnovení (RPO) a cíle doby obnovení (RTO). Vytvoření standardních hodnot zabezpečení Vytvořte nákladový model. Nastavte cíle výkonu.

3. Řízení rozsahu cloudově nativních řešení. Jasně definujte, co je v rozsahu vs. mimo rozsah počáteční verze. Je lákavé zahrnout více "příjemných" funkcí, ale rozšiřování rozsahu může ohrozit časové osy a rozpočty. Zdokumentujte hranice vašeho řešení a implementujte proces řízení změn pro všechny nové požadavky. Schvalte pouze změny, které přímo podporují definované cíle a které je možné doručit bez narušení plánu nebo rozpočtu. Odložit nápady s nižší prioritou na budoucí seznam úkolů. Důkladná správa rozsahu udržuje tým zaměřený na poskytování nejhodnotnějších funkcí jako první v rámci omezení.

Plánování architektur nativních pro cloud

Dobře plánovaná architektura je důležitá pro splnění vašich cílů a požadavků. Každé hlavní rozhodnutí o architektuře zahrnuje kompromisy ve škálovatelnosti, složitosti, nákladech a flexibilitě. Následující kroky a rozhodovací body vám pomůžou vytvořit návrh nativní pro cloud, který je v souladu s osvědčenými postupy:

Prozkoumání ověřených architektur nativních pro cloud

1. Projděte si základy architektury. Než začnete vymyslet architekturu od začátku, projděte si ověřené referenční architektury a základy z Centra architektury Azure. Prozkoumejte ověřené referenční architektury pro běžné úlohy. Tyto architektury pomáhají urychlit rozhodování o návrhu a snížit riziko.

2. Vyberte vhodný styl architektury. Zvolte styl architektury na základě charakteristik vaší úlohy a možností týmu. Mezi styly architektury patří N-vrstvé (monolitické), mikroslužby, řízené událostmi (založené na zprávách), web-queue-worker. Pokud například potřebujete rychlý vývoj pro relativně jednoduchou aplikaci, může stačit dobře strukturovaný N-vrstvý monolit. U rozsáhlých nebo rychle se vyvíjejících aplikací s odlišnými doménami nabízejí mikroslužby nebo přístupy řízené událostmi flexibilitu (za cenu složitosti). V praxi mnoho systémů končí hybridním stylem. Například existuje jádro mikroslužeb s některými sdílenými službami nebo subsystémem řízeným událostmi. Klíčem je pochopení kompromisů jednotlivých stylů a výběr přístupu, který nejlépe vyhovuje vašim požadavkům na škálovatelnost, odolnost a flexibilitu.

3. Použijte osvědčené postupy návrhu. Bez ohledu na to, jaký styl vyberete, dodržujte základy cloudové architektury a osvědčené postupy. Centrum architektury Azure poskytuje katalog vzorů návrhu cloudu (opakování, jistič, CQRS), které řeší běžné problémy v distribuovaných úlohách. Integrace těchto vzorů do návrhu může zlepšit spolehlivost a výkon.

4. Integrujte pět pilířů do rozhodnutí o návrhu. Využijte Well-Architected Framework k vedení rozhodnutí o spolehlivosti, zabezpečení, efektivitě výkonu, optimalizaci nákladů a efektivitě provozu. Těchto pět pilířů by mělo informovat všechna rozhodnutí o návrhu. Například při výběru databáze zvažte spolehlivost (redundanci, zálohování), výkon a náklady společně, abyste mohli dosáhnout správného vyvážení. Zdokumentujte, kde mezi pilíři uděláte kompromisy, například vyšší náklady na vyšší výkon. Tyto poznámky jsou cenné pro budoucí zásady správného řízení a revize.

Plánování integrací se stávajícími systémy

1. Inventarizace všech závislých systémů a služeb Nová cloudově nativní řešení zřídka fungují izolovaně, pokud nejde o startup v rané fázi. Zvažte, jak vaše nová úloha nebo funkce zapadá do prostředí. Namapujte toky dat a zajistěte kompatibilitu se standardy. Vytvořte komplexní seznam všech systémů, se kterými vaše úlohy pracují. Tento seznam obsahuje interní rozhraní API, databáze, zprostředkovatele identit (Microsoft Entra ID), monitorovací nástroje, kanály CI/CD a místní systémy, ke které se přistupuje přes VPN nebo ExpressRoute. Pomocí diagramů architektury a map závislostí můžete tyto relace vizualizovat.

2. Klasifikovat typy integrace a protokoly Kategorizovat jednotlivé body integrace podle typu (ověřování, výměna dat, zasílání zpráv) a protokolu (REST, gRPC, ODBC, SAML, OAuth2). Tato klasifikace pomáhá identifikovat požadavky na kompatibilitu a potenciální kritické body.

3. Ověřte integraci identit a přístupu. Ujistěte se, že se vaše řešení integruje se zprostředkovatelem identity organizace. Místo zavedení nového systému identit použijte například Microsoft Entra ID pro ověřování a autorizaci. Potvrďte podporu jednotného přihlašování (SSO), řízení přístupu na základě role (RBAC) a zásad podmíněného přístupu.

4. Posouzení síťového připojení a zabezpečení Zkontrolujte, jak se vaše úloha připojuje k jiným systémům. Ověřte pravidla brány firewall, rozlišení DNS a směrovací trasy. V případě hybridních scénářů ověřte, že jsou konfigurace ExpressRoute nebo VPN zavedené a otestované. Pomocí služby Azure Network Watcher můžete monitorovat a řešit potíže s připojením.

5. Zajistěte kompatibilitu a dodržování předpisů toku dat. Mapování toků dat mezi systémy Potvrďte požadavky na formáty dat, schémata a transformace. Zajištění souladu se zásadami rezidence, šifrování a uchovávání dat

6. Otestujte integrační body včas a nepřetržitě. Testování integrace proveďte v počátečních fázích vývoje. Pro nedostupné systémy používejte mocky nebo stuby. Automatizujte tyto testy v kanálu CI/CD pomocí nástrojů, jako jsou Azure DevOps nebo GitHub Actions. Monitorujte latenci, propustnost a chybovost. Chcete se například vyhnout situaci, kdy rozhraní API, na kterém vaše aplikace závisí, nepodporuje požadované zatížení, nebo kdy síťový firewall může vaši službu blokovat.

7. Zdokumentujte smlouvy integrace a dohody o úrovni služeb. Definujte a zdokumentujte očekávané chování, dostupnost a výkon jednotlivých bodů integrace. Zahrnují logiku opakování, nastavení časového limitu a záložní mechanismy. V souladu se smlouvami o úrovni služeb (SLA) závislých systémů

Výběr odpovídajících služeb a úrovní služeb Azure

1. Pomocí průvodců rozhodováním můžete vybrat služby, které odpovídají požadavkům na úlohy. Azure nabízí několik možností pro spuštění kódu aplikace, z nichž každá má výhody a nevýhody. Projděte si přehled možností technologií a identifikujte služby, které odpovídají vašim funkčním a nefunkčním požadavkům. Určete prioritu možností typu platforma jako služba (PaaS), protože tyto služby snižují provozní režii díky automatickému zpracování správy, oprav a škálování infrastruktury.

2. Definujte vzory využití a požadavky na výkon pro výběr úrovní služby. Výběr úrovně služby má vliv na náklady i možnosti. Zdokumentovat očekávané objemy transakcí, souběžné zatížení uživatelů, požadavky na úložiště a výkonnostní cíle, jako jsou doby odezvy a propustnost. Pomocí těchto metrik vyberte počáteční úroveň služby (SKU), která splňuje základní požadavky bez významného nadměrného zřizování. Naplánujte úpravu vrstev na základě skutečných vzorů využití po nasazení.

3. Ověřte kompatibilitu funkcí napříč vybranými úrovněmi služby. Důležité funkce, jako jsou pokročilé možnosti zabezpečení, možnosti vysoké dostupnosti nebo rozhraní API integrace, se liší podle úrovně služby. Vytvořte matici funkcí, která mapuje požadované možnosti na dostupné skladové položky. Ujistěte se, že vybraná úroveň podporuje všechny nezbytné funkce, aby se zabránilo nákladným migracím nebo změnám architektury později. Referenční dokumentace pro konkrétní službu pro potvrzení dostupnosti a omezení funkcí

Vyberte, kolik oblastí se má použít.

1. Vyhodnoťte kompromisy nasazení ve více oblastech. Architektury s jedním regionem jsou jednodušší a levnější, ale regionální výpadek by vaši aplikaci shodil. Nasazení ve více oblastech mohou dosáhnout vyšší dostupnosti (jedna oblast může selhat a uživatelé se obsluhují z jiné oblasti) a mohou také zlepšit výkon tím, že obsluhují uživatele z nejbližší oblasti. Kompromisem je zvýšená složitost nasazení a synchronizace dat. Replikaci dat napříč oblastmi musíte zpracovávat s potenciálními problémy s konzistencí, globálním směrováním provozu a vyššími náklady. Nechte toto rozhodnutí řídit požadavky na spolehlivost.

2. Využijte cíle spolehlivosti k vedení regionální strategie. Definujte cíle na úrovni služby (SLO), cíle bodu obnovení (RPO) a cíle doby obnovení (RTO) pro určení regionálních požadavků.

3. Potvrďte dodržování předpisů o uložení dat. Spolupracujte s právními týmy a týmy pro dodržování předpisů a zajistěte, aby regionální volby splňovaly zákonné povinnosti.

Architektury dokumentů

1. Vytvořte podrobný diagram architektury a dokument návrhu. Dokumentace podporuje implementaci, kontrolu a budoucí údržbu. Zahrnout vybrané služby Azure, skladové položky, toky dat a interakce uživatelů. Ujistěte se, že diagram poskytuje jasné vizuální znázornění architektury pro podporu implementace a kontrol.

2. Zaznamenávání klíčových rozhodnutí o návrhu a kompromisů. Zdokumentujte důvody volby architektury, včetně nefunkčních požadavků, jako je spolehlivost, zabezpečení a výkon. Zvýrazněte všechny kompromisy, které se vyrovnaly konkurenčním prioritám.

Plánování strategie nasazení cloudově-nativních aplikací.

Když nasadíte řešení nativní pro cloud do produkčního prostředí, postupujte podle plánované strategie místo jednorázového nabízení. Pevný plán nasazení minimalizuje dopady na uživatele a poskytuje způsoby obnovení, pokud se něco nepovede.

Plánování postupů vývoje a nasazení

Postupy vývoje a nasazení zajišťují konzistentní doručování a provozní připravenost napříč prostředími. Tyto postupy snižují riziko nasazení a zlepšují koordinaci týmů.

1. Vytvořte postupy DevOps pro automatizaci nasazení. Postupy DevOps srovnají vývojové a provozní týmy prostřednictvím automatizace, správy verzí a kanálů CI/CD. Pomocí nástrojů, jako je Azure DevOps nebo GitHub Actions, můžete automatizovat pracovní postupy sestavení, testování a nasazení. Tento přístup snižuje ruční chyby, urychluje cykly vydávání verzí a poskytuje konzistentní procesy nasazení napříč prostředími.

2. Naplánujte provozní připravenost pro podporu nasazení aktivit. Provozní připravenost zahrnuje postupy monitorování, upozorňování a reakce na incidenty pro scénáře nasazení. Zdokumentujte runbooky pro nasazení a automatizační skripty, které zahrnují postupy pro rollback, kontroly stavu a kroky pro řešení problémů. Tyto prostředky uložte do centrálního umístění, jako je wikiweb Azure DevOps nebo GitHub, abyste zajistili přístupnost během aktivit nasazení.

3. Definujte vývojové postupy , které podporují spolehlivá nasazení. K zajištění kvality kódu a připravenosti nasazení použijte standardy kódování, partnerské kontroly a automatizované testování. Integrujte tyto postupy do potrubí CI/CD pro vynucení kontrol kvality před nasazením. Zahrňte testy specifické pro nasazení, jako jsou integrační testy, orientační testy a ověření výkonu, abyste ověřili připravenost systému pro produkční prostředí.

Plánování nasazení pro nové úlohy

1. Pomocí progresivní expozice omezte dopad. U nové aplikace (nový projekt) bez stávajících uživatelů byste měli provést omezené spuštění. Nasaďte ho do produkčního prostředí, ale zpočátku ho zpřístupňujte jenom interním uživatelům nebo pilotní skupině. Tento přístup představuje kanárské nasazení pro novou úlohu. Pokud je skutečně zcela nová a izolovaná, je možné ji jednorázově nasadit do plné produkce, ale stále se doporučuje postupné uvolňování k řízenému zachycení všech problémů. Nespouštějte systém pro všechny uživatele hned první den bez nejprve provedení ověření v reálných podmínkách. Další informace najdete v tématu WAF – Přechod na model progresivní expozice.

2. Zdokumentovat provozní postupy a cesty eskalace Vytvořte jasnou dokumentaci pro restartování služeb, přístup k protokolům, zpracování běžných problémů a eskalaci incidentů. Tuto dokumentaci uložte do sdíleného úložiště, jako je SharePoint nebo GitHub, abyste zajistili dostupnost týmů podpory.

Plánování nasazení pro nové funkce

1. Naplánujte integraci nových funkcí pomocí správy změn. Pokud chcete řídit a dokumentovat produkční změny, postupujte podle procesu správy změn ve vaší organizaci. Definujte postupy vrácení zpět, například vrácení verzí aplikace nebo obnovení záloh databáze. Před nasazením zabezpečte schválení účastníků, abyste zajistili soulad s obchodními cíli. Další informace najdete v tématu Správa změn v CAF.

2. Používejte místní aktualizace pro menší nebo zpětně kompatibilní změny. Nasaďte aktualizace přímo do produkčního prostředí pomocí průběžných aktualizací nebo funkčních příznaků. Začněte malým procentem uživatelů nebo instancí. Monitorujte systémové metriky a protokoly a ověřte stabilitu před úplným uvedením.

3. Používejte modro-zelené (paralelní) nasazení pro hlavní nebo vysoce rizikové změny. Nasaďte novou verzi v samostatném prostředí. Nasměrujte malou část živého provozu do nové verze a ověřte chování. V případě úspěchu převedět veškerý provoz na novou verzi. Pokud dojde k problémům, vraťte provoz do původní verze, abyste zajistili kontinuitu.

4. Naplánujte provozní předání pro nové úlohy. Identifikujte tým zodpovědný za provoz a podporu řešení po nasazení. Definujte model podpory (nepřetržitá pohotovostní podpora nebo podpora během pracovní doby) a zajistěte, aby všichni zainteresované strany porozuměli svým rolím.

5. Definujte vlastnictví a odpovědnost za podporu. Ověřte, že je provozní tým připravený na podporu nové funkce. Aktualizujte dokumentaci a cesty eskalace tak, aby odrážely nové odpovědnosti a zajistily rychlou reakci na incidenty.

Definujte plán obnovení pro cloud-native řešení

Plán vrácení zpět umožňuje týmům rychle obrátit změny v případě selhání nasazení nebo zavedení rizika. Dobře definovaný plán minimalizuje výpadky, omezuje obchodní dopad a udržuje spolehlivost systému. Před zahájením jakékoli migrace nebo nasazení vždy nastavte kritéria a postupy vrácení zpět.

1. Definujte neúspěšné nasazení. Spolupracujte s obchodními účastníky, vlastníky úloh a provozními týmy a rozhodněte se, co se počítá jako neúspěšné nasazení. Mezi příklady patří neúspěšné kontroly stavu, nízký výkon, problémy se zabezpečením nebo nesplněné metriky úspěchu. Tato definice zajišťuje, že rozhodnutí o vrácení zpět odpovídají toleranci rizik vaší organizace. Uveďte konkrétní podmínky, které v plánu nasazení aktivují vrácení zpět, jako jsou limity využití procesoru, prahové hodnoty doby odezvy nebo míry chyb. Toto vyhodnocení dělá rozhodnutí o vrácení zpět jasná a konzistentní během incidentů.

2. Automatizujte kroky vrácení zpět v CI/CD kanálech. K automatizaci úloh vrácení zpět použijte nástroje, jako jsou Azure Pipelines nebo GitHub Actions . Pokud například kontroly stavu selžou, nastavte kanály tak, aby znovu nasadily předchozí verzi.

3. Vytvořte pokyny pro vrácení zpět specifické pro úlohy. Zapište kroky vrácení zpět, které odpovídají vašemu typu úlohy, prostředí a metodě nasazení. Například nasazení IaC vyžadují opětovné použití předchozích šablon. Vrácení aplikace zahrnuje opětovné nasazení předchozího kontejnerového obrázku. Připojte ke svému plánu vrácení zpět skripty, snímky konfigurace a šablony IaC. Tyto prostředky proces urychlují a snižují potřebu ručních kroků.

4. Otestujte postupy vrácení zpět. Simulujte chyby během nasazení v testovacím prostředí a ujistěte se, že zpětné vrácení funguje. Vyhledejte a opravte mezery v automatizaci, oprávněních nebo závislostech. Ověřte, že procedura vrácení zpět obnoví systém do stabilního, známého dobrého stavu.

5. Vylepšení strategií vrácení zpět Po každém nasazení nebo vrácení zpět zkontrolujte, co fungovalo a co ne. Aktualizujte pravidla vrácení zpět, kroky a skripty na základě získaných poznatků. Zohlednit změny návrhu nebo nové nástroje. Udržujte si příručky aktualizované, aby plány vrácení zpět zůstaly aktuální a užitečné.

Další krok

Sestavení nového řešení