Azure Governance je rozsáhlou metodologií, která říká, jak správně řídit Azure prostředí. Nejde jen o samotné zdroje, ale o promítnutí firemních politik a procesů do praxe a technické konfigurace. Správné řízení Azure cloudu se skládá z celkem pěti hlavních disciplín. Jednotlivé disciplíny budou postupně hlouběji rozebírány v jednotlivých článcích.

V dnešním článku si rozebereme disciplínu Resource Consistency – což je v překladu konzistence zdrojů, řekněme jakási jejich přehlednost a struktura. Touto disciplínou je dobré začít proto, že nám říká, jak začít budovat své Azure prostředí lépe, přehledně a strukturovaně. Nemusí se vyloženě jednat jen o budování nového prostředí, praktiky pro Resource Consistency se mohou aplikovat i do již vytvořených struktur. Jejich adopce bude však o něco složitější, než když se začíná na „zelené louce“. Přehlednost zdrojů a jejich konzistenci můžeme v Azure řídit pomocí několika nástrojů, které budou vynucovat některá nastavení automaticky a nedovolí tak nekontrolovatelné rozšiřování prostředí, které může být časem nepřehledné a měsíční faktury mohou být noční můrou všech účetních.

Resource Consistency se také zaměřuje na řešení rizik souvisejících se správou provozu cloudových služeb jak z pohledu IT, tak i z business pohledu. Součástí analýzy rizik je shromáždění dat souvisejících s operacemi, které se provádí na daných zdrojích. Díky tomu se dá zjistit, jak velkému riziku čelíte a jak moc je důležitá investice do této disciplíny. Každá organizace má různé provozní scénáře, nicméně níže uvedený seznam položek přináší hezký příklad toho, jaké metriky je potřeba sbírat a sledovat. Na základě těchto metrik můžeme vytvořit sledovací nebo automatizované mechanismy, které zajistí, že budou dodrženy nastavená pravidla a procesy.

Metrika	Popis
Cloudové zdroje	Celkový počet nasazených zdrojů v cloudu.
Neoznačené zdroje	Počet zdrojů, které nejsou označeny. Nemají žádné tagy pro účetnictví, dopadu na business nebo označení organizační struktury.
Nevyužité zdroje	Počet zdrojů, kde jejich RAM paměť, CPU nebo síťové vytížení neodpovídá jejich kapacitě a jsou většinou nevyužité.
Přetěžované zdroje	Počet zdrojů, kde jsou jejich kapacity RAM, CPU a sítě velmi často přetěžované.
Stáří zdroje	Čas, kdy byl zdroj vytvořen nebo změněn. Vhodné je uvést i datum, kdy už zdroj nebude potřeba a může být smazán (vývoj, testování, dema atd.).
Virtuální servery s kritickou kondicí	Počet VM, které nemají dobrou kondici a je potřebný zásah pro jejich opětovné uvedení do normálního provozu.
Upozornění dle vážnosti	Celkový počet upozornění na nasazeném zdroji v členění podle závažnosti.
Problém na síťový zařízeních	Počet zdrojů, které mají problém se síťovým připojením.
Problém se servisními koncovými body	Počet problémů s koncovými body externí sítě.
Incidenty služeb cloudového providera	Počet výpadků nebo problémů se sítí způsobených poskytovatelem služeb.
SLA	Sledování SLA, které může obsahovat, zda byly dodrženy podmínky ze strany Microsoftu, ale i tak podmínky, kterými se zavazujete u zákazníků nebo externích partnerů.
Dostupnost služby	Procenta, kdy byla služba skutečné dostupná v porovnání s očekávanou dostupností.
Čas pro obnovu (RTO)	Maximální akceptovatelný čas, kdy může být služba nebo aplikace nedostupná v případě poruchy.
Bod obnovy dat (RPO)	Míra času, ve které akceptujeme ztrátu dat při havárii. Například data uložená v jediné databázové instanci bez replikace s hodinovou zálohou znamená maximálně hodinovou ztrátu dat.
Průměrný čas pro obnovení (MTTR)	Průměrný čas potřebný pro obnovení služby po chybě.
Průměrný čas mezi incidenty (MTBF)	Průměrné určení času, kdy může služba nebo aplikace bezproblémově běžet mezi výpadky. Tato metrika nám může pomoci predikovat a určit, jak často bude služba nedostupná.
Stav zálohy	Stav a počet záloh, které byly úspěšně dokončeny. Případně synchronizovány bez problému.
Stav obnovení	Počet úspěšných operací obnovy služby nebo aplikace.

Pomůckou, která definuje nástroje a etapy jejich použití, je Resource Consistency rozhodovací průvodce, který popisuje následující obrázek:

Zdroj: Microsoft

Ve své podstatě nám říká, jak začít, kde pokračovat a jaké nástroje bychom měli použít. Rozhodujícími faktory, jestli v Azure Governance pokračovat v pojetí konzistence zdrojů závisí na velikosti společnosti a množstvím zdrojů, které v cloudu má. Prakticky nemá smysl řešit hierarchii subskripcí, když máme jen jednu, případně dvě. K tomu je samozřejmě navázaná komplexnost samotného prostředí a také to, jestli jsme nějakým způsobem do řízení zdrojů v cloudu nuceni vnějšími nařízeními, certifikacemi nebo normami. Při větším množství subskripcí nám pak mohou pomoci vytvořit smysluplnou strukturu Azure Management Groups.

Zdroj: Microsoft

Podobnou pomůcku jako u rozhodovacího průvodce pro konzistenci můžeme použít i pro „tagování“ (označování) zdrojů. Následující obrázek popisuje spojení tagů z IT a business pohledu.

Zdroj: Microsoft

Základní jmenná konvence nám říká, jak pojmenovávat zdroje – skvělou pomůckou je tento jmenný standard definovaný Microsoftem. Podle něj jsme již na první pohled schopni určit typ zdroje a k čemu pravděpodobně slouží.

Označení funkce zdroje nám říká, k čemu využíváme ten nebo onen virtuální server – app, data, archive, automation atd.

Klasifikace pomůže rozeznat, jestli jde o privátní, veřejný nebo přísné tajný zdroj, případně klasifikaci SLA, důležitost a jiné.

Účetní označení slouží k lepšímu sledování výdajů jednotlivých zdrojů a ke komu půjde příslušná faktura – může to být oddělení, název projektu, případně region.

Vlastník zdroje je velmi používaný tag, protože říká, na koho se obrátit v případě problémů se zdrojem nebo v případě jeho vysokých nákladů nebo při překročení času, po který měl být zdroj vytvořen.

Posledním označením zdroje je business pohled, který definuje hodnotu zdroje a pomůže při investičním rozhodování – např. business critical, revenue impact, business process a jiné. Tagy přináší opravdu neomezené a užitečné možnosti, je však zapotřebí jejich správná definice, která bude dávat smysl.

V příštím článku se podíváme na zoubek disciplíně Security Baseline.