Udostępnij za pośrednictwem


Topologie zespołów DevOps

Dystrybucja ról, obowiązków i zaufania między zespołami IT i zespołami aplikacji ma kluczowe znaczenie dla transformacji operacyjnej biorącej udział w wdrożeniu chmury na dużą skalę.

Zespoły IT dążą do utrzymania kontroli. Właściciele aplikacji starają się zmaksymalizować elastyczność. Równowaga, którą ostatecznie ustanowisz między tymi dwoma celami, znacznie wpływa na sukces modelu operacyjnego w chmurze.

Zgodnie z prawem Conway zespoły produkują architektury w oparciu o ich strukturę komunikacji. Zrozumienie tej zasady ma kluczowe znaczenie, ponieważ pracujesz nad osiągnięciem niezbędnej równowagi między autonomią a kontrolą. Każda organizacja, która projektuje system (zdefiniowany szeroko), utworzy strukturę projektową, która jest kopią struktury komunikacji tej organizacji.

Diagram ilustrujący prawo Conwaya.

Z perspektywy metodyki DevOps organizacje muszą zoptymalizować szybkie reagowanie na potrzeby klientów. Zespoły, które posiadają, projektują i implementują swoje aplikacje i systemy, znajdują najwyższy poziom autonomii w architekturach o następujących cechach:

  • Architektura ewolucyjna, która obsługuje stałe zmiany
  • Możliwość wdrażania
  • Możliwość testowania

Rozwiązaniem Conwaya jest outmaneuver Conway's Law. Jeśli Twoja organizacja korzysta z konkretnej struktury do tworzenia usług i produktów i chce zoptymalizować, należy przemyśleć strukturę organizacyjną. Rozwijanie struktury zespołu i organizacji w celu osiągnięcia żądanej architektury.

Diagram manewru odwrotnego conway.

Ta zasada prowadzi do celowo zaprojektowanych topologii zespołu, w których zespoły są odpowiedzialne za kompleksowe działanie wszystkich aplikacji, systemów lub platform, które posiadają, aby osiągnąć pełną dyscyplinę metodyki DevOps.

Poniższa tabela zawiera uproszczoną kategoryzację tych zespołów.

Typ zespołu Definicja
Zespoły obciążeń aplikacji Zespoły te tworzą aplikacje, które prowadzą do bezpośrednich wyników biznesowych dla segmentu domeny biznesowej. W kontekście stref docelowych platformy Azure te zespoły są odpowiedzialne za cały cykl życia obciążeń aplikacji.
Zespoły platform Te zespoły tworzą atrakcyjne platformy wewnętrzne, aby przyspieszyć dostarczanie i zmniejszyć obciążenie poznawcze zespołów obciążeń aplikacji. W kontekście stref docelowych platformy Azure te zespoły są odpowiedzialne za cały cykl życia strefy docelowej platformy Azure.
Włączanie zespołów Zespoły te pomagają przezwyciężyć luki w umiejętnościach, pomagając innym zespołom w wyspecjalizowanych funkcjach, takich jak DevOps.

Uwagi dotyczące projektowania

  • Ustanów międzyfunkcyjny zespół platformy do projektowania, kompilowania, aprowizacji, zarządzania i obsługi cyklu życia strefy docelowej platformy Azure. Ten zespół może obejmować członków centralnego zespołu IT, zabezpieczeń, zgodności i jednostek biznesowych w celu zapewnienia, że reprezentowane jest szerokie spektrum przedsiębiorstwa. Upewnij się, że unikasz antywzorców.

  • Rozważ ustanowienie zespołu umożliwiającego udostępnianie funkcji DevOps do obsługi aplikacji i platform, które nie mają istniejących możliwości metodyki DevOps, lub przypadku biznesowego w celu ustanowienia jednego (na przykład starszych aplikacji z minimalnymi możliwościami programowania).

  • Nie ograniczaj zespołów obciążeń aplikacji do centralnych artefaktów, ponieważ może to utrudnić ich elastyczność. Możesz użyć ładu opartego na zasadach i kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby wymusić spójne konfiguracje odniesienia i upewnić się, że zespoły aplikacji (jednostek biznesowych) są wystarczająco elastyczne, aby wprowadzać innowacje, ale nadal mogą czerpać ze wstępnie zdefiniowanego zestawu szablonów.

  • Nie wymuszaj, aby zespoły aplikacji używały centralnego procesu ani potoku aprowizacji na potrzeby tworzenia wystąpienia zasobów aplikacji ani zarządzania nimi. Istniejące zespoły, które już korzystają z potoku DevOps na potrzeby dostarczania aplikacji, nadal mogą używać swoich bieżących narzędzi. Pamiętaj, że możesz użyć usługi Azure Policy , aby wymusić standardy organizacyjne i ocenić zgodność na dużą skalę i uwzględnić zagadnienia dotyczące zabezpieczeń procesów DevOps.

  • Ogólne zastosowanie modelu DevOps nie powoduje natychmiastowego ustanowienia zdolnych zespołów DevOps.

  • Inwestycje w możliwości inżynieryjne i zasoby mają kluczowe znaczenie.

  • Zespoły aplikacji dla niektórych starszych aplikacji mogą nie mieć zasobów inżynieryjnych wymaganych do dopasowania do strategii DevOps.

