8 tips para resolver bugs y problemas en producción estando de viaje

A todos nos gusta viajar pero no por eso debemos desatender los sistemas que desarrollamos y mantenemos. Así que es necesario estar siempre alerta para poder resolver cualquier problema en producción que pueda llegar a surgir, estemos donde estemos.

En este artículo te voy a contar algunos tips sobre cómo resolver bugs y todo tipo de problemas de producción cuando uno está de viaje. Todos estos surgen de mi experiencia y quizás, con el tiempo, vaya agregando nuevos.

Este artículo está destinado a programadores web que trabajan como freelancers, aunque quizás pueda aplicarse también a otros tipos de programadores, administradores de sistemas y diseñadores.

No tomo en cuenta los casos en que uno se va de vacaciones y le deja el mantenimiento de un sistema a un colega, porque me parece una situación extraña. En general, cada programador es amo y señor (o ama y señora) del sistema que desarrolla y administra y nadie más toca una línea de código allí.

Antes de continuar, quiero poner énfasis en lo necesario que es evitar clientes que tengan sistemas que requieran mantenimiento. Sin embargo, sé que es complicado e incluso yo mismo tengo algunos aún.

Siempre te voy a recomendar que apuntes a generarte una estructura de ingresos pasivos a través de un sitio web, una app, un libro, cursos online, o cualquier canal de venta que puedas generar. Si no sabés de qué te estoy hablando, te recomiendo el artículo: ¿Qué son los ingresos pasivos y por qué deberías generarlos?

Antes de comenzar con los tips para resolver problemas en producción mientras se viaja, vamos a ver un ítem que lo considero super importante, incluso más que los propios tips.

Más vale prevenir que curar

Resolver problemas en producción es algo que vas a intentar evitar a toda costa. La idea es que no haya nunca un problema allí. Sin embargo, no se puede controlar todo y, como humanos, somos falibles.

Si bien no podemos evitar que ocurran problemas, tomando los recaudos necesarios, es posible disminuir la probabilidad de que estos sucedan.

¿Cómo? Realizando backups periódicos, creando procesos de desarrollo y despliegue, contratando servicios de hosting de calidad, utilizando planes de datos que no te dejen desconectado del mundo y trabajando de forma profesional.

A esto le podemos agregar recaudos simples como llevar la laptop encima y cargada adonde vayamos y disponer de power banks o baterías adicionales. También tener auriculares para el caso en que sea necesario realizar una llamada o videollamada.

Lo más importante de todo es lo que yo llamo programar a conciencia. ¿Qué quiero decir con esto? Resolver los problemas con buenas prácticas de programación, con la máxima concentración posible, pensando siempre los casos más genéricos aunque eso requiera más tiempo y sea más difícil, y dando todo de uno.

Ahora sí, pasemos a los tips.

1. Manener la calma

El reporte de un bug se suele componer, por un lado, de información y, por el otro, de presión. Hay un problema que hay que resolver y esto tiene que ocurrir en el corto plazo. Cada minuto que pasa es un problema, como una astilla (o una espada en el peor de los casos) clavada en el pie (o en el corazón) de tu cliente.

Toda esta presión, que a veces puede venir acompañada de algún improperio, hace que puedas perder la calma. Pero no, es vital mantenerla.

Y acá quiero ser claro. Mantener la calma no es porque te va a hacer mal a tu salud o por un tema de filosofía mental en el que los pensamientos negativos deben ser evitados. Nada de eso.

El problema es que si perdés la calma, vas a tratar de resolver todo rápido y sin control alguno. Y eso lo único que logra es que el problema se convierta en un gran problema.

Por lo tanto, a la hora de encarar un bug o algún tipo de problema en producción, hay que mantener la serenidad. Frialdad absoluta como un robot (o un vulcano).

2. Buscar un lugar cómodo

El problema cuando cae un problema estando de viaje es que quizás te encuentres buceando, en una telesilla yendo a la cima de una montaña, sacando fotos en una antigua iglesia o surfeando las olas.

Ninguno de esos lugares es adecuado para resolver nada. Por lo tanto, el problema deberá esperar a que encuentres un lugar donde puedas trabajar con comodidad.

Sí, lo sé. Ante la llegada del problema, estarás tentado a sentarte en un banco de una plaza a intentar resolverlo. Pero no. Lo mejor es que puedas ir a un lugar donde haya mínimo una silla y una mesa.

El lugar ideal es un café, por supuesto. Lo que hay que intentar procurar es que tenga buena conexión de Wi-Fi. Bueno, al menos que tenga conexión Wi-Fi. Esto puede parecer raro, pero todavía hoy en día hay cafés que no ofrecen este servicio y en algunos lugares del mundo aún están lejos de incorporarlos.

Ante la duda, lo mejor es activar el GPS y buscar el Starbucks más cercano. En la famosa cadena de cafeterías encontrarás Wi-Fi, mesa y silla por una consumición mínima.

Antes de comprar, asegurate que haya espacio para sentarte y que sea un lugar cómodo que te asegure una mesa. Nada de sofás con mesitas ratonas. Bueno, si te parecen cómodos, sí.

Hay que recordar que si te vas a conectar a una red pública es mejor hacerlo a través de una VPN. En este caso en el que seguramente te tengas que conectar a algún servicio de hosting o realizar una conexión con una base de datos, cobra mayor importancia.

3. Tomarse todo el tiempo necesario

La presión por resolver el problema y entregar la solución no se va en ningún momento. Sin embargo, no tenés por qué apurarte.

Yo suelo desplegar todo lo que necesito en la mesa. La laptop, el smartphone, mi libreta de apuntes, bolígrafo y todo aquello que considere fundamental. Convierto el pequeño espacio en el que me encuentro en mi workstation.

