Wdrożenie Microsoft Foundry w mojej organizacji

Plan wdrożenia ustrukturyzowanego pomaga uniknąć luk w zabezpieczeniach, przekroczenia kosztów i rozrastania dostępu podczas wdrażania Microsoft Foundry na dużą skalę. Skorzystaj z tego przewodnika, aby zdefiniować granice obciążeń, wybrać topologię zasobów i ustanowić ład dla zespołów samoobsługowych.

Wymagania wstępne

Przed rozpoczęciem planowania upewnij się, że masz:

  • Zrozumienie organizacji podstawowej subskrypcji platformy Azure i grup zasobów w organizacji.
  • Dane wejściowe dotyczące wymagań organizacji dotyczących zabezpieczeń sieci, szyfrowania i izolacji danych.
  • Początkowy plan regionu oparty na dostępności modelu i funkcji. Aby uzyskać szczegółowe informacje, zobacz dostępność funkcji w różnych regionach chmury.
  • Umowa dotycząca wymagań dotyczących zabezpieczeń sieci, szyfrowania i izolacji danych w organizacji.
  • Spis funkcji i interfejsów API usługi Foundry, które mają być używane przez zespoły.

Definiowanie granic izolacji

Zacznij od Cloud Adoption Framework wskazówek dotyczących udostępniania platformy sztucznej inteligencji, a następnie zastosuj te decyzje do rozwiązania Foundry:

Chociaż każda sytuacja jest unikatowa, w przypadku wspólnej organizacji zalecamy następującą sekwencję:

  1. Zdefiniuj nienegocjacyjne granice udostępniania między jednostkami biznesowymi, domenami danych, własnością produktu i warstwami środowiska.
  2. Ustaw politykę dla środowiska produkcyjnego, która domyślnie wymusza izolację, chyba że udokumentowany wyjątek dopuszcza współlokację.
  3. Ustal strategię eksploracji, która domyślnie zakłada współlokację w celu szybszego eksperymentowania, chyba że zgodność z wymogami lub walidacja wymagają izolacji.
  4. Przypisz odpowiedzialność do każdej granicy, w tym za bezpieczeństwo, koszty i reagowanie na incydenty.

Identyfikowanie wymagań dotyczących możliwości i dostępu

Określ, których funkcji i interfejsów API Foundry wymaga każde obciążenie robocze, zanim ostatecznie ustalisz topologię.

Uwaga / Notatka

Nie wszystkie interfejsy API rozwiązania Foundry obsługują pełen zakres trybów uwierzytelniania, poziomów szyfrowania pamięci masowej i izolacji na poziomie projektów. Niektóre interfejsy API narzędzi Foundry mogą wymagać przypisań ról w zakresie zasobów nadrzędnego rozwiązania Foundry.

W przypadku przypadków użycia współdzielących jeden zasób Foundry używaj projektów Foundry jako izolowanych obszarów roboczych dla każdego przypadku użycia. Na przykład zespoły eksperymentujące z pomysłem mogą utworzyć projekt w celu organizowania spójnych zasobów bez powtarzania konfiguracji infrastruktury na potrzeby zabezpieczeń, wdrożeń modeli i dostępu do narzędzi.

Większość nowszych interfejsów API Foundry zorientowanych na agenta obsługuje uprawnienia na poziomie projektu. Niektóre tradycyjne interfejsy API narzędzi Foundry (dawniej Azure usługi AI), takie jak zamiana mowy na tekst, nadal wymagają dostępu do nadrzędnego zakresu zasobów. Zaplanuj granice i RBAC tak, aby wszystkie wymagane możliwości były dostępne w zamierzonym zakresie zarządzania dostępem.

