Sdílet prostřednictvím

Doporučení pro jednoduché a efektivní návrhy

  • Článek

Platí pro toto doporučení kontrolního seznamu spolehlivosti pro Well-Architected Power Platform:

RE:01 Navrhujte úlohy, které jsou v souladu s obchodními cíli a nejsou zbytečné složité nebo nemají zbytečnou režii. K rozhodování o návrhu zaujměte praktický a vyvážený přístup, který přináší požadované výsledky. Vytvořte návrh, jen jak je nezbytné, abyste minimalizovali neefektivitu a potenciální problémy.

Tato příručka popisuje doporučení, jak minimalizovat zbytečnou složitost a režii, aby byla úloha jednoduchá a efektivní. Zvolte nejlepší komponenty pro provádění nezbytných úkolů úlohy, abyste optimalizovali její spolehlivost. Chcete-li snížit zátěž související s vývojem a správou, využijte výhod, které nabízejí služby poskytované platformou. Tento návrh vám pomůže vytvořit architekturu úlohy, která je odolná, opakovatelná, škálovatelná a spravovatelná.

Definice

Pojem definice
Pracovní zatížení Samostatná schopnost nebo výpočetní úloha, kterou můžete logicky oddělit od ostatních úloh.

Klíčové strategie návrhu

Klíčovým principem návrhu spolehlivé úlohy je udržovat věci jednoduché a efektivní. Návrh úlohy zaměřte na naplnění obchodních požadavků, abyste snížili riziko zbytečné složitosti nebo nadměrné režie. Zvažte doporučení v tomto článku, která vám pomohou při rozhodování o vašem návrhu, abyste vytvořili štíhlou, efektivní a spolehlivou úlohu. Různé úlohy mohou mít různé požadavky na dostupnost, škálovatelnost, konzistenci dat a zotavení po havárii.

Každé designové rozhodnutí musíte odůvodnit obchodním požadavkem. Tento princip návrhu se může zdát samozřejmý, ale pro návrh úlohy je zásadní. Podporuje vaše úloha miliony uživatelů, nebo několik tisíc? Dochází k velkému nárazovému provozu nebo stálému vytížení? Jaká úroveň výpadku je přijatelná? Obchodní požadavky stojí na pozadí těchto úvah o návrhu.

Kompromis Komplexní řešení může nabídnout více funkcí a větší flexibilitu, ale může ovlivnit spolehlivost úlohy, protože vyžaduje větší koordinaci, komunikaci a správu jednotlivých komponent. Případně jednodušší řešení nemusí plně splňovat očekávání uživatelů nebo může mít negativní vliv na rozšiřitelnost s tím, jak se úloha vyvíjí.

Cvičení návrhu na bázi spolupráce

Spolupracujte s účastníky na:

  • Definování a přiřazení úrovně kritičnosti vaší úloze a jejím komponentám. Toto cvičení vám pomůže určit požadované komponenty a nejlepší přístup k dosažení požadované úrovně odolnosti. Další informace najdete v části Definování vrstev aplikací.

  • Definování funkčních a nefunkčních požadavků. Funkční požadavky definují vlastnosti a chování systému. Jsou specifikovány uživatelem a zaznamenány v případech použití. Nefunkční požadavky definují výkonnostní a kvalitativní atributy systému. Ujistěte se, že rozumíte nefunkčním požadavkům, jako je dostupnost, dodržování předpisů, uchovávání/sídlo dat, výkon, soukromí, doba obnovy, zabezpečení a škálovatelnost. Tyto požadavky ovlivňují rozhodnutí o návrhu a výběru technologie.

    Zde je několik příkladů funkčních a nefunkčních požadavků v kontextu úlohy, která zpracovává sestavy výdajů:

    Funkční požadavky Nefunkční požadavky
    Úloha by měla uživatelům umožnit přihlášení pomocí jejich přihlašovacích údajů a přístup pouze k jejich osobním údajům. Úloha by měla být dostupná alespoň po 99,9 % času.
    Úloha by měla zahrnovat řídicí panel, který poskytuje přehled otevřených, schválených a odmítnutých sestav výdajů. Úloha by měla odpovídat příslušným předpisům a standardům pro ochranu dat a soukromí.
    Úloha by měla podporovat operace zálohování a zotavení dat. Úloha by u většiny požadavků uživatelů měla mít dobu odezvy do 5 sekund.
    Úloha by měla odesílat oznámení uživatelům a správcům, když jsou aktivovány určité události nebo prahové hodnoty. Úloha by měla mít vysokou úroveň zabezpečení a šifrování dat při přenosu a v klidu.

    Další informace najdete ve školicím modulu s názvem Práce s požadavky pro Microsoft Power Platform a Dynamics 365.

  • Rozdělení úloh na komponenty. Během procesu zjišťování a shromažďování požadavků by se některé nápady na řešení měly začít vyjasňovat. Identifikujte součásti řešení, které by mohly tvořit navrhované řešení, aby splňovalo vaše obchodní požadavky. Při návrhu upřednostněte jednoduchost, efektivitu a spolehlivost. Určete komponenty, které potřebujete k podpoře své úlohy. Zdůrazněte, kde lze použít předdefinované funkce a kde může být zapotřebí vlastní vývoj.

  • Použití analýzy režimu selhání k identifikaci jednotlivých bodů selhání a potenciálních rizik. Jasně rozumějte toleranci vaší firmy k riziku. Další informace naleznete v části Doporučení pro provádění analýzy režimu selhání.

  • Definování dostupnosti a cílů obnovy pro svou úlohu, abyste mohli rozhodovat o architektuře. Obchodní metriky zahrnují cíle na úrovni služeb (SLO), smlouvy o rozsahu služeb (SLA), střední dobu do obnovení (MTTR), střední dobu mezi selháním (MTBF), cíle doby obnovení (RTO) a cíle bodů obnovení (RPO). Definujte cílové hodnoty pro tyto metriky. Toto cvičení může vyžadovat kompromis a vzájemné porozumění mezi technologickými a obchodními týmy, aby bylo zajištěno, že cíle každého týmu splňují obchodní cíle a jsou realistické. Další informace viz Doporučení pro definování cílů spolehlivosti. Smlouvy SLA v Power Platform poskytují závazky společnosti Microsoft týkající se provozuschopnosti a možností připojení. Různé služby mají různé smlouvy SLA a někdy i jednotlivé SKU v rámci služby mají různé smlouvy SLA. Další informace naleznete v tématu Smlouvy o rozsahu služeb pro online služby.

