Planowanie rozwiązań natywnych dla chmury

Rozwiązanie natywne dla chmury tworzy nową wartość biznesową, tworząc nowe obciążenia (aplikacje) lub dodając nowe funkcje do istniejących obciążeń. Niezależnie od tego, czy tworzysz zupełnie nową aplikację, czy dodasz nowe funkcje do istniejącego systemu, programowanie natywne dla chmury to podróż przez planowanie, tworzenie, wdrażanie i optymalizowanie obciążeń. Ta struktura zawiera kompleksowe wskazówki, aby zapewnić, że aplikacja natywna dla chmury jest zgodna z celami biznesowymi, dobrze zaprojektowaną i dostarczaną z minimalnym ryzykiem.

Wymagania wstępne:strefa docelowa platformy Azure

Definiowanie celów biznesowych dla rozwiązań natywnych dla chmury

1. Zacznij od jasnych celów biznesowych. Zdefiniuj konkretne wyniki, jakie powinno osiągnąć rozwiązanie natywne dla chmury, takie jak umożliwienie nowego produktu cyfrowego, wejście na nowy rynek, poprawę jakości obsługi klienta lub zmniejszenie kosztów operacyjnych. Użyj mierzalnych wskaźników, takich jak wzrost przychodów, skrócenie czasu wprowadzenia na rynek lub liczba zgłoszeń do wsparcia technicznego, aby zmierzyć sukces. W przypadku nowych funkcji zdefiniuj cele, takie jak poprawa jakości obsługi klienta, obniżenie kosztów operacyjnych lub zwiększenie skalowalności systemu.

2. Identyfikowanie ograniczeń i kryteriów powodzenia. Dokumentowanie wszelkich ograniczeń biznesowych, takich jak budżet, zgodność lub harmonogramy dostarczania. Zdefiniuj, jak wygląda powodzenie dla każdego celu. Na przykład "uruchom nowy portal klienta do Q4" lub "zmniejsz opóźnienie realizacji zamówienia o 40%". Te kryteria określają priorytety i pomagają ocenić kompromisy w planowaniu.

3. Zweryfikuj dopasowanie uczestników projektu. Potwierdź, że wszyscy uczestnicy projektu (biznesowe i techniczne) zgadzają się na cele, ograniczenia i jak wygląda sukces. Takie dostosowanie może obejmować warsztaty lub formalne zatwierdzenia. Wczesne wyrównanie zapobiega późniejszym nieporozumieniom i pozwala uniknąć kosztownej przeróbki, zapewniając, że wszyscy mają takie same oczekiwania od samego początku.

Definiowanie wymagań dotyczących rozwiązań natywnych dla chmury

1. Wymagania funkcjonalne dokumentu. Udokumentowanie możliwości i funkcji, które system musi zapewnić, aby spełnić potrzeby użytkowników. Każde wymaganie powinno wiązać się z celem biznesowym, zapewniając, że prace programistyczne bezpośrednio obsługują pożądane wyniki. Skorzystaj z wywiadów uczestników projektu i dokumentów strategii biznesowej, aby zidentyfikować wyniki o wysokiej wartości. Określanie priorytetów funkcji na podstawie wartości biznesowej i możliwości technicznych. Przeprowadź śledzenie każdego wymagania względem mierzalnego celu biznesowego, aby uzasadnić jego włączenie.

2. Ustanów wymagania niefunkcjonalne. Wymagania niefunkcjonalne definiują wymagania techniczne w celu spełnienia wymagań funkcjonalnych i zarządzania. Ustal atrybuty jakości i cele techniczne potrzebne do obsługi tych funkcji. Zdefiniuj docelowe metryki niezawodności , takie jak cele poziomu usług (SLO) dla czasu pracy, cele punktu odzyskiwania (RPO) i cele czasu odzyskiwania (RTO). Ustanów punkt odniesienia zabezpieczeń. Tworzenie modelu kosztów. Ustaw cele wydajności.

