Jakie procesy lub narzędzia umożliwiają podział obowiązków, gdy inżynierowie wdrażają i uruchamiają kod?

18

W ściśle regulowanych środowiskach, takich jak sektor usług finansowych, podział obowiązków jest niezbędnym mechanizmem unikania kolizji między osobami mającymi obowiązki rozwojowe i przywileje produkcyjne.

Tradycyjnie oznacza to, że programiści opracowują kod, a następnie przekazują go do Operacji, jednak w wielu modelach operacyjnych DevOps segregacja między Programowaniem a Operacjami jest co najmniej niewyraźna:

Po miesiącach spędzonych na zgłębianiu podstawowych przyczyn mechanizmu podziału obowiązków wydaje się, że przede wszystkim ma on zaspokoić Sarbanes Oxley Sekcja 404 : Ocena zarządzania kontrolą wewnętrzną:

(a) Wymagane zasady. Komisja określa zasady wymagające, aby każdy raport roczny wymagany zgodnie z sekcją 13 (a) lub 15 (d) Ustawy o giełdzie papierów wartościowych z 1934 r. Zawierał raport z kontroli wewnętrznej, który:

(1) określa odpowiedzialność kierownictwa za ustanowienie i utrzymanie odpowiedniej struktury kontroli wewnętrznej i procedur sprawozdawczości finansowej; i

(2) zawierają ocenę, na koniec ostatniego roku obrotowego emitenta, skuteczności struktury kontroli wewnętrznej i procedur emitenta w zakresie sprawozdawczości finansowej.

(b) Ocena i raportowanie kontroli wewnętrznej. Na podstawie oceny kontroli wewnętrznej wymaganej na mocy podsekcji (a) każda zarejestrowana publiczna firma księgowa, która przygotowuje lub wydaje sprawozdanie z audytu dla emitenta, poświadcza ocenę dokonaną przez kierownictwo emitenta i składa sprawozdanie z tej oceny. Poświadczenie dokonane zgodnie z niniejszą podsekcją powinno być wykonane zgodnie ze standardami dotyczącymi poświadczeń wydanymi lub przyjętymi przez zarząd. Każde takie zaświadczenie nie będzie przedmiotem odrębnego zlecenia.

W oparciu o komentarze ważne jest, aby podać kilka moich założeń :

  • Rozważam przede wszystkim usługi finansowe na masowym rynku, tzn. Wolumeny transakcji są wysokie, ale ich wartość jest stosunkowo niska. Byłoby to w przeciwieństwie do komercyjnych usług finansowych, które mają inny profil wartości transakcji.
  • Oferta online instytucji finansowej będzie się składać z wielu elementów o różnych względach ryzyka:
    • Przenieś pieniądze - przenoszenie pieniędzy między kontami lub transfery między kontami różnych właścicieli. Operacja, która musi wziąć pod uwagę przeciwdziałanie praniu pieniędzy, ochronie przed oszustwami i krajom objętym embargiem, aby wymienić tylko kilka.
    • Pozyskiwanie klientów - mniej „ryzykowne”, ponieważ ma niski wolumen transakcji w porównaniu do Move Money, ale nadal wymaga rozważenia.
    • Bankowość internetowa - obejmuje szeroki zakres usług o różnym poziomie ryzyka, ruchome pieniądze byłyby uważane za część tego.
  • Można sobie wyobrazić inne podejście do każdego z nich w zależności od ryzyka, jednak w celu uproszczenia pracuję nad rozwiązaniem, które byłoby odpowiednie dla niektórych najbardziej ryzykownych operacji.

TL; DR : To jest odpowiedzialność kierownictwa w celu zapewnienia, że odpowiednie kontrole wewnętrzne są w miejscu, które spełniają KPWiG w przepisach .

Sarbanes Oxley 404 jest zwykle usatysfakcjonowany poprzez zakończenie odgórnej oceny ryzyka, której część oceni ryzyko zmowy i przedstawi strategie ograniczania ryzyka.

W firmie, która stosuje praktykę i kulturę DevOps, w której programiści rutynowo mają dostęp zarówno do kontroli źródła, jak i produkcji, w jaki sposób można osiągnąć Podział obowiązków, lub bardziej ogólnie, w jaki sposób można zminimalizować ryzyko zmowy.

