Kompromisy Operational Excellence za Power Platform pracovní zátěž
Operational Excellence podporuje kvalitu pracovní zátěže prostřednictvím implementace jasných týmových standardů, pochopení odpovědnosti a odpovědnosti, pozornosti k výsledkům zákazníků a soudržnosti týmu. Implementace těchto cílů má kořeny v postupech DevOps, které doporučují minimalizovat odchylky procesů, omezit lidskou chybu a v konečném důsledku zvýšit návratnost hodnoty úlohy. Tato hodnota se neměří pouze ve vztahu k funkčním požadavkům, které obsluhují součásti pracovní zátěže. Je měřena také hodnotou, kterou tým poskytuje ve snaze o zlepšení.
Během fáze návrhu pracovní zátěže a během jejího životního cyklu, kdy jsou přijímány kroky k neustálému zlepšování, je důležité zvážit, jak se rozhodují na základě principů návrhu provozní dokonalosti a doporučení v kontrolní seznam kontroly návrhu pro Operational Excellence může ovlivnit cíle a optimalizace další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í.
Kompromisy v provozní dokonalosti v souvislosti se spolehlivostí
Kompromis: Zvýšená složitost. Spolehlivost upřednostňuje jednoduchost, protože jednoduchý návrh minimalizuje nesprávnou konfiguraci a omezuje neočekávané interakce.
Strategie bezpečného nasazení často vyžadují určitou míru dopředné a zpětné kompatibility mezi aplikační logikou a daty v úloze. Tato přidaná složitost zvyšuje zátěž testování a může vést ke složitosti nebo problémům s integritou s daty úlohy.
Vysoce vrstvené, modularizované nebo parametrizované struktury mohou zvýšit pravděpodobnost náhodné chybné konfigurace kvůli složitosti interakce mezi komponentami úlohy.
Vzory cloudového návrhu, které jsou přínosem pro operace, někdy vyžadují zavedení více komponent, například použití tajného úložiště nebo závislosti na Application Insights. Dodatečné komponenty zvyšují body interakce v systému, čímž se zvyšuje možnost selhání nebo nesprávné konfigurace.
Nasazení malých, přírůstkových změn je technika pro zmírnění rizika, ale uživatelé očekávají, že tyto malé změny budou dodávány do výroby častěji. Nasazení může destabilizovat systém, takže s rostoucí rychlostí nasazení roste i toto riziko.
Kultura, která se poměřuje metrikami rychlosti, například podle počtu nasazení za týden, a používá automatizaci usnadňující zavádění změn rychlejším tempem, také pravděpodobně provede více nasazení za kratší dobu.
Zvýšení hustoty za účelem zjednodušení operací snížením počtu kontrolních a pozorovatelných bodů může také vést ke zvýšenému riziku dostupnosti, protože nesprávná funkce nebo nesprávná konfigurace zvyšuje účinek destabilizující události.
Kompromisy v provozní dokonalosti v souvislosti se zabezpečením
Komponenty, které obklopují úlohu a podporují její operace, jako je automatizace nebo vlastní řídicí rovina, musí být rovněž předmětem pravidelného posilování a testování zabezpečení.
Rutinní, neplánované a nouzové operace zvyšují kontaktní body s pracovní zátěží. Přístup nulové důvěry vyžaduje, aby byly tyto procesy považovány za zranitelná místa a musely být zahrnuty do bezpečnostních kontrol a ověřování pro pracovní zátěž.
Platforma pozorovatelnosti systému shromažďuje protokoly a metriky o úloze, což může být cenným zdrojem zveřejňování informací. Proto je třeba rozšířit zabezpečení úlohy, aby byla chráněna úložiště dat před interními a externími hrozbami.
Agenti pro sestavení, externalizovaná konfigurace a úložiště přepínačů funkcí – to vše zvyšuje oblasti potenciálního útoku, které vyžadují zabezpečení.
Vyšší frekvence nasazení způsobená malými postupnými změnami nebo snahou „získej aktuální, zůstaň aktuální“ vede k většímu testování zabezpečení v životním cyklu vývoje softwaru (SDLC).
Platformy pozorovatelnosti ingestují data všech typů, aby získali přehled o stavu a chování úlohy. S tím, jak se týmy snaží dosáhnout vyšší věrnosti v datech pozorovatelnosti, existuje zvýšené riziko, že kontroly klasifikace dat zdrojových systémů, například maskování dat, se nerozšíří na protokoly a protokolovací jímky v platformě pozorovatelnosti.
Společné umístění různorodých komponent aplikací ve sdílených prostředích a zdrojích dat pro snazší správu obrátí segmentaci nebo ztíží dosažení segmentace založené na rolích. Společně umístěné komponenty mohou také vyžadovat sdílení identity úlohy, což může vést k nadměrnému množství přiřazených oprávnění nebo nedostatečné sledovatelnosti.
Shromažďování všech protokolů z celého systému do jednotného úložiště protokolů může usnadnit dotazování a vytváření výstrah. To však může také ztížit nebo znemožnit poskytování řádkového zabezpečení pro zpracování citlivých dat s požadovanými kontrolami auditu.
Zjednodušení správy zabezpečení založeného na atributech nebo rolích snížením granularity rolí a jejich přiřazení může vést k nepatřičně širokým oprávněním.
Kompromisy v provozní dokonalosti v souvislosti s optimalizací prostředí
Vývoj uživatelského zážitku, který vyžaduje značné zdroje, může být upřednostněn, což může způsobit nedostatek použitelnosti, interakcí a vizuálního designu, které uživatelé potřebují.
Vývoj uživatelského rozhraní se často provádí v rychlejších iteracích a lodních cyklech, což může zatěžovat týmové procesy SDLC.
Kompromisy Operational Excellence s účinností výkonu
- Rámec monitorování pracovní zátěže vyžaduje, aby komponenty v architektuře přidělovaly čas a zdroje k vytváření, shromažďování a streamování protokolů a metrik. Tyto datové body pomáhají zajistit, že je možné účinné upozornění a monitorování spolehlivosti, zabezpečení a výkonu. Se zvyšující se úrovní přístrojového vybavení se může zvýšit i zatížení systémových prostředků.
- Některé vzory cloudového návrhu, které podporují přístupy „nezávislé změny v průběhu času“ na podporu ideálů postupného zlepšování, mohou zavádět latenci kvůli průchodu dalších komponent.