Independientemente de la experiencia que tengamos como programadores, todos hemos cometido errores que se despliegan en producción. Ya sea algo pequeño, como un enlace roto, o algo más serio que resulta en grandes costos financieros, es imposible mantener un historial perfecto en este aspecto. Si eres un desarrollador nuevo con síndrome del impostor sufriendo de culpa después de iniciar un fuego programático, solo recuerda que los desarrolladores senior y los expertos en el tema ayudándote a apagar ese fuego son buenos en hacerlo en parte porque ellos también han iniciado algunos propios.

He estado en ingeniería de software durante aproximadamente siete años y he desplegado mi parte justa de versiones que rompen la aplicación, y en el proceso he aprendido algunas lecciones importantes para (a) prevenir que ocurran, (b) gestionarlas cuando suceden y (c) lidiar con las consecuencias una vez que han sido arregladas.

1. Liberar incrementos más pequeños de código con más frecuencia

Una de las razones por las que prefiero un enfoque Agile para el desarrollo de software es que los entregables más pequeños tienen menos probabilidades de contener errores. Si tenemos que lanzar una característica grande y completa con un plazo de dos meses, la probabilidad de que ese código tenga al menos un error es bastante alta.

Por otro lado, liberar un Producto Mínimo Viable (MVP) en un período de tiempo más corto y construir sobre él en iteraciones posteriores no solo nos somete a múltiples controles de calidad de código, sino que también nos permite enfocarnos en piezas más pequeñas de código. Es más fácil detectar un error cuando no está oculto entre un conjunto colosal de cambios de código.

2. Mantener la calma al solucionar un problema de producción

No es divertido ver errores de producción en los registros, o peor aún, que un cliente nos notifique que su aplicación de repente no funciona. Pero es extremadamente importante mantener la calma si y cuando esto suceda, y trabajar con nuestros colegas para solucionar el problema.

Expresar miedo y frustración puede dañar la moral. Maldiciendo el estado de las cosas no aumentará la productividad. En su lugar, es mejor mantenernos enfocados, considerar las variables que podrían haber causado el problema, y buscar diferentes formas de abordar el problema (por ejemplo, revertir, implementar un parche, reiniciar un clúster Kubernetes fallido, etc.). Debemos usar los recursos que tengamos a mano, lo que me lleva a mi próximo punto…

3. No tener miedo de pedir ayuda

Como ingenieros de software, tenemos la tendencia de querer resolver problemas nosotros mismos. Los desafíos son divertidos, y hay pocas cosas más satisfactorias que finalmente resolver un rompecabezas difícil. El problema es que, si bien este enfoque es aceptable, quizás incluso beneficioso, en proyectos personales, no funcionará cuando el Acuerdo de Nivel de Servicio de una empresa garantice un tiempo de actividad del 99.99% y su aplicación no esté funcionando. Ahora es el momento de dejar de lado nuestro ego y contactar a cualquier experto en el tema que pueda ofrecernos asistencia.

4. Aceptar responsabilidad (pero no exagerar)

Construir confianza es fundamental para mantener la fortaleza de un equipo, y parte de esa confianza proviene de la propiedad activa. Mientras esto se aplica a todos los ingenieros en un equipo, se aplica especialmente a los ingenieros senior y líderes técnicos, quienes deben dar ejemplo a los demás.

Identificar otros factores contribuyentes y hacer planes para abordarlos. La realidad es que ninguna persona es completamente responsable de un error de producción. Asegurarse de mejorar el sistema en general dificulta que un solo ingeniero pueda introducir un error.

5. Mantener una buena documentación

Es importante para el equipo mantener buenas notas a lo largo del proceso. Mantener una línea de tiempo actualizada de los eventos desde que se detecta el problema en producción, y sostener una reunión posterior sin culpabilizaciones para discutir qué salió mal, cómo se resolvió y las acciones a tomar para prevenir que vuelva a ocurrir, es vital.

No hay vergüenza en admitir que hemos enviado un error a producción: cada ingeniero lo ha hecho. Lo importante es conocer formas de evitarlo, lidiar con el problema mientras está ocurriendo y reducir la probabilidad de que vuelva a suceder. Reconocer esto es el primer paso para desplegar de manera segura.

Source: Medium