DevOps desde Cero: Respuesta a Incidentes y On-Call

Introduccion

Bienvenido al articulo diecinueve de la serie DevOps from Zero to Hero. En los articulos anteriores configuramos observabilidad con Prometheus y Grafana, construimos dashboards, configuramos alertas y desplegamos pipelines completos de CI/CD. Todo esta monitoreado y automatizado. Pero aca viene la pregunta que nadie quiere hacer: que pasa a las 3 de la manana cuando una alerta se dispara y tu API esta caida?

De eso se trata la respuesta a incidentes. Es el lado humano de la confiabilidad. Podes tener el mejor monitoreo del mundo, pero si nadie sabe que hacer cuando suena una alerta, no importa. En este articulo vamos a cubrir los fundamentos: que son los incidentes, como clasificarlos, como funcionan las rotaciones de on-call, como escribir runbooks que realmente ayuden, y como aprender de las fallas sin culpar a nadie.

Esta es una introduccion para principiantes. Si queres ir mas profundo en temas como incident commanders, practicas especificas de SRE, postmortems como codigo, y automatizacion avanzada de on-call, mira el articulo de SRE Incident Management de la serie de SRE. Ese articulo asume que ya entendes los fundamentos que cubrimos aca.

Arranquemos.

Que es un incidente?

Un incidente es cualquier evento no planificado que interrumpe o degrada un servicio para tus usuarios. No todo bug es un incidente. Un error de tipeo en un footer es un bug. Que el procesamiento de pagos este caido para 500 usuarios es un incidente. La distincion clave es el impacto en los usuarios.

La mayoria de los equipos clasifican los incidentes por niveles de severidad. Las definiciones exactas varian entre organizaciones, pero aca tenes un framework comun:

• SEV1 (Critico): Caida completa del servicio o perdida de datos. Todos o la mayoria de los usuarios estan afectados. Ejemplo: toda la API esta devolviendo errores 500, la base de datos es inalcanzable, o los datos de los clientes se corrompieron. Esto requiere todas las manos a la obra, inmediatamente.
• SEV2 (Mayor): Degradacion significativa pero el servicio funciona parcialmente. Ejemplo: los tiempos de respuesta son 10 veces mas lentos de lo normal, una funcionalidad clave como el checkout esta rota, o el 30% de las requests estan fallando. Esto necesita atencion inmediata del ingeniero de on-call.
• SEV3 (Menor): Un problema notable que afecta a un grupo chico de usuarios o una funcionalidad no critica. Ejemplo: las sugerencias de busqueda no cargan, un widget del dashboard muestra datos desactualizados, o las subidas de imagenes estan lentas. Esto se deberia resolver en horario laboral.
• SEV4 (Bajo): Un problema cosmetico o una molestia menor con impacto minimo en los usuarios. Ejemplo: un tooltip tiene el texto equivocado, un job de background no critico esta reintentando mas de lo usual, o un panel de monitoreo esta roto. Esto va al backlog normal.

El nivel de severidad determina todo lo demas: a quien se le manda la alerta, que tan rapido tenes que responder, si necesitas actualizar la status page, y cuanto del equipo se involucra. Clasificar bien es importante porque sobre-escalar quema a la gente y sub-escalar deja que los problemas crezcan.

El ciclo de vida del incidente

Todo incidente, sin importar la severidad, sigue el mismo ciclo de vida basico. Entender estas fases te ayuda a mantenerte organizado cuando las cosas estan estresantes.

  Detectar ──> Responder ──> Mitigar ──> Resolver ──> Aprender
     │             │            │            │            │
     │             │            │            │            │
  Las alertas   Avisar al    Parar la    Arreglar     Hacer un
  se disparan   on-call      hemorragia  la causa     postmortem
                                         raiz

Veamos cada fase:

1. Detectar

Algo te dice que hay un problema. Idealmente, tu monitoreo lo detecta antes que los usuarios. En el articulo quince configuramos alertas de Prometheus que se disparan cuando las tasas de error o la latencia superan los umbrales. Esas alertas son tu primera linea de deteccion. Otras fuentes incluyen fallas en health checks, reportes de usuarios, y smoke tests automatizados de tu pipeline de CI/CD.

El objetivo es simple: enterarte de los problemas antes de que tus usuarios los tuiteen.

2. Responder

La alerta llega al ingeniero de on-call a traves de una herramienta como PagerDuty o OpsGenie. El ingeniero de on-call reconoce la alerta (para que el sistema sepa que alguien la esta viendo), evalua la severidad, y decide si necesita sumar mas gente. Para un SEV1, podria iniciar un war room inmediatamente. Para un SEV3, podria simplemente abrir un ticket e investigar en horario normal.

3. Mitigar

Esta es la fase mas importante y la que mas confunde a los principiantes. Mitigar no se trata de encontrar la causa raiz. Se trata de detener el impacto en los usuarios lo mas rapido posible. Si tu API esta lenta porque se desplegó un mal deploy, primero haces rollback e investigas despues. Si una base de datos esta sobrecargada, la escalas o redirigas el trafico. Arregla lo suficiente para parar el dolor, despues averiguas por que paso.

Acciones de mitigacion comunes incluyen:

• Rollback: Revertir el ultimo despliegue si el problema empezo despues de un deploy
• Reiniciar: A veces un simple reinicio de pod limpia un proceso trabado
• Escalar verticalmente: Agregar mas replicas o aumentar los limites de recursos
• Feature flag: Deshabilitar una funcionalidad rota sin hacer rollback de todo
• Desviar trafico: Redirigir usuarios a una region o instancia saludable

4. Resolver

Una vez que los usuarios ya no estan afectados, podes tomarte el tiempo para encontrar y arreglar la causa raiz real. Tal vez el despliegue estaba bien pero expuso un bug latente activado por un patron de datos especifico. Tal vez la base de datos necesita un indice. Tal vez la logica de reintentos esta creando un efecto de estampida. Aca es donde haces el trabajo de ingenieria de verdad.

5. Aprender

Despues de que el incidente se resuelve, haces un postmortem. Lo vamos a cubrir en detalle mas adelante en el articulo, pero la version corta es: documentas que paso, construis una linea de tiempo, identificas la causa raiz, y creas items de accion para prevenir que vuelva a pasar. Sin culpa. Solo aprendizaje.

Conceptos basicos de on-call

On-call significa que sos la persona designada que responde cuando las alertas se disparan fuera del horario laboral (y muchas veces durante el horario tambien). Si nunca estuviste de on-call, la idea puede intimidar. Vamos a desglosarlo.

Que significa realmente estar de on-call?

Cuando estas de on-call, llevas un celular (o tenes una laptop cerca) y te comprometes a responder a las alertas dentro de una ventana de tiempo definida, generalmente 5 a 15 minutos para alertas criticas. No necesitas estar sentado frente a la computadora mirando dashboards. Podes ir a cenar, ver una pelicula, o dormir. Pero necesitas estar localizable y poder empezar a investigar dentro del tiempo de respuesta.

Calendarios de rotacion

Nadie deberia estar de on-call todo el tiempo. Los equipos configuran rotaciones donde la responsabilidad de on-call pasa de persona a persona en un calendario regular. Los patrones comunes incluyen:

• Rotacion semanal: La persona A esta de on-call de lunes a lunes, luego la persona B toma el relevo. Simple y predecible. Funciona bien para equipos de 4 o mas.
• Rotacion diaria: Los turnos de on-call cambian cada dia. Menos carga por turno pero mas traspasos. Bueno para equipos que quieren distribuir la carga de manera uniforme.
• Follow-the-sun: Si tu equipo abarca zonas horarias, cada region cubre su horario diurno. Nadie se despierta a las 3am. Es el sueno, pero requiere un equipo distribuido globalmente.
• Primario y secundario: Dos personas estan de on-call al mismo tiempo. El primario recibe la alerta primero. Si no responde dentro de la ventana de escalacion (digamos 10 minutos), el secundario recibe la alerta. Esto proporciona una red de seguridad.

Compensacion

Estar de on-call es trabajo. Las buenas organizaciones lo compensan. Esto puede tomar diferentes formas: pago extra por turnos de on-call, tiempo libre despues de una semana intensa de on-call, o un estipendio fijo por turno. El enfoque especifico varia, pero el principio es claro: si le estas pidiendo a alguien que este disponible fuera del horario normal, deberias reconocer y compensar ese tiempo. Los equipos que no compensan el on-call eventualmente pierden a sus mejores ingenieros.

Procedimientos de traspaso

Cuando tu turno de on-call termina y alguien mas toma el relevo, deberias hacer un traspaso adecuado. Esto significa resumir cualquier problema en curso, alertas raras que notaste, o cualquier cosa que la siguiente persona deberia saber. Un mensaje rapido en Slack o un documento compartido funciona. Lo peor es heredar un turno de on-call sin contexto sobre lo que estuvo pasando.

Herramientas de on-call

Necesitas una herramienta que reciba alertas de tu sistema de monitoreo y las enrute a la persona correcta en el momento correcto a traves del canal correcto (llamada telefonica, SMS, notificacion push, Slack). Aca estan las opciones mas comunes:

• PagerDuty: La plataforma de gestion de incidentes mas establecida. Maneja enrutamiento de alertas, politicas de escalacion, calendarios de on-call, y seguimiento de incidentes. Se integra con todo: Prometheus, Grafana, AWS CloudWatch, Datadog, lo que se te ocurra. Es el estandar de la industria pero tambien es la opcion mas cara.
• OpsGenie (de Atlassian): Similar a PagerDuty en funcionalidades, con integraciones fuertes con el ecosistema de Atlassian (Jira, Confluence, Statuspage). Una opcion solida si tu equipo ya usa herramientas de Atlassian. El precio es mas accesible que PagerDuty.
• Grafana OnCall: Una opcion open-source que se integra nativamente con Grafana. Si ya usas el stack de Grafana para observabilidad (como configuramos en el articulo quince), es una opcion natural. Podes auto-hostearlo o usar la version gestionada de Grafana Cloud. Maneja calendarios, escalaciones y enrutamiento, y es gratis para auto-hosting.

Las tres herramientas siguen el mismo flujo basico:

Alerta de Prometheus
    │
    ▼
Alertmanager ──> Webhook ──> PagerDuty / OpsGenie / Grafana OnCall
                                │
                                ▼
                          Calendario de on-call
                                │
                                ▼
                         Avisar al ingeniero de on-call
                         (telefono, SMS, push, Slack)
                                │
                    ┌───────────┴───────────┐
                    │                       │
              Reconocida              No reconocida
              dentro del SLA          dentro de la ventana de escalacion
                    │                       │
                    ▼                       ▼
              El ingeniero            Avisar al secundario /
              trabaja el              escalar al manager
              incidente

Configurando alertas hacia herramientas de on-call

En el articulo quince configuramos alertas de Prometheus usando recursos PrometheusRule. Esas alertas van al Alertmanager, que es parte del kube-prometheus-stack. Ahora necesitamos conectar Alertmanager con una herramienta de on-call para que las alertas realmente lleguen a un humano.

Aca tenes como configurar Alertmanager para enviar alertas criticas a PagerDuty y alertas no criticas a un canal de Slack:

# alertmanager-config.yaml
apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-config
  namespace: monitoring
stringData:
  alertmanager.yaml: |
    global:
      resolve_timeout: 5m

    route:
      receiver: slack-default
      group_by: [alertname, namespace]
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h

      routes:
        # Alertas criticas van a PagerDuty
        - receiver: pagerduty-critical
          match:
            severity: critical
          continue: false

        # Alertas de warning van solo a Slack
        - receiver: slack-warnings
          match:
            severity: warning
          continue: false

    receivers:
      - name: slack-default
        slack_configs:
          - api_url: "https://hooks.slack.com/services/TU/SLACK/WEBHOOK"
            channel: "#alertas"
            title: '{{ .GroupLabels.alertname }}'
            text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'

      - name: pagerduty-critical
        pagerduty_configs:
          - routing_key: "TU_CLAVE_DE_INTEGRACION_PAGERDUTY"
            severity: critical
            description: '{{ .GroupLabels.alertname }}'
            details:
              namespace: '{{ .GroupLabels.namespace }}'
              summary: '{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}'

      - name: slack-warnings
        slack_configs:
          - api_url: "https://hooks.slack.com/services/TU/SLACK/WEBHOOK"
            channel: "#alertas-baja-prioridad"
            title: '{{ .GroupLabels.alertname }}'
            text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'

Para OpsGenie, reemplazarias el pagerduty_configs con:

      - name: opsgenie-critical
        opsgenie_configs:
          - api_key: "TU_API_KEY_DE_OPSGENIE"
            message: '{{ .GroupLabels.alertname }}'
            priority: P1
            description: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'

Para Grafana OnCall, tipicamente usas un receptor webhook que apunta a tu instancia de Grafana OnCall:

      - name: grafana-oncall
        webhook_configs:
          - url: "https://oncall.tu-grafana.com/integrations/v1/alertmanager/TU_ID/"
            send_resolved: true

El concepto clave es el enrutamiento. No toda alerta deberia despertar a alguien. Enruta por severidad: alertas criticas paginan al on-call, warnings van a Slack, y alertas informativas van a un canal de baja prioridad. Esto es fundamental para evitar la fatiga de alertas.

Fatiga de alertas

La fatiga de alertas es el enemigo numero uno de los programas de on-call. Pasa cuando los ingenieros reciben tantas alertas que empiezan a ignorarlas. Cuando te estan paginando 20 veces por noche, dejas de tomarte las alertas en serio. Y cuando dejas de tomar las alertas en serio, la unica caida real que importa se pierde en el ruido.

Aca va la verdad dura: demasiadas alertas es peor que muy pocas. Con muy pocas alertas, tal vez te pierdas algo, pero al menos cuando una alerta se dispara, la gente presta atencion. Con demasiadas alertas, la gente se desconecta completamente, y te perdes todo.

Signos de fatiga de alertas:

• Alta tasa de reconocimiento, baja tasa de accion: La gente hace clic en “reconocer” solo para silenciar la alerta, sin investigar realmente.
• Alertas duplicadas: El mismo problema subyacente dispara cinco alertas diferentes, inundando al on-call con ruido.
• Alertas que parpadean: Una alerta se dispara, se resuelve, se dispara, se resuelve, todo en minutos. Cada ciclo genera una paginacion.
• Alertas de bajo valor: Alertas por cosas que no requieren accion humana. “Uso de disco al 70%” cuando auto-escalas al 80% es ruido, no senal.
• Paginaciones fuera de horario por temas no urgentes: Que te despierten por un SEV4 que podria esperar hasta manana.

Como combatir la fatiga de alertas:

• Alertar sobre sintomas, no causas: Paginar cuando los usuarios estan afectados (alta tasa de error, respuestas lentas), no cuando las metricas de infraestructura suben (CPU al 80%). Cubrimos esto en el articulo de observabilidad.
• Establecer umbrales significativos: No pongas una alerta de latencia a 200ms si tu p99 normalmente esta en 180ms. Ponela en un nivel que indique un problema real, como 2 veces tu p99 normal.
• Usar enrutamiento basado en severidad: Solo paginar al on-call por alertas criticas. Todo lo demas va a Slack o a una cola de tickets.
• Agrupar alertas relacionadas: Configurar el group_by de Alertmanager para combinar alertas relacionadas en una sola notificacion en vez de cinco paginaciones separadas.
• Agregar reglas de inhibicion: Si todo el cluster esta caido, no necesitas alertas individuales por cada servicio. Una regla de inhibicion suprime alertas hijas cuando una alerta padre esta activa.
• Revisar alertas regularmente: Una vez al mes, revisa todas las alertas que se dispararon. Elimina las que nunca llevaron a una accion. Ajusta los umbrales de las que se disparan demasiado seguido. Esto es mantenimiento continuo, no una tarea que se hace una sola vez.

Un buen benchmark: el ingeniero de on-call no deberia recibir mas de dos paginaciones por turno de on-call en promedio. Si tu equipo esta consistentemente por encima de eso, tenes un problema de ajuste de alertas, no un problema de confiabilidad.

Runbooks

Un runbook es un procedimiento documentado para manejar un tipo especifico de incidente. Cuando una alerta se dispara y estas medio dormido a las 3am, no queres descubrir los pasos de debugging desde cero. Queres una guia clara, paso a paso, que te diga exactamente que revisar y que hacer.

Que hace un buen runbook:

• Esta enlazado desde la alerta: La anotacion de la alerta incluye una URL al runbook. Un clic desde la paginacion a las instrucciones.
• Empieza con chequeos rapidos: Los primeros pasos deberian ayudarte a evaluar la severidad y el alcance en menos de dos minutos.
• Tiene comandos concretos: No “revisar la base de datos” sino “ejecuta esta query especifica y compara el resultado con este umbral.”
• Cubre mitigacion primero, causa raiz despues: Decile al ingeniero como parar la hemorragia antes de pedirle que diagnostique.
• Se mantiene actualizado: Un runbook desactualizado es peor que no tener runbook porque da falsa confianza. Revisa los runbooks despues de cada incidente que los use.

Aca tenes un template que podes usar para cualquier runbook:

# Runbook: [Nombre de la alerta]

## Resumen
- **Alerta**: [Nombre de la alerta que enlaza aca]
- **Severidad**: [SEV1/SEV2/SEV3]
- **Servicio**: [Que servicio esta afectado]
- **Ultima actualizacion**: [Fecha]
- **Responsable**: [Equipo o persona responsable de este runbook]

## Evaluacion rapida (hace esto primero, en menos de 2 minutos)
1. Revisa [link al dashboard] para el estado actual
2. Ejecuta: `[comando especifico]` para confirmar el problema
3. Determina el alcance: son todos los usuarios, un subconjunto, o un solo endpoint?

## Pasos de mitigacion (para la hemorragia)
1. Si esto empezo despues de un deploy reciente, rollback:
   `kubectl rollout undo deployment/[servicio] -n [namespace]`
2. Si el problema es de carga, escalar:
   `kubectl scale deployment/[servicio] --replicas=[N] -n [namespace]`
3. [Cualquier otro arreglo rapido especifico de esta alerta]

## Diagnostico (encontrar la causa raiz)
1. Revisar logs: `kubectl logs -l app=[servicio] -n [namespace] --tail=100`
2. Revisar metricas: [query PromQL especifica]
3. Revisar cambios recientes: [link al historial de deploys o git log]

## Escalacion
- Si no podes mitigar en 30 minutos, escalar a [equipo/persona]
- Para perdida de datos o problemas de seguridad, paginar inmediatamente a [equipo/persona]

## Incidentes anteriores
- [Fecha]: [Descripcion breve y link al postmortem]

La parte mas importante de este template es la seccion de “Evaluacion rapida”. Es lo que el ingeniero de on-call lee primero, con los ojos medio cerrados tratando de averiguar si es un problema real o una falsa alarma.

Ejemplo practico: runbook de tiempo de respuesta de la API

Escribamos un runbook real para una de las alertas mas comunes: tiempo de respuesta de la API superando los 2 segundos. Esto se conecta directamente con las alertas de Prometheus que configuramos en el articulo quince.

Primero, la regla de alerta que dispara esto:

# prometheus-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: api-latency-alerts
  namespace: monitoring
spec:
  groups:
    - name: api-latency
      rules:
        - alert: APIHighLatency
          expr: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_seconds_bucket{service="task-api"}[5m]))
              by (le)
            ) > 2
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "La latencia p99 de la API esta por encima de 2 segundos"
            description: "La latencia p99 del task-api estuvo por encima de 2s durante 5 minutos."
            runbook_url: "https://wiki.example.com/runbooks/api-high-latency"

Fijate la anotacion runbook_url. Cuando esta alerta se dispara y llega a PagerDuty o OpsGenie, el link al runbook se incluye en la notificacion. El ingeniero de on-call puede hacer clic inmediatamente.

Ahora el runbook en si:

# Runbook: APIHighLatency

## Resumen
- **Alerta**: APIHighLatency
- **Severidad**: SEV2 (se convierte en SEV1 si la latencia supera 10s o la tasa de error sube de 5%)
- **Servicio**: task-api
- **Ultima actualizacion**: 2026-06-14
- **Responsable**: Equipo de plataforma

## Evaluacion rapida (menos de 2 minutos)
1. Abrir el dashboard de la API: https://grafana.example.com/d/task-api
2. Revisar la latencia p99 actual. Esta por encima de 2s? Cuanto por encima?
3. Revisar si la tasa de error tambien aumento (indica un problema mas profundo)
4. Revisar si el problema esta aislado a un endpoint o todos:
   Query: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

## Pasos de mitigacion
### Si la latencia empezo despues de un deploy reciente:
1. Revisar la hora del ultimo deploy:
   kubectl rollout history deployment/task-api -n production
2. Si el timing coincide, rollback:
   kubectl rollout undo deployment/task-api -n production
3. Verificar que la latencia se esta recuperando en el dashboard

### Si la latencia es causada por trafico alto:
1. Revisar la cantidad actual de replicas y uso de CPU:
   kubectl top pods -l app=task-api -n production
2. Escalar si las replicas estan al limite de recursos:
   kubectl scale deployment/task-api --replicas=6 -n production
3. Verificar que los nuevos pods estan saludables:
   kubectl get pods -l app=task-api -n production

### Si la latencia es causada por queries lentas a la base de datos:
1. Revisar uso del connection pool de la base de datos:
   Query: pg_stat_activity_count{datname="taskapi"}
2. Revisar queries de larga duracion:
   SELECT pid, now() - pg_stat_activity.query_start AS duration, query
   FROM pg_stat_activity
   WHERE state != 'idle' ORDER BY duration DESC LIMIT 10;
3. Si una sola query esta bloqueando, considerar cancelarla:
   SELECT pg_cancel_backend(<pid>);

## Diagnostico
1. Revisar logs buscando patrones de requests lentas:
   kubectl logs -l app=task-api -n production --tail=200 | grep -i "slow\|timeout"
