Proceso estructurado para manejar incidentes de producción desde detección hasta resolución y post-mortem. Cubre evaluación de severidad usando gradación P0-P3, coordinación de equipo con un incident commander designado, plantillas de comunicación para interesados y usuarios, y requisitos de post-mortem estructurados para impulsar aprendizaje organizacional de cada outage significativo.
Casos de uso
- Un servicio de producción está completamente caído y los usuarios no pueden acceder a la funcionalidad core
- Un outage parcial afectando un subconjunto de usuarios, como una región específica o tier de usuario
- Degradación de rendimiento que dispara alerts automáticas pero aún no es un outage completo
- Un issue de integridad de datos donde datos incorrectos se están mostrando a los usuarios
- Un incidente de seguridad donde acceso no autorizado es sospechado o confirmado
Funciones principales
- Evalúa la severidad y asigna un grado: P0 para outage completo, P1 para funcionalidad major rota, P2 para experiencia degradada, P3 para issue menor con workarounds disponibles
- Declara el incidente en el canal designado con severidad, descripción de impacto y tu nombre como incident commander, luego ensambla el equipo de respuesta
- Comienza mitigación inmediatamente: rollback del último deployment, deshabilita un feature flag o activa un circuit breaker para restaurar servicio antes de investigar causa raíz
- Comunica el status a usuarios afectados vía la página de status dentro de los 15 minutos de la declaración y proporciona actualizaciones a intervalos regulares hasta resolución
- Investiga la causa raíz en paralelo con monitoreo, usando dashboards y logs estructurados en lugar de especulación sobre qué podría haber cambiado
- Cuando el servicio es restaurado, actualiza la página de status inmediatamente y programa una reunión de post-mortem dentro de 48 horas con todas las partes involucradas
- Escribe el documento de post-mortem cubriendo la línea de tiempo completa, análisis de causa raíz, factores contribuyentes y action items concretos con owners y deadlines
Relacionados
Relacionados
3 Entradas indexadas
Systematic debugging
Reemplaza la depuración de prueba-y-error con un proceso basado en hipótesis: formula una hipótesis refutable, construye la reproducción más pequeña posible y verifica la evidencia antes de tocar el código. Este enfoque estructurado es más valioso durante incidentes de producción, builds de CI inestables y regresiones confusas donde la depuración intuitiva desperdicia horas en síntomas correlacionados pero no causales.
Agentic AI orchestration efficiency claims due diligence
Convierte narrativas de eficiencia de IA agéntica en checklist: métricas citadas (p. ej. valor por vatio por usuario), lanzamientos y orquestación vs valuaciones mediáticas. Cita CNBC 3-jun-2026: Srinivas (Perplexity) dijo a Elaine Yu que ganará quien maximice «most taken value per watt per user» equilibrando precisión, latencia, costo, privacidad e inteligencia; Computer (feb) y Personal Computer en Windows; orquestación híbrida; valuación ~US$20.000 millones vs Anthropic ~US$1 billón y OpenAI ~US$850.000 millones; ingresos anualizados triplicados por mejoras de modelos Anthropic—sin usar eslóganes como benchmark interno.
Postmortem trigger and root-cause taxonomy
Resume el Apéndice C del workbook SRE (“Results of Postmortem Analysis”): explica cómo Google estandariza postmortems para relacionar disparadores observables versus categorías de causa raíz, priorizando arreglos sistémicos. El apéndice cita estadística histórica 2010–2017 donde empujes binarios (~37 %) y configuración (~31 %) encabezan triggers, más fracciones menores comportamiento usuarios (~9 %), pipelines (~6 %), cambios proveedor (~5 %), degradación (~5 %), capacidad (~5 %) y hardware (~2 %). Otra tabla liga causa raíz: fallos software (~41 %), proceso desarrollo (~20 %), comportamientos complejos (~17 %), planificación despliegue (~7 %), red (~3 %). Úsalas como benchmark heurístico, no SLA.