¿Cómo implementar el principio de cuatro ojos para reparaciones de emergencia?

Considere este escenario (cualquier comparación con situaciones del mundo real es puramente por accidente):

• 3:07 am : llamada de soporte entrante " Algo en producción cayó, ¡necesito tu ayuda! ".
• 3:12 am : conectado al sistema (inicio de sesión aceptado) ... y no hay tiempo para el café.
• 3:15 am : por suerte, de inmediato podrías detectar el problema a través de algún mensaje de error en alguna parte.
• 3:17 am : use su caja de herramientas SCM para obtener el código, solucionar el problema, probarlo, genial ... ¡mi solución funciona!
• 3:20 am : póngase en contacto con el equipo Dev Ops para enviar la solución y volver a poner en marcha la producción.
• 3:21 am : bandera roja ... " Para respetar los cuatro ojos , necesitamos 2 ojos más para obtener la aprobación de esta solución ".
• 3:22 am : ggggrrrreat, ahora qué, ¿a quién más podemos llamar (= despertar a algún gerente)?

Si implementó algún procedimiento de aprobación similar a mi respuesta a " ¿Cuáles son las posibles implementaciones (o ejemplos) del principio de los cuatro ojos? ", Entonces no tiene suerte ... estas son sus opciones:

• Su solución se bloqueará (léase: la producción se reducirá) hasta que se involucren 2 ojos más.
• Encuentra una manera de evitar los ojos perdidos

Entonces, ¿cómo implementar el principio de cuatro ojos para soluciones de emergencia? ... ¿Para que la producción esté en funcionamiento lo antes posible, es decir, alrededor de las 3:25 am ... Y para que también pueda cerrar la llamada (y volver al lugar de donde vino)?

En el mundo SCM en el que estoy más familiarizado, el escenario anterior generalmente se aborda mediante lo que se denomina el " procedimiento de lista de aprobación abreviada " .

Aquí hay un plano de ello:

• Defina su horario comercial, digamos de 8 am a 6 pm.
• Defina una lista completa de aprobación de (digamos) 3 niveles de aprobación (para los roles X, Y y Z).
• Defina una lista abreviada de aprobación de (digamos) solo 1 nivel de aprobación (solo para roles X).
• Los cambios planificados siempre requieren todas las aprobaciones de la lista de aprobación completa.
• Para los cambios no planificados , la lista de aprobación completa se usa también para recopilar las aprobaciones requeridas, siempre que las aprobaciones se emitan durante el horario comercial definido.
• Para cualquier aprobación de cambios no planificados que se emitirán fuera del horario comercial definido:
  • Solo se requieren las aprobaciones de la lista de aprobación abreviada (como el rol X anterior) para autorizar el cambio. Y después de que se otorgue la autorización por la lista de aprobación abreviada, la implementación del cambio (en el entorno de destino) se realizará realmente.
  • Pero adicionales enviar serán necesarios -approvals después (dentro de una cantidad razonable de horas / día), es decir, de todas las funciones contenidas en la lista de aprobación completa (tal como papel Y y Z anteriormente), que no están también contenida en la lista de aprobación abreviado (como el rol X anterior). Y si dentro de la cantidad de horas / días acordada (por adelantado) no se han emitido todas las aprobaciones posteriores (por ejemplo, porque el arreglo funcionó "esta vez", pero fue solo como un arreglo temporal), entonces el cambio podría estar sujeto a una reversión . Si bien hay al menos 1 aprobación posterior pendiente, el cambio se marca como "aprobaciones posteriores en espera".

Con tal solución, la llamada puede cerrarse alrededor de las 3:23 am ... ya que no habrá más bandera roja a las 3:21 am ... ggggrrreat, hora de que una cerveza celebre mi arreglo para que la producción vuelva a funcionar (en lugar de café) ... y los dedos cruzan las aprobaciones de correos pendientes vendrán pronto ...

En el caso de arreglos de emergencia fuera del horario de atención, es más práctico requerir menos cierre de sesión para los cambios que su procedimiento normal. En general, puede implementar una solución y luego realizar aprobaciones posteriores al siguiente día hábil. Si la solución no se aprueba, se puede revertir y reemplazar con una solución permanente.

Durante una situación de interrupción, la prioridad número uno debe ser restaurar el servicio. Si su organización no reconoce este proceso relajado durante una interrupción, entonces sí, su única opción es comenzar a despertar a más personas para que cierren la sesión.