Как реализовать принцип четырех глаз для экстренного исправления?

Рассмотрим этот сценарий (любое сравнение с реальными ситуациями чисто случайно):

3:07 : входящий звонок в службу поддержки " Что-то в производстве вышло из строя, мне нужна ваша помощь! "
3:12 : подключен к системе (вход в систему принят) ... и нет времени на кофе.
3:15 утра : повезло, вы сразу можете обнаружить проблему с помощью какого-нибудь сообщения об ошибке.
3:17 : используйте набор инструментов SCM, чтобы получить код, исправить проблему, протестировать ее, отлично ... мое исправление работает!
3:20 : свяжитесь с командой ~~Dev~~ Ops, чтобы отправить исправление и снова запустить производство.
3:21 : красный флаг ... « Чтобы уважать четыре глаза , нам нужно еще 2 глаза, чтобы получить разрешение на это исправление ».
3:22 : ggggrrrreat, что теперь, кого еще мы можем назвать (= разбудить какого-нибудь менеджера)?

Если вы применили какую-то процедуру одобрения, аналогичную моему ответу на вопрос « Каковы возможные реализации (или примеры) принципа четырех глаз? », То вам не повезло ... вот ваш выбор:

Ваше исправление будет зависать (читай: производство будет остановлено), пока не будут задействованы еще 2 глаза.
Вы нашли способ обойти пропавшие глаза.

Итак, как реализовать принцип четырех глаз для аварийных исправлений? ... Чтобы вы могли начать производство как можно скорее, то есть около 3:25 утра ... И чтобы вы могли также закрыть вызов (и вернуться туда, откуда пришли)?

configuration four-eyes

— Pierre.Vriens
источник

Вы связались с командой , что означает, что они уже должны были благословить патч в отношении действующих принципов апробации. Я действительно начинаю ненавидеть эти риторические вопросы :( только мое мнение, не беспокойтесь об этом слишком много

— Tensibai

@ Тенсибай, как можно «благословить какой-то патч» (или исправить) заранее, не зная, в чем причина проблемы, когда «с тобой связались»? Кроме того, вы можете быть более конкретным в отношении риторических? Не подходит, что-то еще?

— Pierre.Vriens

Я имею в виду, что вы говорите, что смогли связаться с командой в 3:20, а это значит, что вы не только исправляете ситуацию. Я использую риторику как «гипотетический случай, основанный на опыте или нет, когда вы уже знаете, какой ответ вы ждете». Более или менее мои опасения по поводу мета Я чувствую себя одиноким, не заинтересованным в этих «общих принципах», поэтому я, вероятно, ошибаюсь. В чем я уверен, так это в том, что я не буду дважды посещать вопросы и ответы по общим принципам, если я был аутландером этой бета-версии.

— Тенсибай

Я могу сказать то же самое о типичных вопросах Дженкинса, если они будут приходить сейчас

— Тенсибай

Обязательства не будут вычисляться до публичной бета-версии, пока в частном порядке мы создаем то, что, по нашему мнению, «преданные» пользователи считают образцовой проблемой для этого сайта, и я думаю, что у нас есть куча работы в оставшиеся 12 дней, или я могу просто должны пройти 7 этапов горя

— Тенсибай

Ответы:

В мире SCM, с которым я в основном знаком, описанный выше сценарий, как правило, рассматривается с помощью процедуры, называемой « список сокращенных утверждений».

Вот план этого:

Определите свое рабочее время, скажем, с 8 утра до 6 вечера.
Определите полный список утверждений (скажем, 3 уровня утверждения) (для ролей X, Y и Z).
Определите сокращенный список утверждений (скажем) только 1 уровня утверждения (только для ролей X).
Запланированные изменения всегда требуют всех утверждений из полного списка утверждений.
Для внеплановых изменений полный список утверждений также используется для сбора необходимых утверждений при условии, что утверждения должны быть выданы в течение определенных рабочих часов.
Для любых одобрений незапланированных изменений , которые должны быть выпущены вне установленных рабочих часов:
- Для подтверждения изменения требуются только утверждения из сокращенного списка утверждений (например, роль X выше). И после того, как будет дана авторизация по сокращенному списку утверждений, развертывание изменения (в целевой среде) будет фактически выполнено.
- Но впоследствии потребуются дополнительные пост- утверждения (в течение разумного количества часов / дней), то есть от всех ролей, содержащихся в полном списке одобрения (например, роли Y и Z выше), которые также не содержатся в сокращенном списке одобрения (например, роль X выше). И если в течение (заранее оговоренного) согласованного количества часов / дней были выпущены не все пост-утверждения (например, потому что исправление работало «в этот раз», но было похоже на временное исправление), тогда изменение может быть подвергнуто откату , Несмотря на то, что имеется не менее 1 непогашенного пост-одобрения, изменение помечается как «ожидающие пост-одобрения».

При таком решении вызов может быть закрыт около 3:23 утра ... так как в 3:21 утра больше не будет красного флага ... ggggrrreat, время для пива, чтобы отпраздновать мое исправление, чтобы возобновить производство (вместо кофе) ... и скрестив пальцы, выдающиеся одобрения поста скоро придут ...

— Pierre.Vriens
источник

В случае нештатных срочных исправлений более практично требовать меньшего количества подписей для изменений, чем ваша обычная процедура. Как правило, вы можете развернуть исправление и затем выполнить последующее утверждение на следующий рабочий день. Если исправление не утверждено, его можно отменить и заменить постоянным решением.

Во время сбоя приоритетом номер один должно быть восстановление сервиса. Если ваша организация не распознает этот непринужденный процесс во время простоя, тогда да, ваш единственный вариант - начать разбудить больше людей, чтобы подписаться.

— tayworm
источник

Я согласен с вашей рекомендацией, которая, похоже, похожа на мою собственную рекомендацию (ответ). Можете ли вы вспомнить какой-нибудь пример в мире SCM, с которым вы знакомы, и КАК вы бы реализовали его там? Если да, можете ли вы рассказать об этом в своем ответе?

— Pierre.Vriens