¿Cómo trias un incidente de servicio como SRE?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Un SRE que abre un incidente primero lo cuantifica en términos de SLO: cuántos usuarios, qué recorridos y cuán rápido se consume el presupuesto de error, porque eso decide la severidad y la escalada. Se nombra un comandante de incidente que mantiene una única línea temporal; un responsable de comunicaciones actualiza a los interesados con cadencia fija. La investigación parte de las señales clave del servicio afectado y sus dependencias y del registro de cambios, y avanza una hipótesis a la vez con una prueba para cada una, para que los responders no hagan cinco cambios de golpe. La mitigación que recupera a los usuarios, como rollback, desvío de tráfico o descarte de carga, va antes que la causa raíz. Todo se registra para el postmortem.

Ejemplo

La latencia de búsqueda se duplicó y la tasa de consumo del SLO llegó a 14x a las 14:03. El comandante fijó la severidad por la tasa de consumo, el panel mostró la CPU del clúster de búsqueda saturada y el registro de cambios mostró una nueva funcionalidad de ranking activada a las 13:55. La hipótesis uno, la funcionalidad, se probó desactivando su flag para el 10 por ciento del tráfico; la latencia se recuperó en esa porción, el flag se apagó globalmente a las 14:11 y el equipo investigó después el coste de la funcionalidad.

Errores frecuentes

• Escalar por intuición en lugar de por impacto medido en usuarios.
• Perseguir la causa raíz mientras el presupuesto de error sigue consumiéndose.
• Varios responders cambiando cosas a la vez sin registro de quién hizo qué.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.