Sdílet prostřednictvím


Kompromisy pro spolehlivost

Spolehlivá úloha konzistentně splňuje definované cíle spolehlivosti. Měl by dosáhnout zavedených cílů odolnosti, ideálně obcházením událostí, které ovlivňují spolehlivost. V reálném případě ale úloha musí tolerovat a řídit dopad těchto událostí a udržovat operace na předem určené úrovni během aktivní poruchy. I během havárie se spolehlivá úloha musí v daném časovém období zotavit do určitého stavu, z nichž obě jsou mezi zúčastněnými stranami dohodnuty. Zásadní je plán reakce na incidenty, který umožňuje dosáhnout rychlé detekce a obnovení.

Během fáze návrhu úlohy je potřeba zvážit, jak rozhodnutí na základě principů návrhu spolehlivosti a doporučení v kontrolním seznamu pro kontrolu návrhu pro spolehlivost můžou ovlivnit cíle a optimalizace jiných pilířů. Určitá rozhodnutí mohou mít prospěch z některých pilířů, ale představují kompromis pro jiné. Tento článek popisuje ukázkové kompromisy, se kterými se může setkat tým úloh při navrhování architektury úloh a operací pro spolehlivost.

Kompromisy spolehlivosti se zabezpečením

Kompromis: Zvýšená plocha pracovního vytížení. Pilíř zabezpečení upřednostňuje omezenou a obsaženou plochu, aby minimalizoval vektory útoku a snížil správu bezpečnostních prvků.

  • Spolehlivost se často získává prostřednictvím replikace. Replikace může nastat na úrovni komponenty, na úrovni dat nebo dokonce na geografické úrovni. Repliky podle návrhu zvyšují plochu úlohy. Z hlediska zabezpečení se upřednostňuje zmenšená a obsažená plocha, aby se minimalizovaly potenciální vektory útoku a zjednodušily správu kontrolních mechanismů zabezpečení.

  • Podobně řešení zotavení po havárii, jako jsou zálohy, zvyšují plochu úlohy. Často jsou však izolované od modulu runtime úlohy. Tato řešení vyžadují implementaci dalších kontrolních mechanismů zabezpečení, které můžou být specifické pro přístup pro zotavení po havárii.

  • Kvůli cílům spolehlivosti mohou být pro architekturu potřeba další komponenty, které zvyšují plochu. Například sběrnice zpráv může být přidána k zajištění odolnosti požadavků prostřednictvím oddělení. Tato zvýšená složitost zvyšuje plochu úlohy přidáním nových komponent, které je potřeba zabezpečit, pravděpodobně způsoby, které se v systému ještě nepoužívají. Tyto komponenty jsou obvykle doprovázeny dalšími kódy a knihovnami, které podporují jejich použití nebo obecné vzory spolehlivosti, což také zvyšuje plochu aplikace.

Kompromis: Obejití bezpečnostních kontrol. Pilíř zabezpečení doporučuje, aby všechny kontroly zůstaly aktivní v normálních i stresovaných systémech.

  • Pokud u úlohy dochází k události spolehlivosti, která se řeší v rámci aktivní reakce na incidenty, může naléhavost způsobit tlak týmům úloh, aby obešly kontrolní mechanismy zabezpečení, které jsou optimalizované pro rutinní přístup.

  • Aktivity při řešení potíží můžou způsobit, že tým dočasně zakáže protokoly zabezpečení, takže už zatížený systém může být vystavený dalším bezpečnostním rizikům. Existuje také riziko, že se protokoly zabezpečení nebudou znovu publikovat okamžitě.

  • Podrobné implementace kontrolních mechanismů zabezpečení, jako jsou vlastní přiřazení řízení přístupu na základě role nebo úzká pravidla brány firewall, představují složitost konfigurace a citlivost, což zvyšuje šanci na nesprávnou konfiguraci. Zmírnění tohoto potenciálního dopadu na spolehlivost pomocí rozsáhlých pravidel vyloučí všechny tři principy architektury nulová důvěra (Zero Trust).

Kompromis: Staré verze softwaru. Pilíř zabezpečení podporuje přístup k zajištění aktuálního a aktuálního přístupu k opravám zabezpečení dodavatele.

  • Použití oprav zabezpečení nebo aktualizací softwaru může potenciálně narušit cílovou komponentu, což může způsobit nedostupnost během změny softwaru. Zpoždění nebo zabránění opravám se může vyhnout potenciálním rizikům spolehlivosti, ale systém zůstane nechráněný proti vyvíjejícím se hrozbám.

  • Předchozí aspekty platí také pro kód úlohy. Týká se to například kódu aplikace, který používá staré knihovny a kontejnery, které používají staré základní image. Pokud se aktualizace a nasazení kódu aplikace zobrazí jako neohrožované riziko spolehlivosti, aplikace se v průběhu času vystavuje dalším bezpečnostním rizikům.

Kompromisy při spolehlivosti s optimalizací nákladů