sre financial-services operating-model Richard Slater
źródło
Główna idea organizacji devops polegająca na tym, że wszyscy członkowie zespołu są odpowiedzialni za to, co dzieje się w produkcji, nie może być rozdzielenia obowiązków. Oznacza to przede wszystkim, że tego rodzaju organizacja nie może być naprawdę wykorzystywana, gdy istnieją regulacyjne potrzeby tego oddzielenia.
Tensibai
@Tensbai Fundamentalnie nie zgadzam się z twierdzeniem, że DevOps jest niezgodny z podziałem obowiązków. Przepisy nie mają charakteru nakazowego co do sposobu kontroli, a organy regulacyjne nie nakładają z góry określonego procesu na banki i usługi finansowe. W dużej mierze od organizacji zależy określenie, co jest właściwe, i zachowanie całkowitej przejrzystości wobec organów regulacyjnych i ich wyznaczonych audytorów. Jako przykład zarówno ING, jak i Barclays przyjęły praktyki DevOps, aby umożliwić im przyspieszenie zdolności dostarczania wartości klientom.
Richard Slater
Tak, dewotki na temat podmiotów niezwiązanych z separacją regulacyjną i skorzystali z automatyzacji tradycyjnej organizacji opartej na silosie dla ograniczonych podmiotów (których w rzeczywistości jest bardzo niewiele). Mają tylko dwa rodzaje organizacji w zależności od tego, jakie operacje wykona oprogramowanie
Tensibai
Nie ma czegoś takiego jak „rozdział regulacyjny”, statuty / ustawy i organy regulacyjne nie nakładają separacji na instytucje finansowe, które nakładają odpowiedzialność zarządczą za posiadanie „odpowiednich kontroli” w celu zarządzania ryzykiem finansowym. W ten sam sposób, w jaki Agile przeniosło tworzenie oprogramowania z długich cykli na małe cykle, DevOps przekształca operacje w małe cykle, DevOps w usługach finansowych musi znaleźć sposób na podzielenie obowiązków na małe cykle, na przykład poprzez utworzenie potoku CD, który wymusza „odpowiednie kontrole”, takie jak wzajemna ocena i promocja oparta na zatwierdzeniu.
Richard Slater
1
@ Pierre.Vriens tak szerokie pytanie znajduje się w tytule, starałem się go rozwinąć, przyjmując pewne założenia. Role prawdopodobnie będą częścią rozwiązania, podobnie jak Break-Glass i zarządzanie kontami uprzywilejowanymi. Role i obowiązki są interesującą koncepcją w DevOps / Agile, ponieważ dawno temu miałeś programistę Java, programistę F / E, projektanta, PM, inżyniera budowania, menedżera wydań i inżyniera operacyjnego - teraz masz grupę ludzi, którzy mogą nosić wiele czapek - zespoły funkcjonalne złożone z „inżynierów”, którzy mogą się specjalizować, ale ostatecznie dzielą odpowiedzialność.
Richard Slater

Odpowiedzi:

8

Wygląda na to, że twoje pytanie nie zawiera żadnych założeń dotyczących platformy / systemu operacyjnego, na których jest ono oparte. Dlatego sensowne może być dodanie odpowiedzi na temat tego, jak zazwyczaj robi się to / rozwiązuje w środowisku komputerów mainframe, gdzie „inżynierowie” (jak w tytule twojego pytania) to tak naprawdę grupy ludzi, których dziesiątki (być może setki) ludzi są zaangażowany. Moja odpowiedź opiera się na użyciu produktu SCM, z którym jestem najbardziej zaznajomiony (nie jestem pewien, czy jest to konieczne do ujawnienia nazwy produktu).

1. Architektura

Oto najważniejsze informacje, w jaki sposób odpowiedziałbym na twoje pytanie:

  • Cały kod (i powiązane artefakty, takie jak pliki wykonywalne itp.) Są przechowywane w plikach, które razem nazywamy strukturą biblioteki .
  • Dla każdego środowiska w każdym (ewentualnie zdalnym) systemie docelowym jest serwer („uruchomione zadanie” w mowie na komputerze mainframe), który dba o WSZYSTKIE aktualizacje (powtarzanie: WSZYSTKO) w dowolnej strukturze biblioteki. Istnieje kilka wyjątków (np. Pracownicy ochrony lub zespół zarządzania przestrzenią), ale poza tym nikt (powtórz: nikt) nie ma uprawnień do stosowania aktualizacji do dowolnego pliku w tej strukturze biblioteki. Innymi słowy: serwer otrzymuje wyłączne uprawnienia do aktualizacji całej struktury biblioteki . Uwaga: ludzie OPS wpadną w szał, jeśli wejdziesz, aby ograniczyć ich dostęp (na początku będą się opierać ...), więc upewnij się, że jesteś objęty wyższym kierownictwem (CxO), aby narzucić te zasady dostępu ...
  • Rzeczywiste zmiany oprogramowania składają się z jednego komponentu (drobna poprawka kodu w środku nocy ...), lub mogą to być setki lub tysiące źródeł, plików wykonywalnych lub dowolnych innych artefaktów (podczas weekendu wydania). Aby można było nimi zarządzać, rzeczy, które powinny być przenoszone (mniej więcej) jednocześnie, są pakowane razem w tak zwany pakiet zmian oprogramowania .

