Obchodní závazek při správě cloudu

Definování obchodního závazku je cvičení při vyrovnávání priorit. Cílem je sladit správnou úroveň provozního řízení s přijatelnými provozními náklady. Nalezení této rovnováhy vyžaduje několik datových bodů a výpočtů, které jsme nastínili v tomto článku.

Závazky k obchodní stabilitě prostřednictvím technické odolnosti nebo jiných dopadů smlouvy o úrovni služeb (SLA) jsou obchodním odůvodněním. Pro většinu úloh v prostředí je dostatečná základní úroveň správy cloudu. Pro ostatní je 2x až 4x nárůst nákladů snadno zdůvodněn potenciálním dopadem jakéhokoli přerušení podnikání.

Předchozí články v této sérii vám pomůžou pochopit klasifikaci a dopad přerušení na různé úlohy. Tento článek vám pomůže vypočítat vrácení. Jak je znázorněno na předchozím obrázku, každá úroveň správy cloudu má inflexní body, u kterých se náklady můžou zvýšit rychleji než zvýšení odolnosti. Tyto inflexní body budou vyžadovat podrobná obchodní rozhodnutí a obchodní závazky.

Určení správného závazku s firmou

Pro každou úlohu v portfoliu by se tým cloudového provozu a tým cloudové strategie měly sladit s úrovní správy, kterou zajišťuje přímo tým cloudového provozu.

Při vytváření závazku s firmou je potřeba sladit několik klíčových aspektů:

• Požadavky na provoz IT.
• Odpovědnost za správu.
• Cloudová architektura tenantů.
• Faktory měkkých nákladů.
• Návratnost návratnosti ztrát.
• Ověření úrovně správy

Abychom vám pomohli při rozhodování, popisuje zbývající část tohoto článku tyto aspekty podrobněji.

Požadavky na provoz IT

Průvodce správou Azure popisuje nástroje pro správu, které jsou dostupné v Azure. Před dosažením závazku s firmou by IT mělo určit přijatelný standardní směrný plán správy, který se použije pro všechny spravované úlohy. IT pak vypočítá standardní náklady na správu pro každou spravovanou úlohu v portfoliu IT na základě počtu jader procesoru, místa na disku a dalších proměnných souvisejících s prostředky. IT také odhadlo kombinovanou smlouvu SLA pro každou úlohu na základě architektury.

Tip

Provozní týmy IT často používají výchozí minimální dobu provozu 99,9 % pro počáteční kombinovanou smlouvu SLA. Můžou se také rozhodnout normalizovat náklady na správu na základě průměrného zatížení, zejména u řešení s minimálními potřebami protokolování a úložiště. Zprůměrování nákladů na několik úloh se střední důležitostí může poskytnout výchozí bod pro počáteční konverzace.

Tip

Pokud k plánování správy cloudu používáte sešit správy provozu , měla by se pole správy provozu aktualizovat tak, aby odrážela tyto požadavky. Mezi tato pole patří Úroveň závazku, Kombinovaná smlouva SLA a Měsíční náklady. Měsíční náklady by měly představovat měsíční náklady na přidané nástroje provozní správy.

Směrný plán provozní správy slouží jako počáteční výchozí bod pro ověření v každé z následujících částí.

Odpovědnost za správu

V tradičním místním prostředí se náklady na správu prostředí běžně považují za potopené náklady vlastněné it operacemi. V cloudu je správa účelné rozhodnutí s přímým dopadem na rozpočet. Náklady na jednotlivé funkce správy se dají přímo připsat každé úloze nasazené do cloudu. Tento přístup umožňuje větší kontrolu, ale vytváří požadavek, aby se týmy cloudového provozu a týmy cloudové strategie nejprve zavázaly k dohodě o zodpovědnostech.

Organizace se také můžou rozhodnout, že některé ze svých průběžných funkcí správy přejdou na poskytovatele služeb. Tito poskytovatelé služeb můžou pomocí Služby Azure Lighthouse organizacím poskytnout přesnější kontrolu při udělování přístupu k jejich prostředkům a také lepší přehled o akcích prováděných poskytovateli služeb.

• Delegovaná odpovědnost: Vzhledem k tomu, že není potřeba centralizovat a předpokládat režijní náklady na provozní správu, zvažuje provoz IT v mnoha organizacích nové přístupy. Jeden běžný přístup se označuje jako delegovaná odpovědnost. V modelu špičkového cloudového centra poskytují provoz platformy a automatizace platforem nástroje pro samoobslužnou správu, které můžou využívat obchodní provozní týmy, nezávisle na centralizovaných provozních týmech IT. Díky tomuto přístupu mají obchodní účastníci úplnou kontrolu nad rozpočty souvisejícími se správou. Umožňuje také týmu CCoE (Cloud Center of Excellence) zajistit správnou implementaci minimální sady mantinely. V tomto modelu funguje IT jako zprostředkovatel a průvodce, který pomáhá firmě dělat moudrá rozhodnutí. Obchodní provoz dohlíží na každodenní provoz závislých úloh.