3. Zakres kontroli rozwiązań natywnych dla chmury. Jasno zdefiniuj, co jest w zakresie i poza zakresem dla początkowej wersji. Kuszące jest uwzględnić więcej funkcji "miłych mieć", ale rozszerzanie zakresu może zagrozić harmonogramom i budżetom. Udokumentuj granice swojego rozwiązania i zaimplementuj proces kontroli zmian dla nowych żądań. Zatwierdzanie tylko zmian, które bezpośrednio obsługują zdefiniowane cele i które można dostarczyć bez podważania harmonogramu lub budżetu. Odroczenie pomysłów o niższym priorytcie do przyszłej listy prac. Rygorystycznie zarządzanie zakresem pozwala zespołowi skoncentrować się na dostarczaniu najbardziej wartościowych funkcji w ramach ograniczeń.

Planowanie architektur natywnych dla chmury

Dobrze zaplanowana architektura ma kluczowe znaczenie dla spełnienia Twoich celów i wymagań. Każda główna decyzja dotycząca architektury obejmuje kompromisy w zakresie skalowalności, złożoności, kosztów i elastyczności. Poniższe kroki i punkty decyzyjne ułatwiają tworzenie natywnego dla chmury projektu dostosowanego do najlepszych rozwiązań:

Eksplorowanie zweryfikowanych architektur natywnych dla chmury

1. Przejrzyj podstawy architektury i najlepsze rozwiązania. Przed wymyślaniem architektury od podstaw przejrzyj zweryfikowane architektury referencyjne i podstawy z Centrum architektury platformy Azure. Znane style architektury obejmują eksplorowanie zweryfikowanych architektur referencyjnych dla typowych obciążeń. Te architektury pomagają przyspieszyć decyzje projektowe i zmniejszyć ryzyko.

2. Wybierz odpowiedni styl architektury. Wybierz styl architektury na podstawie cech obciążenia i możliwości zespołu. Style architektoniczne obejmują architekturę wielowarstwową (N-tier, monolityczną), mikrousługi, architekturę sterowaną zdarzeniami (opartą na komunikatach), oraz architekturę web-queue-worker. Jeśli na przykład potrzebujesz szybkiego programowania dla stosunkowo prostej aplikacji, wystarczy dobrze ustrukturyzowany monolit N-warstwowy. W przypadku aplikacji o dużej skali lub szybko zmieniającej się z różnymi domenami, mikrousługi lub podejścia oparte na zdarzeniach oferują elastyczność (kosztem złożoności). W praktyce wiele systemów kończy się stylem hybrydowym. Na przykład istnieje rdzeń mikrousług z niektórymi usługami udostępnionymi lub podsystemem sterowanym zdarzeniami. Kluczem jest zrozumienie kompromisów poszczególnych stylów i wybranie podejścia, które najlepiej spełnia wymagania dotyczące skalowalności, odporności i elastyczności.

3. Stosowanie najlepszych rozwiązań projektowych. Niezależnie od wybranego stylu należy przestrzegać podstaw architektury chmury i najlepszych rozwiązań. Centrum architektury platformy Azure udostępnia wykaz wzorców projektowych chmury (ponawianie, wyłącznik, CQRS), które odpowiadają typowym wyzwaniom związanym z obciążeniami rozproszonymi. Zintegrowanie tych wzorców z projektem może zwiększyć niezawodność i wydajność.

4. Integrowanie pięciu filarów z decyzjami projektowymi. Skorzystaj z platformyWell-Architected Framework , aby kierować decyzjami dotyczącymi niezawodności, bezpieczeństwa, wydajności, optymalizacji kosztów i doskonałości operacyjnej. Te pięć filarów powinno informować o wszystkich decyzjach projektowych. Na przykład podczas wybierania bazy danych należy wziąć pod uwagę niezawodność (nadmiarowość, tworzenie kopii zapasowych), wydajność i koszty w celu uzyskania odpowiedniej równowagi. Dokument, w którym tworzysz kompromisy między filarami, takimi jak większe koszty w celu zwiększenia wydajności. ** Te uwagi są cenne z myślą o przyszłym zarządzaniu i przeglądach.

Planowanie integracji z istniejącymi systemami