Po wprowadzeniu powyższego wszelkie aktualizacje serwera, które zostaną zastosowane w strukturze biblioteki, będą możliwe tylko poprzez dobrze zdefiniowany przepływ pracy, który nazywamy cyklem życia pakietu zmian oprogramowania (SDLC, jeśli wolisz). Aby faktycznie wykonać różne kroki w tym przepływie pracy, wystarczy, aby tak się stało:

  • Tylko serwer wykona wymagane (i wstępnie skonfigurowane) kroki.
  • Serwer wykona tylko określony krok (= zaktualizuje coś gdzieś w strukturze biblioteki), po zebraniu wymaganych zatwierdzeń (od ludzi) do wykonania takiego kroku.
  • Zezwolenia mogą być wydawane tylko przez użytkowników, którzy mają rolę, która pozwala im (= pozwolenie) na wydawanie takich zatwierdzeń.

2. Role i uprawnienia

Serwer zapewni, że użytkownik próbujący dokonać czegoś (np. „Zatwierdzić coś”) będzie mógł to zrobić tylko wtedy, gdy uprawnienia użytkownika będą odpowiednie. Ta część jest łatwa. Ale nie chcesz używać systemu SCM do administrowania wszystkimi uprawnieniami dla wszystkich zaangażowanych użytkowników, to właśnie należy do twojego systemu bezpieczeństwa (nie do systemu SCM!), Abyś mógł dostosować swój przepływ pracy (w systemie SCM) w razie potrzeby sprawdź te uprawnienia. Poniższe kroki zawierają więcej szczegółowych informacji na ten temat.

Krok 1: Skonfiguruj uprawnienia (w systemie bezpieczeństwa)

  • Zdefiniuj jednostki bezpieczeństwa w swoim systemie bezpieczeństwa, używając dobrze zdefiniowanych nazw dla tych jednostek. Kilka próbek (dodaj tyle podobnych do własnych potrzeb):

    • PrmUnitStosowane dla uzyskania uprawnienia do żądania Promuj powiedzieć Jednostka -testing.
    • PrmQAStosowane dla uzyskania uprawnienia do żądania Promuj powiedzieć Qa -testing (załóżmy, jest to najwyższy poziom testowania).
    • PrdEnduser, wykorzystywane przez użytkowników końcowych zaangażowanych w pewien poziom testów, aby wskazać, że są zadowoleni z wyników uzyskanych w wyniku pewnego rodzaju testów. Z tego powodu ci użytkownicy końcowi zgadzają się z postępem zmian w strukturze biblioteki.
    • PrdRelmgnt, używane przez menedżerów wydań do autoryzacji aktywacji w produkcji (= ostatni / najwyższy poziom w strukturze biblioteki).

  • Zdefiniuj grupy użytkowników w systemie bezpieczeństwa. Kilka próbek (dodaj tyle podobnych do własnych potrzeb):

    • GrpDevs, co (powiedzmy) odpowiada Twoim programistom (prawdopodobnie więcej niż tylko 1).
    • GrpEnduser, który (powiedzmy) odpowiada użytkownikom końcowym (co najmniej 1, najlepiej z podobnymi użytkownikami).
    • GrpRelMgnt, co (powiedzmy) odpowiada menedżerom wydań (co najmniej 1, najlepiej kilku innym użytkownikom).

  • Udziel uprawnień , także przy użyciu systemu zabezpieczeń, aby umożliwić dostęp do wybranych „ podmiotów bezpieczeństwa ” dla wybranych „ grup użytkowników ”. Aby kontynuować powyższy przykład, oto, co wydaje się właściwe (dostosuj do własnych potrzeb):

    • Grupa GrpDevsuzyskuje dostęp do (tylko!) Jednostki bezpieczeństwa PrmUnit.
    • Grupa GrpEnduseruzyskuje dostęp do (tylko!) Jednostki bezpieczeństwa PrdEnduser.
    • Grupa GrpRelMgntuzyskuje dostęp do (zarówno!) Jednostki bezpieczeństwa, jak PrmQAi PrdRelmgnt.

