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

13

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

  • 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 этапов горя
Тенсибай

Ответы:

8

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

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

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

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

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

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

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

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