1. Spis wszystkich zależnych systemów i usług. Nowe rozwiązania chmuro-native rzadko działają w izolacji, chyba że jesteś startupem we wczesnej fazie rozwoju. Zastanów się, jak nowe obciążenie lub funkcja pasuje do środowiska. Mapuj przepływy danych i zapewnij zgodność ze standardami. Utwórz kompleksową listę wszystkich systemów, z którymi współdziała obciążenie. Ta lista zawiera wewnętrzne interfejsy API, bazy danych, dostawców tożsamości (Microsoft Entra ID), narzędzia do monitorowania, potoki CI/CD oraz systemy lokalne dostępne za pośrednictwem sieci VPN lub usługi ExpressRoute. Użyj diagramów architektury i map zależności, aby zwizualizować te relacje.

2. Klasyfikowanie typów integracji i protokołów. Kategoryzuj każdy punkt integracji według typu (uwierzytelnianie, wymiana danych, obsługa komunikatów) i protokół (REST, gRPC, ODBC, SAML, OAuth2). Ta klasyfikacja pomaga zidentyfikować wymagania zgodności i potencjalne wąskie gardła.

3. Zweryfikuj integrację tożsamości i dostępu. Upewnij się, że rozwiązanie jest zintegrowane z dostawcą tożsamości organizacji. Na przykład użyj identyfikatora Entra firmy Microsoft do uwierzytelniania i autoryzacji zamiast wprowadzenia nowego systemu tożsamości. Potwierdź obsługę logowania jednokrotnego (SSO), kontroli dostępu opartej na rolach (RBAC) i zasad dostępu warunkowego.

4. Ocena łączności sieciowej i zabezpieczeń. Sprawdź, jak obciążenie łączy się z innymi systemami. Zweryfikuj reguły zapory, rozpoznawanie nazw DNS i ścieżki routingu. W przypadku scenariuszy hybrydowych upewnij się, że konfiguracja usługi ExpressRoute lub sieci VPN jest w miejscu i przetestowana. Monitorowanie łączności i rozwiązywanie problemów z łącznością za pomocą usługi Azure Network Watcher.

5. Zapewnienie kompatybilności i zgodności przepływu danych. Mapuj przepływy danych między systemami. Potwierdź formaty danych, schematy i wymagania dotyczące przekształcania. Zapewnienie zgodności z zasadami rezydencji danych, szyfrowania i przechowywania.

6. Testowanie punktów integracji na wczesnym i ciągłym etapie. Przeprowadzanie testów integracji na wczesnych etapach programowania. Użyj makiety lub wycinków dla niedostępnych systemów. Zautomatyzuj te testy w ramach swojego potoku CI/CD, korzystając z narzędzi takich jak Azure DevOps lub GitHub Actions. Monitoruj opóźnienia, przepływność i współczynniki błędów. Na przykład chcesz uniknąć sytuacji, w której interfejs API, od którego zależy Twoja aplikacja, nie obsługuje wymaganego obciążenia, lub zapory sieciowej blokującej Twoją usługę.

7. Dokumentowanie kontraktów integracji i umów SLA. Zdefiniuj i udokumentuj oczekiwane zachowanie, dostępność i wydajność każdego punktu integracji. Uwzględnij logikę ponawiania, ustawienia limitu czasu i mechanizmy rezerwowe. Zgodność z umowami dotyczącymi poziomu usług (SLA) systemów zależnych.

Wybieranie odpowiednich usług i warstw usług platformy Azure

1. Skorzystaj z przewodników decyzyjnych, aby wybrać usługi zgodne z wymaganiami dotyczącymi obciążenia. Platforma Azure oferuje wiele opcji uruchamiania kodu aplikacji, z których każdy ma zalety i wady. Przejrzyj przegląd opcji technologicznych , aby zidentyfikować usługi zgodne z wymaganiami funkcjonalnymi i niefunkcjonalnymi. Określanie priorytetów opcji typu "platforma jako usługa" (PaaS), ponieważ te usługi zmniejszają nakłady operacyjne dzięki automatycznej obsłudze zarządzania infrastrukturą, stosowania poprawek i skalowania.