Krok 2: Skonfiguruj przepływ pracy (w systemie SCM)

Po skonfigurowaniu uprawnień w systemie bezpieczeństwa (jak w kroku 1), wszystko, co pozostało do zrobienia w systemie SCM, to skonfigurowanie, w jaki sposób poszczególne kroki w cyklu życia pasują do powiązanych jednostek bezpieczeństwa w systemie bezpieczeństwa. Oznacza to, że tylko ci użytkownicy, którzy mają odpowiedni dostęp do wymaganej jednostki bezpieczeństwa, mogą poprosić serwer o wykonanie odpowiedniego kroku w przepływie pracy.

Oto kilka przykładów konfiguracji systemu SCM, aby magia się wydarzyła:

  • Jeśli użytkownik ma dostęp do PrmUnit, wówczas użytkownik może poprosić o Promuj się Jednostka -testing. Oczywiście, użytkownicy w grupie GrpDevssą użytkownikami upoważnionymi do tego (uwaga: nie, np. Użytkownicy w grupie GrpRelMgnt).
  • Jeśli użytkownik ma dostęp do PrmQA, wówczas użytkownik może poprosić o Promuj do QA -testing. Oczywiście, użytkownicy w grupie GrpRelMgntsą użytkownikami upoważnionymi do tego (uwaga: nie, np. Użytkownicy w grupie GrpDevslub w grupie GrpEnduser).
  • Jeśli użytkownik ma dostęp PrdEnduser, może zezwolić na zmianę w strukturze biblioteki (co jest zwykle warunkiem wstępnym dla użytkowników w grupie, GrpRelMgntaby mogli przejrzeć zmianę). Oczywiście, użytkownicy w grupie GrpEndusersą (jedynymi) użytkownikami upoważnionymi do tego.
  • Jeśli użytkownik ma dostęp do PrdRelmgnttakiego konta, może autoryzować Aktywację w produkcji (= ostatni / najwyższy poziom w strukturze biblioteki).

3. Spodziewaj się nieoczekiwanego i przygotuj się na to

Powyższe jest tylko schematem, który, mam nadzieję, pomoże zrozumieć, w jaki sposób ostatecznie serwer zajmuje się podziałem obowiązków ... pod warunkiem, że masz CxO narzucające ci zasady dostępu, które nie wszystkim się spodobają.

Aby uzupełnić obraz, jak wyjaśniono powyżej, serwer tworzy ścieżkę audytu (rejestrowanie) wszystkiego, co dzieje się w systemie. Aby w dowolnym momencie zawsze można było odpowiedzieć na pytania takie jak

Co się stało, kiedy i dlaczego, i który autoryzowany użytkownik faktycznie zatwierdził to ... z góry?

Ale prawdopodobnie najtrudniejszą częścią jest posiadanie odpowiednich narzędzi do raportowania (i umiejętność ich używania). Przynajmniej w celu (łatwego) spełnienia wymagań audytorów IT (ich pytania mogą być bardzo trudne). Ale również wskaż odpowiednie zapisy dziennika w twoim systemie SCM, aby odpowiedzieć na wszelkiego rodzaju pytania „co się stało” w sytuacjach kryzysowych, w których produkcja (części) spada.

PS: Pozostawiam to każdemu do oceny, jeśli moja odpowiedź brzmi „tak” lub „nie” zgodna z DevOps.

