Jak wdrożyć zasadę czterech oczu w przypadku napraw awaryjnych?

Rozważ ten scenariusz (każde porównanie z sytuacjami w świecie rzeczywistym jest przypadkowe):

3:07 : przychodzące wezwanie pomocy technicznej „ Coś w produkcji spadło, potrzebuję twojej pomocy! ”.
3:12 : podłączony do systemu (logowanie zaakceptowane) ... i nie ma czasu na kawę.
3:15 : na szczęście, od razu możesz znaleźć problem za pomocą jakiegoś komunikatu o błędzie.
3:17 : użyj swojego przybornika SCM, aby pobrać kod, naprawić problem, przetestować go, świetnie ... moja poprawka działa!
3:20 : skontaktuj się z zespołem ~~Dev~~ Ops, aby wysłać poprawkę i ponownie uruchomić produkcję.
3:21 : czerwona flaga ... „ Aby uszanować czwórkę , potrzebujemy jeszcze 2 oczu, aby uzyskać zgodę na tę poprawkę ”.
3:22 : ggggrrrreat, a teraz, do kogo jeszcze możemy zadzwonić (= obudzić jakiegoś kierownika)?

Jeśli wdrożyłeś procedurę zatwierdzania podobną do mojej odpowiedzi na „ Jakie są możliwe wdrożenia (lub przykłady) zasady czterech oczu? ”, To nie masz szczęścia… oto twoje wybory:

Twoja poprawka zostanie zablokowana (czytaj: produkcja spadnie), dopóki nie zaangażuje się jeszcze 2 oczu.
Wymyślisz sposób obejścia brakujących oczu.

Jak więc wdrożyć zasadę czterech oczu w przypadku napraw awaryjnych? ... Abyś mógł uruchomić produkcję jak najszybciej, tj. Około 3:25 rano ... I żebyś mógł także zamknąć połączenie (i wrócić do miejsca, z którego przyszedłeś)?

configuration four-eyes

— Pierre.Vriens
źródło

Skontaktowałeś się z zespołem , co oznacza, że powinni byli już pobłogosławić łatkę w odniesieniu do obowiązujących zasad zatwierdzania. Naprawdę nie znoszę tych retorycznych pytań :( tylko moja opinia, nie przejmuj się tym zbytnio

— Tensibai

@Tensibai, jak można „z góry pobłogosławić jakąś łatkę” (lub naprawić), nie wiedząc, jaka była przyczyna problemu, kiedy „skontaktowano się z Tobą”? Czy możesz być bardziej szczegółowy na temat retoryki? Niezbyt dobrze pasuje, coś jeszcze?

— Pierre.Vriens

Mam na myśli, że powiedziałeś, że mogłeś skontaktować się z drużyną o 3:20, co oznacza, że to nie tylko ty poprawiasz. Używam retoryki jako „hipotetycznego przypadku, opartego na doświadczeniu lub nie, w którym już wiesz, na którą odpowiedź czekasz”. Mniej więcej moje obawy dotyczące meta Czuję się samotny, że nie interesuje mnie to „ogólne zasady” P / A, więc prawdopodobnie się mylę. Jestem pewien, że nie odwiedzę dwa razy pytania / odpowiedzi na temat ogólnych zasad, gdybym był dziwakiem tej wersji beta.

— Tensibai

Mogę powiedzieć to samo o ogólnych pytaniach Jenkinsa, gdyby przyszły

— Tensibai

Zobowiązania nie zostaną naliczone do publicznej wersji beta, ponieważ teraz prywatnie budujemy to, co „zaangażowani” użytkownicy uważają za przykładowe pytania dla tej witryny, i myślę, że mamy sporo pracy w ciągu pozostałych 12 dni, a może po prostu muszę przejść przez 7 etapów żałoby

— Tensibai

Odpowiedzi:

W świecie SCM, z którym jestem najbardziej zaznajomiony, powyższy scenariusz zazwyczaj rozwiązuje tak zwana „ procedura listy skróconych zatwierdzeń”.

Oto jego schemat:

Określ godziny pracy, powiedzmy od 8 rano do 6 wieczorem.
Zdefiniuj pełną listę zatwierdzeń (powiedzmy) 3 poziomów zatwierdzenia (dla ról X, Y i Z).
Zdefiniuj skróconą listę zatwierdzeń (powiedzmy) tylko 1 poziom zatwierdzenia (tylko dla ról X).
Planowane zmiany zawsze wymagają wszystkich zatwierdzeń z pełnej listy zatwierdzeń.
W przypadku nieplanowanych zmian pełna lista zatwierdzeń służy również do zebrania wymaganych zatwierdzeń, pod warunkiem, że zatwierdzenia będą wydawane w określonych godzinach roboczych.
W przypadku wszelkich zatwierdzeń nieplanowanych zmian, które mają zostać wydane poza określonymi godzinami pracy:
- Tylko zatwierdzenia ze skróconej listy zatwierdzeń (takie jak rola X powyżej) są wymagane do autoryzacji zmiany. Po udzieleniu autoryzacji przez skróconą listę zatwierdzeń wdrożenie zmiany (w środowisku docelowym) zostanie faktycznie wykonane.
- Ale dodatkowe pocztowe -approvals będą później potrzebne (w rozsądnej ilości godzin / dni), czyli od wszystkich ról zawartych w pełnym wykazie zatwierdzenia (takich jak rola Y i Z powyżej), które nie są zawarte w wykazie zatwierdzenia skróconą (np. rola X powyżej). A jeśli w uzgodnionej (z góry) liczbie godzin / dni nie wszystkie wydane zostały późniejsze zatwierdzenia (np. Ponieważ poprawka działała „tym razem”, ale była tylko tymczasową poprawką), to zmiana może podlegać wycofaniu . Chociaż jest co najmniej 1 zaległa po zatwierdzeniu, zmiana jest oznaczona jako „oczekująca na zatwierdzenie po”.

Dzięki takiemu rozwiązaniu połączenie może zostać zamknięte około 3:23 rano ... ponieważ o 3:21 nie będzie już czerwonej flagi ... ggggrrreat, czas na piwo, aby świętować moją poprawkę, aby wznowić produkcję (zamiast kawy) ... i trzymamy kciuki za zaległe aprobaty pocztowe wkrótce ...

— Pierre.Vriens
źródło

W przypadku napraw awaryjnych poza godzinami pracy bardziej praktyczne jest wymaganie mniejszego wyrejestrowywania się w celu wprowadzenia zmian niż w przypadku zwykłej procedury. Zasadniczo można wdrożyć poprawkę, a następnie dokonać zatwierdzeń następczych następnego dnia roboczego. Jeśli poprawka nie zostanie zatwierdzona, można ją cofnąć i zastąpić trwałym rozwiązaniem.

W sytuacji awarii priorytetem powinno być przywrócenie usługi. Jeśli Twoja organizacja nie rozpozna tego łagodnego procesu podczas awarii, wtedy tak, jedyną opcją jest rozpoczęcie budzenia większej liczby osób do wypisania się.

— tayworm
źródło

Zgadzam się z pańską rekomendacją, która wydaje się podobna do mojej własnej rekomendacji (odpowiedź). Czy możesz pomyśleć o jakimś znanym świecie SCM i jak go tam zaimplementować? Jeśli tak, czy możesz rozwinąć tę kwestię w swojej odpowiedzi?

— Pierre.Vriens