Sdílet prostřednictvím

Kompromisy spolehlivosti za Power Platform pracovní zátěž

  • Článek

Spolehlivá úloha konzistentně splňuje definované cíle spolehlivosti. Měla by dosáhnout stanovených cílů odolnosti, ideálně obcházením událostí, které ovlivňují spolehlivost. Reálně však musí úloha tolerovat a kontrolovat dopad takových událostí a udržovat operace na předem stanovené úrovni během aktivní poruchy. I během katastrofy se musí spolehlivá úloha zotavit do určitého stavu a v daném časovém období, jak je dohodnuto s účastníky. Plán reakce na incidenty, který vám umožní dosáhnout rychlé detekce a zotavení, je zásadní.

Během fáze návrhu úlohy je důležité zvážit, jak rozhodnutí na základě principů návrhu spolehlivosti a doporučení v kontrolním seznamu kontroly návrhu ohledně spolehlivosti může ovlivnit cíle a optimalizaci ostatních pilířů. Některá rozhodnutí mohou být přínosem pro některé pilíře, zatímco pro jiné mohou být kompromisem. Tento článek uvádí příklady kompromisů, se kterými se tým úlohy může setkat při navrhování architektury úlohy a operací z hlediska spolehlivosti.

Kompromisy ve spolehlivosti v souvislosti se zabezpečením

Kompromis: Větší pracovní plocha. Pilíř zabezpečení upřednostňuje snížené a uzavřené možnosti útoku, aby se minimalizovaly vektory útoků a omezila se správa bezpečnostních opatření.

  • Spolehlivosti je často dosaženo replikací. Replikace může probíhat na úrovni komponent, na úrovni dat nebo dokonce na geografické úrovni. Repliky z podstaty rozšiřují možnosti útoku na úlohu. Z pohledu zabezpečení jsou upřednostňovány snížené a uzavřené možnosti útoku, aby se minimalizovaly potenciální vektory útoků a zefektivnila správa bezpečnostních opatření.

  • Podobně řešení pro zotavení po havárii, jako jsou zálohy, rozšiřují možnosti útoku na úlohu. Často jsou však izolovány od modulu runtime úlohy. To vyžaduje implementaci dalších bezpečnostních opatření, která mohou být specifická pro řešení zotavení po havárii.

  • Kvůli cílům spolehlivosti může architektura vyžadovat další komponenty, které rozšiřují možnosti útoku. Tato zvýšená složitost rozšiřuje možnosti útoku na úlohu přidáním nových komponent, které je třeba zabezpečit, a třeba i způsoby, které zatím nejsou v systému použity. Tyto komponenty jsou obvykle doprovázeny dodatečným kódem pro jejich použití nebo obecnými vzory spolehlivosti, což také rozšiřuje možnosti útoku na aplikaci.

Kompromis: Obejití bezpečnostní kontroly. Pilíř zabezpečení doporučuje, aby všechna opatření zůstala aktivní v normálních i namáhaných systémech.

  • Když úloha zaznamená událost spolehlivosti, která je řešena aktivní reakcí na incidenty, naléhavost situace může vytvořit tlak na týmy pro úlohy, aby obcházely bezpečnostní opatření, která jsou optimalizována pro rutinní přístup.

  • Aktivity při odstraňování problémů mohou způsobit, že tým dočasně deaktivuje bezpečnostní protokoly, takže již tak namáhaný systém může být vystaven dalším bezpečnostním rizikům. Existuje také riziko, že bezpečnostní protokoly nebudou okamžitě obnoveny.

  • Granulární implementace bezpečnostních opatření, jako jsou přiřazení řízení přístupu na základě rolí nebo pravidla brány firewall, zavádějí složitost a citlivost konfigurace, což zvyšuje šanci nesprávné konfigurace. Zmírnění tohoto potenciálního dopadu na spolehlivost použitím tolerantních pravidel narušuje všechny tři principy architektury nulové důvěry (Zero Trust).

Kompromis: Staré verze softwaru. Pilíř zabezpečení podporuje přístup k opravám zabezpečení dodavatelů typu „získej aktualizace, zůstaň aktuální“.

  • Použití aktualizací vln vydání nebo aktualizací na knihovny dodavatelů, jako jsou komponenty nebo řešení třetích stran, může potenciálně narušit cílovou komponentu a způsobit její nedostupnost během této aktualizace. Zpoždění nebo vyhnutí se opravám může zabránit potenciálním ohrožením spolehlivosti, ale ponechává systém nechráněný proti vyvíjejícím se hrozbám.

  • Předchozí úvaha platí také pro kód úlohy. Týká se například kódu aplikace, který používá staré knihovny a komponenty. Pokud je aktualizace a nasazení kódu aplikace považováno za nezmírněné riziko spolehlivosti, aplikace je v průběhu času vystavena dalším bezpečnostním rizikům.

