Incidentes, post-mortems y trabajo en equipo
Trabajo en equipo, lo más importante para resolver un problema
Mi intención con este artículo inicialmente era hablar sobre cómo gestionar los incidentes cuando ocurren, como identificar el origen de los problemas y como asegurarnos de que no vuelvan a pasar.
Como he hecho en otras ocasiones, había pensado en crear una historia que reflejara todo esto de una forma narrativa con la que entender de primera mano este tipo de situaciones. Sin embargo, pensando sobre ello me he dado cuenta de que la mejor forma de expresarlo era contándoos una historia real de un incidente, como el equipo reaccionó y como tomaron medidas para solucionarlo.
Así que esta vez os traigo no una historia mía sino de un equipo con el que he trabajado estrechamente en Mercadona Tech. Es una historia sobre incidentes, acciones tomadas y lecciones aprendidas.
El día del incidente
Ese día el equipo estaba visitando una de las colmenas, los almacenes donde preparamos los pedidos en Mercadona Tech. Habían estado probando unas nuevas funcionalidades relacionadas con la recepción de los camiones y hacia medio día terminaron todo el trabajo. Había salido todo como esperaban así que bajaron al aparcamiento para coger los coches y volver a la oficina.
Fue entonces cuando el móvil de guardia sonó.
Una, dos, tres tiendas estaban llamando a soporte porque les saltaba un error cuando escaneaban un contenedor al bajarlo del camión… Sin validarlo no podían continuar y empezar a reponer las estanterías.
El equipo dejó los coches y corrió escaleras arriba para mirar que pasaba y solucionarlo. ¿Habían tocado algo que no debían? ¿El fallo se debía a un cambio de la aplicación o un fallo de infraestructura?
Se dirigieron a la cocina y sacaron los portátiles. Los backends se pusieron a mirar los últimos cambios que habían subido al proyecto y los desarrolladores android empezaron a investigar los logs para comprobar que podía estar pasando.
No tardaron en encontrar el problema, un endpoint que se supone que ya no se utilizaba y que habían borrado esa misma mañana. ¿Porque fallaba algo que nadie estaba usando?
Los android enseguida lo descubrieron, resulta que ese endpoint aún se usaba en versiones viejas que algunas tiendas aun utilizaban. Lo habían quitado hacía unas versiones, pero algunas tiendas usaban una versión de hacía unas semanas y aun no habían actualizado.
¿No habían hablado ya de esto? ¿No se suponía que habían forzado ya hace tiempo? No importaba, ya lo analizarían después, lo importante ahora era desbloquear a las tiendas.
¿Qué solución tenían entre manos? Forzar la aplicación a la última versión. ¿Consecuencias? Una actualización forzada de versión a tiendas que no estaban afectadas por el problema.
Valoraron el riesgo, la parte negativa de forzar la versión era que todas las tiendas que no estuvieran en la última versión tendrían que descargarla para poder continuar con sus procesos, pero era una forma rápida de solucionar el problema y que no bloqueaba al resto de tiendas. Además, muchas de las tiendas ya estaban en la última versión así que el impacto final no era demasiado grande.
Otra opción sería hacer rollback de la versión de backend para recuperar ese endpoint y que pudiesen continuar, pero no tenían del todo claro que impacto podría tener un rollback en ese momento.
Finalmente, y después de hacer un balance de los riesgos, decidieron forzar la versión de la aplicación, desbloquear a las tiendas era lo más importante en ese momento.
Eso solucionó el problema y, después de actualizar, las tiendas ya pudieron continuar.
El port-mortem
Al día siguiente el equipo se juntó para analizar qué había pasado. Empezaron el post-mortem como era habitual: describieron lo que había sucedido en orden y como lo habían solucionado. También comentaron el impacto: una actualización forzada a algunas tiendas que no habían sufrido el problema.
Después analizaron el origen del problema: habían borrado un endpoint que no se estaba utilizando, o eso creían.
¿Había sido un problema de comunicación? En realidad no, backend y androids se habían comunicado como tocaba, habían hablado sobre el cambio y habían comprobado que el endpoint ya no existía en la implementación.
¿Entonces cuál había sido el error? Un simple fallo humano, no habían tenido en cuenta que versiones antiguas aun podían estar usándolo y no habían mirado los logs para comprobarlo. Nada que no pudiera pasarle a cualquiera.
¿Alguien se echó la culpa? Obviamente no, trabajaban en equipo, lo importante no era señalar a los que habían cometido el fallo, lo importante era encontrar la forma de que aquello no les volviera a pasar.
En un rato definieron las acciones a tomar para evitar este tipo de problemas en el futuro. Retomaron una conversación que había salido un par de veces en el pasado: implementar un sistema de contract testing que comprobara la compatibilidad de los contratos entre la aplicación de android y los servicios web para no subir nada a producción que fuera incompatible con las versiones disponibles.
En poco tiempo tuvieron un prototipo funcionando y comprobando que los cambios que hicieran en los contratos eran verificados contra las versiones productivas.
Todo esto pasó hace unos 8 meses, desde entonces no han vuelto a tener ningún incidente parecido.
Trabajar en equipo para que no vuelva a pasar
Como hemos podido observar, una de las cosas más importantes de cara a resolver un problema es trabajar en equipo. Apoyarte en tus compañeros y trabajar juntos para darle solución es la mejor manera de salir adelante. Además, frente a una crisis o resolver un incidente las cosas importantes son:
- Primero desbloquea, luego analiza: como hemos visto en el ejemplo, el equipo se centró primero en desbloquear la situación y después analizar porque habían llegado hasta ese punto. Frente a una crisis lo importante es solucionarla primero. Investigar que la ha causado vendrá después cuando no trabajes contrarreloj.
- Equilibra el riesgo: frente a acciones debes valorar el riesgo que pueden tener. El equipo valoró el impacto que tendría forzar la versión y decidieron seguir adelante porque el posible impacto era aceptable. En ocasiones puede que el riesgo sea demasiado grande y tengas que valorar otras opciones.
- Cultura blameless: esta es la más importante. No se ha de señalar a ningún culpable. Trabajamos en equipo para resolver el problema y ofrecer valor a nuestros usuarios. Somos un equipo, no competimos entre nosotros, hay que premiar la mejora y aprendizaje continuo frente a las culpas individuales.
- Saca acciones que eviten que vuelva a ocurrir: todo post-mortem tiene un objetivo: definir las acciones a tomar para que el problema no vuelva a ocurrir. Estas acciones además tienen que ser preventivas en vez de reactivas, es decir, en vez de un parche que solucione el problema actual se ha de pensar en acciones que se adelanten a problemas potenciales. Implementar contract testing por ejemplo era una de estas acciones, introduciendo una validación de los contratos antes de desplegar cambios a producción no solo resolvieron ese problema sino cualquiera que introdujeran en el futuro.
Como hemos visto, el trabajo en equipo y la toma de decisiones para mitigar y evitar posibles problemas es esencial cuando nos enfrentamos a incidentes. El equipo trabajó de forma ejemplar para solucionarlo y el problema no fue a más. Además, tomaron las acciones necesarias para que no volviera a pasar y desde entonces no ha ocurrido nada parecido.
Quiero dar las gracias a Alejandro Capdevila, y Luis Cencillo por contarme los detalles de aquel día y a todo el equipo de V6 por el buen trabajo que hicieron y siguen haciendo.
Si queréis leer más sobre como implementaron contract testing para resolver el problema os dejo aquí un artículo de Edgar Miró sobre como lo llevaron a cabo: Contract Tests: A New Hope
Trabajo en equipo, lo más importante para resolver un problema.
TL;DR
La rápida identificación del problema y la toma de decisiones para desbloquear la situación demuestran la importancia de la acción inmediata en situaciones críticas. El post-mortem realizado al día siguiente del incidente refleja una cultura blameless, donde el énfasis está en el aprendizaje y la mejora continua en lugar de señalar culpas individuales.
La implementación de medidas preventivas, como el contract testing, es una estrategia efectiva para evitar que problemas similares vuelvan a ocurrir. El éxito de estas acciones se muestra en la ausencia de incidentes similares en los últimos 8 meses, subrayando la eficacia de las decisiones tomadas por el equipo.
No solo es importante la resolución efectiva de un incidente, sino que también es esencial cultivar un entorno de colaboración, toma de decisiones informada y medidas preventivas. La historia de este equipo en Mercadona Tech sirve como un recordatorio de que, ante los desafíos, la fuerza del equipo y la capacidad para aprender y evolucionar juntos son fundamentales para el éxito a largo plazo.