Comprender el problema cuando las cosas se rompen en la producción

Guión:

• Empujas a la producción
• El empujón rompió múltiples cosas
• Esa misma compilación no rompió qa o dev
• Como desarrollador, no tienes acceso a productos.
• Hay mucha presión desde arriba para que las cosas funcionen nuevamente.

Detalles específicos:

• Aplicación PHP / MVC que funciona con API en Zend.
• Implementado en unos pocos servidores.

Mi pregunta:

Mientras investigamos, digamos que tengo el presentimiento de que algo está mal. Pero no estoy seguro. Y, por supuesto, no puedo probar cosas en producción. Si tengo una solución sugerida basada en esa corazonada, ¿sería prudente intentar aplicarla y ver si funciona, antes de entender cuál es el problema?

Obtenga tanta información sobre el problema como pueda (archivos de registro, etc.) y luego revierta los servidores de producción a un estado de funcionamiento. Eso es un dolor desde el punto de vista del desarrollador, por supuesto, pero lo más probable es que sea un hecho.

A continuación, intente ver si puede reproducir el problema en un entorno de desarrollo. Si puedes, arréglalo e intenta liberarlo nuevamente.

Si no puede reproducirlo, vea si puede agregar más diagnósticos y liberarlo en un servidor por un corto tiempo para obtener más información sobre el problema.

Si eso no es posible, observe más de cerca las diferencias entre la producción y los entornos de desarrollo / qa e intente acercar un entorno de desarrollo a la producción.

¿ Qué tan bien entiendes el problema? ¿Cuál es el riesgo de que tu corazonada empeore las cosas? ¿Es posible regresar y reproducir el problema en las regiones DEV / QA? ¿Qué puede hacer para sincronizar su región DEV / QA para acercarla a PROD? Tal vez tenga que cambiar algunas configuraciones ambientales o de la base de datos, tal vez tenga que importar los datos PROD a DEV, tal vez tenga que cambiar alguna configuración de depuración.

En general, no recomendaría empujar su presentimiento de una solución a PROD a menos que pueda confirmar que es correcta en otra región. Entiendo el tipo de problemas que surgen cuando ocurre un error en PROD y no se puede reproducir en ningún otro lugar. Es entonces cuando se trata de ver qué más difiere entre DEV / QA y PROD y enfocarse en eso. En mi experiencia, generalmente es una configuración ambiental o alguna configuración diferente, específicamente para PROD. Y sé que probablemente haya mucha presión desde arriba para solucionar esto, por lo que es posible volver al estado de trabajo anterior y luego intentar reproducir el problema en DEV, encontrar una solución en DEV y luego intentar de nuevo en PROD? Eso es lo que sugeriría.

Depende del tipo de solución. La mayoría de las veces, los problemas en la producción que no aparecen en el desarrollo están relacionados con contender en la base de datos. Por lo tanto, la aplicación de un error que cambia el contenido de la base de datos sin estar seguro de qué es exactamente "lo que hay" puede ser el primer paso en un gran desastre. Si puede recuperar el cambio fácilmente, puede intentarlo. Pero, en general, si no tiene acceso directo, al menos debería haber una copia de la base de datos o de todo el servidor para las pruebas. Las personas con los privilegios correctos aún tendrían que ejecutar el nuevo código, pero al menos sin riesgo de pérdida de datos. (Pero a veces el tamaño de la base de datos o la complejidad de la infraestructura prohíbe dicha configuración)

Es realmente difícil, ya que hay muchas posibilidades, como diferentes configuraciones, bibliotecas y versiones de software.

Tal vez pueda escribir primero un fragmento de código que evalúe con algún resultado de depuración si su suposición de la fuente del error fue correcta y solo luego aplique la corrección de error real.

Por lo general, se trata de problemas de configuración o de datos, suponiendo que el código y la base de datos son idénticos entre Prod, QA y dev.

Primero miraría lo siguiente:

• Cualquier dato de registro que tenga su código.
• Verifique el visor de eventos para ver las excepciones no controladas.
• Verifique los datos que representan el progreso de su aplicación, puede estar en la base de datos, archivos, etc. ¿Tiene sentido o no? Es lo que esperas

Una vez que comprenda lo que está sucediendo, debe revertir la producción a un estado de trabajo y trabajar para solucionar el problema en un entorno inferior, hasta que se arregle y se vuelva a implementar en la producción.

Si bien su entorno es PHP, he realizado una presentación sobre cómo pensarlo para Java: http://www.infoq.com/presentations/maintaining-production-java-apps

Los problemas centrales son los mismos: comprender los posibles puntos críticos para solucionar la situación: red, acceso al sistema de archivos, archivos de registro, puntos muertos, etc. Además, saber cómo hacer las preguntas correctas: "Sistema inactivo" - "¿Qué hace usted específicamente? significa: ¿la página web es lenta, hay un mensaje de error específico, hay tiempo de espera ", etc.

Además, hay algunas herramientas para facilitar la solución de problemas: Wireshark para la solución de problemas de red es absolutamente mejor y vale la pena aprenderlo. Otros dependen de la O / S que use. Para Windows, cualquier cosa de SysInternal (ahora parte de Microsoft) es brillante. Para Unix / Linux, mira truss / strace.

En cuanto al acceso a la producción, el grupo de operaciones debe saber cómo usar esas herramientas / técnicas o usted tiene un caso de negocios (junto con usted) para aprender cómo usarlas. Después de eso, necesitan un conjunto específico de protocolos de solución de problemas para ejecutarse cuando ocurre el problema, por lo que puede hacer su análisis fuera de línea.

Respuesta corta: no si tienes otra opción.

Respuesta larga: si no comprende el problema, existen varios riesgos involucrados en dicho parche:

1. Podría romper algo más, que incluso podría ser menos reproducible.
2. Podrías enmascarar el problema, haciendo que sea más difícil notarlo y reproducirlo (lo que lo empeora)
3. Está desperdiciando la experiencia doméstica potencial: experiencia que podría convertirlo en un mejor programador y, al mismo tiempo, más valioso para su empresa (es decir, un posible aumento futuro).

Por otro lado, no veo ningún daño en verificar primero si su solución hipotética funciona, y si funciona, entonces profundice y descubra la razón real u otras formas posiblemente mejores de resolver el problema.