2. Revisar traces en Jaeger/Tempo para requests de alta latencia
3. Comparar con la linea base normal: el p99 tipico es 200-400ms
4. Revisar PRs recientes mergeados a main buscando cambios en queries o endpoints nuevos

## Escalacion
- Si no se mitiga en 30 minutos: paginar al tech lead del equipo de backend
- Si esta relacionado con la base de datos: paginar al DBA o equipo de infraestructura
- Si la latencia supera 10s o la tasa de error > 5%: escalar a SEV1

## Incidentes anteriores
- 2026-05-20: Queries lentas despues de migracion sin indice. Se arreglo con CREATE INDEX.
- 2026-04-15: Memory leak causaba pausas de GC. Se arreglo actualizando la version de Node.js.

Este runbook es especifico, accionable, y organizado por probabilidad. El ingeniero de on-call no necesita adivinar. Sigue los pasos, revisa los datos relevantes, y toma accion basandose en lo que encuentra.

Comunicacion durante incidentes

Cuando algo esta roto, la gente quiere saber. Tus usuarios, tu equipo de soporte, tu liderazgo. Buena comunicacion durante incidentes reduce el panico, construye confianza, y te deja enfocarte en arreglar el problema en vez de responder mensajes de “ya esta arreglado?” de doce personas diferentes.

Status pages

Una status page publica (o interna) es la unica fuente de verdad durante un incidente. Herramientas como Statuspage (de Atlassian), Cachet (open source), o incluso una pagina estatica simple les dan a tus usuarios un lugar donde revisar en vez de inundar tus canales de soporte.

Una buena actualizacion de estado incluye:

• Que esta afectado: “La API de checkout esta experimentando tiempos de respuesta lentos”
• Estado actual: “Investigando / Identificado / Monitoreando / Resuelto”
• Impacto: “Algunos usuarios pueden experimentar demoras al completar compras”
• Proxima actualizacion: “Vamos a dar una actualizacion en 30 minutos o cuando tengamos mas informacion”

Mantene las actualizaciones facticas y concisas. No especules sobre las causas raiz en las actualizaciones publicas. Deci “identificamos el problema y estamos implementando una solucion” en vez de “creemos que el indice de la base de datos se corrompio.”

Comunicacion interna

Para tu equipo y stakeholders, necesitas mas detalle. La mayoria de los equipos usan un canal dedicado de Slack por incidente (por ejemplo, #inc-2026-06-14-api-latency). Esto mantiene la conversacion enfocada y crea un registro escrito que podes referenciar en el postmortem.

En el canal del incidente, publica actualizaciones regulares incluso si no hay novedades. “Todavia investigando, sin hallazgos nuevos” es mejor que el silencio. El silencio pone nerviosa a la gente.

War rooms

Para incidentes SEV1, los equipos suelen abrir una videollamada (a veces llamada war room o bridge call) donde todos los que estan trabajando en el incidente pueden comunicarse en tiempo real. Las reglas clave para war rooms:

• Mantenerlo enfocado: Solo las personas que estan trabajando activamente en el incidente deberian estar en la llamada. Los observadores pueden seguir el canal de Slack.
• Designar un responsable de comunicacion: Una persona maneja todas las actualizaciones externas para que los ingenieros puedan enfocarse en arreglar las cosas.
• Documentar decisiones: Alguien deberia estar anotando que esta pasando, que se intento, y cual es el plan actual. Esto se convierte en la linea de tiempo de tu postmortem.

Postmortems sin culpa

Un postmortem (tambien llamado retrospectiva o revision de incidente) es un analisis estructurado de lo que paso durante un incidente. La palabra “sin culpa” es la parte mas importante. Un postmortem sin culpa se enfoca en sistemas y procesos, no en individuos.

Por que importa que sea sin culpa

Si la gente tiene miedo de que la castiguen por causar un incidente, van a esconder informacion, evitar tomar riesgos, y no reportar situaciones que casi fueron incidentes. La culpa crea una cultura de miedo y silencio. La ausencia de culpa crea una cultura de transparencia y aprendizaje. La persona que hizo el cambio que causo la caida es muchas veces la que mejor entiende el sistema y puede ayudar a prevenir que vuelva a pasar. Queres que hablen abiertamente, no que se defiendan.

Esto no significa ignorar la responsabilidad. Significa reconocer que la mayoria de los incidentes son causados por fallas del sistema (herramientas malas, falta de guardrails, procesos poco claros), no porque la gente fue descuidada.

Template de postmortem

# Postmortem del incidente: [Titulo]

## Resumen
- **Fecha**: [Cuando ocurrio el incidente]
- **Duracion**: [Cuanto duro]
- **Severidad**: [Nivel SEV]
- **Impacto**: [Quien fue afectado y como]
- **Autores**: [Quien escribio este postmortem]

## Linea de tiempo (todos los horarios en UTC)
- 14:32 - Se dispara alerta de monitoreo: APIHighLatency
- 14:35 - El ingeniero de on-call reconoce la alerta
- 14:38 - El ingeniero revisa el dashboard, confirma latencia p99 en 4.2s
- 14:42 - Identifica que el pico de latencia empezo a las 14:25, correlacionando con el deploy abc123
- 14:45 - Inicia rollback del despliegue
- 14:48 - Rollback completo, la latencia empieza a recuperarse
- 14:55 - Latencia volvio a la normalidad (p99 en 280ms)
- 14:58 - Incidente marcado como resuelto

## Causa raiz
Una migracion de base de datos en el commit abc123 agrego una nueva columna a la tabla de orders
sin un indice. El endpoint /orders hace una query de filtro sobre esta columna, lo que causo un
full table scan en cada request. Bajo trafico normal, esto aumento la latencia p99 de 250ms a mas
de 4 segundos.

## Que salio bien
- La alerta se disparo dentro de los 7 minutos del deploy
- El ingeniero de on-call respondio en 3 minutos
- El rollback fue rapido y efectivo (menos de 5 minutos desde la decision hasta la recuperacion)
- La status page se actualizo en 10 minutos

## Que salio mal
- La migracion no incluyo un indice para la nueva columna
- No se hizo load testing contra la base de datos de staging con volumenes de datos realistas
- La base de staging tiene 1.000 filas; produccion tiene 2 millones, asi que la diferencia de
  performance no era visible en staging

## Items de accion
- [ ] Agregar indice a la nueva columna (responsable: equipo de backend, fecha: 2026-06-16)
- [ ] Agregar un chequeo de CI que marque migraciones sin indices en columnas consultadas (responsable: equipo de plataforma, fecha: 2026-06-30)
- [ ] Popular la base de staging con volumenes de datos realistas (responsable: equipo de plataforma, fecha: 2026-07-15)
- [ ] Agregar un chequeo de latencia a los smoke tests post-deploy (responsable: equipo de plataforma, fecha: 2026-06-30)

Fijate en la estructura. La linea de tiempo es factica y precisa. La causa raiz es tecnica, no personal. “Que salio bien” es tan importante como “que salio mal” porque refuerza las cosas que tu equipo deberia seguir haciendo. Y los items de accion son especificos, asignados, y tienen fechas limite.

Llevando adelante la reunion de postmortem

Agenda el postmortem dentro de las 48 horas del incidente mientras los recuerdos estan frescos. Que dure 30-60 minutos. El facilitador (generalmente alguien que no estuvo directamente involucrado en el incidente) recorre la linea de tiempo y hace preguntas:

• “Que informacion tenias en ese momento?”
• “Que intentaste y por que?”
• “Que te hubiera ayudado a resolver esto mas rapido?”
• “Hubo senales que nos perdimos que podrian haber detectado esto antes?”

El objetivo es entender el sistema, no juzgar decisiones tomadas bajo presion. La gente toma decisiones razonables basandose en la informacion que tiene en el momento. Si el sistema hizo facil desplegar una migracion sin indice, el arreglo es un mejor sistema, no un sermon.

Construyendo una cultura de on-call saludable

El on-call no tiene que ser una tortura. Vi equipos donde el on-call es temido y equipos donde es manejable e incluso gratificante. La diferencia se reduce a cultura e inversion.

Expectativas razonables

• Frecuencia: Nadie deberia estar de on-call mas de una semana de cada cuatro. Si tu equipo es demasiado chico para esa rotacion, necesitas contratar, compartir la rotacion con otro equipo, o reducir el alcance de tu on-call.
• Carga de trabajo: El ingeniero de on-call deberia poder hacer su trabajo regular durante turnos tranquilos de on-call. Si el on-call es tan ocupado que no pueden escribir codigo durante el dia, tus alertas necesitan ajuste.
• Sueno: Que te paginen una vez por noche es aceptable ocasionalmente. Que te paginen tres o cuatro veces cada noche es un problema sistemico. Registra las paginaciones fuera de horario como una metrica y establece un objetivo para reducirlas.

Practicar incidentes

El peor momento para aprender respuesta a incidentes es durante un incidente real. Practica con game days o ejercicios de mesa. Un game day es un ejercicio planificado donde intencionalmente rompes algo (de manera controlada) y practicas la respuesta. Un ejercicio de mesa es donde recorres un escenario de incidente verbalmente sin romper nada.

Ejemplo de escenario de mesa:

"Son las 2am de un martes. Te paginan por APIHighLatency.
 Revisas el dashboard y ves la latencia p99 en 8 segundos.
 La tasa de error esta en 12%. El ultimo deploy fue hace 6 horas.

 Que haces primero?
 Que revisas?
 A quien contactas?
 Como te comunicas con los stakeholders?"

Estos ejercicios construyen memoria muscular. Cuando un incidente real pasa, el ingeniero de on-call no esta pensando “que hago?” Sino “ya hice esto antes, voy a seguir el proceso.”

Calidad del traspaso

Un buen traspaso entre turnos de on-call incluye:

• Incidentes activos: Cualquier cosa que siga en curso o se haya resuelto recientemente
• Alertas recientes: Alertas que se dispararon y fueron manejadas, con contexto
• Problemas conocidos: Cosas que podrian paginarte pero que ya se estan trabajando
• Cambios en el entorno: Despliegues recientes, cambios de infraestructura, o ventanas de mantenimiento

Una llamada rapida de 15 minutos o un mensaje estructurado en Slack a la hora del traspaso previene mucha confusion.

Invertir en herramientas

Cada vez que alguien es paginado por algo que podria haberse automatizado, eso es una falla de herramientas. Registra tus incidentes y busca patrones. Si el mismo problema sigue pasando y el runbook siempre dice “reiniciar el pod”, automatiza el reinicio. Si una alerta particular siempre resulta ser un falso positivo, arregla la alerta. El on-call deberia ser para problemas que genuinamente necesitan un cerebro humano, no para tareas que un script podria manejar.

Temas avanzados

Cubrimos los fundamentos de la respuesta a incidentes en este articulo, pero hay mucho mas para explorar a medida que tu equipo y sistemas crecen:

• Rol de incident commander: Para incidentes SEV1, un incident commander dedicado coordina la respuesta, maneja la comunicacion, y toma decisiones sobre escalacion. Este rol es separado de los ingenieros haciendo el trabajo tecnico.
• Practicas de SRE: Error budgets, alertas basadas en SLOs, y reduccion de toil son conceptos avanzados que se construyen sobre todo lo que cubrimos aca.
• Postmortems como codigo: Templates de postmortem versionados, generacion automatizada de lineas de tiempo, y seguimiento de items de accion integrado en tu herramienta de gestion de proyectos.
• Ingenieria del caos: Inyectar fallas intencionalmente para probar tu proceso de respuesta a incidentes antes de que pasen incidentes reales.

Para una inmersion profunda en todos estos temas, mira el articulo de SRE Incident Management. Cubre workflows de incident commander, automatizacion de on-call con operadores de Kubernetes, templates de postmortem como codigo gestionados a traves de GitOps, y estrategias avanzadas de alertas.

Notas finales

La respuesta a incidentes no se trata solo de herramientas y procesos. Se trata de personas. Se trata de asegurarse de que la persona que es paginada a las 3am tenga lo que necesita para resolver el problema: alertas claras, buenos runbooks, el acceso correcto, y la confianza que viene de la practica.

En este articulo cubrimos que son los incidentes y como clasificarlos con niveles de severidad, las cinco fases del ciclo de vida del incidente, como funcionan las rotaciones de on-call y como hacerlas justas, configurar alertas desde Prometheus hasta PagerDuty o OpsGenie, por que la fatiga de alertas es peligrosa y como combatirla, como escribir runbooks que realmente ayuden, buenas practicas de comunicacion durante incidentes, postmortems sin culpa que impulsen mejoras, y construir una cultura donde el on-call sea sostenible.

Lo mas importante para llevarse es esto: inverti en tu proceso de respuesta a incidentes antes de necesitarlo. Escribi los runbooks, ajusta las alertas, practica los escenarios, y hace los postmortems. Cuando el incidente real pase, vas a estar listo.

En el proximo y ultimo articulo de la serie, vamos a juntar todo y ver que viene despues de dominar los fundamentos.

Espero que te haya resultado util y que lo hayas disfrutado, hasta la proxima!

Errata

Si encontras algun error o tenes alguna sugerencia, mandame un mensaje para que se corrija.

Tambien, podes revisar el codigo fuente y los cambios en las fuentes aca