Pierre.Vriens
źródło
To brzmi jak podstawowa implementacja odgórnej oceny ryzyka, nie rozumiem, w jaki sposób odpowiada ona na pytanie, w jaki sposób można to wdrożyć w sposób devops, w którym deweloperzy mieliby prawo do uruchomienia przełącznika „wdróż”. Czy to pomysł, że nie możesz tego zrobić w organizacji devops?
Tensibai,
@Tensibai „jeśli” deweloperzy mieliby autoryzację (rolę) (np.) Ostatecznego zatwierdzenia dla prod (czego zwykle NIE mają w takich organizacjach), to taki serwer (rozpoczęte zadanie) rozpocząłby wdrożenie. A jeśli chodzi o tytuł pytania, myślę, że jest to „możliwa” odpowiedź. Można jednak zadać pytanie, czy to właśnie nazwalibyśmy organizacją DevOps, ale wiem, że audytorom podoba się ten rodzaj „konfigurowalnego” podziału obowiązków (np. Cztery oczy i ich warianty). Może Richard może nam pomóc z jego poglądem na ten temat?
Pierre.Vriens
1
Zgadzam się z audytorami, że to absolutnie absolutnie, właśnie przegapiłem, jak to się odnosi do „eksplozji” dostępu, czego audytor zwykle nie lubi, gdy lista zawiera więcej niż 6 do 7 osób. Mówienie, że nie pasuje, jest absolutnie prawidłową odpowiedzią IMHO.
Tensibai
1
Dziękujemy za poświęcenie tyle czasu na odpowiedź. Właściwie myślę o wdrożeniu reguły 3-osobowej, w której jeden programista pisze kod, inny programista sprawdza kod, a trzecia naciska przycisk zwalniający, aby wdrożyć kod. Innym aspektem jest to, że jest to część przyjęcia Agile / DevOps w całej firmie, zespoły programistyczne są dość małe, z efektem netto małych grup ludzi mających dostęp do produkcji do cienkiego segmentu produkcji, wydaje się to korzystne z perspektywy ryzyka .
Richard Slater
1
@ Pierre.Vriens Nie mogę dwukrotnie głosować, świetne rozszerzenie :)
Tensibai
5

Odpowiedź oparta na mojej znajomości francuskiego rozporządzenia „Kontrola wewnętrzna”, coś w rodzaju odpowiednika przepisów SEC, na które wskazujesz, zakładam, że link tutaj do francuskiego tekstu prawnego nie byłby naprawdę przydatny i nie znam dobrego tłumaczenia tego.

W idealnym modelu „Budujesz, uruchamiasz” wszyscy w zespole będą odpowiedzialni za zmianę. Ocena ryzyka nie może być wymuszona przez podział obowiązków, a jedynym sposobem, w jaki wiem, aby zachować zgodność z przepisami, jest przeprowadzanie okresowej kontroli krótkiego cyklu transakcji wraz z niezmiennym śledzeniem działań, aby wrócić do osoby, która dokonała zwolnienia .
Oznacza to, że wszystkie dzienniki transakcji i działań są przekazywane do ograniczonego obszaru, do którego zespół nie ma dostępu, zmiana w tym, co jest rejestrowane „powinna” zostać przechwycona przez testy funkcjonalne, do których zespół nie ma dostępu, a co gorsza, zostanie złapana przez audyt i śledzone przez autora.

Nie dotyczy to wszystkich produktów, podczas pisania we Francji każda firma, która może emitować pieniądze (głównie banki), musi dopilnować, aby każda transakcja została zarejestrowana, a zatem nie może podjąć ryzyka pominięcia transakcji.
Z drugiej strony nie mają prawnego obowiązku śledzenia żadnej oferty handlowej ani oceny ryzyka, gdy ktoś poprosi o pożyczkę, a zatem produkty obsługujące tę selekcję klientów i obliczające opłaty, które będą w ofercie, łatwiej zmieścić na stanowisku -release model audytu.

Główną ideą jest to, że model wydania musi zostać dostosowany zgodnie z obowiązkami oceny ryzyka.

Pokrewnym zasobem jest norma ISO27001 .

Tensibai
źródło
Ciekawa odpowiedź i bardzo istotna, ponieważ wiele banków europejskich faktycznie działa we Francji. Czy jest jakaś szansa na rozwinięcie znaczenia „Emit Money”, tj. Czy jest to tylko gotówka z bankomatu, czy też obejmuje saldo transferów. W takim przypadku link do statutu byłby cenny, ponieważ daje wskazówkę do odpowiednich przepisów, niezależnie od języka, w jakim się znajdują.
Richard Slater
@RichardSlater W skrócie, każda firma pracująca z pieniędzmi może być firmą wyłącznie inwestycyjną, a także pośrednikami kredytowymi wzdłuż tradycyjnych banków. Dotyczy to przede wszystkim wszystkiego, co gdzieś ma wpływ finansowy (poza nielicznymi wyjątkami, które organ może podać w określonych okolicznościach). Legalna „lista” po francusku jest tutaj, ale nawet po francusku nie zawsze jest to oczywiste.
Tensibai
Przyjmuję założenie, że link do normy ISO powinien faktycznie być ISO27001: 2013
Richard Slater
@ Richard rzeczywiście wydaje się, że link z francuskiego na angielski nie został zaktualizowany na Wikipedii. Zaktualizuję później (lub jeśli chcesz, możesz edytować)
Tensibai
powiązane: Jak przekonać programistów w moim zespole do przyjęcia „Ty budujesz, uruchamiasz”?
Dan Cornilescu
0

