Resumen

  • Una función que creaba un productor de Kafka por cada solicitud de API generó casi 4,2 millones de productores adicionales por hora en el pico, agotando el heap del broker y degradando las rutas de eventos, notificaciones, integraciones, API, móviles y comunicación de estado.
  • La primera respuesta restauró el servicio sin identificar y eliminar el desencadenante; una recurrencia el mismo día vinculó el tráfico anómalo de Kafka con la función y llevó a PagerDuty a revertir el código ofensivo.

Una plataforma de gestión de incidentes ocupa una posición inusual en la cadena de responsabilidad operativa. Sus clientes no la utilizan solo cuando las condiciones son normales. Dependen de ella en el momento en que otro sistema está fallando, cuando un evento retrasado, una notificación perdida o una actualización de estado poco fiable pueden distorsionar la respuesta a una emergencia separada. Eso no hace posible un servicio ininterrumpido. Hace que la asignación de control sea inusualmente importante. La pregunta relevante no es si PagerDuty podría prometer que Kafka nunca fallaría.

Es si la empresa controló las decisiones que crearon el fallo, las señales que retrasaron el diagnóstico, los mecanismos que ampliaron el impacto y la evidencia necesaria para demostrar que el mismo camino había sido cerrado.

El relato de PagerDuty sobre sus interrupciones del 28 de agosto de 2025 proporciona un caso concentrado. Una característica destinada a apoyar el análisis posterior del uso de claves de API provocó que se creara un nuevo productor de Kafka para cada solicitud de API. En el pico, PagerDuty dice que Kafka rastreaba casi 4,2 millones de productores adicionales por hora, 84 veces su número típico de nuevos productores.

La carga de metadatos aumentó la presión de memoria en los brokers de Kafka, llevó la recolección de basura de la Máquina Virtual Java a un estado de thrashing, agotó la memoria heap y cascó a través de un clúster que soportaba trabajo asíncrono en todo el servicio. El resultado visible no fue una interrupción limpia. Fue una mezcla de eventos entrantes rechazados, procesamiento retrasado, notificaciones retrasadas, errores de API, webhooks duplicados o retrasados, integraciones deterioradas y actualizaciones de estado que los respondedores redactaron pero que los clientes no podían ver.

La cronología importa porque la misma condición técnica apareció dos veces el mismo día. El primer incidente comenzó a las 03:53 UTC. PagerDuty estabilizó Kafka, recuperó los servicios dependientes, procesó el trabajo atrasado e informó operaciones normales a las 10:10 UTC. La compañía no identificó y eliminó el desencadenante de la función durante esa respuesta. Una recurrencia más pequeña comenzó a las 16:38 UTC. Los respondedores repitieron la mitigación anterior, encontraron el patrón de tráfico anómalo, revirtieron el código ofensivo y mitigaron el impacto al cliente en unos 50 minutos.

PagerDuty dice que todos los servicios se restauraron completamente a las 20:24 UTC. La primera recuperación, por lo tanto, restauró el servicio sin eliminar de manera concluyente la condición iniciadora. La segunda respuesta conectó los síntomas de infraestructura con el cambio de software.

Esa secuencia convierte un defecto de software en un registro de responsabilidad. La causa raíz, el evento desencadenante, las condiciones contribuyentes, el fallo de detección, el fallo de respuesta y el fallo de recuperación estaban relacionados, pero no eran idénticos. Tratarlos como una "interrupción de Kafka" indiferenciada oscurecería quién controlaba cada capa. También falsearía la evidencia pública. PagerDuty no identificó a Kafka como un producto defectuoso de terceros. Identificó un error lógico en su propio código de función y la forma en que ese código interactuó con la arquitectura de la empresa.

La distinción es central: la responsabilidad debe seguir el control sobre el mecanismo, no el nombre de tecnología más reconocible en la pila.

La evidencia es detallada, pero sigue siendo un relato de la empresa

La base factual para esta reconstrucción es la autopsia técnica de PagerDuty, publicada el 5 de septiembre de 2025. Es un registro operativo primario de la organización que ejecutaba el sistema afectado. Proporciona horas de inicio y restauración, el mecanismo de la característica, la ruta de diagnóstico de la primera respuesta, la razón por la que no se produjo ninguna reversión durante esa respuesta, la recurrencia y numerosas mediciones de impacto. Esos detalles permiten un análisis más preciso que una colección de quejas en redes sociales o un resumen de interrupción sin fuente.

La misma fuente tiene un límite inevitable. Una autopsia de empresa no es una auditoría independiente. Puede confirmar lo que PagerDuty representó públicamente, pero no puede por sí misma establecer la experiencia de cada cliente, cada decisión interna o cada pérdida posterior. La autopsia dice que PagerDuty retuvo eventos y datos previamente aceptados. Esa declaración no significa que cada evento intentado fuera aceptado: PagerDuty dice por separado que algunos eventos entrantes pueden haber sido rechazados, incluyendo respuestas 502 de la API de Eventos en el pico de impacto. Tampoco significa que una notificación retrasada no causara daño.

Significa la proposición más estrecha que la empresa hizo sobre los datos ya aceptados por la plataforma.

