Zalecenia dotyczące projektowania i wydajności
Dotyczy tego Power Platform zalecenia dotyczącego listy kontrolnej niezawodności Well-Architected Reliability:
RE:01 | Projektować pracą tak, aby był wyrównany z celami biznesowymi i aby uniknąć niepotrzebnej złożoności i powielania. Aby podejmować decyzje dotyczące projektu, które zapewniają żądane rezultaty, należy stosować praktyczny i zrównoważony sposób. Należy także ograniczyć projekt i potencjalne problemy, aby zmniejszyć brak wydajności i potencjalne problemy. |
---|
W tym przewodniku opisano zalecenia minimalizując niepotrzebną złożoność i minimalizację obciążenia w celu prostego i wydajnej obsługi prac. Wybierz najlepsze składniki do wykonania zadań wymagających obciążenia, aby zoptymalizować niezawodność obciążenia. Aby mniejsze obciążenie związane z rozwojem i zarządzaniem, można skorzystać z możliwości oferowanych przez platformy. Ułatwia to tworzenie architektury obciążenia, która jest insekcyjna, powtarzalnych, skalowalnych i możnających się nimi zarządzać.
Definicje
Termin | Definicja |
---|---|
Obciążenie | Zadanie dyskretne lub obliczeniowe, które można logicznie oddzielić od innych zadań. |
Kluczowe strategie projektowania
Kluczem do projektowania i niezawodności jest utrzymanie prostego i wydajnego rozwiązania. Skoncentruj projekt prac na spełnianiu wymagań biznesowych, aby zmniejszyć ryzyko niepotrzebnej złożoności lub powielania zadań. Rozważ zalecenia zawarte w tym artykule, aby pomóc w podejmować decyzje dotyczące projektu w celu utworzenia wydajnego i wiarygodnego obciążenia. Różne obciążenia mogą mieć różne wymagania dotyczące dostępności, skalowalności, spójności danych i odzyskiwania danych.
Każda decyzja projektowa musi być wymagana ze strony firmy. Może to stanowić decydujące znaczenie dla projektowania prac. Czy Twoje obciążenie obsługuje miliony użytkowników, czy kilka tysięcy? Czy jest dużo ruchu i jest to stały? Jaki poziom przestoju jest dopuszczalny? Kwestie te są związane z wymaganiami biznesowymi.
Kompromis: Złożone rozwiązanie może oferować więcej funkcji i elastyczności, ale może mieć wpływ na niezawodność obciążenia, ponieważ wymaga większej koordynacji, komunikacji i zarządzania komponentami. Prostsza rozwiązanie może nie w pełni spełniać oczekiwań użytkowników lub może mieć ujemny wpływ na rozszerzanie w zależności od rozwoju obciążenia.
Zespołowe ćwiczenia projektowe
Praca z interesariuszami w celu:
Zdefiniuj i przypisz poziom krytyczności do obciążenia i jego składników. To ćwiczenie pomoże w określeniu wymaganych składników i najlepszego podejścia do osiągnięcia wymaganego poziomu jakości. Zobacz definiowanie warstwy aplikacji, aby uzyskać więcej informacji.
Definiowanie wymagań funkcjonalnych i niefunkcjonalnych. Wymagania funkcjonalności określają funkcje i zachowanie systemu. Są one określone przez użytkownika i zarejestrowane w przypadkach użycia. Wymagania nieakcje definiują atrybuty wydajności i jakości systemu. Upewnij się, że rozumiesz wymagania nieakcyjne, takie jak dostępność, zgodność, przechowywanie/przechowywanie danych, wydajność, prywatność, czas odzyskiwania, zabezpieczenia i skalowalność. Te wymagania mają wpływ na decyzje dotyczące projektu i opcje technologii.
Oto kilka przykładów wymagań funkcjonalnych i nieakcjonalnych w kontekście obciążenia, który obsługuje raporty dotyczące wydatków:
Wymagania funkcjonalne Wymagania niefunkcjonalne Obciążenia powinny umożliwić użytkownikom zalogowanie się przy użyciu ich poświadczeń i uzyskiwanie dostępu tylko do ich danych osobowych. Obciążenie powinno być dostępne przez co najmniej 99,9% czasu. Pracą powinien być pulpit nawigacyjny udostępniacy omówienie otwartych, zatwierdzonych i odrzuconych raportów dotyczących wydatków. Pracowicie powinno być zgodne z odpowiednimi przepisami i standardami dotyczącymi ochrony danych i prywatności. Obciążenia powinny obsługiwać operacje tworzenia i przywracania danych w obciążeniach. W przypadku większości żądań użytkownika czas odpowiedzi nie może być krótszy niż 5 sekund. Obciążenia powinny wysyłać powiadomienia do użytkowników i administratorów o wyzwoleniu określonych zdarzeń lub progów. Obciążenia powinny mieć duży poziom zabezpieczeń i szyfrowania danych w różnych grupach i podczas przechowywania. Aby uzyskać więcej informacji, zobacz moduł szkoleniowy zatytułowany Praca z wymaganiami usługi Microsoft Power Platform i Dynamics 365.
Podziel obciążenie na składniki. Podczas procesu odnajdowania i zbierania wymagań niektóre pomysły na rozwiązania powinny zacząć być jasne. Zidentyfikuj składniki rozwiązania, które mogą się znaleźć w proponowanych rozwiązaniach, aby spełnić potrzeby biznesowe. Priorytet podczas projektowania, wydajności i niezawodności. Należy określić składniki potrzebne do obsługi obciążenia. Zaznacz miejsca, w których można korzystać z funkcji dostosowanych do potrzeb oraz gdzie może być potrzebne opracowanie niestandardowego oprogramowania.
Użyj analizy trybu awarii , aby zidentyfikować pojedyncze punkty awarii i potencjalne zagrożenia. Dobrze rozumiesz tolerancję ryzyka firmy. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące wykonywania analizy trybu awarii.
Zdefiniuj cele dostępności i odzyskiwania dla obciążenia, aby informować o decyzjach dotyczących architektury. Metryki biznesowe to m.in. cele poziomu usług (SLO), umowy dotyczące poziomu usług (SLA), czas średni do naprawy (MTTR), czas średni między niepowodzeniami (MTBF), cele naprawy (RTO) i cele punktów naprawy (RPO). Definiować wartości docelowe tych metryk. To zadanie może wymagać kompromisów i wzajemnego zrozumienia między technologią a zespołami biznesowymi, aby zapewnić, że cele poszczególnych zespołów spełniają cele biznesowe i zostaną naruszone. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące definiowania wartości docelowych niezawodności. Power Platform Umowy SLA zawierają Microsoft zobowiązania dotyczące czasu pracy i łączności. Różne usługi mają różne umowy SLA, a czasami jednostki SKU w ramach usługi mają różne umowy SLA. Aby uzyskać więcej informacji, zobacz umowy dotyczące poziomu usług dotyczące usług online.
Dodatkowe zalecenia dotyczące projektu
Bez angażowania interesariuszy można wykonać następujące zalecenia:
Dąż do prostoty i przejrzystości w swoim projekcie. Należy użyć odpowiedniego poziomu streszczenie i ziarnistości dla składników i usług. Należy unikać stosowania zbytnich usług lub podsyłania rozwiązania. Na przykład:
Jeśli zostanie rozwiązane wymaganie automatyzacji procesów z Power Automate, przerwanie dużego procesu w wielu mniejszych przepływach w chmurze może ułatwić zrozumienie, przetestowanie i konserwację. Z drugiej strony zachowanie wszystkich zmian w dużym przepływie może mieć ujemny wpływ na wydajność i liczbę rozmów interfejsów API.
Jeśli wymagania są rozwiązane przez Power Apps, duża aplikacja z wieloma formantami może mieć ujemny wpływ na wydajność. Przekroczenie jej na pojedyncze aplikacje lub strony niestandardowe może spowodować, że testowanie będzie trudne, ale może to mieć znaczący pozytywny wpływ na wydajność.
Przewiduj zmiany w czasie, niezależnie od tego, czy chodzi o naprawianie błędów, wdrażanie nowych funkcji lub technologii, czy też zwiększanie skalowalności i odporności istniejących systemów.
Przenieś zagadnienia przekrojowe do oddzielnej usługi. Minimalizuj konieczność duplikowania kodu w różnych funkcjach. Woli ponownie używać usług z dobrze zdefiniowanymi interfejsami, które mogą być łatwo wykorzystywane przez różne składniki. Jeśli na przykład trzeba wykonać zestaw operacji danych z różnych miejsc, można przenieść tę funkcję do dodatku plug-in z małym kodem.
Oceń przydatność typowych wzorców i praktyk dla swoich potrzeb. Należy unikać następujących trendów i zaleceń, które mogą nie być najlepsze dla kontekstu lub wymagań. Na przykład implementacja składników kodu niestandardowego może nie być najlepszym rozwiązaniem dla każdej aplikacji, ponieważ może to spowodować złożoność, rozmiary i problemy z zależnościami.
Rozwiń wystarczającą ilość kodu
Zasady projektowania, wydajności i niezawodności dotyczą również praktyk programistów. Rozważmy te zalecenia:
Funkcje platformy można używać, gdy spełniają wymagania biznesowe. Na przykład:
- Korzystaj z nowoczesnych kontrolek zamiast opracowywać własne składniki kodu, aby osiągnąć standard projektowania Fluent 2.
- Używaj łączników natywnych zamiast opracowywać łączniki niestandardowe, aby zmniejszyć ilość niestandardowego kodu.
- Korzystaj z generatywnych odpowiedzi Microsoft Copilot Studio , aby umożliwić drugiemu pilotowi znajdowanie i prezentowanie informacji z wielu źródeł, wewnętrznych lub zewnętrznych, bez konieczności ręcznego tworzenia tematów.
Wprowadzenie sesji przeglądu dedykowanego kodu jako metody projektowania.
Zaimplementowano podejście do identyfikowania martwego kodu. Bądź sceptyczny co do kodu, który nie jest obejmuje automatycznych testów.
Weź pod uwagę zestaw umiejętności zespołu projektowego. Wymaga czasu, aby nauczyć się nowych umiejętności lub na nowo technologii.
Rozważ, gdzie znajdują się Twoje dane
W ramach projektu architektury należy rozważyć sposób przechowywania danych lub pobierania danych dla działań odczytu. Dane można pobierać i zapisywać na kilka sposobów:
Nowe dane: jeśli aplikacja tworzy dane, które jeszcze nie istnieją, na przykład gdy istniejący proces biznesowy został wykonany na papierze, zalecamy przechowywanie tych danych Microsoft Dataverse.
Odczyt/zapis z istniejącego systemu: Jeśli aplikacja musi pobrać dane z istniejącej bazy danych lub systemu, należy ocenić najlepszy sposób nawiązania połączenia z bazą danych lub systemem: przy użyciu gotowego łącznika, łącznika niestandardowego lub tabel wirtualnych.
Utwórz kopię danych: W sytuacjach, w których oryginalne dane nigdy nie powinny być modyfikowane ani zastępowane, można skopiować dane do innego magazynu danych, takiego jak Dataverse. Ta strategia utrzymuje oryginalne dane systemu bez zmian, jednocześnie umożliwiając aplikacji pracę z nimi. Ten scenariusz jest typowy podczas pracy z danymi w systemach z informacjami dotyczącymi księgowania i przychodów. Należy rozważyć sposób kopiowania danych, jak często są one aktualizowane i czy ma być synchronizowane w obu sposób.
Ułatwienia Power Platform
Aby uzyskać praktyczne porady dotyczące projektowania, zapoznaj się z następującymi artykułami:
Power Apps:
- Określanie , gdzie w systemie umieścić logikę: aplikacje kanwy, aplikacje oparte na modelu Microsoft Dataverse lub przepływy Power Automate
- Określanie typu aplikacji do utworzenia: aplikacje oparte na modelu lub aplikacje kanwy
- Modelowanie danych: Projektowanie struktury danych
- Projekt danych: Praca z systemami przedsiębiorstwa
Power Automate:
Copilot Studio:
- Przewodnik Microsoft Copilot Studio wdrożeniowy zapewnia ramy do przeprowadzenia oceny 360 stopni Twojego projektu. Zadając wnikliwe pytania, identyfikuje potencjalne zagrożenia i luki, dostosowuje projekt do mapy drogowej produktu oraz udostępnia wskazówki, najlepsze praktyki i przykłady architektury referencyjnej.
- Dokumentacja Microsoft Copilot Studio ze wskazówkami zawiera najlepsze rozwiązania, wskazówki dotyczące implementacji i wskazówki dotyczące architektury od zespołu, który współpracuje z naszymi klientami korporacyjnymi.
Informacje pokrewne
- Umowy o gwarantowanym poziomie usług dla usług online
- Praca z wymaganiami dotyczącymi Microsoft Power Platform i Dynamics 365
- Planowanie Power Apps projektu
- Planowanie Power Automate projektu
- Planowanie projektu konwersacyjnej sztucznej inteligencji
Lista kontrolna niezawodności
Zapoznaj się z kompletną zestawem zaleceń.