IMHO, Developers & Operations mogą być reprezentowane jedynie przez dwa repozytoria git dla tej samej bazy kodów , z odrębnymi modelami uprawnień, tak aby zespoły w ogóle nie przeszkadzały sobie w pracy.

Nazwijmy je Dev.mygithub.co & ops.mygithub.co , jako przykład.

Chodzi o to, że deweloperzy mogą swobodnie tworzyć / oddział / scalanie do syta -git jest zapewnienie pełnej identyfikowalności i że liczy się tutaj- międzyczasie, w momentach, że ramy regulacyjne implikuje wysiłek przeglądu Zapytanie Pull mogą być podniesione, na połączenie nastąpi w kontrolowany sposób.

Przenosząc tę ​​koncepcję na wyższy poziom: rozwijać gałąź można rozmnażać w kierunku zdalnych ops' produkcji poprzez kolejną Pull żądanie czynu. Ta ostatnia część musi odbywać się rękami i oczami operatorów, ponieważ mają oni obowiązek zweryfikować ją w produkcji i wybierają poziom recenzji.

Taki schemat pozwala na nieskończoną elastyczność, pełną identyfikowalność, zdolność do wczesnego wychwytywania problemów za pomocą różnych procesów, oddzielenie problemów i bardzo rozsądne doświadczenie użytkownika w tym procesie !

Uwaga: Model opisany powyżej może być zastosowany, nawet jeśli Ops & Dev całkowicie się pokrywają!

fgeorgatos
źródło
1
Z pewnością tę samą kontrolę można osiągnąć poprzez żądania ściągania i przechwyty po zatwierdzeniu, które zapewniają, że programiści mogą swobodnie zatwierdzać, jednak scalanie zatwierdzeń może być dokonywane tylko przez zatwierdzoną grupę osób. Podobnie ten sam haczyk po zatwierdzeniu mógłby zapewnić, że autorzy zatwierdzeń, którzy utworzyli żądanie ściągnięcia, nie obejmowali osoby składającej żądanie ściągnięcia.
Richard Slater
@RichardSlater: powód, dla którego możesz chcieć mieć dwa odrębne repozytoria, to podwójna potrzeba umożliwienia programistom scalenia - kiedy swobodnie podmieniają kod w trybie programistycznym - oraz zablokowania większości programistów przed scalaniem kodu, gdy jest przejść do produkcji (modulo SysOps, tj. tak zwana „zatwierdzona grupa ludzi”).
fgeorgatos
Ponownie możesz to osiągnąć dzięki przechwytywaniu po zatwierdzeniu i żądaniom ściągania, nie wspominając już o tym, że GitHub Enterprise pozwala na chronione gałęzie.
Richard Slater
0

wyższy jest droższy:

  • odrębne strony deweloperów i operatorów oraz metody przenoszenia pracy z jednej strony na drugą
  • odrębne systemy i metody deweloperów i operatorów operacyjnych, jak wyżej
  • odrębne repozytoria dev i ops git / vcs i powiązane metody
  • odrębne gałęzie dev i ops git / vcs (chronione) i powiązane metody

W zależności od tego, co robisz, niektóre rozwiązania są lepsze niż inne, na przykład jeśli potrzebujesz obsługiwać dwa zespoły z odrębnymi rolami, a każdy z nich ma własność i zapewnia pełną identyfikowalność, przesuwasz się nad pierwszymi trzema.

Krótko mówiąc, wszystko, co wymusza to, że jeden facet lub gal nie może wziąć piłki samotnie i biegać z nią, a on / ona przekracza wyraźną wyraźną granicę między deweloperami i operatorami. Teraz, w zależności od poziomu ryzyka, granica ta może być egzekwowana lub nie.

fgeorgatos
źródło