Resolver no es aprender
Un servicio falla, el equipo lo arregla, todos respiran y vuelven a lo suyo. Tres meses después, el mismo fallo, en otro servicio, con otra persona de guardia que no sabía lo que pasó la primera vez.
Resolver un incidente es necesario. Pero si al final del incidente la plataforma es exactamente igual que antes, lo único que se ganó fue tiempo.
El ciclo completo
- Recuperar el servicio, con el procedimiento que se diseñó para eso (lo vimos al diseñar para fallar).
- Analizar sin buscar culpables. La pregunta no es quién se equivocó, sino qué permitió que el error llegara a producción.
- Encontrar la causa de fondo, que casi nunca es la obvia. "Alguien subió una configuración mal" es el síntoma; "nada comprobaba esa configuración antes de desplegarla" es la causa.
- Convertirla en algo permanente.
Qué cuenta como "permanente"
No cuenta "tener más cuidado". Cuenta algo que siga funcionando cuando todos se hayan olvidado del incidente:
- Una prueba que habría detectado el fallo.
- Una validación automática en la construcción, como las del artículo sobre que falle la construcción.
- Una regla en la norma de la organización, con su comprobación.
- Un registro de decisión si el fallo reveló que una decisión de diseño ya no se sostiene.
Medirlo
Una plataforma que aprende se nota en dos números: los incidentes repetidos bajan y cada vez más fallos se detienen en la construcción en lugar de llegar a producción.
Muchas de esas reglas y validaciones las aplican hoy asistentes de IA que trabajan dentro de la plataforma. Cómo se gobierna eso es el último bloque de la serie.
Cómo lo aplicamos: Ingeniería de Plataforma.