La evidencia se divide en cuatro clases. Los hechos confirmados son declaraciones en la autopsia, atribuidas a PagerDuty cuando la atribución importa. Las inferencias respaldadas por evidencia conectan esos hechos con responsabilidades de control, pero no pretenden revelar intenciones no documentadas. No hay una alegación disputada necesaria en el centro de este caso; el relato causal central proviene de la propia PagerDuty.

Las incógnitas siguen siendo desconocidas: la fuente no proporciona un libro de contabilidad de daños cliente por cliente, no prueba que todos los clientes o regiones se vieran afectados, no cuantifica las pérdidas comerciales independientes ni divulga el registro completo de aprobación interna y pruebas de la característica. Esos límites evitan que la gravedad se convierta en especulación.

Antes de las 03:53 UTC: una función de informes entró en una ruta crítica

PagerDuty describe a Kafka como la columna vertebral de su arquitectura asíncrona. Esa descripción establece el primer hecho de control importante. Kafka no era periférico al servicio. El trabajo dependiente de él incluía las rutas de procesamiento que conectaban los eventos entrantes con notificaciones, integraciones, webhooks, sistemas de chat, acciones móviles y otras capacidades. Un cambio que aumentaba la carga en esa columna vertebral llevaba por tanto un radio de explosión potencial diferente al de un cambio aislado en una interfaz de informes no crítica.

La nueva función estaba destinada a apoyar el análisis y la generación de informes sobre las tendencias de uso de las claves de API. PagerDuty esperaba que su volumen fuera aproximadamente comparable al uso de claves de API. En su cara, ese es un objetivo de producto razonable: registrar información de uso, enviarla a un tema de Kafka y analizarla más tarde sin detener la solicitud iniciadora. El problema de responsabilidad no surgió del objetivo. Surgió de la unidad de trabajo de la implementación. En lugar de reutilizar un productor para publicar mensajes, la función instanciaba un nuevo productor de Kafka para cada solicitud de API.

Esa distinción es fácil de comprimir en una frase y fácil de subestimar. Un productor no era meramente un objeto local transitorio sin efecto más allá de la solicitud que lo creó. Kafka tenía que rastrear metadatos asociados con cada productor. Repetir esa operación a escala de solicitudes de API transformó el tráfico de aplicación en presión de control y memoria dentro del clúster de colas de mensajes. El pico medido por PagerDuty —casi 4,2 millones de productores adicionales por hora— era 84 veces la tasa ordinaria de nuevos productores. La función, por lo tanto, no simplemente añadió el flujo esperado de mensajes de uso.

Cambió la población de identidades de productores que los brokers tenían que gestionar.

El hecho confirmado es el error lógico y el volumen de productores resultante. Una inferencia respaldada por evidencia sigue: la garantía centrada solo en el número de mensajes habría medido el riesgo equivocado. Una prueba podría observar que cada solicitud de API generaba un evento de uso esperado y aún así perder el costo de metadatos multiplicador creado por un productor por solicitud.

Del mismo modo, un despliegue gradual podría limitar el tráfico inmediato pero no exponer la relación causal si los revisores observaban las tasas de éxito de la aplicación sin observar la creación de productores, el heap del broker y el comportamiento de recolección de basura como indicadores vinculados.

La autopsia revela un despliegue por etapas del 1% el 21 de agosto al 5% y luego al 25% el 27 de agosto, seguido del 75% el 28 de agosto; no revela el conjunto de pruebas previas a la producción exacto, la cadena de aprobación o los umbrales de alerta. Sería infundado decir que no se realizaron pruebas o que un empleado nombrado ignoró un peligro conocido.

La conclusión más estrecha es defendible: los controles que existían no impidieron que un patrón de productor por solicitud llegara a una columna vertebral compartida de Kafka, y la imagen de monitoreo inicial no identificó rápidamente ese patrón como la fuente de la presión de memoria sistémica.

Esa es una condición contribuyente más que el evento desencadenante en sí. El código creó la capacidad de crecimiento anómalo de productores. El tráfico de API en vivo lo ejerció. Kafka acumuló metadatos. La presión de memoria del broker aumentó. La recolección de basura comenzó a consumir esfuerzo sin restaurar un margen estable. El agotamiento del heap movió entonces el problema de un comportamiento ineficiente a un fallo del servicio. Cada paso tenía una señal posible diferente. La responsabilidad depende en parte de si esas señales eran visibles juntas o separadas entre los equipos de aplicación e infraestructura.

03:53 UTC: el primer fallo parecía más pequeño de lo que era

PagerDuty marca las 03:53 UTC como el comienzo del primer incidente. Un fallo en uno de sus sistemas de colas de mensajes Kafka desencadenó problemas en cascada que interrumpieron o retrasaron el procesamiento de nuevos eventos entrantes para algunos clientes en las Regiones de Servicio de EE. UU. "Algunos clientes" y "Regiones de Servicio de EE. UU." son límites materiales. El registro no respalda una afirmación de que todos los clientes de PagerDuty en todo el mundo perdieran el servicio. Respalda una degradación grave de múltiples capacidades dentro del alcance que la empresa informó.