2. Zdefiniuj wzorce użycia i wymagania dotyczące wydajności, aby wybrać warstwy usług. Wybór warstwy usług ma wpływ zarówno na koszty, jak i możliwości. Dokumentowanie oczekiwanych woluminów transakcji, współbieżnych obciążeń użytkowników, wymagań dotyczących magazynu i celów wydajności, takich jak czasy odpowiedzi i przepływność. Użyj tych metryk, aby wybrać początkowy poziom usługi (SKU), który spełnia podstawowe wymagania bez znaczącej nadmiernej aprowizacji. Zaplanuj dostosowanie warstw na podstawie rzeczywistych wzorców użycia po wdrożeniu.

3. Zweryfikuj zgodność funkcji w wybranych warstwach usług. Krytyczne funkcje, takie jak zaawansowane funkcje zabezpieczeń, opcje wysokiej dostępności lub interfejsy API integracji różnią się w zależności od warstwy usług. Utwórz macierz funkcji, która mapuje wymagane możliwości na dostępne jednostki SKU. Upewnij się, że wybrana warstwa obsługuje wszystkie niezbędne funkcje, aby uniknąć kosztowych migracji lub zmian architektury później. Aby potwierdzić dostępność i ograniczenia funkcji, zapoznaj się z dokumentacją specyficzną dla usługi.

Wybieranie liczby regionów do użycia

1. Ocena kompromisów związanych z wdrożeniami w wielu regionach. Architektury z jednym regionem są prostsze i tańsze, ale awaria regionalna spowoduje wyłączenie aplikacji. Wdrożenia w wielu regionach mogą osiągnąć wyższą dostępność (jeden region może zakończyć się niepowodzeniem, a użytkownicy są obsługiwani z innego regionu), a także zwiększyć wydajność, obsługując użytkowników z najbliższego regionu. Kompromis polega na zwiększeniu złożoności wdrażania i synchronizacji danych. Należy obsługiwać replikację danych między regionami z potencjalnymi problemami ze spójnością, routingiem ruchu globalnego i wyższymi kosztami. Pozwól, aby wymagania dotyczące niezawodności napędzały tę decyzję.

2. Użyj celów dotyczących niezawodności, aby kierować strategią regionalną. Zdefiniuj cele poziomu usług (SLO), cele punktu odzyskiwania (RPO) i cele czasu odzyskiwania (RTO), aby określić wymagania regionalne.

3. Potwierdź zgodność z regulacjami dotyczącymi lokalizacji danych. Współpracuj z zespołami prawnymi i zespołami ds. zgodności, aby zapewnić wybory regionalne spełniające zobowiązania regulacyjne.

Architektury dokumentów

1. Utwórz szczegółowy diagram architektury i dokument projektowy. Dokumentacja obsługuje implementację, przegląd i przyszłą konserwację. Uwzględnij wybrane usługi platformy Azure, jednostki SKU, przepływy danych i interakcje użytkownika. Upewnij się, że diagram zawiera wyraźną wizualną reprezentację architektury w celu obsługi implementacji i przeglądów.

2. Rejestruj kluczowe decyzje projektowe i kompromisy. Udokumentuj uzasadnienie wyboru architektury, w tym niefunkcjonalne wymagania, takie jak niezawodność, bezpieczeństwo i wydajność. Wyróżnij wszelkie kompromisy dokonane w celu zrównoważenia konkurencyjnych priorytetów.

Planowanie strategii wdrażania cloud-native

Podczas wdrażania rozwiązania natywnego dla chmury w środowisku produkcyjnym należy postępować zgodnie z planowaną strategią, zamiast działać na zasadzie ad hoc. Solidny plan wdrożenia minimalizuje wpływ na użytkowników i zapewnia sposoby odzyskiwania, jeśli coś pójdzie nie tak.

Planowanie rozwiązań dotyczących programowania i wdrażania

Praktyki dotyczące programowania i wdrażania zapewniają spójne dostarczanie i gotowość operacyjną w różnych środowiskach. Te rozwiązania zmniejszają ryzyko związane z wdrażaniem i zwiększają koordynację zespołu.

1. Wdróż praktyki DevOps dla automatyzacji wdrażania. Praktyki DevOps łączą zespoły programistyczne i operacyjne poprzez automatyzację, kontrolę wersji i potoki CI/CD. Użyj narzędzi, takich jak Azure DevOps lub GitHub Actions, aby zautomatyzować przepływy pracy kompilacji, testowania i wdrażania. Takie podejście zmniejsza błędy ręczne, przyspiesza cykle wydawania i zapewnia spójne procesy wdrażania w różnych środowiskach.

2. Planowanie gotowości operacyjnej do obsługi działań związanych z wdrażaniem. Gotowość operacyjna obejmuje procedury monitorowania, alertów i reagowania na zdarzenia dla scenariuszy wdrażania. Dokumentuj runbooki wdrożeniowe i skrypty automatyzacji, które obejmują procedury wycofywania, kontrole kondycji oraz kroki rozwiązywania problemów. Przechowuj te zasoby w centralnej lokalizacji, takiej jak witryna typu wiki usługi Azure DevOps lub GitHub, aby zapewnić dostępność podczas działań związanych z wdrażaniem.

3. Zdefiniuj praktyki programistyczne , które obsługują niezawodne wdrożenia. Używaj standardów kodowania, przeglądów równorzędnych i zautomatyzowanych testów, aby zapewnić gotowość do jakości i wdrażania kodu. Zintegruj te praktyki z potokiem CI/CD, aby wymusić punkty kontrolne jakości przed wdrożeniem. Uwzględnij testy specyficzne dla wdrożenia, takie jak testy integracyjne, testy weryfikacyjne oraz testy wydajnościowe, aby zweryfikować gotowość systemu do produkcji.

Planowanie wdrożenia dla nowych obciążeń

1. Użyj progresywnej ekspozycji, aby ograniczyć wpływ. W przypadku nowej aplikacji tworzonej od podstaw, bez istniejących użytkowników, należy przeprowadzić testowe uruchomienie. Wdróż do środowiska produkcyjnego, ale udostępnij je początkowo tylko użytkownikom wewnętrznym lub grupie pilotażowej. Takie podejście jest wdrożeniem kanaryjskim dla nowego obciążenia. Jeśli jest to naprawdę nowe i odizolowane, jednorazowe wdrożenie do pełnej produkcji jest możliwe, ale zaleca się stopniowe wprowadzanie, aby w sposób kontrolowany wychwycić wszelkie problemy. Nie uwalniaj systemu na 100% użytkowników pierwszego dnia bez wcześniejszej weryfikacji w świecie rzeczywistym. Aby uzyskać więcej informacji, zapoznaj się z WAF (Zaporą aplikacji internetowej) – adopcja progresywnego modelu ekspozycji.

2. Dokumentowanie procedur operacyjnych i ścieżek eskalacji. Utwórz przejrzystą dokumentację dotyczącą ponownego uruchamiania usług, uzyskiwania dostępu do dzienników, obsługi typowych problemów i eskalacji zdarzeń. Przechowuj tę dokumentację w udostępnionym repozytorium, takim jak SharePoint lub GitHub, aby zapewnić dostępność zespołów pomocy technicznej.

Planowanie wdrożenia nowych funkcji

1. Planowanie nowej integracji funkcji przy użyciu zarządzania zmianami. Postępuj zgodnie z procesem zarządzania zmianami w organizacji, aby kontrolować i dokumentować zmiany produkcyjne. Zdefiniuj procedury wycofywania, takie jak przywracanie wersji aplikacji lub przywracanie kopii zapasowych bazy danych. Zabezpieczanie zatwierdzenia uczestników projektu przed wdrożeniem w celu zapewnienia zgodności z celami biznesowymi. Aby uzyskać więcej informacji, zobacz Zarządzanie zmianami w caF.

2. Używaj aktualizacji w miejscu dla drobnych zmian lub takich, które są zgodne z wcześniejszymi wersjami. Wdrażaj aktualizacje bezpośrednio do środowiska produkcyjnego, używając aktualizacji stopniowych lub flag funkcji. Zacznij od niewielkiej liczby użytkowników lub wystąpień. Monitoruj metryki systemu i dzienniki, aby zweryfikować stabilność przed pełnym wdrożeniem.

3. Użyj wdrożeń równoległych (niebiesko-zielonych) w przypadku zmian o dużym ryzyku lub dużych ryzyka. Wdróż nową wersję w osobnym środowisku. Przekieruj niewielką część ruchu na żywo do nowej wersji w celu zweryfikowania zachowania. W przypadku powodzenia przenieś cały ruch sieciowy do nowej wersji. Jeśli wystąpią problemy, przywróć ruch do oryginalnej wersji, aby zapewnić ciągłość.

