Una historia de #BestProduct Parte III — #BestOps
Si no leíste la Parte I y Parte II de nuestra historia de #BestProduct, te recomiendo que lo hagas para tener mejor contexto de esta serie.
Hoy narramos la tercer parte: garantizar el mejor producto con la mejor operación.
El viernes llego Lionel a la oficina unos minutos tarde porque había un poco más de tráfico, y al entrar vió que todo el equipo estaba en la sala de reuniones. Cuándo Andrés lo vio aparecer, le hizo un gesto para que se sume.
-“¿Que pasó? ¿Me olvide de ver algo en el calendario?” — preguntó Lionel al entrar.
-“No no. Ayer tuvimos una incidencia en producción y estamos haciendo el post mortem para ver que oportunidades de mejora encontramos” — respondió Andrés
-“Uh suena serio, ¿Qué pasó?”
-“Tranquilo, nada grave. Justo estábamos por empezar a repasar el timeline. Pedro, continua por favor”.
El relato de lo sucedido
“A las 3 am recibimos una alerta de degradación de tiempo de respuesta de nuestra API y incremento de consumo de CPU por sobre el threshold que tenemos configurado” — comenzó Pedro.
“¿Cómo funciona eso? ¿Tenemos un NOC o BOC (Network / Business Operation Center)? ¿Cómo saben ellos a quien llamar?” — preguntó Lionel curioso.
“Si tenemos un BOC, pero hace tiempo automatizamos el proceso de alerta y llamada. Es simple, tenemos cientos de alertas configuradas para monitorear varios aspectos de las aplicaciones que de ocurrir señalizarían una denegación o degradación del servicio. Cada alerta está asociada a una aplicación. Las aplicaciones están mapeadas a los equipos de trabajo que le damos mantenimiento. Por ejemplo, la aplicación “Shopping” está mapeada a nosotros. Cada equipo tiene una planilla de guardias rotativas sincronizada con el sistema PagerDuty. Cuándo una alerta se dispara, PagerDuty la lee, ve la aplicación afectada y mira que persona está de guardia en el equipo para iniciar una llamada automática e informarle” — le explicó Andrés.
“¡Wow! ¿Y si no lo encuentra? ¿Ahí entra el BOC?” — retrucó Lionel que ya se estaba entusiasmando con el proceso.
“Es muy raro que pase. Somos super críticos con atender con suma urgencia los issues en producción, y la persona que no atienda deberá dar sus buenas explicaciones. Pero de todas formas tenemos un sistema simple de escalación, dónde el algoritmo de PagerDuty va buscando contactos alternativos hasta que encuentre a alguien.” — terminó de explicar Andrés
“¿Ya puedo seguir señores?” — Dijo Pedro ansioso — “Cómo yo estaba de guardia me tocó recibir la llamada automática de PagerDuty. Lo que había pasado es que alrededor de la 2:50 uno de nuestros socios comerciales Rostel había incrementado su tráfico.”
“Eso suena difícil de detectar” — dijo Lionel — “¿cómo sabías que se debía a aumento de tráfico y de ese canal particular?”
“Gracias a la instrumentación de hits por cliente fue muy fácil detectarlo, había un warning de incremento de tráfico y mirá cómo este gráfico mostraba el culpable” — continuó Pedro mostrando su pantalla al resto.
“Para que sepas Lionel esto es super crítico en todos los desarrollos que hacemos. Sabemos que los problemas van a ocurrir, lo que no sabemos es cuándo (y siempre es en el peor momento). Entonces lo importante es que apliquemos todas las métricas e instrumentación que nos lleven a una rápida detección de dónde esta el problema cuando suceda” — indicó Andrés.
“Me llamo la atención que dispare una alerta porque tenemos hace tiempo el autoscaling que hace que incremente la infraestructura en estas situaciones.” — siguió Pedro — “Efectivamente eso había funcionado, y ahora teníamos más hardware atendiendo las peticiones sin problema. Lo otro que también se había activado era el limitador de request, que descartaba los que llegaban cuándo pasaban los 20.000 por minuto.”
“¿Por qué limitar los requests si tenemos autoscaling?” — se atrevió a interrumpir Lionel.
“Eso surgió de una de estás postmortems.” — comentó Jose que sentía que había estado mucho tiempo cayado — “Una vez uno de nuestros socios comerciales recibió un ataque de un robot que incrementó muchísimo su tráfico fuera de los parámetros normales. Por más que tengamos autoscaling hay situaciones dónde no tiene sentido escalar, es perjudicial para el negocio y es mejor directamente trabajar con bloqueo de comportamientos extraños”.
“A ver si me dejan llegar a lo que realmente pasó gente…” — dijo Pedro que quería lograr una buena conclusión del caso — “Por otra parte nuestro sitio también recibió una suba de tráfico a causa de un metabuscador, lo cuál hizo que se genere un incremento de escritura de tarifas en la base de datos de pricing temporal y la aplicación empezó a dar timeouts por no poder escribir en base de datos. Cuándo ingrese a ver el problema a las 3am, vi que ya se estaba ejecutando el scaling automático de la base de datos y corría el script de reintento del pool de requests fallidos. Así que esperé unos minutos, el problema se solucionó sin que tuviera que hacer nada, ni escalar ni llamar al equipo SWAT de special operations.”
“¡Momento, momento!” — exclamó Lionel desconcertado—“¿significa que además de autoscaling tenemos otras cosas que ocurren automáticamente?”
“¡Claro! Tenemos una batería de herramientas de self-healing, ¿o acaso a vos te gusta levantarte a las 2 am a arreglar servidores?” — se burló Manuel — “Tenemos el script que levanta servidores caídos (y nos dispara una alerta luego de 2 intentos fallidos), tenemos el de compresión y almacenamiento especial de datos antiguos cuando se están llenando discos, tenemos el que remueve de rotación servidores con alta tasa de error y los reinicia… y muchos más”
¿Y qué hacemos con esto?
Andrés que lideraba la reunión le pregunto al equipo entonces:
-“¿Qué opinan? ¿Qué hacemos con esto?”
-“Yo creo que fue un falso positivo. Nuestros sistemas se comportaron cómo esperamos y se recuperaron del pico doble que sufrimos”— dijo Manuel
-“No estoy de acuerdo. Efectivamente tuvimos una degradación de tiempos de respuesta que afectó a usuarios y a un socio comercial” —objetó José
-“Pero eso es normal, recibimos pico de tráfico, iniciamos autoscaling, cuándo se logra el autoscaling desaparece el problema” — replicó Manuel
-“Si bien vimos las métricas de tiempo de respuesta, acá les puedo mostrar las métricas de conversión. Podemos ver que esos 10 minutos bajó casi un 50%, lo cuál significo una pérdida de algunos miles de dólares en venta” — sumó Ariel mostrando algunos gráficos en su pantalla
-“Yo creo que ambos tienen razón” — sentenció Andrés. “A ninguno nos gusta levantarnos a las 2 am por un problema que se resuelve solo. Si creo que en ese sentido es un falso positivo y deberíamos atacarlo cómo tal, para que pase a ser un warning que veamos por la mañana. Pero por otra parte, tenemos que trabajar en ese lapso de 10’, ¿cómo podemos acortar ese efecto para reducir pérdidas y mal servicio a los clientes?”
“Una opción podría ser anticipar el autoscaling de base de datos para cuándo recibimos una suba de un socio y que no peligre la afectación al sitio…” — empezó a proponer José.
Y así siguieron al rededor de 20′ debatiendo a modo brainstorm que opciones tenían para solucionar la causa raíz de la afectación. Lionel se familiarizó rápido con las técnicas de self-healing y hasta propuso desarrollar un balanceador especial que tenga una base de datos “apagada” de backup que puedan encender y reducir el tiempo de autoscaling a prácticamente cero.
Las reflexiones de Lionel
Luego de esa inesperada reunión por la mañana, Lionel se quedó por la tarde reflexionando en lo que había ocurrido. Se dio cuenta de 3 aspectos que eran fundamentalmente distintos a cómo había trabajado en el pasado:
- Los problemas en producción deben ser la prioridad número uno de cualquier equipo de producto que quiera brindar un servicio excepcional a sus clientes.
- Una de las mejores maneras de garantizar la rápida detección y corrección de los problemas es tener y sumar constantemente métricas en todos los niveles, que permitan alertas más precisas
- La principal forma de poder garantizar ese nivel de servicio es automatizar lo máximo posible todo el proceso: alertas bien configuradas, robustos sistemas de recovery automático, sistema de llamada y escalación automática, robots de monitoreo de casos de prueba, y ¡todo lo que se encuentre que se pueda automatizar!
Se dio cuenta que en sus trabajos anteriores estás técnicas y herramientas estaban a su alcance. Y que por ende tener #BestOps es una cuestión cultural y de foco, y no simplemente un “hard skill” o parte de un job description.