• Centralizovaná odpovědnost: Požadavky na dodržování předpisů, technická složitost a některé modely sdílených služeb můžou vyžadovat model centrálního týmu IT . V tomto modelu IT nadále vykonává své povinnosti spojené se správou provozu. Návrh životního prostředí, kontrolní mechanismy a nástroje zásad správného řízení mohou být centrálně řízeny a kontrolovány, což omezuje roli obchodních subjektů při přijímání závazků v oblasti řízení. Ale přehled o nákladech a architektuře cloudových přístupů usnadňuje centralizovaným IT komunikaci nákladů a úrovně správy jednotlivých úloh.

• Smíšený model: Klasifikace je jádrem smíšeného modelu odpovědností za správu. Společnosti, které jsou uprostřed transformace z místního prostředí na cloud, můžou nějakou dobu vyžadovat místní provozní model. Společnosti s přísnými požadavky na dodržování předpisů nebo společnosti, které jsou závislé na dlouhodobých smlouvách s dodavateli IT outsourcingu, mohou vyžadovat centralizovaný provozní model.

  Bez ohledu na svá omezení musí dnešní podniky inovovat. Když musí rychlé inovace vzkvétat, uprostřed centrálního modelu IT a centralizované odpovědnosti, může přístup založený na smíšeném modelu poskytnout rovnováhu. Při tomto přístupu poskytuje centrální tým IT centralizovaný provozní model pro všechny úlohy, které jsou důležité pro chod firmy nebo obsahují citlivé informace. Všechny ostatní klasifikace úloh mohou být současně umístěny v cloudovém prostředí, které je navržené pro delegované odpovědnosti. Přístup centralizované odpovědnosti slouží jako obecný provozní model. Firma má pak flexibilitu pro přijetí specializovaného provozního modelu na základě požadované úrovně podpory a citlivosti.

Prvním krokem je zavázat se k přístupu odpovědnosti, který pak formuje následující závazky.

Která organizace bude odpovědná za každodenní správu provozu pro tuto úlohu?

Cloudová architektura tenantů

Pro většinu firem je správa jednodušší, když se všechny prostředky nacházejí v jednom tenantovi. Některé organizace ale můžou potřebovat udržovat více tenantů. Informace o tom, proč může firma vyžadovat prostředí Azure s více tenanty, najdete v tématu Centralizace operací správy pomocí služby Azure Lighthouse.

Bude se tato úloha nacházet společně se všemi ostatními úlohami v jednom tenantovi Azure?

Faktory měkkých nákladů

Další část popisuje přístup ke srovnávacím výnosům, které souvisejí s úrovněmi procesů řízení a nástrojů. Na konci této části každá analyzovaná úloha měří náklady na správu vzhledem k předpokládanému dopadu přerušení podnikání. Tento přístup poskytuje poměrně snadný způsob, jak zjistit, zda je investice do bohatších přístupů ke správě oprávněná.

Než čísla spustíte, je důležité se podívat na faktory s mírnými náklady. Faktory měkkých nákladů generují výnos, ale tento výnos je obtížné měřit prostřednictvím přímých úspor tvrdých nákladů, které by byly viditelné ve výkazu zisků a ztrát. Faktory s mírnými náklady jsou důležité, protože můžou znamenat potřebu investovat do vyšší úrovně řízení, než je rozpočtově obezřetné.

Několik příkladů faktorů s mírnými náklady může zahrnovat:

• Denní využití úloh správní radou nebo generálním ředitelem.
• Využití úloh x % nejvyšších zákazníků, které vede k většímu dopadu na výnosy jinde.
• Dopad na spokojenost zaměstnanců.

Dalším datovým bodem, který se vyžaduje k vytvoření závazku, je seznam faktorů s mírnými náklady. Tyto faktory nemusí být v této fázi dokumentovány, ale obchodní účastníci by si měli být vědomi důležitosti těchto faktorů a jejich vyloučení z následujících výpočtů.

Výpočet návratnosti návratnosti ztrát

Při výpočtu relativní návratnosti nákladů na řízení provozu by it tým zodpovědný za cloudový provoz měl splnit výše uvedené požadavky a předpokládat minimální úroveň správy pro všechny úlohy.

Dalším závazkem, který je třeba učinit, je přijetí nákladů spojených s nabídkou spravovanou podle směrného plánu ze strany firmy.

Souhlasí firma s tím, že bude investovat do základní nabídky, aby splňovala minimální standardy cloudového provozu?

Pokud firma nesouhlasí s danou úrovní správy, musí být navrženo řešení, které firmě umožní pokračovat, aniž by to mělo podstatný vliv na cloudové operace jiných úloh.

Pokud firma chce více, než je standardní úroveň správy, zbytek této části vám pomůže ověřit tuto investici a související výnosy (ve formě předcházení ztrátám).

Vyšší úrovně správy: Principy návrhu a katalog služeb

U spravovaných řešení je možné kromě směrného plánu správy použít několik principů návrhu a šablonových řešení. Každý z principů návrhu pro spolehlivost a odolnost zvyšuje provozní náklady na zatížení. Aby se IT a firma na těchto dodatečných závazcích dohodly, je důležité porozumět potenciálním ztrátám, kterým je možné se těmito zvýšenými investicemi vyhnout.

Následující výpočty vás provedou vzorci, které vám pomůžou lépe porozumět rozdílům mezi ztrátami a zvýšenými investicemi do správy. Pokyny k výpočtu nákladů na zvýšenou správu najdete v tématu Automatizace úloh a Automatizace platformy.

Tip

Pokud k plánování správy cloudu používáte sešit správy provozu , aktualizujte pole správy provozu tak, aby odrážela jednotlivé konverzace. Mezi tato pole patří Úroveň závazku, Kombinovaná smlouva SLA a Měsíční náklady. Měsíční náklady by měly představovat měsíční náklady na přidané nástroje pro provozní správu. Po aktualizaci budou pole aktualizovat vzorce NÁVRATNOSTI a všechna následující pole.

Odhad výpadku (počet hodin za rok)

Composite SLA je smlouva o úrovni služeb, která je založená na nasazení každého prostředku v úloze. Toto pole řídí odhadovaný výpadek (označený Est.Outage v sešitu). Pokud chcete vypočítat odhadovaný výpadek v hodinách za rok bez použití sešitu, použijte následující vzorec:

Odhadovaný výpadek = (1 – složené procento smlouvy SLA) × počet hodin v roce

Sešit používá výchozí hodnotu 8 760 hodin za rok.

Dopad standardní ztráty

Standardní dopad ztráty (označený Standard Impact v sešitu) předpovídá finanční dopad jakéhokoli výpadku za předpokladu, že se odhadovaná předpověď výpadku ukáže jako správná. Pokud chcete tuto prognózu vypočítat bez použití sešitu, použijte následující vzorec:

Standardní dopad = odhadovaný výpadek při třech 9s doby provozu × dopad na časovou hodnotu

To slouží jako základ pro náklady, pokud by se obchodní účastníci rozhodli investovat do vyšší úrovně správy.

Dopad složené smlouvy SLA

Dopad na složenou smlouvu SLA (označený Commitment level impact v sešitu) poskytuje aktualizovaný fiskální dopad na základě změn smlouvy SLA o době provozu. Tento výpočet umožňuje porovnat předpokládaný finanční dopad obou možností. Pokud chcete vypočítat dopad této prognózy bez tabulky, použijte následující vzorec:

Dopad na složenou smlouvu SLA = odhadovaný dopad výpadku × dopad na časovou hodnotu

Tato hodnota představuje potenciální ztráty, kterým by se mělo vyhnout změněná úroveň závazku a nová kombinovaná smlouva SLA.

Základ porovnání

Srovnávací základna vyhodnocuje standardní dopad a složený dopad smlouvy SLA a určuje, která z nich je ve sloupci pro vrácení nejvhodnější.

Návratnost vyhnutí se ztrátě

Pokud náklady na správu úloh překročí potenciální ztráty, navrhovaná investice do správy cloudu nemusí být plodná. Pokud chcete porovnat návratnost při předcházení ztrátám, podívejte se na sloupec s názvem RoI*****. Pokud chcete tento sloupec vypočítat sami, použijte následující vzorec:

Výnos z předcházení ztrátám = (srovnávací základ – (měsíční náklady × 12) ) ÷ (měsíční náklady × 12) )

Pokud není potřeba vzít v úvahu další faktory s mírnými náklady, může toto porovnání rychle navrhnout, jestli by se měly investovat hlouběji do cloudového provozu, odolnosti, spolehlivosti nebo jiných oblastí.

Ověření závazku

V tomto okamžiku procesu byly učiněny závazky: centralizovaná nebo delegovaná odpovědnost, tenantská architektura Azure a úroveň závazku. Každý závazek by měl být ověřen a zdokumentován, aby se zajistilo, že tým cloudového provozu, tým cloudové strategie a obchodní účastníci jsou na tomto závazku ke správě úloh sladění.

Další kroky

Po provedení závazků můžou zodpovědné provozní týmy začít danou úlohu konfigurovat. Abyste mohli začít, vyhodnoťte různé přístupy k inventáři a viditelnosti.

Možnosti inventáře a viditelnosti