Üzleti elkötelezettség a felhőkezelésben

Az üzleti kötelezettségvállalás meghatározása a prioritások kiegyensúlyozásának gyakorlata. A cél az operatív felügyelet megfelelő szintjének megfelelő szintű igazítása elfogadható üzemeltetési költségekhez. Az egyenleg megállapításához szükség van néhány adatpontra és számításra, amelyeket ebben a cikkben ismertetünk.

Az üzleti stabilitásra vonatkozó kötelezettségvállalások a műszaki rugalmasság vagy más szolgáltatásiszint-megállapodások (SLA) hatásai révén üzleti indoklással kapcsolatos döntések. A környezet legtöbb számítási feladatához elegendő a felhőkezelés alapszintje. Mások számára a 2-4-szeres költségnövekedés könnyen indokolt az üzleti megszakítások lehetséges hatása miatt.

A sorozat korábbi cikkei segíthetnek megérteni a különböző számítási feladatok megszakításainak besorolását és hatását. Ez a cikk segítséget nyújt a visszatérések kiszámításában. Ahogy az előző képen is látható, a felhőkezelés minden egyes szintje rendelkezik olyan inflexiós pontokkal, ahol a költségek gyorsabban emelkedhetnek, mint a rugalmasság növekedése. Ezek az inflexiós pontok részletes üzleti döntéseket és üzleti kötelezettségvállalásokat fognak kérni.

A vállalkozással való megfelelő kötelezettségvállalás meghatározása

A portfólió minden számítási feladatához a felhőüzemeltetési csapatnak és a felhőstratégiáért felelős csapatnak igazodnia kell a felhőüzemeltetési csapat által közvetlenül biztosított felügyeleti szinthez.

Miközben elkötelezi magát az üzlettel, néhány fontos szempontot kell összehangolnia:

• Informatikai üzemeltetési előfeltételek.
• Felügyeleti felelősség.
• Felhőbeli bérlő.
• Helyreállítható költségtényezők.
• Veszteségelkerülési MEGTÉRÜLÉS.
• A felügyeleti szint ellenőrzése.

A döntési folyamat támogatásához a cikk hátralévő része részletesebben ismerteti ezeket a szempontokat.

Informatikai üzemeltetési előfeltételek

Az Azure felügyeleti útmutatója ismerteti az Azure-ban elérhető felügyeleti eszközöket. Mielőtt elkötelezi magát az üzlettel, az informatikai részlegnek meg kell határoznia egy elfogadható standard szintű felügyeleti alapkonfigurációt, amelyet az összes felügyelt számítási feladatra alkalmazni kell. Ezt követően az informatikai portfólióban lévő összes felügyelt számítási feladathoz standard felügyeleti költséget számítana ki a processzormagok, a lemezterület és az egyéb eszközhöz kapcsolódó változók száma alapján. Az informatikai szolgáltató az architektúra alapján minden számítási feladathoz egy összetett SLA-t is megbecsülne.

Tipp

Az informatikai üzemeltetési csapatok gyakran legalább 99,9 százalékos alapértelmezett üzemidőt használnak a kezdeti összetett SLA-hoz. Dönthetnek úgy is, hogy az átlagos számítási feladat alapján normalizálják a felügyeleti költségeket, különösen a minimális naplózási és tárolási igényű megoldások esetében. Néhány közepes kritikussági számítási feladat költségeinek átlagolása kiindulópontot jelenthet a kezdeti beszélgetésekhez.

Tipp

Ha az operations management munkafüzetet használja a felhőfelügyelet megtervezéséhez, az operations management mezőket frissíteni kell, hogy megfeleljenek ezeknek az előfeltételeknek. Ezek a mezők tartalmazzák a kötelezettségvállalási szintet, az összetett SLA-t és a havi költséget. A havi költségnek a hozzáadott üzemeltetési felügyeleti eszközök havi költségeit kell képviselnie.

Az operations management alapkonfigurációja az alábbi szakaszokban érvényesítendő kezdeti kiindulási pontként szolgál.

Felügyeleti felelősség