Kompromis: Zvýšená redundance implementace nebo plýtvání. Úloha optimalizovaná pro náklady minimalizuje nedostatečně využité prostředky a zabraňuje nadměrnému zřizování prostředků.

  • Replikace je klíčovou strategií pro spolehlivost. Konkrétně je strategie dostatek replikace pro zpracování daného počtu souběžných selhání uzlů. Tolerance pro více souběžných selhání uzlů vyžaduje vyšší počet replik, což vede ke zvýšení nákladů.

  • Nadměrné zřizování je další technika pro absorbování neočekávaného zatížení systému, například během události převzetí služeb při selhání, která by jinak mohla vést k problému se spolehlivostí. Jakákoli nadbytečná kapacita, která se nevyužívá, se považuje za plýtvání.

  • Pokud úloha používá řešení zotavení po havárii, které nadměrně splňuje cíle bodu a času úlohy, vede nadbytek k vyšším nákladům z důvodu plýtvání.

  • Samotná nasazení úloh představují potenciální zdroj pro dopad na spolehlivost a tento dopad je často zmírnit redundancí v době nasazení prostřednictvím strategie nasazení, jako je modrá/zelená. Tato přechodná duplikace prostředků během bezpečného nasazení obvykle zvyšuje celkové náklady na úlohu během těchto období. Náklady se zvyšují s frekvencí nasazení.

Kompromis: Vyšší investice do provozu, které nejsou v souladu s funkčními požadavky. Jedním z přístupů k optimalizaci nákladů je vyhodnocení hodnoty poskytované všemi nasazenými řešeními.

  • K dosažení spolehlivosti systém vyžaduje pozorovatelnost. Systémy monitorování vyžadují přenos a shromažďování dat pozorovatelnosti. S rostoucími možnostmi monitorování se frekvence a objem dat zvyšuje, což vede k dalším nákladům.

  • Dostupnost spolehlivosti v úlohách vyžaduje testování a postupy. Navrhování a spouštění testů trvá určitou dobu a potenciálně specializované nástroje, za které se účtují náklady.

  • Úlohy s cíli s vysokou spolehlivostí často mají rychlý proces odezvy, který vyžaduje, aby členové technického týmu byly součástí formální obměny na volání. Tento proces způsobuje dodatečné náklady na personál a ztrátu nákladů na příležitosti kvůli pozornosti, která by mohla být směrována jinde. Za řízení procesu se také účtují potenciální náklady na nástroje.

  • Smlouvy o podpoře s poskytovateli technologií jsou klíčovou součástí spolehlivé úlohy. Smlouvy o podpoře, které se nevyužívají, protože úroveň podpory je nadměrně zřízená.

Kompromisy mezi spolehlivostí díky efektivitě provozu

Kompromis: Zvýšená provozní složitost. Efektivita provozu, jako je spolehlivost sama, upřednostňuje jednoduchost.

  • Spolehlivost obvykle zvyšuje složitost úlohy. S rostoucí složitostí úloh se také můžou zvýšit provozní prvky úlohy, aby podporovaly přidané komponenty a procesy z hlediska koordinace nasazení a oblasti konfigurace.

  • Komplexní strategie monitorování pro úlohu je klíčovou součástí efektivity provozu. Zavedení dalších komponent do architektury pro implementaci 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 prostředků jedné oblasti nebo implementace aktivní/aktivní architektury zvyšuje složitost provozní správy úlohy. Tato složitost je zaváděná nutností spravovat více oblastí a nutností spravovat replikaci dat mezi nimi.

Kompromis: Zvýšené úsilí o generování týmových znalostí a povědomí. Pilíř Efektivita provozu doporučuje uchovávat a udržovat úložiště dokumentace pro postupy a topologie.

  • Vzhledem k tomu, že se úloha stává robustnější díky přidání komponent a vzorů spolehlivosti, trvá delší dobu, než se zachová provozní postupy a dokumentace k artefaktům.

  • Trénování se s rostoucím počtem komponent v úloze stává složitější. Tato složitost ovlivňuje čas potřebný k onboardingu. Složitost také zvyšuje znalosti potřebné ke sledování plánů produktů a nejnovějších pokynů na úrovni služeb.

Kompromisy mezi spolehlivostí díky efektivitě výkonu

Kompromis: Zvýšená latence. Efektivita výkonu vyžaduje systém pro dosažení výkonnostních cílů pro toky uživatelů a dat.

  • Vzorce spolehlivosti často zahrnují replikaci dat, aby přežila selhání 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 tok dat.

  • Spolehlivost někdy využívá různé formy vyrovnávání prostředků k distribuci nebo redistribuci zatížení do replik, které jsou v pořádku. Vyhrazená komponenta, která se používá k vyrovnávání, obvykle ovlivňuje výkon požadavku nebo procesu, který se vyrovnává.

  • Distribuce komponent napříč geografickými hranicemi nebo zónami dostupnosti za účelem přežití omezeného dopadu přináší latenci sítě při komunikaci mezi komponentami, které tyto hranice dostupnosti pokrývají.

  • Rozsáhlé procesy se používají ke sledování stavu úlohy. Monitorování je sice důležité pro spolehlivost, ale instrumentace může ovlivnit výkon systému. S nárůstem pozorovatelnosti může dojít ke snížení výkonu.

Kompromis: Zvýšení nadměrného zřizování. Pilíř efektivity výkonu nedoporučuje příliš zřizovat, místo toho doporučuje používat pouze dostatek prostředků, aby uspokojily poptávku.

  • Automatické operace škálování nejsou okamžité, a proto nedokáže spolehlivě zvládnout náhlý a dramatický nárůst poptávky, který nelze tvarovat ani vyhladit. Nadměrné zřizování prostřednictvím větších instancí nebo více instancí je proto důležitou taktikou spolehlivosti, která zohledňuje prodlevu mezi signálem poptávky a vytvořením nabídky, která pomáhá absorbovat nárůsty. Nevyužitá kapacita čítače cílů efektivity výkonu.

  • Někdy není možné škálovat komponentu 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 zřizování plýtvání v situacích, které jsou mimo případ použití.

Prozkoumejte kompromisy pro ostatní pilíře: