Respuesta a incidentes con SQL

La respuesta a incidentes es más rápida cuando los respondedores responden las mismas preguntas en el mismo orden: ¿cuándo comenzó el cambio, qué usuarios y flujos de trabajo se ven afectados, qué cambió y se recuperó el sistema? Los eventos estructurados preservan esas dimensiones para que puedas pasar de una señal amplia a una línea de tiempo defendible sin buscar mensajes no estructurados.

Comience con una señal acotada

Elija un evento de finalización estable como api_request_completed y luego compare depósitos completos de cinco minutos. Mantenga las plantillas de ruta, los identificadores de versión, el estado, las categorías de error y los identificadores de cuentas seguras como campos separados.

SELECT
  date_bin(INTERVAL '5 minutes', timestamp_utc, TIMESTAMP '1970-01-01') AS bucket,
  COUNT(*) AS requests,
  100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_request_events
WHERE timestamp_utc >= now() - INTERVAL '2 hours'
GROUP BY bucket
ORDER BY bucket;

No declare un incidente de un segmento de bajo volumen. Compare la tarifa con el volumen de solicitudes y el objetivo operativo de ese servicio.

Alcance de rutas afectadas y emisiones

Una vez que la hora de inicio esté clara, conserve las dimensiones que puedan explicar el cambio. Agrupe por ruta y lanzamiento, mantenga un umbral de volumen mínimo y clasifique por solicitudes fallidas y por tasa.

SELECT
  route_template,
  release,
  COUNT(*) AS requests,
  SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) AS failed_requests,
  100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_request_events
WHERE timestamp_utc >= now() - INTERVAL '30 minutes'
GROUP BY route_template, release
HAVING COUNT(*) >= 20
ORDER BY failed_requests DESC, error_rate_pct DESC;

Repita la consulta con error_type, dependencia, región o un identificador de cuenta seguro para la privacidad solo cuando esa dimensión pueda cambiar la respuesta. Evite cuerpos de solicitud sin formato, encabezados de autorización, correos electrónicos y textos de excepción de formato libre.

Construir y preservar la línea de tiempo

Registre cada hipótesis, consulta, ventana de tiempo, resultado y acción en el registro de incidentes. Guarde las consultas más útiles junto al panel para que un segundo interviniente pueda reproducir el alcance. Marque las implementaciones, los cambios en los indicadores de funciones, los errores de dependencia y las acciones de recuperación con sus marcas de tiempo UTC exactas.

Utilice Receta de tasa de error API para clasificar las rutas afectadas, liberar receta de regresión para comparar compilaciones y receta de quema de presupuesto de error para conectar el incidente con un objetivo de disponibilidad. Cuando los socorristas necesiten un contrato explícito de impacto en el cliente, comience con el esquema del evento incident_impact_observed.

Verificar recuperación

Una reversión o un cambio de configuración no es una recuperación en sí misma. Espere a que se completen los depósitos, verifique que la tasa de error y la latencia hayan regresado a sus rangos esperados y verifique que el volumen de tráfico no haya desaparecido. Continúe observando una ventana el tiempo suficiente para cubrir los reintentos retrasados ​​y el trabajo en segundo plano.

Después del incidente, convierta la consulta de detección validada en un panel o alerta, documente su volumen mínimo y su propiedad, y actualice el contrato del evento si los socorristas carecían de un campo seguro necesario para aislar el impacto. El guía de solución de problemas de alerta explica cómo probar la ruta de notificación resultante sin crear ruido.