Obszar możliwości Organizowanie według projektu Izolacja RBAC na poziomie projektu Przynieś własne miejsce do przechowywania danych Obsługa sieci/szyfrowania Implikacja planowania
Możliwości agenta (agenci, odpowiedzi, oceny, zestawy danych, indeksy, pliki i zasoby placu zabaw) Yes Yes Yes Ograniczone w podstawowej konfiguracji (pamięć masowa zarządzana). Aby uzyskać pełne pokrycie, użyj opcji "Standardowa". Dobrze nadaje się do segmentacji według projektów dla poszczególnych przypadków użycia w środowiskach współdzielonych.
Dostrajanie szkolenia Nie (tylko projekt domyślny) No Częściowe (tylko dane wejściowe) Yes Jeśli każdy zespół potrzebuje niezależnego dostrajania, użyj oddzielnych zasobów rozwiązania Foundry. Wdrożenia dostrojonych modeli są współdzielone i mogą być używane w różnych projektach w obrębie jednego zasobu.
Obrazy OpenAI, wideo, wsadowe No No Częściowe (tylko Batch) Yes Użyj izolowanej konfiguracji obciążenia, a jeśli wymagana jest zarządzana pamięć masowa, odpowiednio wcześnie zweryfikuj ograniczenia RBAC.
Opis zawartości Yes No Yes Yes Jeśli wymagana jest ścisła izolacja dostępu dla poszczególnych przypadków użycia, należy preferować oddzielne zasoby usługi Foundry.
Mowa Tak (dostrojenie) No Yes Ograniczone w podstawowej konfiguracji (pamięć masowa zarządzana). Aby uzyskać pełne pokrycie szyfrowania CMK, użyj usługi BYO Storage.
Język Tak (dostrojenie) No Yes Ograniczone w podstawowej konfiguracji (pamięć masowa zarządzana). Aby uzyskać pełne pokrycie szyfrowania CMK, użyj usługi BYO Storage.
Translator No No No Yes Użyj oddzielnego zasobu Foundry, jeśli izolacja jest konieczna.

Ważne

Przed wdrożeniem potwierdź dokładną kombinację możliwości. Jeśli wymagany interfejs API działa tylko w zakresie zasobów usługi Foundry, przypisz role w tym zakresie lub izoluj obciążenia do oddzielnych zasobów usługi Foundry.

Wybierz topologię zasobów Foundry

Po zdefiniowaniu granic i potrzeb dotyczących możliwości wybierz topologię dla każdego środowiska.

Ścieżka decyzyjna Zalecana konfiguracja rozwiązania Foundry Najlepsze dopasowanie Główny kompromis
Współlokowanie obciążeń Jeden zasób Foundry z wieloma projektami (zazwyczaj jeden projekt dla każdego przypadku użycia) Środowiska nastawione na eksperymentowanie, wczesne prototypy oraz zespoły, które korzystają ze współdzielonych wdrożeń i współdzielonych połączonych danych lub narzędzi Wspólny obszar oddziaływania incydentów produkcyjnych, wyczerpania limitów i błędnej konfiguracji
W pełni izolowane obciążenia Jeden zasób Foundry na granicę dla produkcyjnego obciążenia roboczego (często z jednym głównym projektem na każde obciążenie robocze) Obciążenia produkcyjne wymagające ścisłego ograniczenia operacyjnego, niezależnej kontroli dostępu i niezależnych limitów przydziału lub granic kosztów Wdrożenie samoobsługowe jest trudniejsze ze względu na większą liczbę zasobów do zarządzania i większy narzut związany z konfiguracją

Tip

W przypadku środowiska produkcyjnego należy traktować izolację jako domyślną. Użyj kolokacji jako celowego wyjątku tylko wtedy, gdy granice obciążenia, wymagania dotyczące danych i akceptacja ryzyka są dostosowane.

Zrzut ekranu diagramu przedstawiającego zasób Foundry.

Planowanie punktu odniesienia zabezpieczeń

Użyj tej tabeli referencyjnej jako listy kontrolnej dla decyzji projektowych dotyczących zabezpieczeń.

