Vytvoření procesů správy provozu

Když váš podnik začne provozovat úlohy v Azure, dalším krokem je vytvoření procesu provozní správy a kondice. Tento proces provádí výčet, implementuje a iterativně kontroluje a optimalizuje provozní stav těchto úloh.

Proces kontroly provozní způsobilosti zajišťuje, aby celé portfolio úloh splňovalo obchodní závazky týkající se výkonu, spolehlivosti a nákladů. Tento proces ladí úsilí centrálního IT, cloudového centra excelence a týmů úloh o zajištění efektivity provozu ve velkém.

Vytvoření základního procesu pro kontrolu provozní způsobilosti

Vytvořte proces pro kontrolu provozní kondice, abyste plně porozuměli problémům, které vyplývají ze spouštění úloh v produkčním prostředí, a jak tyto problémy napravit a vyřešit. Tento článek popisuje základní proces kontroly provozní kondice, který může váš podnik použít k dosažení tohoto cíle.

Provozní fitness v Microsoftu

Od samého počátku se do vývoje platformy Azure zapojilo mnoho týmů v Microsoftu. U projektu takové velikosti a složitosti je obtížné zajistit kvalitu a konzistenci. K pravidelnému výčetu a implementaci základních nefunkčních požadavků potřebujete robustní proces.

Procesy, které Společnost Microsoft sleduje, tvoří základ pro procesy popsané v tomto článku.

Principy rolí a provozních modelů

Řízení provozu je široká disciplína zahrnující více rolí v rámci společnosti. V závislosti na provozním modelu organizace můžou tyto role fungovat v maticovém prostředí s řadou předávání mezi centralizovanými a decentralizovanými provozními týmy.

  • Centrální IT / CCoE: Tato centralizovaná technologická funkce zodpovídá za konfiguraci, provoz, zásady správného řízení a zabezpečení všech technologických prostředků v technologickém portfoliu.
  • Cloudové operace: Funkce v rámci centralizované technologické organizace spravuje stav a provoz technologického portfolia. Je jejich zodpovědností zajistit hladký průběh procesu, aby každá sousední role v procesu měla potřebné nástroje a aby každá z následujících rolí byla zodpovědná za očekávání tohoto procesu.
  • Cloudová strategie: Poskytuje znalosti o podniku, aby bylo možné identifikovat a určit prioritu závazků pro zajištění provozních požadavků různých úloh. Tato role také porovnává náklady na zmírnění rizik s obchodním dopadem a řídí konečné rozhodnutí o nápravě.
  • Tým úloh: Zodpovídá za vývoj a provoz diskrétních úloh, které se mapují na konkrétní podpůrné aplikace, služby a infrastrukturu, ať už místně nebo v cloudu. Role vyžaduje hlubokou znalost architektury úloh.

Provozní model každé organizace určuje odpovědnost a každodenní aktivity výše uvedených rolí:

  • Centralizované operace: Centrální IT zajišťuje plnou odpovědnost za provoz. Vlastníci úloh můžou mít vstupy do operací a konfigurace, ale nemají přístup ke změnám produkčních prostředí. Provozní změnu za účelem zlepšení provozní kondice může přinést pouze centrální provoz IT a cloudový provoz.
  • Decentralizované operace: Týmy úloh plně zodpovídají za provoz, obecně prostřednictvím vyspělého kanálu CI/CD a automatizace DevOps. V tomto modelu neexistuje centrální podpora konfigurace, provozu, zásad správného řízení ani zabezpečení. Tento přístup k operacím je pro Cloud Adoption Framework mimo rozsah. Pro tento provozní model by se měl zobrazit azure Well-Architected Framework , kde najdete provozní pokyny.
  • Podnikové operace: Za provoz zodpovídá špičkové cloudové centrum. Každý tým cloudového provozu a úloh sdílí odpovědnost za konkrétní aspekty provozní způsobilosti.

Cíl přezkumu

Provozní zdatnost se v rámci portfolia vyhodnocuje pomocí několika metrik: spolehlivosti, výkonu a nákladů. Tyto vlastnosti společně umožňují rychlé vyhodnocení stavu a zdatnosti všech aktiv v portfoliu. Tyto metriky se vyhodnocují napříč třemi zvýšeními úrovně správy operací.

