¿QUÉ PASO?
El otro día se cayó Chipax. No fue nada demasiado grave: una página en particular no se pudo ver durante 30-40 minutos. De hecho, no estoy seguro ni qué día fue.
La crisis en sí fue muy poco importante, pero el problema es importantísimo. O, mejor dicho, el que no nos pase de nuevo es nuestra responsabilidad. Aunque no hayamos estado todos comiendo popcorn viendo cómo apagaban el incendio, todos aprendimos qué pasó, por qué pasó, y cómo se solucionó.
Lo aprendimos a través de los tétricamente llamados post mortems. Son, en pocas palabras, un análisis de las causas de un problema, una descripción de la mitigación y las medidas a tomar para evitar que vuelva a ocurrir.
No es publicar los datos personales del que cometió el error para hacer un bug-shaming público. Es un ejercicio retrospectivo para aprender y para que el problema no vuelva de la tumba a atormentarnos.
¿POR QUÉ PASÓ?
En la ingeniería de software los bugs parecen entrar por osmosis. Google, Facebook, Amazon: todos se han caído muchas veces. No lo suficiente para perder la vergüenza, pero sí para darse cuenta de que tratar de ocultarlos es imposible, y la transparencia es el mejor camino.
Incluso hay empresas que esporádicamente publican en sus blogs de ingeniería post mortems de sus sistemas para dar explicaciones de sus caídas. Esto, claro, cuando no signifique divulgar detalles confidenciales de la arquitectura o del código. Es una ceremonia pública de aprendizaje a costa de la humanidad de la empresa.
¿CÓMO PASÓ?
¿En qué consiste un post mortem? Acá puedes ver un ejemplo de Google (en inglés). Ahí lo explican mejor de lo que yo podría hacerlo, pero solo apuntar algunas observaciones:
- El gatillante (trigger) no es lo mismo que las causas de raíz (root causes); es posible que el bug estuviera latente desde el 2012, pero recién se evidenció cuando aumentó el flujo de usuarios.
- Medir el impacto es crucial. Si tuviste una caída y no sabes medir el impacto en clientes, USD y/o tiempo de empleados, lo más probable es que no aprendas todo lo que puedes del problema. De ser así, una de las acciones correctivas debe ser generar herramientas para medir impacto: consultas SQL, paneles en tiempo real de flujo de usuarios en la aplicación: estas deberían existir antes de que comience el incendio.
- El tiempo de respuesta va a quedar plasmado en el timeline. El gap más vergonzoso es entre que existe el problema y el equipo de tecnología reconoce que este existe. Por eso la pregunta “¿estamos caídos?” debiese poder ser respondida instantáneamente.Y la persona responsable de responder tiene que tenerlo muy, muy claro.
- El aprendizaje de la caída no necesariamente es de software. Puede que el eslabón más débil haya sido la respuesta operacional: todos corrieron en círculos mientras los clientes cerraban sus cuentas en signo de protesta.
EN CONCLUSIÓN
Los primeros en saber que tu producto no es perfecto son tus clientes. Lo menos que puedes hacer es transparentar que estás haciendo todo lo posible para mejorar cada día. Eso significa mejorar la operación, aumentar el conocimiento de la organización y hacer crecer constantemente la capa de polvo sobre el extintor. El slogan moderno es build fast, break things. La segunda parte implícita es fix fast, learn things. Ojalá no se nos olvide nunca.