Las alertas tempranas sugerían un fallo de un broker y posiblemente un problema de hardware. Ese diagnóstico era lo suficientemente plausible como para dirigir la primera respuesta. Los ingenieros ampliaron el clúster y eliminaron un broker. Esas acciones abordaron el aparente componente fallido y aumentaron la capacidad. No eliminaron el comportamiento de la función que generaba continuamente nuevos productores. Cuando brokers adicionales se quedaron sin memoria, el incidente dejó de parecer un problema de un solo nodo. PagerDuty reconoció entonces un problema de software sistémico.

Este es el fallo de detección en su forma precisa. No fue un fallo en notar que algo iba mal; las alertas se dispararon y los respondedores actuaron. Fue un fallo de detección causal. La telemetría inicial presentaba un síntoma de infraestructura local más claramente que el comportamiento a nivel de aplicación que estaba llevando al clúster hacia el agotamiento. Un sistema de detección puede ser rápido en anunciar el dolor y aún así ser lento en identificar su fuente.

Para una columna vertebral asíncrona compartida, esa diferencia determina si la primera intervención elimina un componente fallido o detiene una carga de trabajo que agotará también la capacidad de reemplazo.

Llamar irrazonable a la interpretación temprana iría más allá de la evidencia. Los fallos de hardware y de broker son hipótesis ordinarias cuando un broker alerta. La cuestión de responsabilidad es si el diseño de observabilidad hizo que una alternativa sistémica estuviera disponible lo suficientemente pronto. La creación de productores que se elevaba a 84 veces la tasa típica de nuevos productores era una señal distintiva. El consumo de heap del broker y el thrashing de recolección de basura eran señales relacionadas. Un despliegue de funciones era una señal de cambio relevante.

La fuente no dice cuándo cada una se volvió visible para los respondedores o si una consola las correlacionó. Muestra que la relación no se estableció antes de que múltiples brokers sufrieran agotamiento de memoria.

Ese retraso amplió el radio de explosión efectivo. La expansión del clúster añadió espacio, pero el patrón de creación anómalo podía consumir espacio adicional. Eliminar un broker eliminó un nodo sintomático, pero no el flujo de trabajo de metadatos. La respuesta se volvió efectiva solo después de que el equipo trató el evento como sistémico: PagerDuty duplicó el tamaño del heap, reinició el clúster, estabilizó Kafka y luego restauró los servicios que dependían de Kafka. Esos pasos abordaron la presión inmediata de recursos y permitieron que el trabajo en cola se moviera de nuevo.

La causa raíz no fue un heap insuficiente en el sentido ordinario. Más heap fue una mitigación. Si el mismo patrón erróneo de productor permanecía activo, la capacidad podría retrasar el agotamiento sin hacer que el diseño fuera sólido. Tampoco fue la causa raíz el backlog que apareció durante la restauración. El backlog fue una consecuencia del procesamiento deteriorado y una fuente de carga de recuperación posterior. La clasificación precisa importa porque de lo contrario una organización puede documentar una intervención exitosa de capacidad mientras deja el comportamiento de software iniciador en su lugar.

El impacto fue una cadena de fallos desiguales

Una plataforma de incidentes tiene al menos dos flujos relevantes. Debe recibir y procesar señales, y debe convertir esas señales en acciones útiles a través de notificaciones e integraciones. La primera interrupción de PagerDuty afectó a ambos. En el pico, algunos eventos entrantes pueden haber sido rechazados con respuestas 502 de la API de Eventos. Otros eventos fueron aceptados pero retrasados.

Las notificaciones salientes, los webhooks, las integraciones de chat incluyendo Slack y Microsoft Teams, las operaciones de la API REST, el reconocimiento y resolución móvil, y varias integraciones empresariales se vieron afectadas en diferentes proporciones y por diferentes duraciones.

La diferencia entre rechazo y retraso es operativamente importante. Un evento rechazado puede requerir que el sistema emisor reintente o puede desaparecer si ese sistema carece de una ruta de reintento fiable. Un evento retrasado permanece en una cola, pero puede llegar después del momento en que habría cambiado una decisión de respuesta. Un webhook o mensaje de chat duplicado puede hacer que los respondedores se pregunten si hay múltiples incidentes o si una transición de estado ocurrió dos veces. Un error de API puede impedir el reconocimiento o la actualización incluso mientras una notificación ya ha llegado a una persona.

Un solo porcentaje de "disponibilidad" ocultaría estas diferentes cargas.

PagerDuty afirma que alrededor del 14% de los eventos se retrasaron. El rechazo de eventos alcanzó un pico de aproximadamente el 95% durante 38 minutos. Esas cifras no deben fusionarse en una afirmación de que el 95% de todos los eventos se perdieron permanentemente. Miden condiciones diferentes. La empresa también informa que alrededor del 16% de los eventos de ingesta de correo electrónico se retrasaron y menos del 1% no se procesaron. Para eventos de cambio, el 6,5% fueron rechazados durante 55 minutos. Cada número está limitado por la categoría y la duración en la autopsia.

En la ruta de salida, alrededor del 23% de las notificaciones se retrasaron al menos cinco minutos durante 209 minutos. PagerDuty dice que no se descartó ninguna notificación por completo. Esa declaración es tranquilizadora en una dimensión y grave en otra. Un sistema de notificaciones puede eventualmente entregar cada mensaje y aún así fallar en un propósito sensible al tiempo. Cinco minutos no es un retraso abstracto cuando el mensaje está destinado a movilizar una respuesta. El registro público no establece lo que sucedió en el incidente de cada cliente individual, por lo que no puede apoyar una emergencia o pérdida financiera inventada.

Sí establece un período prolongado en el que casi una cuarta parte de las notificaciones, según la medición de PagerDuty, superaron un umbral de retraso de cinco minutos.

La API REST experimentó tasas de error aumentadas durante unos 150 minutos. PagerDuty informa que el 18,87% de las solicitudes de creación devolvieron respuestas 5xx durante 130 minutos y el 4,35% de las solicitudes de actualización devolvieron respuestas 5xx durante 190 minutos. Los flujos de trabajo móviles también se vieron afectados: el 6,06% de los usuarios no pudieron reconocer o resolver incidentes a través de la aplicación móvil. Estos fallos pueden interactuar.

Si una notificación se retrasa, una solicitud de reconocimiento falla y una integración reintenta más tarde, el registro del cliente de lo que los respondedores sabían y cuándo puede volverse menos fiable incluso si los datos subyacentes del incidente se conservan eventualmente.

PagerDuty también enumera eventos de integración retrasados o perdidos para Jira, ServiceNow, Salesforce y Zendesk durante unos 100 minutos. Los webhooks se retrasaron, perdieron o duplicaron durante unos 100 minutos. Los sistemas de chat experimentaron retrasos y mensajes duplicados. Estas no son conveniencias intercambiables. Los clientes a menudo incrustan tales salidas en la creación de tickets, escalada, propiedad y pistas de auditoría. La fuente de PagerDuty no mide la calidad de la reconciliación posterior de cada cliente.

Confirma que la plataforma entregó a esos clientes trabajo de recuperación: reintentar, verificar si hay lagunas, suprimir duplicados y determinar si un mensaje tardío reflejaba el estado actual.

La evidencia, por lo tanto, respalda una inferencia limitada. El costo de la interrupción no se limitó al tiempo en que una página web no estaba disponible. Transfirió incertidumbre a las operaciones del cliente. Cuanto más había automatizado un cliente en torno a las salidas de PagerDuty, más necesitaba distinguir los eventos aceptados de los rechazados, las notificaciones retrasadas de las actuales y los duplicados del nuevo estado. Esa inferencia no cuantifica una pérdida. Identifica dónde la responsabilidad por la semántica fiable importa en una dependencia vendida para la coordinación de incidentes.

Una página de estado falló en el momento en que el estado importaba

El primer incidente también interrumpió el proceso de comunicación externa de PagerDuty. La empresa dice que las actualizaciones se redactaron internamente pero no aparecieron públicamente en la página de estado. Se involucraron equipos de ingeniería adicionales y los respondedores utilizaron procedimientos de respaldo para añadir actualizaciones manualmente. PagerDuty registra actualizaciones de la página de estado retrasadas durante unos 100 minutos.

Este fue un fallo de respuesta separado de la causa raíz de Kafka. El error de la función no requería lógicamente que las comunicaciones públicas se retrasaran. El retraso surgió porque el proceso que convertía el conocimiento interno de incidentes en información de estado externa no se completó con éxito, y la ruta de respaldo requirió intervención manual. Se supone que una página de estado reduce la incertidumbre del cliente cuando el servicio primario está degradado.

Si la publicación depende de una ruta acoplada al entorno afectado —o de un proceso externo que no se verifica de forma independiente— los clientes pueden perder tanto el servicio como la explicación autorizada juntos.

La autopsia no proporciona los borradores internos, la dependencia exacta de publicación, la hora de cada actualización intentada, o el procedimiento manual completo. Sería especulación afirmar que una herramienta particular falló o que un equipo particular descuidó un deber. El límite confirmado es más estrecho: existían actualizaciones internas, la visualización pública no ocurrió a tiempo, se involucraron más ingenieros y se utilizaron procedimientos de respaldo. La lección respaldada por la evidencia es que la recuperación de la comunicación merece el mismo ensayo que la recuperación técnica.

Un mensaje redactado no tiene valor operativo para un cliente que no puede verlo.

El retraso también complica el diagnóstico del cliente. Cuando una plataforma de gestión de incidentes se comporta de manera inconsistente, los clientes deben determinar si sus propios sistemas monitorizados dejaron de emitir eventos, si una integración falló o si la plataforma está retrasada. Una señal de estado independiente y oportuna puede acotar esa búsqueda. Una actualización faltante empuja a cada cliente hacia pruebas locales, contactos de soporte o conjeturas. Esa duplicación del trabajo diagnóstico es una consecuencia predecible del fallo de comunicación, aunque la autopsia no la cuantifica.

La estabilización a las 10:10 UTC no fue la eliminación del desencadenante

PagerDuty dice que todos los servicios y capacidades del sistema volvieron a la normalidad a las 10:10 UTC. Alcanzar ese punto requirió estabilizar Kafka y restaurar los servicios que dependían de él. A medida que se reanudaba el procesamiento, los clientes podían recibir notificaciones y alertas retrasadas mientras PagerDuty trabajaba con los mensajes atrasados. Algunos podían recibir webhooks duplicados. La recuperación tenía por tanto una cola de procesamiento: la infraestructura podía ser estable mientras el trabajo antiguo continuaba emergiendo en los sistemas del cliente.

Esa cola es una condición de recuperación, no prueba de un nuevo fallo. Los mensajes en cola deben procesarse o descartarse deliberadamente bajo una política explícita. PagerDuty dice que los eventos y datos previamente aceptados no se perdieron, por lo que procesar el backlog era coherente con la preservación. Pero la preservación crea preguntas de orden y oportunidad. Un cliente que recibe una alerta antigua necesita suficiente contexto para saber que es antigua. Un endpoint automatizado que recibe un reintento o duplicado necesita un comportamiento idempotente o un proceso de reconciliación.

La plataforma y el cliente controlan cada uno diferentes partes de ese límite.

La limitación más consecuente era que la función ofensiva no se había revertido. PagerDuty explica explícitamente por qué: durante el primer incidente, el desencadenante no era evidente y los respondedores se concentraron en estabilizar Kafka. Esa declaración debe tomarse en serio en lugar de reescribirse como intención o indiferencia. Los respondedores de incidentes a menudo deben elegir entre restaurar un sistema crítico compartido e investigar todas las posibles causas ascendentes. La estabilización inmediata puede ser la prioridad racional cuando el panorama causal está incompleto.

Sin embargo, la decisión tiene una consecuencia de responsabilidad incluso si fue razonable. El servicio era operativo, pero la ruta de código iniciadora seguía siendo capaz de producir la misma carga anómala. La primera respuesta había aumentado el heap y reiniciado el clúster; no había demostrado de manera concluyente que la condición que consumió el heap había desaparecido. En términos de fiabilidad, la recuperación se había logrado a nivel de servicio pero no todavía a nivel causal. Esa brecha se hizo visible más tarde el mismo día.

Este es el primer fallo de recuperación, cuidadosamente definido. No significa que el trabajo de restauración no lograra restaurar el servicio a las 10:10. Significa que la garantía de recuperación no estableció que el desencadenante había sido eliminado antes de que el incidente se considerara operativamente normal. La fuente pública no dice qué monitoreo o condiciones de congelación de cambios se aplicaron durante el intervalo. Muestra que la misma clase de problema de Kafka recurrió a las 16:38.

16:38 UTC: la recurrencia convirtió la mitigación en diagnóstico

PagerDuty describe el segundo incidente como una recurrencia más pequeña. Los respondedores reaplicaron los pasos de mitigación utilizados anteriormente y limitaron el impacto al cliente en unos 50 minutos. Esta contención más rápida sugiere que el equipo había aprendido a estabilizar el sistema afectado. No muestra por sí mismo que la causa raíz anterior se entendiera. El cambio decisivo en la segunda respuesta fue el descubrimiento de la fuente de tráfico anómalo y la reversión del código ofensivo.

La recurrencia agudizó la evidencia. Una explicación de broker o hardware ya no podía dar cuenta cómodamente de todo el día. La misma plataforma experimentó un fallo relacionado de Kafka después de la primera intervención en el clúster. Los respondedores tenían ahora una línea base reciente, pasos de mitigación conocidos y una ventana de búsqueda más pequeña en torno a los cambios y el comportamiento del tráfico. PagerDuty dice que descubrió la fuente de los patrones de tráfico anómalos durante esta respuesta.

Una vez que el código de la función se vinculó con el aumento de productores, la reversión abordó la condición de software iniciadora en lugar de solo sus consecuencias de memoria.

La distinción entre "impacto mitigado" y "completamente restaurado" vuelve a ser importante. El impacto al cliente del segundo evento se mitigó en aproximadamente 50 minutos, según la empresa. PagerDuty informa la restauración completa de todos los servicios a las 20:24 UTC. Esas declaraciones pueden coexistir. Un incidente puede dejar de causar daño agudo nuevo mientras los sistemas dependientes, colas, integraciones y tareas de verificación continúan hacia el estado normal. Comprimir el registro a una interrupción de 50 minutos omitiría ese intervalo de recuperación. Llamar a todo el intervalo igualmente severo también sería impreciso.

La reversión proporcionó una evidencia causal más fuerte que la expansión de capacidad por sí sola. La autopsia no proporciona un experimento controlado, pero la secuencia respalda una inferencia respaldada por evidencia: el tráfico anómalo de productores dejó de regenerarse una vez que se eliminó la función ofensiva, permitiendo que el estado de infraestructura reparado se mantuviera. La narrativa causal de la autopsia identifica el error lógico, la multiplicación de productores, la presión de metadatos, el thrashing de recolección de basura, el agotamiento del heap y la cascada del clúster.

No se presenta ninguna causa pública competidora en el registro publicado.

