Як реалізувати принцип чотирьох очей для виправлення аварійних ситуацій?

Розглянемо цей сценарій (будь-яке порівняння з ситуаціями в реальному світі - випадково):

• 3:07 ранку : вхідний дзвінок підтримки " Щось у виробництві знизилося, мені потрібна ваша допомога! ".
• 03:12 : підключено до системи (вхід прийнято) ... і часу на каву немає.
• 3:15 ранку : пощастило, одразу ви могли десь помітити проблему через якесь повідомлення про помилку.
• 3:17 ранку : використовуйте свою панель інструментів SCM, щоб схопити код, виправити проблему, протестувати її, чудово ... моє виправлення працює!
• 3:20 ранку : зв’яжіться з командою Dev Ops, щоб відправити виправлення та знову запустити виробництво.
• 3:21 ранку : червоний прапор ... " Для поваги до чотирьох очей нам потрібні ще 2 очі, щоб отримати схвалення для цього виправлення ".
• 3:22 ранку : ggggrrrreat, тепер що, кого ще ми можемо зателефонувати (= розбудити якогось менеджера)?

Якщо ви застосували якусь процедуру затвердження, подібну моїй відповіді до " Які можливі реалізації (або приклади) принципу з чотирма очима? ", То вам не пощастило ... ось ваш вибір:

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

Тож як реалізувати принцип чотирьох очей для аварійних виправлень? ... Щоб ви почали виробництво і працювали якнайшвидше, тобто близько 3:25 ранку ... І щоб ви також могли закрити дзвінок (і повернутися туди, звідки ви прийшли)?

У світі SCM, де я здебільшого знайомий, описаний вище сценарій, як правило, називається " процедурою списку скороченого затвердження" .

Ось його креслення:

• Визначте свій робочий час, скажімо, з 8 ранку до 18 вечора.
• Визначте повний перелік схвалень (скажімо) 3 рівня затвердження (для ролей X, Y і Z).
• Визначте скорочений список затвердження (скажімо) лише 1 рівня схвалення (лише для ролей X).
• Планові зміни завжди потребують усіх схвалень із повного списку затверджень.
• Для незапланованих змін повний список затвердження використовується також для збору необхідних схвалень, за умови, що затвердження повинні бути видані протягом визначених робочих годин.
• Для будь-яких схвалень незапланованих змін, які мають бути видані поза визначеним робочим часом:
  • Для затвердження змін потрібні лише схвалення зі скороченого списку схвалення (наприклад, роль X вище). А після надання авторизації за скороченим списком затвердження фактично буде здійснено розгортання зміни (у цільовому середовищі).
  • Але додаткові поштові -approvals будуть необхідні згодом ( в межах розумного кількості годин / днів), тобто від всіх ролей , що містяться в повному списку затвердження (наприклад, роль Y і Z вище), які не містяться також в скороченому списку затвердження (наприклад, роль X вище). І якщо в межах (наперед) узгодженої кількості годин / днів не було видано всіх після затвердження (наприклад, тому, що виправлення спрацювало "цей" час, але було лише як тимчасове виправлення), то ці зміни можуть бути предметом відкоту . Хоча існує щонайменше 1 непогашений пост-затвердження, зміна позначається як "затвердження на пост очікування".

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

У разі виправлення аварійних ситуацій у позаробочий час практичніше вимагати менше входу для змін, ніж ваша звичайна процедура. Як правило, ви можете розгорнути виправлення, а потім зробити наступне затвердження наступного робочого дня. Якщо виправлення не затверджено, його можна повернути та замінити постійним рішенням.

Під час аварійних ситуацій пріоритетом номер один має бути відновлення послуги. Якщо ваша організація не визнає цей спокійний процес під час відключення, то так, ваш єдиний варіант - почати пробуджувати більше людей для виходу.