Area Co należy zdecydować Rozpocznij od
Tożsamość i dostęp Zdefiniuj osoby administratora, menedżera projektu i użytkownika projektu. Przypisz każdą personę do ról z minimalnym zakresem uprawnień i grup Microsoft Entra ID. Kontrola dostępu oparta na rolach w narzędziu Foundry
Sieć Wybierz model sieci na środowisko. Użyj zarządzanej sieci wirtualnej, aby uzyskać bardziej bezpieczną, prostą konfigurację. Użyj własnej sieci wirtualnej (BYO) w celu uzyskania zaawansowanej kontroli sieci i niestandardowych wymagań dotyczących routingu. Zweryfikuj prywatny DNS i proces zatwierdzania punktu końcowego przed wdrożeniem produkcyjnym. Konfigurowanie zarządzanej sieci wirtualnej, konfigurowanie łącza prywatnego dla rozwiązania Foundry i konfiguracja zabezpieczona siecią (sieć wirtualna BYO)
Ochrona danych i klucze Zdecyduj, czy klucze zarządzane Microsoft spełniają wymagania zasad, czy też są wymagane klucze zarządzane przez klienta. Klucze zarządzane przez klienta w narzędziu Foundry
Model uwierzytelniania Preferowane są Microsoft Entra ID i RBAC w przypadku osób i usług. Używaj kluczy API tylko tam, gdzie nie jest wymagany szczegółowy podział ról. Kontrola dostępu oparta na rolach w narzędziu Foundry

Planowanie strategii modelu, regionu i pojemności

Dla każdego obciążenia zdefiniuj:

  • Rodziny modeli i typy wdrożeń wymagane przez przypadek użycia.
  • Wymagania dotyczące przetwarzania danych (na przykład ograniczenia globalne lub regionalne).
  • Cele przepływności i opóźnień dla scenariuszy interakcyjnych i wsadowych.
  • Wymagania dotyczące limitu przydziału i aprowizowanej pojemności dla obciążeń w stanie stałym i szczytowym.

Użyj tych odniesień:

Planowanie łączności i integracji danych

Dla każdego obciążenia zidentyfikuj zależności zewnętrzne i wzorce połączeń:

  • Źródła danych i magazyny danych.
  • Wewnętrzne interfejsy API i systemy biznesowe.
  • Narzędzia SaaS inne niż Azure wymagane przez agentów lub przepływy orkiestracji.
  • Wymagania dotyczące sieci, w tym prywatnych punktów końcowych, rozpoznawania nazw DNS, kontrole ruchu wychodzącego oraz czy wymagana jest zarządzana sieć lub sieć wirtualna BYO.

Użyj opcji Dodaj połączenia w narzędziu Foundry , aby standandaryzować konfigurację połączenia.

Połączenia można tworzyć zarówno na poziomie nadrzędnego zasobu Foundry, jak i na poziomie projektu podrzędnego, w zależności od wymaganego zakresu izolacji. Połączenia skonfigurowane na poziomie nadrzędnym są dostępne dla wszystkich projektów.

Zrzut ekranu przedstawiający łączność projektu Foundry i integrację z innymi usługami Azure.

Planowanie automatyzacji i operacji

Definiowanie sposobu, w jaki zespoły tworzą zasoby i zarządzają nimi spójnie w różnych środowiskach.

  • Stosuj infrastrukturę jako kod, aby wdrażać podstawowe zasoby i domyślne ustawienia zasad.
  • Standaryzacja potoków wdrażania dla projektów, połączeń, wdrożeń modelu i zmian konfiguracji.
  • Zdefiniuj procedury wycofywania i reagowania na zdarzenia dla zmian modelu i zasad.

W przypadku wzorców automatyzacji i początkowych implementacji użyj:

Przykładowe szablony obejmują kompleksowe wzorce typowych scenariuszy zabezpieczeń, takich jak sieć prywatna, klucze zarządzane przez klienta i kontrola dostępu oparta na rolach.

Zdefiniuj samoobsługowe zabezpieczenia