Por lo tanto, hay poco valor en tratar la causa como disputada por equilibrio retórico. La distinción responsable es entre un relato confirmado de la empresa y una verificación independiente que no está en el registro público utilizado aquí. PagerDuty asumió públicamente la responsabilidad del mecanismo de la función. Las incógnitas se refieren al registro de control interno y los resultados posteriores de los clientes, no a una alegación alternativa de sabotaje, crimen o conducta deliberada. Nada en la evidencia publicada respalda tales afirmaciones.

El libro de contabilidad causal

La causa raíz fue el error lógico de la función: crear un productor de Kafka por cada solicitud de API en lugar de reutilizar un productor para publicar mensajes de uso. Esa implementación hizo que el volumen ordinario de solicitudes generara metadatos extraordinarios de productores. PagerDuty controlaba el código de la función y la arquitectura del servicio en la que se ejecutaba. Esta es la causa documentada más profunda porque eliminar el comportamiento erróneo abordó el mecanismo iniciador.

El evento desencadenante fue la ejecución en vivo de ese código a escala. Las solicitudes de API instanciaron repetidamente productores hasta que Kafka rastreaba casi 4,2 millones de productores adicionales por hora en el pico. El desencadenante no fue un evento de tráfico malicioso en el relato público, y no fue identificado como un defecto del producto Kafka. Fue el encuentro entre el comportamiento de la función de PagerDuty y el volumen de solicitudes de producción.

Las condiciones contribuyentes incluyeron la criticidad de la columna vertebral compartida de Kafka, el costo de metadatos de la proliferación de productores, el heap finito del broker y una respuesta de recolección de basura que se convirtió en thrashing en lugar de alivio. La arquitectura permitió que la presión creada por una función analítica afectara múltiples rutas orientadas al cliente y a la respuesta. El registro público también respalda la preocupación sobre la cobertura de garantía: la implementación llegó a producción sin un control que impidiera o señalara rápidamente la creación de productores por solicitud.

La fuente no revela qué prueba o aprobación específica debería haberlo detectado, por lo que esa preocupación sigue siendo una inferencia sobre el resultado, no una afirmación sobre una violación de proceso nombrada.

El fallo de detección fue diagnóstico. Las alertas inicialmente apuntaron a los respondedores hacia un broker y un posible problema de hardware. El sistema detectó síntomas de fallo, pero la correlación entre capas de una función reciente, la aceleración del conteo de productores, la presión del heap del broker y el comportamiento de recolección de basura no produjo la causa correcta al principio del primer evento. PagerDuty reconoció la naturaleza sistémica una vez que brokers adicionales agotaron la memoria. Encontró la fuente de tráfico anómalo solo durante la recurrencia.

El fallo de respuesta tuvo dos partes. Técnicamente, las acciones tempranas —añadir capacidad al clúster y eliminar un broker— trataron el aparente fallo local sin detener la carga de trabajo que consumiría más capacidad. Esto no es una afirmación de que las acciones fueran irracionales; es una declaración de que fueron incompletas en relación con la causa real. Comunicativamente, las actualizaciones de estado redactadas internamente no se convirtieron en actualizaciones públicas oportunas, y los procedimientos de respaldo requirieron atención adicional de ingeniería y publicación manual.

El fallo de recuperación también fue de dos capas. La primera restauración devolvió los servicios a la normalidad pero dejó la función ofensiva activa porque su papel aún no se conocía. Eso dejó riesgo de recurrencia. Por separado, la recuperación generó efectos de mensajes atrasados y salidas duplicadas que los clientes tuvieron que interpretar. Durante el segundo incidente, los respondedores utilizaron mitigaciones conocidas, identificaron y revirtieron el código, y luego continuaron restaurando todas las capacidades dependientes hasta las 20:24.

La consecuencia fue un portafolio de impactos limitados en lugar de una única interrupción binaria. El trabajo entrante podía ser rechazado o retrasado. Las notificaciones salientes podían llegar tarde sin ser descartadas permanentemente. Las API podían devolver errores. Las integraciones podían retrasar, perder o duplicar trabajo. Los usuarios móviles podían no poder reconocer o resolver. La información de estado público podía retrasarse respecto al conocimiento interno. Estos efectos importan precisamente porque PagerDuty se encuentra entre la detección y la respuesta para sus clientes.

Esta clasificación evita dos errores comunes. El primero es asignar todo el incidente a un único error de codificación e ignorar las condiciones que permitieron que ese error estresara una columna vertebral compartida y evadiera el diagnóstico temprano. El segundo es distribuir la culpa tan ampliamente que ningún controlador permanezca visible. Kafka, los sistemas del cliente y el tráfico de red eran parte del entorno, pero la evidencia de PagerDuty sitúa la función decisiva, la arquitectura, la observabilidad, la mitigación, la comunicación y los controles de reversión dentro del dominio operativo de PagerDuty.

La responsabilidad sigue los controles que PagerDuty poseía

PagerDuty controlaba el diseño de la función. Decidió cómo se producirían y enviarían los datos de uso de la API a Kafka. Controlaba la revisión del código, el entorno de prueba, el método de despliegue y la observabilidad de producción, aunque la fuente pública no revela el contenido de cada control. Controlaba la arquitectura compartida de Kafka y la capacidad y alertas a su alrededor. Controlaba la respuesta a incidentes, el proceso de publicación de estado, la reversión y la autopsia. Esos controles hacen de PagerDuty el actor responsable principal para prevenir, detectar, contener, explicar y reparar este fallo.

