Jakie są możliwe wdrożenia (lub przykłady) zasady czterech oczu?

22

Michael Grünewald opublikował ostatnio ten komentarz :

Bardzo ważną metodą, o której nie wspominasz, jest „zasada czterech oczu” stosowana w finansach - albo jako obowiązek regulacyjny, albo jako ochrona. W branży oprogramowania jest on wdrażany na różne sposoby, np. Recenzje kodu, ale może być również wykorzystywany do sprawdzania poprawności poleceń wpływających na systemy na żywo.

Popraw mnie, jeśli się mylę, ale nauczono mnie, że „zasada czterech oczu” dotyczy czegoś, co jest „zatwierdzone na wydarzenie”, po tym, jak co najmniej 2 istoty ludzkie (i / lub zautomatyzowane procesy) udzieliły wcześniejszego błogosławieństwa. Lub użyć (nieznacznie poprawionego) sformułowania o „regule dwóch (wo) ludzi” z Wikipedii :

Reguła dwóch osób to mechanizm kontrolny zaprojektowany w celu osiągnięcia wysokiego poziomu bezpieczeństwa szczególnie krytycznych materiałów lub operacji. Zgodnie z tą zasadą wszelki dostęp i działania wymagają obecności dwóch upoważnionych osób przez cały czas.

Obowiązki regulacyjne są tutaj całkiem pewne, ale w kontekście „bezpiecznej ochrony”, jakie są możliwe koncepcyjne wdrożenia tej zasady czterech oczu, które prawdopodobnie mogłyby mieć zastosowanie do dowolnej używanej platformy / systemu operacyjnego / sprzętu?

Pierre.Vriens
źródło

Odpowiedzi:

11

Jedną z implementacji kodu jest spopularyzowany przez GitHub model żądania żądania (PR).

Głównym powodem jest to, że tylko niewielki zestaw opiekunów produktu będzie mógł scalić kod z gałęzią wydania. Każda nowa funkcja / poprawka pojawi się w nowej gałęzi, a po jej zakończeniu zostanie zdefiniowana jako żądanie ściągnięcia.

Pozwala to na automatyczne testowanie scalenia kodu z rzeczywistego wydania (głównego) z kodem w PR (Travis jest najbardziej popularny w publicznym projekcie) i daje pierwszą informację zwrotną na temat jakości kodu. Travis CI (na przykład) może działać na wyniku rzeczywistego wzorca z połączonym z nim kodem z żądania ściągnięcia, więc zawiedzie, jeśli scalenie jest niemożliwe lub jeśli polecenia zdefiniowane w travisci.yml zwrócą niezerowe wyjście kod

Po automatycznych testach, zgodnie z zasadą 4 oczu, nadal wymagana jest konfigurowalna liczba osób do przeglądu i zatwierdzenia zmiany, zanim zostanie ona scalona, ​​oczywiście co najmniej 1 osoba (która nie jest autorem PR), aby wymusić 4 oczy oceniające zmiany.

Istnieje szeroki zakres opcji automatycznego scalania po osiągnięciu kworum recenzentów lub ciągłego ręcznego scalania przez opiekuna.

Zezwolenia na przeglądanie i scalanie można rozdzielić, co pomaga większej liczbie osób w „głosowaniu” nad statusem scalania, zachowując jednocześnie możliwość ograniczenia, kto może faktycznie scalić.

Tensibai
źródło
Sprawdź drobne zmiany swojej odpowiedzi (literówki). Jeśli ich nie lubisz, po prostu cofnij lub ponownie edytuj, dobrze? Poza tym nie myślałem o tych PR-ach, więc na pewno bardzo przydatne. Oznaczę tę odpowiedź jako zaakceptowaną („nauczyłem się” z niej, rzeczy w mojej własnej odpowiedzi oczywiście znałem). Chociaż nie gwarantuję w przyszłości, że mogę zmienić zdanie (nieakceptowane), jeśli zostanie opublikowana jeszcze lepsza odpowiedź. About: „Pozwala to na automatyczne testowanie połączenia z faktycznego wydania (głównego) kodu z kodem w PR”, nie rozumiem, czy powinienem zadać nowe pytanie?
Pierre.Vriens
@ Pierre możesz zmienić zdanie tak często, jak chcesz :) W celu przetestowania proponowanego kodu Travis CI (na przykład) może działać na wyniku rzeczywistego wzorca z połączonym z nim kodem żądania ściągnięcia, więc będzie kończy się niepowodzeniem, jeśli scalenie jest niemożliwe lub jeśli polecenia zdefiniowane w pliku travisci.yml zwracają niezerowy kod wyjścia. FWIW, googlowanie brzmi najlepiej, podejście IMHO, temat jest duży
Tensibai
@ pierre i dla celów edycji, tylko jeden punkt, zasada 4 oczu polega na tym, że 1 osoba musi dokonać przeglądu, co oznacza, że ​​2 osoby widziały zmianę (autor jej nie sprawdził), stąd liczba pojedyncza na zmiennej liczbie osób ( jak może być tylko jeden, a po francusku może tylko jeden jest w liczbie pojedynczej: p). Nie mówię tak płynnie po angielsku, jak bym chciał, ale myślę, że pierwszy punkt jest poprawny (2 czytelników, 2
widziało
aha, to masz na myśli, teraz rozumiem (i mogłem skopiować / wkleić dodatkowe wyjaśnienie do swojej odpowiedzi). BTW: ex a mple (w EN), nie ex e mple (jak we FR) ...
Pierre.Vriens
@ Pierre.Vriens obwinia auto-korektę podwójnym językiem :)
Tensibai,
9

