Cómo crear un sistema para responder a lo inesperado

Llevo más de 10 años trabajando en ingeniería, desde Microsoft hasta Stripe, y si hay algo que tengo claro es que los incidentes no se pueden evitar… pero sí se pueden preparar.

Este blog resume lo que conté en Tech Talks: un caso real y cinco ideas que creo que pueden mejorar mucho cómo enfrentamos el on-call. Puedes ver la charla completa o leer este blog post donde trataré de resumir la charla en menos de 5 minutos.

El incidente de Cookie Monster

Una noche me llamó PagerDuty. 321 errores críticos en un servicio que se llamaba... Cookie Monster. ¿Qué es Cookie Monster? Ni idea. Solo sabía que era grave, eran las 3AM y estaba sola frente al computador.

En Stripe trabajaba en los procesos batch que mueven plata de las tarjetas de crédito a los bancos. Cada cierto tiempo se mandan archivos gigantes con miles de transacciones. Y esa noche, ese sistema estaba caído.

Pasaron minutos, luego horas. Llegamos a 4000 errores. Eventualmente, descubrimos que la falla tenía que ver con conexiones SFTP. Pero no fue fácil: el gráfico correcto estaba en el tercer link del segundo dashboard que solo conocía alguien que llevaba mucho tiempo en el equipo.

Después de mirar los logs, revisar todos los Pull Requests del último día, hablar con AWS y con los bancos, dimos con la causa: una actualización de Go había cambiado una librería de SFTP que rompía las conexiones con un solo banco… el único que usaba IBM.

Y ese fue el quiebre.

¿Se puede entender a las 2AM después de 2 piscolas?

Ahí me di cuenta de algo que no se me olvidó nunca más: las herramientas de monitoreo tienen que poder entenderse en cualquier momento del día. Sobre todo a las 2AM, con dos piscolas encima.

Puede sonar chistoso, pero es real. Muchas veces he tenido que responder a incidentes desde el gimnasio, en el cumpleaños de un amigo, o medio zombie en la madrugada. Y en esas condiciones, si no puedes entender el sistema rápido, todo se complica.

Lecciones para construir un sistema (y un equipo) que aguante

De esa noche (y muchas otras), salieron varias ideas que aplicamos después. Algunas son herramientas, otras son hábitos. Acá van cinco.

1. Piensa en tu yo del futuro

Una buena práctica de ingeniería: documentar tus Pull Requests con cariño.

Una vez, gracias a esto, resolvimos un problema porque alguien había documentado, cuatro años antes, cómo encriptar un dato para un test. Cuatro. Años. Sin eso, quizás cuánto tiempo más hubiésemos estado buscando el problema.

2. Cada alerta debe tener su runbook

Si una alerta llega a producción, tiene que tener un runbook (una guía paso a paso para saber qué hacer si algo falla) asociado. Y este tiene que estar actualizado.

Muy importante: usar un lenguaje visual consistente. Verde = dashboards. Azul = logs. Morado = personas. Cuando son las 3AM y estás con sueño, eso hace una diferencia.

3. Postmortems blameless (dormir primero, culpar nunca)

Después de un incidente, lo primero es dormir. Después, escribir un postmortem.

El foco no es culpar, es aprender. Si alguien borró la base de datos de producción, el problema es que el sistema lo permitió. Un buen postmortem distribuye el aprendizaje. No sirve que solo quien respondió al incidente entienda qué pasó.

Para inspirarte y aprender de otros, puedes revisar esta lista de postmortems.

4. Hand-off meetings al cerrar el turno

Es importante dar contexto. Tener mini reuniones donde se entrega el estado actual del sistema al próximo turno, 15 minutos, pueden evitar horas de confusión.

• ¿Qué pasó esta semana?
• ¿Qué patrones vimos?
• ¿Hay trabajo pendiente?
• ¿Descubrimos algo nuevo que aún no es un bug, pero podría serlo?

5. Reconocer el trabajo de on-call (esto también es productividad)

On-call es trabajo. Es cuando un integrante del equipo está disponible para responder a incidentes dentro y fuera del horario laboral. Y tiene que ser valorado como tal. No todo puede ser features nuevas. También hay que mantener lo que ya lanzaste.

Mis recomendaciones:

• Equipos de ~8 personas para tener una rotación sana.
• Dedicación del 10–20% del tiempo para trabajo que viene de on-call.
• Apoyo del liderazgo. Esto no se logra sin buy-in.

El on-call como parte de la cultura

No se trata solo de apagar incendios. Se trata de construir una cultura donde el on-call se tome en serio, donde haya espacio para mejorar procesos, escribir documentación y evitar que el conocimiento se quede en la cabeza de una sola persona.

Lo esperado de lo inesperado

El título de esta charla era “cómo responder a lo inesperado”. Pero la verdad es que muchos de los incidentes que vivimos eran esperables... solo que no sabíamos cuándo iban a pasar.

La clave está en prepararse. En tener datos organizados. En distribuir el conocimiento. Y en construir sistemas que no dependan de que alguien recuerde algo a las 3AM con dos piscolas encima.

Si solo te llevas tres ideas de esta charla…

1. El on-call tiene que ser parte de la cultura del equipo.
2. El conocimiento tribal hay que distribuirlo.
3. Los datos tienen que estar organizados para tener valor.

Implementar esto puede parecer trabajo extra al principio, pero hace la diferencia. Vas a dormir más tranquilo, responder mejor a lo inesperado y tu equipo lo va a agradecer.

Escalar sistemas es uno de los temas que se hablan en Tech Talks by Fintoc. Si te gustaría ir al próximo, inscríbete a nuestro newsletter o síguenos en LinkedIn e Instagram para estar atento.

Bernardita Torres

Berni es ingeniera civil de computación de la UC. Partió su carrera en una startup chilena y después se fue a Seattle, donde trabajó casi siete años en Microsoft. Ahí pasó por Xbox, Azure Search y Microsoft Research, desarrollando sistemas operativos y agentes inteligentes para profesionales de la salud.

En 2019 se unió a Stripe y fue parte del equipo encargado de las integraciones con tarjetas de crédito. Ha trabajado con C++, C#, Go, TypeScript y Ruby. Se define como backend/platform engineer, con foco en excelencia operacional y productos para developers.

Hoy trabaja en Oilcan, donde está construyendo Hotpot, una mejor manera de hacer on-call.