Hagyományos helyszíni környezetben a környezet kezelésének költsége általában az informatikai műveletek tulajdonában lévő, elsüllyedt költségnek számít. A felhőben a felügyelet céltudatos döntés, közvetlen költségvetési hatással. Az egyes felügyeleti függvények költségei közvetlenül hozzárendelhetők a felhőben üzembe helyezett összes számítási feladathoz. Ez a megközelítés nagyobb kontrollt tesz lehetővé, de követelményt teremt a felhőüzemeltetési csapatok és a felhőstratégiáért felelős csapatok számára, hogy először véglegesítsenek egy, a felelősségekkel kapcsolatos megállapodást.

A szervezetek dönthetnek úgy is, hogy kiszervezik a folyamatban lévő felügyeleti funkciók egy részét egy szolgáltatónak. Ezek a szolgáltatók az Azure Lighthouse használatával pontosabb ellenőrzést biztosíthatnak a szervezeteknek az erőforrásaikhoz való hozzáférés biztosításában, valamint nagyobb betekintést nyújthatnak a szolgáltatók által végrehajtott műveletekbe.

• Delegált felelősség: Mivel nem kell központosítani és átvenni az üzemeltetési felügyeleti többletterhelést, számos szervezet informatikai műveletei új megközelítéseket fontolgatnak. Az egyik gyakori megközelítést delegált felelősségnek nevezzük. A felhőbeli kiválósági modellben a platformműveletek és a platformautomatizálás olyan önkiszolgáló felügyeleti eszközöket biztosítanak, amelyeket az üzleti vezetésű üzemeltetési csapatok használhatnak, függetlenül a központosított informatikai üzemeltetési csapattól. Ez a megközelítés teljes körű ellenőrzést biztosít az üzleti résztvevőknek a felügyelettel kapcsolatos költségvetések felett. Emellett lehetővé teszi a felhőbeli kiválósági központ (CCoE) csapatának, hogy biztosítsa a minimális védőkorlátok megfelelő implementálását. Ebben a modellben az informatikai részleg közvetítőként és útmutatóként szolgál az üzleti döntések meghozatalában. Az üzleti műveletek felügyelik a függő számítási feladatok napi műveleteit.

• Központosított felelősség: A megfelelőségi követelmények, a műszaki összetettség és egyes megosztott szolgáltatási modellek központi informatikai csapatmodellt igényelhetnek. Ebben a modellben az INFORMATIKAI továbbra is gyakorolja az üzemeltetéskezelési feladatait. A környezeti tervezés, a felügyeleti vezérlők és a szabályozási eszközök központilag kezelhetők és vezérelhetők, ami korlátozza az üzleti szereplők szerepét a felügyeleti kötelezettségvállalások teljesítésében. A felhőbeli megközelítések költségének és architektúrájának láthatósága azonban sokkal egyszerűbbé teszi a központosított informatikai rendszer számára az egyes számítási feladatok költségeinek és kezelési szintjének közlését.

• Vegyes modell: A besorolás a felügyeleti felelősségek vegyes modelljének középpontjában áll. Azok a vállalatok, amelyek a helyszíniről a felhőbe való átalakítás közepén vannak, egy ideig helyszíni első üzemeltetési modellt igényelhetnek. A szigorú megfelelőségi követelményekkel rendelkező vagy az informatikai kiszervezési szállítókkal kötött hosszú távú szerződésektől függő vállalatok központi üzemeltetési modellt igényelhetnek.

  A korlátozásoktól függetlenül a mai vállalkozásoknak innovációra van szükség. Amikor a gyors innovációnak virágoznia kell, egy központi informatikai, központosított felelősségi modell közepén a vegyes modellel való megközelítés egyensúlyt teremthet. Ebben a megközelítésben a központi informatikai csapat központosított üzemeltetési modellt biztosít minden olyan számítási feladathoz, amely kritikus fontosságú, vagy bizalmas információkat tartalmaz. Ugyanakkor az összes többi számítási feladat besorolása elhelyezhető egy olyan felhőkörnyezetben, amely delegált felelősségekhez van kialakítva. A központosított felelősségi megközelítés az általános üzemeltetési modell. A vállalat ezután rugalmasan alkalmazhat egy speciális üzemeltetési modellt a szükséges szintű támogatás és érzékenység alapján.

Az első lépés egy felelősségi megközelítésre való véglegesítés, amely a következő kötelezettségvállalásokat alakítja ki.

Melyik szervezet felel majd a számítási feladat napi műveleteinek felügyeletéért?

Felhőbeli bérlő