Zvýšení úrovně operací

  • Provozní směrný plán (nebo vylepšený směrný plán): Vyhodnocuje provozní způsobilost všech nasazených prostředků bez ohledu na jejich funkci. Tento široký pohled na provoz umožňuje rozsáhlé změny a velké dopady, ale je omezený nedostatečným přehledem o architektuře jednotlivých úloh. Všechny prostředky nasazené v cloudu by měly být pokryté standardními provozními hodnotami s pravidelnou podporou z cloudového provozu. Některá prostředí můžou vyžadovat vyšší stupeň provozní podpory, aby vyhovovala potřebám rozšířeného standardního plánu.
  • Operace platformy: Vyhodnocuje provozní způsobilost centralizovaných technologických platforem. Toto zobrazení operací je přesnější, protože bere v úvahu architekturu platformy a způsob, jakým změny řešení ovlivní provozní způsobilost. Změny centrálních technologických platforem můžou mít široký dopad na podporované úlohy. Všechny klíčové platformy by měly dostávat vyhrazenou podporu od centrálního IT týmu.
  • Operace úloh: Vyhodnocuje provozní způsobilost jednotlivých úloh. Toto zobrazení operací je nejpřesnější a mělo by se zvážit, pokud vylepšení provozní kondice vyžadují změny architektury úlohy. Operace úloh by měly být v souladu s principy rozhraní Azure Well-Architected Framework. Všechny důležité úlohy s aktivním cyklem DevOps by měly mít vyhrazenou podporu od týmu úloh.

Cílem přezkumu provozní způsobilosti je pravidelně vyhodnocovat provozní způsobilost na všech úrovních. Identifikovaná vylepšení pak mohou být použita na příslušné úrovni, aby informovala o změnách potřebných ke správě celkového portfolia.

Proces kontroly provozní způsobilosti

Klíčem k zachování výkonu a kontinuity portfolia podniku je implementace procesu kontroly provozní způsobilosti.

Přehled procesu kontroly provozní způsobilosti

Na vysoké úrovni má proces dvě fáze. Ve fázi požadavků se požadavky stanoví a mapují na podpůrné služby. K této fázi dochází zřídka: možná ročně nebo při zavádění nových operací. Výstup fáze předpokladů se používá ve fázi toku. Fáze toku se vyskytuje častěji, například měsíčně.

Fáze požadavků

Kroky v této fázi zachycují požadavky na provádění pravidelné kontroly portfolia a všech důležitých úloh.

  1. Identifikace důležitých obchodních operací Identifikujte klíčové obchodní operace podniku na základě dohodnutých obchodních závazků. Obchodní operace jsou nezávislé na všech podpůrných funkcích služeb. Jinými slovy, obchodní operace představují skutečné aktivity, které firma musí provádět a které jsou podporovány sadou IT služeb.

    Termín "kritická" (neboli pro firmu kritická) odráží závažný dopad na firmu, pokud je operace ztížená. Online prodejce může například provádět obchodní operaci, například "umožnit zákazníkovi přidat položku do nákupního košíku" nebo "zpracovat platbu platební kartou". Pokud se některý z těchto operací nezdaří, zákazník nemůže dokončit transakci a podnik nedokáže realizovat prodej.

  2. Mapování operací na služby Namapujte důležité obchodní operace na SLUŽBY IT (standardní hodnoty, operace platformy nebo úloh), které je podporují. Pro mapování operací a služeb na zodpovědné týmy by měla být také identifikována jakákoli technologická platforma nebo úloha potřebná k podpoře důležitých obchodních funkcí.

  3. Analýza závislostí služby Většina obchodních operací vyžaduje orchestraci mezi několika podpůrnými úlohami a technologickými platformami. Je důležité pochopit závislosti mezi jednotlivými sadami podpůrných prostředků a tok klíčových transakcí prostřednictvím těchto služeb.

    Zvažte také závislosti mezi místními službami a službami Azure. V příkladu nákupního košíku může být služba správy zásob hostovaná místně a ingestovat data zadaná zaměstnanci z fyzického skladu. Může ale ukládat data mimo místní prostředí ve službě Azure, jako je Azure Storage, nebo v databázi, jako je Azure Cosmos DB.

Výstupem z těchto aktivit je sada metrik přehledu výkonnostních metrik pro správu operací. Přehled výkonnostních metrik měří kritéria, jako je spolehlivost, výkon a náklady. Metriky přehledu výkonnostních metrik vyjadřují provozní kritéria, která očekáváte, že služba bude splňovat.

Přehled výkonnostních metrik by měl být vyjádřen jednoduchými výrazy, aby bylo možné smysluplně diskutovat mezi vlastníky firmy, cloudovým provozem a týmy úloh. Metrika přehledu výkonnostních metrik pro spolehlivost může být například barevně odlišovaná na základě dosažení smluv SLA. Zelená znamená splnění definované smlouvy SLA, žlutá znamená nesplnění definovaných kritérií, ale aktivní implementaci plánované nápravy a červená znamená nesplnění definovaných kritérií bez plánu nebo akce.

