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

13

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ć , 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ś)?

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:

8

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
3

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