A legtöbb vállalkozás esetében egyszerűbb a felügyelet, ha az összes eszköz egyetlen bérlőben található. Előfordulhat azonban, hogy egyes szervezeteknek több bérlőt is fenn kell tartaniuk. Ha meg szeretné tudni, hogy egy vállalat miért igényelhet több-bérlős Azure-környezetet, olvassa el a Felügyeleti műveletek központosítása az Azure Lighthouse-ral című témakört.

Ez a számítási feladat egyetlen Azure-bérlőben fog elhelyezkedni az összes többi számítási feladat mellett?

Helyreállítható költségtényezők

A következő szakasz a felügyeleti folyamatok és az eszközök szintjeihez kapcsolódó összehasonlító visszatérések megközelítését ismerteti. A szakasz végén minden elemzett számítási feladat az üzleti fennakadások előrejelzési hatásához viszonyítva méri a kezelés költségeit. Ez a megközelítés viszonylag egyszerű módot kínál annak megértésére, hogy indokolt-e a gazdagabb felügyeleti megközelítésekbe történő befektetés.

A számok futtatása előtt fontos áttekinteni a helyreállítható költségek tényezőit. A helyreállítható költségtényezők hozamot eredményeznek, de ezt a megtérülést nehéz közvetlen, költségmegtakarítással mérni, amely látható lenne egy eredménykimutatásban. A soft-cost tényezők azért fontosak, mert azt jelezhetik, hogy a pénzügyi szempontból megfontolandónál magasabb szintű vezetésbe kell befektetni.

Néhány példa a helyreállítható költségekre:

• A napi számítási feladatok kihasználtsága a vezetőség vagy a vezérigazgató szerint.
• A számítási feladatok kihasználtsága az ügyfelek felső x%- ában, ami máshol nagyobb bevételi hatást eredményez.
• Az alkalmazottak elégedettségére gyakorolt hatás.

A kötelezettségvállaláshoz szükséges következő adatpont a helyreállítható költségek tényezőinek listája. Ezeket a tényezőket jelenleg nem kell dokumentálni, de az üzleti érdekelt feleknek tisztában kell lenniük ezeknek a tényezőknek a fontosságával és az alábbi számításokból való kizárásukkal.

Veszteségelkerülési megtérülés kiszámítása

Az üzemeltetéskezelési költségek relatív megtérülésének kiszámításakor a felhőműveletekért felelős informatikai csapatnak teljesítenie kell a korábban említett előfeltételeket, és fel kell vennie egy minimális szintű felügyeletet az összes számítási feladathoz.

A következő kötelezettségvállalás az, hogy a vállalkozás elfogadja az alapkonfiguráció által kezelt ajánlathoz kapcsolódó költségeket.

A vállalat beleegyezik abba, hogy az alapkonfigurációs ajánlatba fektet be, hogy megfeleljen a felhőműveletek minimális szabványainak?

Ha a vállalat nem fogadja el ezt a szintű felügyeletet, olyan megoldást kell kidolgozni, amely lehetővé teszi a vállalkozás számára a folytatást anélkül, hogy ez jelentős hatással lenne más számítási feladatok felhőbeli műveleteire.

Ha az üzlet a standard felügyeleti szintnél többet szeretne, a szakasz hátralévő része segít ellenőrizni a befektetést és a kapcsolódó megtérülést (veszteségelkerülés formájában).

Magasabb szintű felügyelet: Tervezési alapelvek és szolgáltatáskatalógus

Felügyelt megoldások esetén a felügyeleti alapkonfiguráció mellett számos tervezési alapelv és sablonmegoldás is alkalmazható. A megbízhatóság és a rugalmasság minden tervezési alapelve üzemeltetési költségeket ad a számítási feladathoz. Ahhoz, hogy az informatikai részleg és a vállalkozás megállapodjon ezekről a további kötelezettségvállalásokról, fontos megérteni a potenciális veszteségeket, amelyek elkerülhetők a megnövekedett befektetéssel.

Az alábbi számítások képleteket mutatnak be, amelyek segítenek jobban megérteni a veszteségek és a nagyobb felügyeleti befektetések közötti különbségeket. A megnövekedett felügyelet költségeinek kiszámításával kapcsolatos útmutatásért lásd: Számítási feladatok automatizálása és platformautomatizálás.

