Houston, we have a problem

O, cómo organizar un equipo para soportar errores inesperados en sus apps

Lyndon B. Johnson Space Center — Apollo 13 command center

Sábado, 11.30 am, mate, facturas, balcón. You have 3 unread mails: 
Alert on app XXX, % error >3%.
Alert on app YYY, % error >3%.
Alert on app ZZZ, % error >3%.

Reflexión filosófica sobre por qué no cambiamos a una profesión u oficio en el que uno no tenga que estar 24*365 alerta de que algo no este funcionando como debería. En al rededor de 5 o 10 segundos nos damos cuenta de que son los gajes de un oficio que nos gusta y/o que no sabemos hacer otra cosa; así que sacamos la compu de la mochila, vemos el grupo de chat del trabajo donde varios están en una situación similar y nos ponemos a ver qué está pasando.

Si esta situación les resulta familiar, probablemente también las siguientes preguntas: ¿Cómo hago para que mi equipo responda de forma eficiente ante problemas en producción?, ¿Hasta donde me meto como líder y hasta donde dejo al equipo que resuelva el problema?, ¿Qué hago si la situación se vuelve recurrente?, ¿Cómo distingo las alarmas reales, de las “ah, esto pasa siempre, no tiene importancia”? La mayoría no tiene una respuesta única al respecto, pero les cuento las cosas que me fueron resultando positivas en mi experiencia.

El primer tema importante es en quién dentro del equipo recae la responsabilidad de actuar ante algún inconveniente inesperado fuera del horario laboral. Y la respuesta es EN TODOS. Cuando hay un error en producción se aprende 10 veces lo que se aprende en situaciones normales. Si bien es muy probable que los más experimentados tengan más herramientas que los jr, es clave que compartan una misma sensación de responsabilidad por cuidar su “bichito” vivo en producción. Primero porque para un restart o para levantar un nodo de una base de datos no hace falta mucha experiencia y esto resuelve gran parte de los problemas fuera de hora (al menos hasta que volvamos a la oficina y podamos ver que pasó), y segundo porque en caso de que haga falta mano experta, el jr va a poder aprender sobre que es lo que se hace en estos casos y así ganar seniority. Si tenes un equipo de X personas, que las X estén juntas en algún canal de chat y con las mismas posibilidades de enterarse y de meter mano ante un problema; sin importar cuan grande resulte X.

Ahora bien, lamentablemente (o por suerte) no hay muchas más formas de educar que con el ejemplo. Así como decirle a un hijo que no fume mientras tenes un cigarrillo en la mano no es gran garantía de que no fume, decirle a tu equipo que esté alerta ante problemas y con voluntad para solucionarlos no va a hacer que pase si cuando pasa vos no te arremangás y te metés a solucionarlo. Es cierto también que hay que jugar con un gris complejo que oscila entre meterse a resolver un problema y dar un tiempo para que alguien del equipo tenga oportunidad de hacerlo, pero hay que entender que lo primero es dar el ejemplo. Con ese reconocimiento ganado, hay que empezar a aflojar y a dar lugar e ir viendo en cada caso puntual cuando conviene meterse y cuando no, pero siempre hay que ser ejemplo.

Llegado el lunes, es fundamental revisar con más detenimiento qué fue lo que pasó, no solo en la parte técnica que derivó en un problema, sino en cómo funcionó el equipo al respecto. ¿Actuamos con la velocidad que esperábamos?, ¿Alguno tuvo intenciones de resolver y se encontró con algún impedimento?, ¿Estamos conformes con el modo y momento del que fuimos notificados del problema?, ¿Tenemos algún plan de acción para que ese error especifico no vuelva a pasar?

Para terminar no quiero dejar pasar un tema crucial: el “over alarming”. Los problemas desgastan, las alarmas desgastan. Lamentablemente los errores que no son un problema real, pero que nos alarman de la misma forma que los que si lo son, tarde o temprano traen problemas. El clásico: “ah, como me llegan alarmas todos los días cuando llegó esta no le di importancia” o el más silencioso, que hace que un dev deje de hacer lo que este haciendo para revisar un problema que no lo ameritaba. Las notificaciones que nos lleguen sobre nuestras apps, via mail, chat o teléfono, tienen que representarnos un problema para que valga la pena la alarma. Si no vale la pena enterarnos fuera de hora del tema, hay ir a buscar esa información de forma activa y no que esa info nos llegue a nosotros con un push.

Hacer que un equipo responda de forma eficiente ante problemas es un objetivo que no se logra de un día para el otro y tiene mucho más de constancia que de buenas ideas. El Apollo 13 no volvió a la tierra por arte de magia…

Show your support

Clapping shows how much you appreciated Sebi Kaiser’s story.