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

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 ...

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ę.