La responsabilidad principal no es lo mismo que la responsabilidad ilimitada por cada evento posterior. La autopsia no cuantifica las pérdidas comerciales de los clientes ni muestra que cada mensaje retrasado causara daño. No establece resultados contractuales. Una asignación forense no debe saltar de "el 23% de las notificaciones se retrasaron al menos cinco minutos" a una cifra monetaria total.

Debe preguntar qué evidencia puede proporcionar PagerDuty a los clientes afectados para que puedan reconstruir sus propias líneas de tiempo: registros de aceptación, respuestas de rechazo, marcas de tiempo de entrega, comportamiento de reintento, identificadores de duplicados y alcance de la región de servicio.

Los clientes conservaban algunos controles, pero no equivalentes. Un cliente podía monitorear sus propios sistemas de forma independiente, preservar colas de eventos locales, implementar lógica de reintento para respuestas 502, hacer que los consumidores de webhooks fueran idempotentes, mantener contactos de escalado alternativos y evitar tratar la página de estado de un proveedor como la única fuente de verdad. Esos son controles de dependencia prudentes. No transfieren la responsabilidad por un defecto de productor por solicitud al cliente.

Los clientes podían mitigar su exposición; no podían inspeccionar ni revertir la función interna de PagerDuty.

La misma asimetría se aplica al retraso de notificaciones. Los clientes deciden qué eventos ingresan a PagerDuty y cómo responden sus equipos. PagerDuty controla si un evento aceptado se mueve a través de su plataforma a tiempo. Un relato maduro de responsabilidad compartida debe identificar ambos lados sin crear una falsa equivalencia. El proveedor posee la fiabilidad del procesamiento interno y la evidencia veraz del incidente. El cliente posee el diseño de contingencia para la posibilidad residual de que el proveedor esté deteriorado, especialmente cuando el proveedor es parte de la propia ruta de emergencia del cliente.

Kafka no debe ser asignado como un fallo de producto en este registro. La autopsia de PagerDuty describe el rastreo de metadatos y el comportamiento de memoria de Kafka como el entorno en el que el error de la función se volvió destructivo. No dice que Kafka violara una garantía documentada o contuviera un defecto que causara el evento. Llamar a esto un "fallo de Kafka" puede ser operativamente conveniente, porque los brokers de Kafka agotaron el heap, pero es incompleto como conclusión de responsabilidad.

La causa raíz accionable residía en la creación de productores por parte de PagerDuty y la ausencia de una restricción efectiva sobre ese patrón.

El problema de la página de estado también pertenece a PagerDuty. Los clientes no controlaban si los borradores internos aparecían públicamente. Un diseño de comunicación resiliente no debe asumir que las mismas condiciones que deterioran el servicio dejarán intacta cada dependencia de publicación. La evidencia no nos dice si el proceso de respaldo de PagerDuty se probaba rutinariamente. Nos dice que se necesitó el respaldo y que las actualizaciones se retrasaron durante unos 100 minutos.

La responsabilidad después del evento requiere más que decir que la publicación manual funcionó finalmente; requiere evidencia de que la ruta independiente es lo suficientemente rápida bajo condiciones de fallo realistas.

También hay un deber de responsabilidad en la medición. La autopsia de PagerDuty es inusualmente específica sobre los porcentajes de error y las duraciones. Esa precisión ayuda a las organizaciones afectadas a evitar una interpretación de todo o nada. También crea preguntas de seguimiento. ¿Se calcularon los porcentajes sobre todas las solicitudes relevantes o sobre una población acotada? ¿Pueden los clientes obtener datos específicos de su inquilino? ¿Cómo se clasificaron las salidas retrasadas, perdidas, rechazadas y duplicadas? El resumen publicado no responde a esas preguntas.

Plantearlas es legítimo porque la medición controla el límite entre una narrativa general de incidente y una reconstrucción utilizable por el cliente.

Finalmente, la responsabilidad se extiende desde la explicación hasta la prueba de reparación duradera. Revertir el código detuvo el desencadenante documentado. No prueba, por sí mismo, que un error similar del ciclo de vida de un objeto no pueda llegar a otra cola compartida o que el monitoreo correlacione la próxima anomalía a nivel de aplicación con la presión de recursos del broker.

La evidencia duradera incluiría una restricción en la creación de productores, pruebas que fallen en una cardinalidad anómala de productores, alertas vinculadas a tasas en lugar de solo a la muerte del broker, controles de despliegue vinculados a la salud de la infraestructura y una ruta de comunicación verificada independientemente de la plataforma primaria de incidentes. Estos son requisitos respaldados por evidencia derivados del fallo, no afirmaciones de que PagerDuty haya o no implementado cada elemento.

Lo que el registro público no puede resolver

La autopsia no identifica a cada cliente afectado ni cuantifica cada región. Dice que algunos clientes en las Regiones de Servicio de EE. UU. experimentaron interrupción o retraso. Cualquier afirmación más amplia excedería el registro. No enumera incidentes individuales para los que una notificación llegó demasiado tarde, y no calcula de forma independiente la pérdida económica. Esas lagunas no deben llenarse con víctimas hipotéticas presentadas como hechos.

