Azure Governance díl I. – Resource Consistency
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.
![Share on Facebook Facebook](https://www.oldrichsrubar.cz/wp-content/plugins/social-media-feather/synved-social/image/social/regular/64x64/facebook.png)
![Share on Twitter twitter](https://www.oldrichsrubar.cz/wp-content/plugins/social-media-feather/synved-social/image/social/regular/64x64/twitter.png)
![Share on Reddit reddit](https://www.oldrichsrubar.cz/wp-content/plugins/social-media-feather/synved-social/image/social/regular/64x64/reddit.png)
![Pin it with Pinterest pinterest](https://www.oldrichsrubar.cz/wp-content/plugins/social-media-feather/synved-social/image/social/regular/64x64/pinterest.png)
![Share on Linkedin linkedin](https://www.oldrichsrubar.cz/wp-content/plugins/social-media-feather/synved-social/image/social/regular/64x64/linkedin.png)
![Share by email mail](https://www.oldrichsrubar.cz/wp-content/plugins/social-media-feather/synved-social/image/social/regular/64x64/mail.png)