7 técnicas de depuración para acelerar la resolución de problemas en producción

Brindar soporte de producción a una aplicación es uno de los aspectos más desafiantes del desarrollo de software. Los desarrolladores están asignados al equipo de mantenimiento y trabajan para corregir errores en la aplicación. Sin embargo, también están disponibles de guardia en caso de que ocurra una interrupción de la producción, en cuyo caso trabajan para que la aplicación vuelva a funcionar lo más rápido posible.

Este artículo tiene como objetivo proporcionar un conjunto de recomendaciones seleccionadas para que pueda evitar errores en la producción y encontrar problemas mucho más rápido. Manejar estas aplicaciones en producción es una tarea complicada: a menudo, no hay documentación disponible, la aplicación se ha escrito en una pila de tecnología heredada, o ambas cosas. Hay muy pocas sesiones de capacitación y es común que lo llamen para brindar soporte para una aplicación de la que sabe poco.

Muchos desarrolladores no tienen experiencia en el manejo de una aplicación en producción. Hay una variedad de problemas que ocurren en los entornos de producción que causan errores e interrupciones, lo que generalmente genera miles y, a veces, millones de dólares en pérdidas de ingresos para la empresa. Además, dado que la mayoría de los desarrolladores no están expuestos al medio ambiente, siguen cometiendo algunos errores que, a su vez, causarán esos problemas. Esta lista de consejos debería hacer que su trabajo sea menos doloroso al enseñar desde la experiencia de producción.

Sugerencia n.º 1: elimine o automatice toda la configuración necesaria para que se ejecute la aplicación.

¿Cuánta configuración se requiere para instalar el software en un servidor nuevo? En el pasado, esto a veces podía tardar tres días en completarse cada vez que había un nuevo desarrollador en el equipo. La instalación de la aplicación requeriría muchos pasos que deben realizarse manualmente. Con el tiempo, el software evoluciona a nuevas versiones que se vuelven incompatibles con esas instrucciones y, por supuesto, las instrucciones generalmente no se actualizan. De repente, está gastando mucho más tiempo del necesario simplemente para poner en marcha la aplicación.

Con el advenimiento de la creación de contenedores, se ha vuelto mucho más fácil proporcionar una forma de poner en marcha una aplicación en muy poco tiempo, sin configuración y con el beneficio adicional de que, dado que la imagen de Docker es autónoma, se ejecuta una cantidad mucho menor. riesgo de tener problemas con diferentes versiones del sistema operativo, idiomas y marcos utilizados.

Del mismo modo, simplifique la configuración del desarrollador, por lo que no llevará mucho tiempo estar en funcionamiento, incluida la configuración de IDE. Un desarrollador debería poder pasar de cero a héroe en menos de 30 minutos.

Cuando ocurre un problema de producción, a veces es posible que sus mejores expertos no estén disponibles (p. ej., por vacaciones o por enfermedad) y desea que quienquiera que envíe el problema pueda resolverlo rápidamente.

Consejo n.º 2: no caiga en la trampa de la sopa de pilas tecnológicas.

Cuantas menos tecnologías se utilicen, mejor. Por supuesto, a veces, debe usar la herramienta adecuada para el trabajo. Sin embargo, tenga cuidado de no sobrecargarse con las "herramientas adecuadas". Incluso beber agua puede provocar serios problemas de salud si lo hace demasiado. Cada nuevo lenguaje y marco agregado a la pila tecnológica debe pasar por un proceso de toma de decisiones claramente definido con una cuidadosa consideración de los impactos.

• No agregue una nueva dependencia de marco solo porque necesita una clase StringUtils .
• No agregue un idioma completamente nuevo solo porque necesita escribir un script rápido para mover archivos.

Una gran pila de dependencias puede arruinarle la vida cuando las bibliotecas se vuelven incompatibles o cuando se encuentran amenazas de seguridad en los propios marcos o en sus dependencias transitivas.

Además, recuerde, las complejidades adicionales de la pila hacen que sea un desafío encontrar y capacitar a nuevos desarrolladores para el equipo. La gente pasa a nuevos roles en otras empresas, y tienes que encontrar otros nuevos. La rotación es muy alta en los equipos de ingeniería, incluso en empresas reconocidas por tener excelentes beneficios y tratos de equilibrio entre el trabajo y la vida personal. Desea encontrar al nuevo miembro del equipo lo más rápido posible. Cada nueva tecnología agregada a la pila de tecnología aumenta el tiempo para encontrar un nuevo candidato y tiene el potencial de hacer que las nuevas contrataciones sean cada vez más costosas.

Consejo n.° 3: el registro debe guiarlo para encontrar el problema, no ahogarlo con detalles inútiles.