Me tomo el tiempo incluso para cargar el ticket correspondiente al bug en el tracker que uso, que generalmente es Taiga. Si no conocés este gestor de proyectos ágiles, te dejo mi artículo: Mi experiencia con Taiga.

Además de generar el ticket, suelo consultar la base de incidencias para ver si ya resolví un problema parecido o si hay alguna información adicional que me pueda hacer comprender mejor el problema.

Te puede llegar a ocurrir que en cuanto comiences a mirar el código o a ver el error, creerás saber cuál es el problema. En la mayoría de los casos así será. Sin embargo, hay que tener cuidado en sacar conclusiones apresuradas.

Te recomiendo que revises una o dos veces si tu primera impresión fue correcta. Y para eso, tomate todo el tiempo del mundo.

4. Backups de todo antes de realizar cualquier acción

Por precaución es buena idea realizar backups antes de realizar cualquier cambio en el código. Esta copia de respaldo es recomendable hacerla tanto para los mismos archivos de código como para la base de datos.

No importa que haya backups periódicos (que los tiene que haber). Seguramente si hay un respaldo de este tipo, se realizó hace horas. Por lo tanto, lo más seguro es disponer de un backup del momento previo a la intervención que se está por realizar.

En el caso del código, si se trata de un ajuste puntual, recomiendo copiar los archivos que serán afectados. El conjunto del código debería estar asegurado a través de alguna herramienta como integración continua o de despliegues automáticos, sincronizada con el repositorio. De esto te comento más adelante.

5. Realizar pruebas en los ambientes de test

Si bien realizar el testing en local y en stage es algo que hay que hacer siempre, todos sabemos en el fondo que hay problemas muy sencillos que uno los puede mandar a producción directamente.

Obviamente que la solución tiene que pasar todas las pruebas automatizadas, si es que las hay.

En este caso te recomiendo que aunque este sea una de esas veces en la que el problema es fácil de resolver, igualmente primero despliegues la solución en el ambiente de prueba más parecido que tengas a producción.

Sólo por las dudas y para eliminar cualquier tipo de aspecto que no estés considerando. Si funciona bien en ese ambiente de prueba, entonces tiene que funcionar bien en producción.

La idea es hacer un único despliegue que resuelva el bug y no tener que realizar luego varios despliegues a modo de parche debido a que el primero no cubrió del todo el problema.

6. Usar integración continua o herramientas de despliegue automatizado

Insisto con este punto porque a mí me cambió la forma de realizar las implementaciones.

Realizar despliegues automáticos te garantiza que se suban los archivos que se tienen que subir y que no se toque más nada. El sistema se sincroniza con el repositorio, que puede estar en BitBucket, Github o en cualquier otro servicio.

El despliegue es tan simple como presionar un botón y se envía la versión del software que desees. Por lo tanto, en caso de error, podrías volver a la versión anterior también con un solo click.

Yo uso Jenkins, que tiene una configuración tal vez un poco avanzada. Pero no tenés por qué usar este mismo software. Hoy en día hay servicios en la nube que se encargan de realizar despliegues mediante herramientas de integración continua.

Los días de subir por FTP quedaron en el pasado. Hay que aprovechar las herramientas más modernas aunque al principio parezcan un poco intimidantes.

7. Esperar confirmación

Una vez realizado el despliegue y enviado el mensaje correspondiente al cliente, hay que esperar que este confirme que ha visto resuelto el problema. Esto suele llevar algunos minutos extra donde no queda otra que esperar.

Hay que pensar que el cliente quizás no usa esa funcionalidad que da error durante todo el tiempo. Tal vez solamente en algunos momentos específicos, como cuando tiene que realizar una operación en particular.

Es bueno aclararle que necesitamos una confirmación. A veces esto no queda del todo claro y el cliente sigue trabajando normalmente mientras estás esperando que te diga si ya lo pudo comprobar o no. Por eso mismo hay que ser claro en este aspecto al enviar el mensaje de resolución.

Una vez que el cliente confirma ya podemos apagar todo y seguir disfru… ¡No! Hay un último tip que te recomiendo.

8. Esperar 20 minutos más luego de la confirmación

No sé por qué, pero algo que suele ocurrir es que luego de unos minutos de la confirmación, algo más ocurre. A veces es simplemente un mensaje o un llamado donde se hace una re-confirmación de que todo funciona bien. Pero otras veces es el renacer del bug y otras, la generación de otro bug asociado, producto de lo que se modificó.

Por eso te recomiendo que esperes 20 minutos más. Si estás en una cafetería, disfrutá de una rica bebida y mirá por la ventana. O buscá videos graciosos en YouTube. Tomate ese tiempo para esperar a ver si surge algo más.

Yo le calculo unos 20 minutos pero puede ser un poco más.

Una vez que pasa ese tiempo de gracia, ahí ya podés levantarte y seguir disfrutando de tu viaje.

¿Y si vuelve a surgir un bug? Bueno, habrá que repetir el proceso una vez más. Esta vez con mucha más rigurosidad.

Concluyendo

Los proyectos de mantenimiento no son los más recomendables para los freelancers. Estos te atan a un sistema y si funcionan 24hs. hacen que te puedan solicitar en cualquier momento. Sin embargo, todos desarrollamos o mantenemos sitios que requieren un soporte de estas características.

Si surge un error mientras estás de viaje, lo importante es mantener la calma y proceder tomándote todo el tiempo del mundo. Realizá los pasos necesarios. Asegurate de tener backups y luego de entregar la solución, esperá unos minutos extra a ver si realmente todo ha sido resuelto.