Kompromisy ve spolehlivosti v souvislosti s provozní dokonalostí

Kompromis: Zvýšená provozní složitost. Provozní dokonalost, stejně jako samotná spolehlivost, upřednostňuje jednoduchost.

  • Mít komplexní strategii monitorování úlohy je klíčovou součástí provozní dokonalosti. Zavedení dalších komponent do architektury za účelem implementace vzorů návrhu spolehlivosti vede ke správě více zdrojů dat, což zvyšuje složitost implementace distribuovaného trasování a pozorovatelnosti.

  • Použití více oblastí k překonání omezení kapacity zdrojů jedné oblasti a/nebo implementace aktivní architektury zvyšuje složitost provozní správy úlohy. Tato složitost je způsobena potřebou spravovat více oblastí a spravovat replikaci dat mezi nimi.

Kompromis: Zvýšené úsilí o vytváření týmových znalostí a povědomí. Pilíř provozní dokonalosti doporučuje používat a udržovat úložiště dokumentace ohledně procedur a topologie.

  • Vzhledem k tomu, že se úloha stává robustnější v důsledku přidaných komponent a vzorů spolehlivosti, údržba provozních postupů a dokumentace artefaktů vyžaduje více času.

  • Školení se stává složitější, jak se zvyšuje počet komponent v úloze. Tato složitost ovlivňuje dobu potřebnou pro onboarding a zvyšuje znalosti potřebné ke sledování produktových plánů a pokynů na úrovni služeb.

Kompromisy ve spolehlivosti v souvislosti s optimalizací prostředí

Kompromis: Snížená agilita. Pilíř optimalizace prostředí upřednostňuje efektivitu uživatelů.

  • Důraz na přísné testování může zpozdit vydání funkcí, které jsou nezbytné pro zavedení.

  • Optimalizace spolehlivosti může přehnaně minimalizovat složitost, což znevýhodňuje funkce pro poutavější uživatelské prostředí, jako jsou vlastní komponenty a integrace.

Kompromisy spolehlivosti s účinností výkonu

Kompromis: Zvýšená latence. Výkon Efektivita vyžaduje systém k dosažení výkonnostních cílů pro uživatele a datové toky.

  • Vzory spolehlivosti často zahrnují replikaci dat, aby přežily poruchu repliky. Replikace zavádí další latenci pro spolehlivé operace zápisu dat, které spotřebovávají část rozpočtu na výkon pro konkrétního uživatele nebo datový tok.

  • Spolehlivost někdy využívá různé formy vyvažování zdrojů k distribuci nebo přerozdělení zátěže na zdravé repliky. Vyhrazená komponenta, která se používá pro vyvažování, obvykle ovlivňuje výkon požadavku nebo procesu, který je vyvažován.

  • Distribuce komponent přes geografické hranice nebo zóny dostupnosti, aby přežily rozsah dopadu, zavádí latenci sítě do komunikace mezi komponentami, které tyto hranice dostupnosti překračují.

  • Ke sledování zdravotního stavu pracovní zátěže se používají rozsáhlé procesy. I když je monitorování pro spolehlivost kritické, přístrojové vybavení může ovlivnit výkon systému. Se zvyšující se pozorovatelností může klesat výkon.

Kompromis: Zvýšené nadměrné zajišťování. Pilíř Performance Efficiency odrazuje od nadměrného zajišťování, místo toho doporučuje použití právě dostatečného množství zdrojů k uspokojení poptávky.

  • Operace automatického škálování nejsou okamžité, a proto nemohou spolehlivě zvládnout náhlý a dramatický nárůst poptávky, který nelze tvarovat nebo vyhlazovat. Proto je nadměrné poskytování prostřednictvím větších instancí nebo více instancí kritickou taktikou spolehlivosti, která zohledňuje zpoždění mezi signálem poptávky a tvorbou nabídky. Nevyužitá kapacita je v rozporu s cíli efektivity výkonu.

  • Někdy nelze komponentu škálovat v reakci na poptávku a tato poptávka není plně předvídatelná. Použití velkých instancí k pokrytí nejhoršího případu vede k nadměrnému poskytování odpadu v situacích, které jsou mimo tento případ použití.