4. Plan przekazania operacyjnego dla nowych obciążeń. Zidentyfikuj zespół odpowiedzialny za obsługę i obsługę rozwiązania po wdrożeniu. Zdefiniuj model pomocy technicznej (24/7 na wezwanie lub pomoc techniczną w godzinach pracy) i upewnij się, że wszyscy uczestnicy projektu rozumieją swoje role.

5. Definiowanie własności i obowiązków związanych z wsparciem technicznym. Upewnij się, że zespół operacyjny jest przygotowany do obsługi nowej funkcji. Aktualizowanie dokumentacji i ścieżek eskalacji w celu odzwierciedlenia nowych obowiązków i zapewnienia szybkiego reagowania na zdarzenia.

Definiowanie planu wycofywania dla rozwiązań natywnych dla chmury

Plan wycofywania umożliwia zespołom szybkie odwrócenie zmian w przypadku niepowodzenia wdrożenia lub wprowadzenia ryzyka. Dobrze zdefiniowany plan minimalizuje przestoje, ogranicza wpływ na działalność biznesową i utrzymuje niezawodność systemu. Zawsze ustanawiaj kryteria wycofywania i procedury przed zainicjowaniem jakiejkolwiek migracji lub wdrożenia.

1. Zdefiniuj wdrożenie, które zakończyło się niepowodzeniem. Współpracuj z osobami biorącymi udział w projekcie biznesowym, właścicielami obciążeń i zespołami operacyjnymi, aby zdecydować, co liczy się jako wdrożenie, które zakończyło się niepowodzeniem. Przykłady obejmują testy kondycji zakończone niepowodzeniem, niską wydajność, problemy z zabezpieczeniami lub niezaspokojone metryki powodzenia. Ta definicja gwarantuje, że decyzje wycofywania są zgodne z tolerancją ryzyka w organizacji. Uwzględnij określone warunki, które wyzwalają wycofanie w planie wdrożenia, takie jak limity użycia procesora CPU, progi czasu odpowiedzi lub współczynniki błędów. Ta ocena sprawia, że decyzje wycofywania są jasne i spójne podczas zdarzeń.

2. Zautomatyzować kroki wycofania w potokach CI/CD. Użyj narzędzi, takich jak Azure Pipelines lub GitHub Actions , aby zautomatyzować procesy wycofywania. Na przykład skonfiguruj potoki, aby ponownie wdrożyć poprzednią wersję, jeśli sprawdzanie kondycji nie powiedzie się.

3. Utwórz instrukcje wycofywania specyficzne dla konkretnego obciążenia. Twórz kroki wycofywania zgodne z typem obciążenia, środowiskiem i metodą wdrażania. Na przykład wdrożenia infrastruktury jako kodu wymagają ponownego zastosowania poprzednich szablonów. Wycofywanie aplikacji obejmuje ponowne wdrażanie poprzedniego obrazu kontenera. Dołączanie skryptów wycofywania, migawek konfiguracji i szablonów infrastruktury jako kodu do planu wycofywania. Te zasoby umożliwiają szybkie wykonywanie i zmniejszanie zależności od interwencji ręcznej.

4. Testuj procedury wycofywania zmian. Symulowanie niepowodzeń wdrażania w środowisku przedprodukcyjnym w celu zweryfikowania skuteczności wycofywania. Identyfikowanie i rozwiązywanie luk w automatyzacji, uprawnieniach lub zależnościach. Upewnij się, że operacja wycofania przywraca system do stabilnego i znanego dobrego stanu.

5. Ulepszanie strategii wycofywania Po każdym zdarzeniu wdrażania lub wycofywania należy przeprowadzić retrospektywę, aby ocenić, co zadziałało i co nie. Aktualizowanie kryteriów wycofywania, procedur i automatyzacji na podstawie wyciągniętych lekcji, zmian architektury lub nowych narzędzi. Zachowaj dokumentację, aby zapewnić, że strategie wycofywania pozostają aktualne i skuteczne.

Następny krok