Je důležité zdůraznit, že tyto metriky by měly přímo odrážet obchodní závazky.

Fáze kontroly služeb

Fáze kontroly služeb je základem kontroly provozní způsobilosti. Zahrnuje tyto kroky:

  1. Měření metrik služby Metriky přehledu výkonnostních metrik použijte k monitorování výkonu na jednotlivých úrovních správy provozu, abyste zajistili, že služby splňují obchodní závazky. Služby inventáře a viditelnosti v rámci směrného plánu operací jsou nezbytné. Pokud nemůžete monitorovat sadu prostředků s ohledem na obchodní závazky, zvažte, že odpovídající metriky přehledu výkonnostních metrik jsou červené. V tomto případě je prvním krokem k nápravě implementace odpovídajícího monitorování služby. Pokud například firma očekává, že služba bude fungovat s 99,99% dostupností, ale neexistuje žádná produkční telemetrie pro měření dostupnosti, předpokládejme, že tento požadavek nesplníte.

  2. Naplánujte nápravu. Pro každý obchodní závazek, pro který metriky spadají pod přijatelnou prahovou hodnotu, určete odpovídající provozní tým, který dokončí požadovanou nápravu. Tento tým zodpovídá za výpočet nákladů na nápravu služby, aby se operace na přijatelnou úroveň. Pokud jsou náklady na nápravu problému vyšší než rozpočet přidělený této službě, mělo by centrální ODDĚLENÍ IT/CCoE projít s týmem cloudové strategie a vyhodnotit další investice.

  3. Implementujte nápravu. Jakmile cloudový provoz nebo tým úloh přijme plán nápravy, implementujte ho. Pokaždé, když zkontrolujete metriky přehledu výkonnostních metrik, nahlaste stav implementace.

Tento proces je iterativní. Centrální tým IT/CCoE zodpovídá za správu procesu a hlášení o průběhu týmu cloudové strategie. Tento tým by se měl pravidelně scházet, aby zkontroloval stávající nápravné projekty, zahájil základní revizi nových úloh a sledoval celkový přehled výkonnostních metrik podniku. Tým by také měl mít oprávnění k tomu, aby týmy pro nápravu (cloudové operace nebo operace úloh) zodpovídaly v případě, že jsou pozadu nebo nesplní metriky.

Zkontrolovat schůzku

Doporučujeme, aby se vaše provozní zdatnost pravidelně kontrolovala. Centrální tým IT / CCoE a cloudový provozní tým jsou povinnou účastí na kontrole. Týmům pro cloudovou strategii a provoz úloh se doporučuje, aby se zúčastnily, ale jsou funkční. Základní tým se může například scházet každý měsíc, aby se přizpůsobil plánům a pohnali k zodpovědnosti různé provozní týmy. Čtvrtletně by se mohla připojit cloudová strategie a všechny týmy úloh, aby porozuměly stavu a metrikám.

Přizpůsobte si podrobnosti procesu a schůzky tak, aby vyhovovaly vašim konkrétním potřebám. Jako výchozí bod doporučujeme následující aspekty:

  • Centralizované operace: Týmy úloh se pravděpodobně nebudou aktivně účastnit procesu, ale měly by být zahrnuty do všech sestav, aby se zviditelnilo.
  • Decentralizované operace: Tým cloudového provozu by měl s týmy úloh sdílet osvědčené postupy používané ke zlepšení provozu technických platforem. Týmy úloh by měly sdílet změny v příslušných úlohách, aby identifikovaly vylepšení, která by bylo možné použít u technických platforem a standardních hodnot provozu.
  • Azure Automanage. Azure Automanage automaticky monitoruje provozní způsobilost napříč standardními provozními hodnotami a automatizuje použití různých strategií náprav v rámci portfolia.
  • Azure Advisor Azure Advisor poskytuje přizpůsobená doporučení na základě vašeho využití a konfigurací, která vám pomůžou optimalizovat prostředky. Ve výchozím nastavení tento nástroj poskytuje doporučení pro celé předplatné za účelem vylepšení standardních hodnot operací. Dá se také použít podrobněji k identifikaci vylepšení technologických platforem nebo jednotlivých úloh.
  • Microsoft Azure Well-Architected Framework: Pokyny ke zlepšení operací úloh nebo k vedení decentralizovaných operací.