El registro tampoco expone la historia completa de gobierno de la función. No conocemos la discusión precisa de la revisión del código, los casos de prueba, la forma de la prueba de carga, las etapas de despliegue, las transferencias de guardia o los umbrales de decisión utilizados entre las 03:53 y las 10:10. Conocemos el resultado: la función llegó a producción, el conteo de productores se disparó, las señales tempranas se asemejaban a un fallo de broker o hardware, y el desencadenante no se identificó durante el primer incidente.

Eso es suficiente para probar el diseño de control, pero no suficiente para acusar a un individuo de aceptar el riesgo a sabiendas.

No hay evidencia aquí de conducta criminal, fraude, sabotaje o degradación intencional del servicio. No hay base para afirmar que PagerDuty ocultó la pérdida de eventos aceptados; su relato dice expresamente que los eventos y datos previamente aceptados no se perdieron, mientras que por separado informa rechazo y retraso. Esas declaraciones deben preservarse juntas. Un análisis crítico se vuelve más débil, no más fuerte, cuando convierte hechos operativos cuidadosamente acotados en alegaciones no respaldadas.

La fuente tampoco verifica de forma independiente la finalización de la remediación a largo plazo. La reversión es una acción confirmada del incidente. La estabilización del clúster está confirmada en el relato de la empresa. El proceso de estado utilizó una ruta manual de respaldo. Pero el aprendizaje propuesto o implícito de una autopsia no es lo mismo que una auditoría posterior que muestre controles operando a lo largo del tiempo. Los revisores deben distinguir la intención de reparación, la evidencia de implementación y la evidencia de efectividad. Solo las intervenciones del día del incidente están cerradas por el registro publicado.

La evidencia del lado del cliente sigue siendo otra incógnita. Un cliente con registros de solicitudes locales, códigos de respuesta de PagerDuty, identificadores de webhook y marcas de tiempo de notificaciones podría reconstruir su propia exposición con más precisión. Esa evidencia está fuera de la autopsia publicada. La ausencia de un libro de contabilidad público cliente por cliente no debe malinterpretarse como prueba de que nadie resultó perjudicado, ni debe tratarse como permiso para inventar daños. Es una razón para mantener las conclusiones al nivel que la evidencia respalda.

La recuperación está completa solo cuando la causa, la cola y el registro son estables

Las interrupciones del 28 de agosto de PagerDuty muestran por qué la restauración del servicio es solo una capa de la recuperación. A las 10:10 UTC, los servicios eran normales, pero el desencadenante causal no había sido identificado y eliminado. Durante la restauración, los mensajes atrasados y las salidas duplicadas aún podían llegar a los clientes. La comunicación de estado público ya se había retrasado respecto a la respuesta interna. El sistema funcionaba, pero la causa, la cola y el registro externo no estaban todos igualmente resueltos.

Para el segundo incidente, los respondedores tenían un manual de estabilización conocido. Mitigaron el impacto más rápido, encontraron la fuente de tráfico anómalo y revirtieron el código ofensivo. La restauración completa a las 20:24 cerró el día operativo en un estado más sólido que la primera restauración. Eso no borra el fallo anterior. Lo aclara: la expansión de capacidad y la recuperación del clúster pueden ganar tiempo, pero la recuperación causal requiere eliminar la carga de trabajo que hizo que la capacidad fuera inadecuada.

El caso también muestra por qué un proveedor de gestión de incidentes no puede definir la fiabilidad solo como entrega eventual. Su producto se encuentra dentro de los relojes de respuesta de los clientes. Una notificación que se conserva pero llega tarde, un webhook que se duplica, un evento que se rechaza y una actualización de estado que permanece sin publicar imponen riesgos diferentes. Cada uno necesita su propia evidencia y comportamiento de recuperación. Agregarlos en un solo número de tiempo de actividad haría más difícil ver la cadena de responsabilidad.

La publicación por parte de PagerDuty de métricas detalladas y un mecanismo causal concreto es parte de la divulgación responsable. Hace posible el escrutinio. La prueba restante es si la organización puede demostrar que sus controles ahora observan el comportamiento que importaba: tasa de creación de productores, memoria del broker y recolección de basura en relación con los cambios, semántica del backlog, publicación de estado independiente y cierre causal antes de que un incidente se declare completamente recuperado. Esas no son demandas de perfección. Son demandas de evidencia alineada con los controles que la empresa realmente posee.

La lección central es moderada pero exigente. Una plataforma utilizada para gestionar incidentes se convirtió en una fuente de incertidumbre durante dos de los suyos propios. La causa raíz documentada fue un error lógico en el código de la función de PagerDuty. La arquitectura compartida de Kafka y la detección incompleta entre capas contribuyeron. La primera respuesta restauró el servicio sin eliminar el desencadenante. La segunda vinculó el tráfico anómalo con la función y la revirtió. No se necesita ninguna alegación no respaldada.

La cronología misma muestra dónde pertenece la responsabilidad: con las partes que podían ver, restringir, comunicar y eliminar el riesgo —y la mayoría de esos controles decisivos eran de PagerDuty.

Fuentes