Recenzje kodu

Chodzi o to, aby przynajmniej 1 inna osoba spojrzała na kod napisany przez kogoś, np. W celu oceny, czy spełnia on określone wcześniej kryteria, takie jak:

  • Standardy kodowania (wcięcia itp.).
  • Dokumentacja wbudowana.
  • Utrzymywalność kodu.
  • Obsługa błędów.
  • Kompletność (np if/then/elselub case/whenkonstrukty obejmują wszystkie możliwe przypadki).

Zatwierdzenia do aktualizacji niektórych środowisk docelowych

Chodzi o posiadanie co najmniej 2 potwierdzeń od jakiejś osoby i / lub zautomatyzowanego systemu, zanim będzie można zaktualizować jakieś środowisko docelowe (które może być aktywne lub może być czymś w rodzaju biblioteki plików głównych / podstawowej). Oto niektóre przykłady:

  • Podczas przekształcania (budowania) komponentów źródłowych w komponenty wykonywalne dozwolony jest tylko ograniczony zestaw ostrzeżeń.
  • Pewien zestaw testów automatycznych musiał zostać zakończony bez żadnych problemów.
  • Niektóre istoty ludzkie musiały wcześniej wyrazić zgodę (i bez tego wszelkie próby aktualizacji środowisk docelowych automatycznie nie powiodą się).
Pierre.Vriens
źródło
6

Oto strategie / wzorce, o których mogę myśleć:

Rozdzielenie cła

DevOps, przynajmniej moim zdaniem, nie oznacza ucieleśnienia zarówno deweloperów, jak i operatów w jednej osobie. Tak więc nadal można rozdzielić ten obowiązek tak, aby ten, który pisze kod (dev), nie był tym, który go wykonuje (ops).

Na przykład, jeśli instrukcja SQL ma być wykonywana w środowisku na żywo, jeden zapisuje SQL, a drugi go wykonuje. To, co zakłada, to ta, która wykonuje, musi także rozumieć SQL, a nie tylko wykonywać.

Wdróż wyzwalacz

Chociaż istnieją zalety ciągłego wdrażania. Zespół z bardziej uregulowanej branży może wyznaczyć inną (oddzielną) stronę do uruchomienia wdrożenia zamiast wdrażania automatycznego. Lista kontrolna, testy automatyczne, sumy kontrolne są możliwymi kontrolami przed uruchomieniem wdrażania.

Po uruchomieniu automatyzacja może rozpocząć wdrażanie.

Programowanie par

Osobiście nie cytowałem tej techniki jako metody służącej audytorowi do spełnienia zasady kontroli i równowagi. Ale potencjalnie myślę, że może to być strategia.

MSZ

Być może rozciągam się nieco przy tym, ale możliwe jest, że z jakiegoś powodu nie chcesz jednostronnego wejścia do systemu, ktoś może przechowywać hasło, a inna osoba może posiadać token lub urządzenie dla jednego kodu czasowego. Aby więc ocenić system, muszą być obecne 2 osoby.

kenchew
źródło
Merci za te ciekawe odmiany! Nigdy wcześniej nie słyszałem o tym „Programowaniu par”, to naprawdę wydaje się odmianą gry na pianinie z „4 rękami”!
Pierre.Vriens
1
Niedawno przeprowadziłem wywiad z firmą, która wykonuje najbardziej intensywną formę programowania par, jaką kiedykolwiek widziałem. Mieli konfiguracje „pod” z dwoma maszynami, każda z jednym dedykowanym monitorem i jednym monitorem współdzielonym. WSZYSTKO opracowano w parach. To nie jest dla wszystkich, ale według wszystkich raportów działa dla nich dobrze.
Dave Swersky