Zalecenia dotyczące projektowania

Poniższe sekcje zawierają zalecenia dotyczące projektowania, które ułatwiają projektowanie topologii zespołu.

Dopasowywanie topologii zespołu do modelu operacyjnego w chmurze

Upewnij się, że topologie zespołu są dopasowane do żądanego modelu operacyjnego w chmurze.

Ustanów podstawowy proces przeglądów sprawności operacyjnej, aby w pełni zrozumieć problemy, które mogą wynikać ze struktur zespołu.

Definiowanie funkcji dla zespołu platformy

Poniższa lista zawiera zalecany zestaw funkcji dla zespołu platformy odpowiedzialnego za strefy docelowe platformy Azure:

  • Zarządzanie architekturą
  • Aprowizowanie subskrypcji i delegowanie wymaganych zasad sieci, tożsamości i dostępu
  • Zarządzanie platformami i monitorowanie (całościowe)
  • Zarządzanie kosztami (całościowe)
  • Platforma jako kod (zarządzanie szablonami, skryptami i innymi zasobami)
  • Ogólne operacje na platformie Microsoft Azure w ramach dzierżawy firmy Microsoft Entra (zarządzanie jednostkami usług, rejestracją interfejsu API programu Microsoft Graph i definicjami ról)
  • Kontrola dostępu oparta na rolach platformy Azure (holistyczne)
  • Zarządzanie kluczami dla usług centralnych (prosty protokół transferu poczty i kontrolery domeny)
  • Zarządzanie zasadami i wymuszanie (całościowe)
  • Monitorowanie i inspekcje zabezpieczeń (całościowe)
  • Zarządzanie siecią (całościowe)

Definiowanie funkcji dla zespołów obciążeń aplikacji

Poniższa lista zawiera zalecany zestaw funkcji dla zespołów aplikacji odpowiedzialnych za obciążenia aplikacji:

  • Tworzenie zasobów aplikacji i zarządzanie nimi za pomocą modelu DevOps
  • Zarządzanie bazami danych
  • Migracja lub transformacja aplikacji
  • Zarządzanie aplikacjami i monitorowanie (zasoby aplikacji)
  • Kontrola dostępu oparta na rolach platformy Azure (zasoby aplikacji)
  • Monitorowanie i inspekcje zabezpieczeń (zasoby aplikacji)
  • Zarządzanie wpisami tajnymi i kluczami (klucze aplikacji)
  • Zarządzanie kosztami (zasoby aplikacji)
  • Zarządzanie siecią (zasoby aplikacji)

Definiowanie funkcji umożliwiających zespołom

Poniższa lista zawiera zalecany zestaw funkcji umożliwiających zespołowi odpowiedzialnemu za pomoc innym zespołom:

  • Definicja poziomych (wielofunkcyjnych) wskazówek i możliwości ułatwiających uzyskanie odpowiedniej wiedzy w całej organizacji, co zapewnia dopasowanie do ogólnego docelowego modelu operacyjnego w chmurze (takiego jak DevOps)
  • Wsparcie, szkolenie i coaching dla innych zespołów w celu osiągnięcia niezbędnego poziomu wiedzy
  • Utworzenie wspólnego zestawu szablonów wielokrotnego użytku i bibliotek dla zespołów aplikacji lub platform oraz wspieranie wewnętrznego tworzenia modułów, takich jak zweryfikowane moduły platformy Azure.

Definiowanie trybów interakcji między zespołami

Cele interakcji między zespołami to:

  • Osiągnięcie autonomii
  • Odblokowywanie zależności
  • Minimalizuj czas marnowania
  • Unikaj wąskich gardeł

Topologie zespołu przedstawiają trzy tryby interakcji zespołu:

Tryb interakcji opis
Współpraca Zespoły ściśle współpracują ze sobą.
X-as-a-Service Zespoły używają lub udostępniają coś innym zespołom z minimalną współpracą, podobnie jak w przypadku interakcji z dostawcami innych firm.
Ułatwianie Pomoc zespołu lub pomocna przez inny zespół w celu usunięcia przeszkód.