Włącz samoobsługę tylko w ramach jasnych ograniczeń:

  • Zdefiniuj, które role mogą tworzyć projekty, wdrażać modele i łączyć narzędzia zewnętrzne.
  • Stosowanie mechanizmów kontroli zasad dotyczących wdrażania modelu i zachowania środowiska uruchomieniowego, w tym dostawców modeli i dozwolonych połączeń narzędzi.
  • Ustaw mechanizmy kontroli kosztów i alerty budżetowe dla środowisk udostępnionych i izolowanych.
  • Wymuś rejestrowanie śladów w centralnym systemie obserwowalności w Microsoft Foundry, Microsoft Copilot Studio i Microsoft 365.

Użyj tych odniesień:

Przypisz właściciela i nadzór

Ten krok należy traktować jako przejście z aprowizowanej infrastruktury do użycia operacyjnego dewelopera.

Większość organizacji zarządza już dostępem za pomocą wstępnie utworzonych grup Microsoft Entra ID. Zamapuj te grupy na role usługi Foundry w wymaganym zakresie, a następnie zweryfikuj ścieżki dostępu do zarządzania i programowania.

Foundry rozdziela dostęp według:

  • Akcje kontroli RBAC płaszczyzny sterowania na potrzeby zarządzania zasobami.
  • Akcje RBAC płaszczyzny danych dla obciążeń programistycznych.

Ważne

Role zarządzania, takie jak Właściciel lub Współautor, nie są wystarczające dla wszystkich scenariuszy programowania. Na przykład użytkownik może zarządzać zasobami, ale nadal potrzebuje ról płaszczyzny danych, aby porozmawiać z agentem w narzędziu Foundry.

Aby uzyskać wskazówki dotyczące mapowania ról i wymagane kombinacje ról, zobacz Kontrola dostępu oparta na rolach w narzędziu Foundry.

Po wdrożeniu grup użytkowników rozważ utworzenie lub rozbudowę pulpitów zarządzania, aby śledzić wykorzystanie Foundry, niezawodność, pochodzenie danych i zgodność:

Przykładowe wdrożenie platformy

Organizacja IT w firmie Contoso musi obsługiwać wiele zespołów, równoważąc dwa priorytety:

  • Szybkie innowacje, w których deweloperzy mogą rygorystycznie testować najnowsze technologie sztucznej inteligencji przy użyciu danych nieprodukcyjnych.
  • W pełni odizolowane środowiska deweloperskie/testowe i produkcyjne dla sprawdzonych przypadków użycia, które otrzymują finansowanie na wdrożenie operacyjne.

Diagram pokazuje, jak firma Contoso udostępnia wszystkim zespołom wspólną instancję eksploracyjną Foundry do celów innowacyjnych, o ograniczonej pojemności oraz ze wstępnie połączonymi danymi i narzędziami. Przykładowa lista prac odzwierciedla typowe funkcje przedsiębiorstwa, takie jak obsługa klienta, pomoc techniczna dla pracowników, operacje finansowe, zaopatrzenie i sprzedaż. Dotychczas tylko nieliczne przypadki użycia osiągają etap potwierdzonej wykonalności lub pozyskują finansowanie na wdrożenie w środowisku dewelopersko-testowym. Spośród nich jeszcze mniejszy podzbiór trafia do środowiska prod. Na przykładzie widać również dwa powiązane scenariusze użycia w sprzedaży, które pozostają współlokowane na etapie eksploracji i dev/test, ponieważ współdzielą te same dane CRM, persony użytkowników i połączone systemy. W miarę dojrzewania przypadków użycia zespołom przydziela się środowiska o coraz wyższym poziomie izolacji, aż po pełną separację klasy produkcyjnej, w razie potrzeby.

Diagram przedstawiający przypadki użycia firmy Contoso przenoszone ze współdzielonego środowiska eksploracyjnego Foundry do izolowanych lub współlokowanych środowisk programistyczno-testowych, a następnie do izolowanych środowisk produkcyjnych dla mniejszej liczby obciążeń.

Dowiedz się więcej

Następny krok

Tworzenie projektu w narzędziu Foundry

  • Last updated on