Další doporučení k návrhu

Následující doporučení můžete provést bez zapojení účastníků:

  • Usilujte o jednoduchost a srozumitelnost návrhu. Použijte vhodnou úroveň abstrakce a podrobností pro vaše komponenty a služby. Vyvarujte se příliš komplikovanému nebo příliš jednoduchému řešení. Příklad:

    • Pokud řešíte požadavek na automatizaci procesů pomocí Power Automate, rozdělení velkého procesu na několik menších cloudových toků může ztížit pochopení, testování a údržbu. Na druhou stranu, udržování všeho ve velkém toku může mít negativní dopad na výkon a objem volání rozhraní API.

    • Pokud řešíte požadavek na uživatele pomocí Power Apps, velká monolitická aplikace plátna s mnoha ovládacími prvky může mít negativní dopad na výkon. Rozdělení na jednotlivé aplikace nebo vlastní stránky může ztížit testování, ale může mít významný pozitivní dopad na výkon.

  • Předvídejte změny v průběhu času, ať už jde o opravu chyb, implementaci nových funkcí nebo technologií nebo o zvýšení škálovatelnosti a odolnosti stávajících systémů.

  • Přesuňte průřezové záležitosti do samostatné služby. Minimalizujte potřebu duplikování kódu napříč různými funkcemi. Preferujte opakované použití služeb s dobře definovanými rozhraními, která mohou být snadno spotřebována různými komponentami. Pokud je například třeba provést sadu datových operací z různých míst, můžete tuto funkci přesunout do modulu plug-in s minimem kódu.

  • Vyhodnoťte vhodnost běžných vzorců a postupů pro vaše potřeby. Vyhněte se sledování trendů nebo doporučení, které nemusí být nejlepší pro váš kontext nebo požadavky. Například implementace komponent vlastního kódu nemusí být nejlepší volbou pro každou aplikaci, protože může způsobit problémy se složitostí, režií a závislostí.

Nevyvíjejte více kódu, než je třeba

Principy jednoduchosti, efektivity a spolehlivosti platí i pro vaše vývojové postupy. Zvažte tato doporučení:

  • Využijte možnosti platformy, pokud splňují vaše obchodní požadavky. Příklad:

    • Používejte moderní ovládací prvky místo vývoje vlastních komponent kódu, abyste dosáhli standardu návrhu Fluent 2.
    • Místo vývoje vlastních konektorů použijte nativní konektory, abyste snížili vlastní kód.
    • Používejte generativní odpovědi v Microsoft Copilot Studio a umožněte vašemu agentovi vyhledávat a prezentovat informace z více zdrojů, interních nebo externích, aniž byste museli vytvářet témata ručně.

  • Zaveďte vyhrazené relace kontroly kódu jako vývojový postup.

  • Implementujte přístup k identifikaci mrtvého kódu. Buďte skeptičtí ke kódu, který není součástí automatizovaných testů.

  • Zvažte soubor dovedností vašeho vývojového týmu. Naučit se novou dovednost nebo přijmout novou technologii nějakou dobu trvá.

Přemýšlejte, kde jsou umístěna vaše data

V rámci architektonického návrhu musíte zvážit, jak data uchovávat nebo jak je získat ke čtení. Data lze načíst a uložit různými způsoby:

  • Nová data: Pokud vaše aplikace vytvoří data, která ještě nikde neexistují, například když existující obchodní proces proběhl na papíře, doporučujeme data uložit do Microsoft Dataverse.

  • Čtení/zápis z existujícího systému: Pokud vaše aplikace potřebuje data načíst z existující databáze nebo systému, musíte vyhodnotit nejlepší způsob připojení k databázi nebo systému: pomocí předpřipraveného konektoru, vlastního konektoru nebo virtuálních tabulek.

  • Vytvoření kopie dat: V situacích, kdy by původní data neměla být nikdy upravována nebo přepsána, můžete data zkopírovat do jiného úložiště dat, jako je Dataverse. Tato strategie zachová data původního systému beze změny a zároveň umožní vaší aplikaci s nimi pracovat. Tento scénář je běžný při práci s údaji v účetnictví a v systémech souvisejících s příjmy. Je třeba zvážit, jak se data kopírují, jak často se aktualizují a zda je třeba provést obousměrnou synchronizaci.

Usnadnění dáky Power Platform

Praktické rady ohledně návrhu najdete v následujících článcích:

Kontrolní seznam spolehlivosti

Podívejte se na úplný soubor doporučení.

Kontrolní seznam spolehlivosti