Tipp

Ha az operations management munkafüzetet használja a felhőkezelés megtervezéséhez, frissítse az operations management mezőket úgy, hogy tükrözzék az egyes beszélgetéseket. Ezek a mezők tartalmazzák a kötelezettségvállalási szintet, az összetett SLA-t és a havi költséget. A havi költségnek a hozzáadott üzemeltetési felügyeleti eszközök havi költségét kell képviselnie. A frissítések után a mezők frissítik a ROI-képleteket és az alábbi mezők mindegyikét.

Üzemkimaradás becslése (óra/év)

Az összetett SLA egy szolgáltatási szintű szerződés, amely az egyes objektumok számítási feladatban való üzembe helyezésén alapul. Ez a mező a becsült kimaradást (a munkafüzetben címkézve Est.Outage ) hajtja végre. Ha a munkafüzet használata nélkül szeretné kiszámítani a becsült üzemkimaradást óránként óránként, alkalmazza a következő képletet:

Becsült üzemkimaradás = (1 – összetett SLA százalék) × óraszám egy év alatt

A munkafüzet az alapértelmezett évi 8760 órát használja.

Standard veszteség hatása

A standard ( a munkafüzetben címkézett Standard Impact ) veszteséghatás előrejelezi a kimaradások pénzügyi hatását, feltéve, hogy a becsült kimaradás előrejelzése pontosnak bizonyul. Ha a munkafüzet használata nélkül szeretné kiszámítani ezt az előrejelzést, alkalmazza a következő képletet:

Standard hatás = becsült üzemkimaradás @ három 9 üzemidő × időértékre gyakorolt hatás

Ez a költség alapkonfigurációjaként szolgál, ha az üzleti érdekelt felek magasabb szintű vezetésbe fektetnek be.

Az összetett SLA hatása

Az összetett SLA-hatás (a munkafüzetben címkézett Commitment level impact ) frissített pénzügyi hatást biztosít az üzemidőSLA változásai alapján. Ez a számítás lehetővé teszi mindkét lehetőség várható pénzügyi hatásának összehasonlítását. Ha számolótábla nélkül szeretné kiszámítani ezt az előrejelzési hatást, alkalmazza a következő képletet:

Összetett SLA-hatás = becsült kimaradás × időértékre gyakorolt hatás

Az érték a megváltozott kötelezettségvállalási szint és az új összetett SLA által elkerülhető potenciális veszteségeket jelöli.

Összehasonlítás alapja

Az összehasonlítási alap kiértékeli a standard hatást és az összetett SLA-hatást annak meghatározásához, hogy melyik a legmegfelelőbb a visszatérési oszlopban.

Visszatérés a veszteségelkerüléshez

Ha a számítási feladatok kezelésének költsége meghaladja a lehetséges veszteségeket, előfordulhat, hogy a felhőkezelésbe történő tervezett befektetés nem lesz eredményes. A Veszteségelkerülési megtérülés összehasonlításához tekintse meg az Éves ROI**** címkével ellátott oszlopot. Az oszlop önálló kiszámításához használja a következő képletet:

Veszteségelkerülés megtérülése = (összehasonlítási alap – (havi költség × 12) ) ÷ (havi költség × 12) )

Ha nincs más megfontolandó költségtényező, ez az összehasonlítás gyorsan arra utalhat, hogy a felhőműveletbe, a rugalmasságba, a megbízhatóságba vagy más területekbe kell-e mélyebb befektetést fektetni.

A kötelezettségvállalás érvényesítése

A folyamat ezen pontján kötelezettségvállalások történtek: központosított vagy delegált felelősség, Azure-bérlő és kötelezettségvállalási szint. Minden egyes kötelezettségvállalást ellenőrizni és dokumentálni kell annak biztosítása érdekében, hogy a felhőüzemeltetési csapat, a felhőstratégiáért felelős csapat és az üzleti érdekelt felek igazodjanak ehhez a kötelezettségvállaláshoz a számítási feladat kezeléséhez.

Következő lépések

A kötelezettségvállalások teljesítése után a felelős üzemeltetési csapatok megkezdhetik a kérdéses számítási feladat konfigurálását. Első lépésként értékelje ki a leltár és a láthatóság különböző megközelítéseit.

Leltározási és láthatósági beállítások