El registro es muy similar a los comentarios. Es necesario documentar todas las decisiones críticas que se toman además de toda la información a utilizar en sus técnicas de depuración. No es simple, pero con un poco de experiencia, es posible trazar algunos escenarios posibles de cortes de producción y luego realizar el registro necesario para resolver al menos eso. Por supuesto, el registro evoluciona junto con el código base según el tipo de problemas que se presenten. En términos generales, debe tener el 80 % de su inicio de sesión en el 20 % más importante de su código, la parte que más se usará. La información importante, por ejemplo, son los valores de los argumentos pasados ​​a un método, los tipos de tiempo de ejecución de las clases secundarias y las decisiones importantes tomadas por el software, es decir, el momento en que se encontraba en una encrucijada y eligió la izquierda o la derecha.

Consejo #4: Maneje situaciones inesperadas.

Traza muy claramente cuáles son los supuestos del código. Si una determinada variable siempre debe contener los valores 2, 5 o 7, asegúrese de que sea de tipo enumeración, no int. La fuente número uno de grandes cortes de producción es cuando falla cierta suposición. Todos buscan el problema en el lugar equivocado porque dan algunas cosas por sentadas.

Las suposiciones deben documentarse explícitamente, y cualquier falla en esas suposiciones debe generar suficientes alarmas para que el equipo de soporte de producción pueda rectificar la situación rápidamente. También debe haber un código para evitar que los datos entren en un estado no válido, o al menos crear algún tipo de alerta en ese caso. Si se debe almacenar cierta información en un registro, y de repente hay dos registros, se debe disparar una advertencia.

Sugerencia n.º 5: Debería ser sencillo replicar un problema que le sucede a un cliente.

Uno de los pasos más difíciles es siempre replicar el problema que enfrenta el cliente. Muchas veces, pasará el 95 % del tiempo tratando de replicar el problema y luego, en el momento en que pueda replicarlo, es cuestión de minutos parchear, probar e implementar. Como tal, el arquitecto de la aplicación debe asegurarse de que sea tremendamente simple y rápido replicar problemas. Mucho de esto sucede porque, para llegar a la misma situación en la que se encuentra el cliente, el desarrollador tiene que realizar una gran cantidad de configuración de la aplicación. Hay muchos registros almacenados que juntos componen la situación en la que se encuentra el cliente; el problema es que usted, como desarrollador, tiene que adivinar exactamente lo que hizo el cliente. Y en ocasiones, han realizado una secuencia de pasos, de los cuales solo recuerdan el último.

Además, el cliente explicará el problema en términos comerciales, que luego el desarrollador debe traducir a términos técnicos. Y si el desarrollador tiene menos experiencia con la aplicación, no sabrá pedir los detalles que faltan, ya que ni siquiera sabe los detalles que faltan todavía. Copiar toda la base de datos de producción a su máquina es inviable. Por lo tanto, debería haber una herramienta para importar rápidamente desde la base de datos de producción solo los pocos registros necesarios para simular la situación.

Digamos que el cliente tiene un problema con la pantalla Pedidos. Es posible que deba importar algunos de sus pedidos, su registro de clientes, algunos registros de detalles de pedidos, registros de configuración de pedidos, etc. Luego, puede exportarlos a una base de datos dentro de una instancia de Docker, iniciar esa instancia y, así, está viendo lo mismo que el cliente está viendo. Todo esto, por supuesto, debe hacerse con el cuidado adecuado para garantizar que ningún desarrollador tenga acceso a datos confidenciales.

Consejo #6: Debería ser obvio dónde colocar los puntos de interrupción en la aplicación.

Si tiene una pantalla de Cliente, debe haber algún objeto de Cliente donde pueda colocar los puntos de interrupción para depurar un problema en esa pantalla. A veces, los desarrolladores caen en la fiebre de la abstracción y presentan algunos conceptos increíblemente inteligentes sobre cómo manejar los eventos de la interfaz de usuario. En cambio, siempre debemos confiar en el principio KISS (Keep it Simple, St— er, Silly) y tener un método fácilmente localizable por evento de interfaz de usuario. Del mismo modo, para trabajos de procesamiento por lotes y tareas programadas, debería haber una manera fácil de detectar dónde se encuentran los puntos de interrupción para evaluar si ese código funciona o no.

Sugerencia n.º 7: asegúrese de que todas las dependencias externas estén explícitamente documentadas.

Idealmente, haga esto en el archivo README dentro del sistema de control de fuente para que la documentación no se pierda. Documente cualquier sistema externo, base de datos o recursos que deban estar disponibles para que la aplicación funcione correctamente. Además, tenga en cuenta cuáles de estos son opcionales y agregue instrucciones sobre cómo manejarlos cuando sean opcionales y no estén disponibles.

Más allá de las técnicas de depuración

Una vez que se sigan estas recomendaciones mientras se crean nuevas funciones o se brinda mantenimiento a un sistema, el soporte de producción será mucho más fácil y su empresa gastará mucho menos tiempo (y dinero). Como ya sabe, el tiempo es esencial al solucionar errores y bloqueos de producción: cualquier minuto que se pueda ahorrar marca una gran diferencia en el resultado final. ¡Feliz codificación!