Resumo

  • Um recurso que criava um produtor Kafka por requisição de API gerou quase 4,2 milhões de produtores adicionais por hora no pico, esgotando a heap dos brokers e degradando os caminhos de eventos, notificações, integrações, API, mobile e comunicação de status.
  • A primeira resposta restaurou o serviço sem identificar e remover o gatilho; uma recorrência no mesmo dia conectou o tráfego anormal do Kafka ao recurso e levou a PagerDuty a reverter o código problemático.

Uma plataforma de gerenciamento de incidentes ocupa uma posição incomum na cadeia de responsabilidade operacional. Seus clientes não a utilizam apenas quando as condições são normais. Eles dependem dela no momento em que outro sistema está falhando, quando um evento atrasado, uma notificação ausente ou uma atualização de status não confiável pode distorcer a resposta a uma emergência separada. Isso não torna o serviço ininterrupto possível. Torna a alocação de controle excepcionalmente importante. A pergunta relevante não é se a PagerDuty poderia prometer que o Kafka nunca falharia.

É se a empresa controlava as decisões que criaram a falha, os sinais que atrasaram o diagnóstico, os mecanismos que ampliaram o impacto e as evidências necessárias para mostrar que o mesmo caminho havia sido fechado.

O relato da PagerDuty sobre suas interrupções de 28 de agosto de 2025 fornece um caso concentrado. Um recurso destinado a apoiar análises futuras do uso de chaves de API criava um novo produtor Kafka para cada requisição de API. No pico, a PagerDuty afirma que o Kafka estava rastreando quase 4,2 milhões de produtores adicionais por hora, 84 vezes seu número típico de novos produtores. A carga de metadados aumentou a pressão de memória nos brokers Kafka, levou a coleta de lixo da Java Virtual Machine a um estado de thrashing, esgotou a memória heap e cascateou por um cluster que suportava trabalho assíncrono em todo o serviço.

O resultado visível não foi uma interrupção limpa. Foi uma mistura de eventos recebidos rejeitados, processamento atrasado, notificações atrasadas, erros de API, webhooks duplicados ou atrasados, integrações prejudicadas e atualizações de status que os respondedores redigiam, mas os clientes não podiam ver.

A cronologia importa porque a mesma condição técnica apareceu duas vezes no mesmo dia. O primeiro incidente começou às 03:53 UTC. A PagerDuty estabilizou o Kafka, recuperou os serviços dependentes, processou trabalho pendente e reportou operações normais às 10:10 UTC. A empresa não identificou e removeu o gatilho do recurso durante essa resposta. Uma recorrência menor começou às 16:38 UTC. Os respondedores repetiram as mitigações anteriores, encontraram o padrão de tráfego anormal, reverteram o código problemático e mitigaram o impacto ao cliente em cerca de 50 minutos.

A PagerDuty afirma que todos os serviços foram totalmente restaurados às 20:24 UTC. A primeira recuperação, portanto, restaurou o serviço sem remover conclusivamente a condição iniciadora. A segunda resposta conectou os sintomas de infraestrutura à mudança de software.

Essa sequência transforma um defeito de software em um registro de responsabilidade. Causa raiz, evento desencadeador, condições contribuintes, falha de detecção, falha de resposta e falha de recuperação estavam relacionados, mas não eram idênticos. Tratá-los como uma única "interrupção do Kafka" indiferenciada obscureceria quem controlava cada camada. Também distorceria a evidência pública. A PagerDuty não identificou o Kafka como um produto defeituoso de terceiros. Identificou um erro lógico em seu próprio código de recurso e a forma como esse código interagia com a arquitetura da empresa.

A distinção é central: a responsabilidade deve seguir o controle sobre o mecanismo, não o nome de tecnologia mais reconhecível na pilha.

A Evidência é Detalhada, mas Ainda é um Relato da Empresa

A base factual para esta reconstrução é o postmortem de engenharia da PagerDuty, publicado em 5 de setembro de 2025. É um registro operacional primário da organização que executou o sistema afetado. Ele fornece horários de início e restauração, o mecanismo do recurso, o caminho de diagnóstico da primeira resposta, a razão pela qual nenhum rollback ocorreu durante essa resposta, a recorrência e inúmeras medições de impacto. Esses detalhes suportam uma análise mais rigorosa do que uma coleção de reclamações em redes sociais ou um resumo de interrupção sem fontes permitiria.

A mesma fonte tem um limite inevitável. Um postmortem de empresa não é uma auditoria independente. Ele pode confirmar o que a PagerDuty representou publicamente, mas não pode por si só estabelecer a experiência de cada cliente, cada decisão interna ou cada perda downstream. O postmortem afirma que a PagerDuty reteve eventos e dados previamente aceitos. Essa afirmação não significa que todo evento tentado foi aceito: a PagerDuty separadamente afirma que alguns eventos recebidos podem ter sido rejeitados, incluindo respostas 502 da API de Eventos no pico do impacto. Também não significa que uma notificação atrasada não causou dano.

Significa a proposição mais restrita que a empresa fez sobre os dados já aceitos pela plataforma.

A evidência se enquadra em quatro classes. Fatos confirmados são declarações no postmortem, atribuídas à PagerDuty quando a atribuição importa. Inferências apoiadas por evidências conectam esses fatos a responsabilidades de controle, mas não pretendem revelar intenção não documentada. Não há alegação disputada necessária no centro deste caso; o relato causal central vem da própria PagerDuty.

Incógnitas permanecem desconhecidas: a fonte não fornece um registro de danos cliente por cliente, prova que todos os clientes ou regiões foram afetados, quantifica perdas comerciais independentes ou divulga o registro completo de aprovação e teste interno do recurso. Esses limites impedem que a gravidade se torne especulação.

Antes das 03:53 UTC: Um Recurso de Relatórios Entrou em um Caminho Crítico

A PagerDuty descreve o Kafka como a espinha dorsal de sua arquitetura assíncrona. Essa descrição estabelece o primeiro fato de controle importante. O Kafka não era periférico ao serviço. O trabalho dependente dele incluía os caminhos de processamento que conectavam eventos recebidos a notificações, integrações, webhooks, sistemas de chat, ações móveis e outras capacidades. Uma mudança que aumentasse a carga nessa espinha dorsal, portanto, carregava um raio de explosão potencial diferente de uma mudança isolada para uma interface de relatórios não crítica.

O novo recurso deveria apoiar a análise e relatórios sobre tendências de uso de chaves de API. A PagerDuty esperava que seu volume fosse aproximadamente comparável ao uso de chaves de API. À primeira vista, esse é um objetivo de produto razoável: registrar informações de uso, enviá-las para um tópico Kafka e analisá-las posteriormente sem atrasar a requisição iniciadora. O problema de responsabilidade não surgiu do objetivo. Surgiu da unidade de trabalho da implementação. Em vez de reutilizar um produtor para publicar mensagens, o recurso instanciava um novo produtor Kafka para cada requisição de API.

Essa distinção é fácil de comprimir em uma frase e fácil de subestimar. Um produtor não era meramente um objeto local transitório sem efeito além da requisição que o criou. O Kafka tinha que rastrear metadados associados a cada produtor. Repetir essa operação na escala de requisições de API transformou o tráfego de aplicação em pressão de controle e memória dentro do cluster de filas de mensagens. O pico medido pela PagerDuty — quase 4,2 milhões de produtores adicionais por hora — era 84 vezes a taxa ordinária de novos produtores. O recurso, portanto, não adicionou simplesmente o fluxo esperado de mensagens de uso.

Mudou a população de identidades de produtores que os brokers tinham que gerenciar.

O fato confirmado é o erro lógico e o volume resultante de produtores. Uma inferência apoiada por evidências segue: a garantia focada apenas no número de mensagens teria medido o risco errado. Um teste poderia observar que cada requisição de API gerava um evento de uso esperado e ainda assim perder o custo de metadados multiplicador criado por um produtor por requisição.

Da mesma forma, uma implantação gradual poderia limitar o tráfego imediato, mas falhar em expor a relação causal se os revisores observassem as taxas de sucesso da aplicação sem observar a criação de produtores, a heap dos brokers e o comportamento da coleta de lixo como indicadores vinculados.

O postmortem divulga uma implantação em fases de 1% em 21 de agosto para 5% e depois 25% em 27 de agosto, seguido por 75% em 28 de agosto; não divulga o conjunto exato de testes de pré-produção, a cadeia de aprovação ou os limites de alerta. Seria infundado dizer que nenhum teste ocorreu ou que um funcionário nomeado ignorou um perigo conhecido.

A conclusão mais restrita é defensável: quaisquer que fossem os controles existentes, eles não impediram que um padrão de produtor por requisição alcançasse um backbone Kafka compartilhado, e o quadro de monitoramento inicial não identificou prontamente esse padrão como a fonte da pressão sistêmica de memória.

Essa é uma condição contribuinte, não o evento desencadeador em si. O código criou a capacidade para crescimento anormal de produtores. O tráfego de API ao vivo o exerceu. O Kafka acumulou metadados. A pressão de memória dos brokers aumentou. A coleta de lixo começou a consumir esforço sem restaurar uma margem estável. O esgotamento da heap moveu o problema de comportamento ineficiente para falha de serviço. Cada etapa teve um sinal diferente possível. A responsabilidade depende em parte se esses sinais estavam visíveis juntos ou separados entre equipes de aplicação e infraestrutura.

03:53 UTC: A Primeira Falha Pareceu Menor do Que Era

A PagerDuty marca 03:53 UTC como o início do primeiro incidente. Uma falha em um de seus sistemas de enfileiramento de mensagens Kafka desencadeou problemas em cascata que interromperam ou atrasaram o processamento de novos eventos recebidos para alguns clientes nas Regiões de Serviço dos EUA. "Alguns clientes" e "Regiões de Serviço dos EUA" são limites materiais. O registro não suporta a alegação de que todos os clientes da PagerDuty globalmente perderam serviço. Suporta uma degradação séria e de múltiplas capacidades dentro do escopo que a empresa reportou.

Os primeiros alertas sugeriam uma falha de um broker e possível problema de hardware. Esse diagnóstico era plausível o suficiente para direcionar a primeira resposta. Engenheiros expandiram o cluster e removeram um broker. Essas ações trataram o componente aparentemente falho e aumentaram a capacidade. Elas não removeram o comportamento do recurso que continuava gerando novos produtores. Quando brokers adicionais ficaram sem memória, o incidente deixou de parecer um problema de nó único. A PagerDuty então reconheceu um problema de software sistêmico.

Esta é a falha de detecção em sua forma precisa. Não foi uma falha em perceber que algo estava errado; alertas dispararam e respondedores agiram. Foi uma falha de detecção causal. A telemetria inicial apresentou um sintoma de infraestrutura local mais claramente do que apresentou o comportamento no nível da aplicação que estava levando o cluster à exaustão. Um sistema de detecção pode ser rápido em anunciar dor e ainda assim ser lento em identificar sua fonte.

Para um backbone assíncrono compartilhado, essa diferença determina se a primeira intervenção remove um componente falho ou interrompe uma carga de trabalho que também esgotará a capacidade de substituição.

Chamar a interpretação inicial de irracional iria além da evidência. Falhas de hardware e falhas de broker são hipóteses comuns quando um broker alerta. A questão de responsabilidade é se o design de observabilidade tornou uma alternativa sistêmica disponível cedo o suficiente. A criação de produtores subindo para 84 vezes a taxa típica de novos produtores foi um sinal distintivo. O consumo de heap dos brokers e o thrashing da coleta de lixo foram sinais relacionados. Uma implantação de recurso foi um sinal de mudança relevante. A fonte não diz quando cada um se tornou visível para os respondedores ou se um console os correlacionou.

Mostra que a relação não foi estabelecida antes que múltiplos brokers sofressem exaustão de memória.

Esse atraso expandiu o raio de explosão efetivo. A expansão do cluster adicionou espaço, mas o padrão de criação anormal poderia consumir espaço adicional. Remover um broker eliminou um nó sintomático, mas não o fluxo de trabalho de metadados. A resposta se tornou eficaz somente depois que a equipe tratou o evento como sistêmico: a PagerDuty dobrou o tamanho da heap, rolou o cluster, estabilizou o Kafka e depois restaurou os serviços que dependiam do Kafka. Essas etapas trataram a pressão imediata de recursos e permitiram que o trabalho enfileirado se movesse novamente.

A causa raiz não foi heap insuficiente no sentido comum. Mais heap foi uma mitigação. Se o mesmo padrão errôneo de produtor permanecesse ativo, a capacidade poderia adiar a exaustão sem tornar o design sólido. A causa raiz também não foi o backlog que apareceu durante a restauração. O backlog foi uma consequência do processamento prejudicado e uma fonte de carga de recuperação posterior. A classificação precisa importa porque, caso contrário, uma organização pode documentar uma intervenção de capacidade bem-sucedida enquanto deixa o comportamento de software iniciador no lugar.

O Impacto Foi uma Cadeia de Falhas Desiguais

Uma plataforma de incidentes tem pelo menos dois fluxos relevantes. Ela deve receber e processar sinais, e deve transformar esses sinais em ação útil por meio de notificações e integrações. A primeira interrupção da PagerDuty afetou ambos. No pico, alguns eventos recebidos podem ter sido rejeitados com respostas 502 da API de Eventos. Outros eventos foram aceitos, mas atrasados. Notificações de saída, webhooks, integrações de chat incluindo Slack e Microsoft Teams, operações da API REST, confirmação e resolução móveis, e várias integrações empresariais foram prejudicadas em diferentes proporções e por diferentes durações.

A diferença entre rejeição e atraso é operacionalmente importante. Um evento rejeitado pode exigir que o sistema de envio tente novamente ou pode desaparecer se esse sistema não tiver um caminho de retry confiável. Um evento atrasado permanece em uma fila, mas pode chegar após o momento em que teria mudado uma decisão de resposta. Um webhook duplicado ou mensagem de chat pode fazer os respondedores se perguntarem se há múltiplos incidentes ou se uma transição de estado ocorreu duas vezes. Um erro de API pode impedir a confirmação ou atualização mesmo enquanto uma notificação já alcançou uma pessoa.

Uma única porcentagem de "disponibilidade" ocultaria esses diferentes ônus.

A PagerDuty afirma que cerca de 14% dos eventos foram atrasados. A rejeição de eventos atingiu o pico de cerca de 95% por 38 minutos. Esses números não devem ser mesclados em uma alegação de que 95% de todos os eventos foram permanentemente perdidos. Eles medem condições diferentes. A empresa também relata que cerca de 16% dos eventos de ingestão de e-mail foram atrasados e menos de 1% não foram processados. Para eventos de mudança, 6,5% foram rejeitados por 55 minutos. Cada número é limitado pela categoria e duração no postmortem.

No caminho de saída, cerca de 23% das notificações foram atrasadas em pelo menos cinco minutos por 209 minutos. A PagerDuty afirma que nenhuma notificação foi descartada completamente. Essa declaração é tranquilizadora em uma dimensão e séria em outra. Um sistema de notificação pode eventualmente entregar toda mensagem e ainda assim falhar a um propósito sensível ao tempo. Cinco minutos não é um atraso abstrato quando a mensagem se destina a mobilizar uma resposta. O registro público não estabelece o que aconteceu no incidente de cada cliente individual, então não pode suportar uma emergência inventada ou perda financeira.

Estabelece um período prolongado em que quase um quarto das notificações, pela medição da PagerDuty, ultrapassou um limite de atraso de cinco minutos.

A API REST viu taxas de erro aumentadas por cerca de 150 minutos. A PagerDuty relata que 18,87% das requisições de criação retornaram respostas 5xx por 130 minutos e 4,35% das requisições de atualização retornaram respostas 5xx por 190 minutos. Fluxos de trabalho móveis também foram afetados: 6,06% dos usuários não conseguiram confirmar ou resolver incidentes através do aplicativo móvel. Essas falhas podem interagir.

Se uma notificação é atrasada, uma requisição de confirmação falha e uma integração tenta novamente mais tarde, o registro do cliente do que os respondedores sabiam e quando pode se tornar menos confiável mesmo que os dados subjacentes do incidente sejam eventualmente preservados.

A PagerDuty também lista eventos de integração atrasados ou descartados para Jira, ServiceNow, Salesforce e Zendesk por cerca de 100 minutos. Webhooks foram atrasados, descartados ou duplicados por cerca de 100 minutos. Sistemas de chat experimentaram atrasos e mensagens duplicadas. Estas não são conveniências intercambiáveis. Os clientes frequentemente incorporam essas saídas em criação de tickets, escalonamento, propriedade e trilhas de auditoria. A fonte da PagerDuty não mede a qualidade da reconciliação downstream de cada cliente.

Confirma que a plataforma entregou trabalho de recuperação a esses clientes: tentar novamente, verificar lacunas, suprimir duplicatas e determinar se uma mensagem tardia refletia o estado atual.

A evidência, portanto, suporta uma inferência limitada. O custo da interrupção não se limitou ao tempo em que uma página web estava inacessível. Transferiu incerteza para as operações do cliente. Quanto mais um cliente automatizou em torno das saídas da PagerDuty, mais ele precisava distinguir eventos aceitos de rejeitados, notificações atrasadas de atuais e duplicatas de novo estado. Essa inferência não quantifica uma perda. Identifica onde a responsabilidade por semântica confiável importa em uma dependência vendida para coordenação de incidentes.

Uma Página de Status Falhou no Momento em que o Status Importava

O primeiro incidente também interrompeu o processo de comunicação externa da PagerDuty. A empresa afirma que as atualizações foram redigidas internamente, mas não apareceram publicamente na página de status. Equipes de engenharia adicionais foram engajadas e os respondedores usaram procedimentos de backup para adicionar atualizações manualmente. A PagerDuty registra atrasos nas atualizações da página de status por cerca de 100 minutos.

Esta foi uma falha de resposta separada da causa raiz do Kafka. O bug do recurso não exigia logicamente que as comunicações públicas fossem atrasadas. O atraso surgiu porque o processo que convertia conhecimento interno de incidentes em informações de status externas não foi concluído com sucesso, e o caminho de backup exigiu intervenção manual. Uma página de status deve reduzir a incerteza do cliente quando o serviço principal está degradado.

Se a publicação depende de um caminho acoplado ao ambiente afetado — ou de um processo externo que não é verificado independentemente — os clientes podem perder tanto o serviço quanto a explicação autoritativa juntos.

O postmortem não fornece os rascunhos internos, a dependência exata de publicação, o horário de cada tentativa de atualização ou o procedimento manual completo. Seria especulação afirmar que uma ferramenta específica falhou ou que uma equipe específica negligenciou um dever. O limite confirmado é mais restrito: atualizações internas existiam, a exibição pública não ocorreu a tempo, mais engenheiros foram engajados e procedimentos de backup foram usados. A lição apoiada por evidências é que a recuperação da comunicação merece o mesmo ensaio que a recuperação técnica.

Uma mensagem redigida não tem valor operacional para um cliente que não pode vê-la.

O atraso também complica o diagnóstico do cliente. Quando uma plataforma de gerenciamento de incidentes se comporta de forma inconsistente, os clientes devem determinar se seus próprios sistemas monitorados pararam de emitir eventos, se uma integração falhou ou se a plataforma está atrasada. Um sinal de status externo oportuno e independente pode restringir essa busca. Uma atualização ausente empurra cada cliente para testes locais, contatos de suporte ou conjectura. Essa duplicação de trabalho diagnóstico é uma consequência previsível da falha de comunicação, embora o postmortem não a quantifique.

Estabilização às 10:10 UTC Não Foi Eliminação do Gatilho

A PagerDuty afirma que todos os serviços e capacidades do sistema retornaram às operações normais às 10:10 UTC. Alcançar esse ponto exigiu estabilizar o Kafka e restaurar os serviços que dependiam dele. À medida que o processamento era retomado, os clientes podiam receber notificações e alertas atrasados enquanto a PagerDuty trabalhava através de mensagens desatualizadas. Alguns podiam receber webhooks duplicados. A recuperação, portanto, teve uma cauda de fila: a infraestrutura podia estar estável enquanto trabalho antigo continuava a emergir nos sistemas dos clientes.

Essa cauda é uma condição de recuperação, não prova de uma nova falha. Mensagens enfileiradas precisam ser processadas ou deliberadamente descartadas sob uma política explícita. A PagerDuty afirma que eventos e dados previamente aceitos não foram perdidos, então processar o backlog era consistente com a preservação. Mas a preservação cria questões de ordenação e tempestividade. Um cliente recebendo um alerta antigo precisa de contexto suficiente para saber que é antigo. Um endpoint automatizado recebendo uma retentativa ou duplicata precisa de comportamento idempotente ou um processo de reconciliação.

A plataforma e o cliente controlam diferentes partes desse limite.

A limitação mais consequente era que o recurso ofensor não havia sido revertido. A PagerDuty explica explicitamente por quê: durante o primeiro incidente, o gatilho não era evidente e os respondedores se concentraram em estabilizar o Kafka. Essa declaração deve ser levada a sério, e não reescrita como intenção ou indiferença. Os respondedores de incidentes frequentemente devem escolher entre restaurar um sistema crítico compartilhado e investigar toda causa upstream possível. A estabilização imediata pode ser a prioridade racional quando o quadro causal está incompleto.

No entanto, a decisão tem uma consequência de responsabilidade mesmo que fosse razoável. O serviço estava operacional, mas o caminho de código iniciador permanecia capaz de produzir a mesma carga anormal. A primeira resposta aumentou a heap e rolou o cluster; não demonstrou conclusivamente que a condição que consumiu a heap havia desaparecido. Em termos de confiabilidade, a recuperação havia sido alcançada no nível do serviço, mas ainda não no nível causal. Essa lacuna tornou-se visível mais tarde no mesmo dia.

Esta é a primeira falha de recuperação, definida cuidadosamente. Não significa que o trabalho de restauração falhou em restaurar o serviço às 10:10. Significa que a garantia de recuperação não estabeleceu que o gatilho havia sido removido antes que o incidente fosse considerado operacionalmente normal. A fonte pública não diz qual monitoramento ou condições de congelamento de mudanças foram aplicadas durante o intervalo. Mostra que a mesma classe de problema do Kafka recorreu às 16:38.

16:38 UTC: Recorrência Transformou Mitigação em Diagnóstico

A PagerDuty descreve o segundo incidente como uma recorrência menor. Os respondedores reaplicaram as etapas de mitigação usadas anteriormente e limitaram o impacto ao cliente em cerca de 50 minutos. Essa contenção mais rápida sugere que a equipe havia aprendido a estabilizar o sistema afetado. Não mostra por si só que a causa raiz anterior foi compreendida. A mudança decisiva na segunda resposta foi a descoberta da fonte de tráfego anormal e a reversão do código ofensor.

A recorrência aguçou a evidência. Uma explicação de broker ou hardware não podia mais responder confortavelmente por todo o dia. A mesma plataforma experimentou uma falha relacionada do Kafka após a primeira intervenção no cluster. Os respondedores agora tinham uma linha de base recente, etapas de mitigação conhecidas e uma janela de busca menor em torno de mudanças e comportamento de tráfego. A PagerDuty afirma que descobriu a fonte dos padrões de tráfego anormais durante essa resposta.

Uma vez que o código do recurso foi vinculado ao aumento de produtores, a reversão tratou a condição de software iniciadora, não apenas suas consequências de memória.

A distinção entre "impacto mitigado" e "totalmente restaurado" é novamente importante. O impacto ao cliente do segundo evento foi mitigado em aproximadamente 50 minutos, de acordo com a empresa. A PagerDuty relata a restauração completa de todos os serviços às 20:24 UTC. Essas declarações podem coexistir. Um incidente pode parar de causar danos agudos novos enquanto sistemas dependentes, filas, integrações e tarefas de verificação continuam em direção ao estado normal. Comprimir o registro a uma interrupção de 50 minutos omitiria esse intervalo de recuperação.

Chamar todo o intervalo de igualmente severo também seria impreciso.

A reversão forneceu evidência causal mais forte do que a expansão de capacidade sozinha. O postmortem não fornece um experimento controlado, mas a sequência suporta uma inferência baseada em evidências: o tráfego anormal de produtores parou de ser regenerado uma vez que o recurso ofensor foi removido, permitindo que o estado de infraestrutura reparado se mantivesse. A própria narrativa causal do postmortem identifica o erro lógico, a multiplicação de produtores, a pressão de metadados, o thrashing da coleta de lixo, o esgotamento da heap e a cascata no cluster. Nenhuma causa concorrente pública é apresentada no registro publicado.

Consequentemente, há pouco valor em tratar a causa como disputada para equilíbrio retórico. A distinção responsável é entre um relato confirmado da empresa e uma verificação independente que não está no registro público usado aqui. A PagerDuty assumiu publicamente o mecanismo do recurso. As incógnitas dizem respeito ao registro de controle interno e aos resultados downstream para os clientes, não a uma alegação alternativa de sabotagem, crime ou conduta deliberada. Nada na evidência publicada suporta tais alegações.

O Livro-Caixa Causal

A causa raiz foi o erro lógico do recurso: criar um produtor Kafka para cada requisição de API em vez de reutilizar um produtor para publicar mensagens de uso. Essa implementação fez com que o volume ordinário de requisições gerasse metadados de produtor extraordinários. A PagerDuty controlava o código do recurso e a arquitetura de serviço na qual ele era executado. Esta é a causa documentada mais profunda porque remover o comportamento errôneo tratou o mecanismo iniciador.

O evento desencadeador foi a execução ao vivo desse código em escala. As requisições de API instanciavam produtores repetidamente até que o Kafka estivesse rastreando quase 4,2 milhões de produtores adicionais por hora no pico. O gatilho não foi um evento de tráfego malicioso no relato público e não foi identificado como um defeito de produto do Kafka. Foi o encontro entre o comportamento do recurso da PagerDuty e o volume de requisições de produção.

As condições contribuintes incluíam a criticidade do backbone Kafka compartilhado, o custo de metadados da proliferação de produtores, a heap finita dos brokers e uma resposta de coleta de lixo que se tornou thrashing em vez de alívio. A arquitetura permitiu que a pressão criada por um recurso analítico afetasse múltiplos caminhos voltados ao cliente e à resposta. O registro público também suporta preocupação sobre a cobertura de garantia: a implementação chegou à produção sem um controle que impedisse ou sinalizasse prontamente a criação de produtores por requisição.

A fonte não revela qual teste ou aprovação específica deveria ter capturado isso, então essa preocupação permanece uma inferência sobre o resultado, não uma alegação sobre uma violação de processo nomeada.

A falha de detecção foi diagnóstica. Alertas inicialmente apontaram os respondedores para um broker e possível problema de hardware. O sistema detectou sintomas de falha, mas a correlação entre camadas — um recurso recente, aceleração na contagem de produtores, pressão na heap dos brokers e comportamento da coleta de lixo — não produziu a causa correta no início do primeiro evento. A PagerDuty reconheceu a natureza sistêmica uma vez que brokers adicionais esgotaram a memória. Ela encontrou a fonte de tráfego anormal apenas durante a recorrência.

A falha de resposta teve duas partes. Tecnicamente, as ações iniciais — adicionar capacidade ao cluster e remover um broker — trataram a falha local aparente sem interromper a carga de trabalho que consumiria mais capacidade. Não é uma alegação de que as ações foram irracionais; é uma afirmação de que foram incompletas em relação à causa real. Comunicativamente, as atualizações de status redigidas internamente não se tornaram atualizações públicas oportunas, e os procedimentos de backup exigiram atenção adicional de engenharia e postagem manual.

A falha de recuperação também teve duas camadas. A primeira restauração retornou os serviços ao normal, mas deixou o recurso ofensor ativo porque seu papel ainda não era conhecido. Isso deixou risco de recorrência. Separadamente, a recuperação gerou efeitos de mensagens desatualizadas e saídas duplicadas que os clientes tiveram que interpretar. Durante o segundo incidente, os respondedores usaram mitigações conhecidas, identificaram e reverteram o código, depois continuaram restaurando todas as capacidades dependentes até as 20:24.

A consequência foi um portfólio de impactos limitados, em vez de uma única interrupção binária. O trabalho recebido podia ser rejeitado ou atrasado. As notificações de saída podiam estar atrasadas sem serem permanentemente descartadas. As APIs podiam retornar erros. As integrações podiam atrasar, descartar ou duplicar trabalho. Usuários móveis podiam não conseguir confirmar ou resolver. As informações públicas de status podiam ficar atrás do conhecimento interno. Esses efeitos importam precisamente porque a PagerDuty está entre a detecção e a resposta para seus clientes.

Essa classificação previne dois erros comuns. O primeiro é atribuir todo o incidente a um erro de codificação e ignorar as condições que permitiram que esse erro sobrecarregasse um backbone compartilhado e evitasse o diagnóstico precoce. O segundo é distribuir a culpa tão amplamente que nenhum controlador permanece visível. Kafka, sistemas de clientes e tráfego de rede faziam parte do ambiente, mas a evidência da PagerDuty coloca o recurso decisivo, a arquitetura, a observabilidade, a mitigação, a comunicação e os controles de rollback dentro do domínio operacional da PagerDuty.

A Responsabilidade Segue os Controles que a PagerDuty Detinha

A PagerDuty controlava o design do recurso. Ela decidiu como os dados de uso da API seriam produzidos e enviados ao Kafka. Ela controlava a revisão de código, o ambiente de teste, o método de implantação e a observabilidade de produção, embora a fonte pública não divulgue o conteúdo de cada controle. Ela controlava a arquitetura Kafka compartilhada e a capacidade e os alertas em torno dela. Ela controlava a resposta a incidentes, o processo de publicação de status, o rollback e o postmortem. Esses controles tornam a PagerDuty o principal ator responsável por prevenir, detectar, conter, explicar e reparar essa falha.

Responsabilidade primária não é o mesmo que responsabilidade ilimitada por todo evento downstream. O postmortem não quantifica perdas comerciais dos clientes ou mostra que toda mensagem atrasada causou dano. Não estabelece resultados contratuais. Uma alocação forense não deve pular de "23% das notificações foram atrasadas em pelo menos cinco minutos" para um valor monetário total.

Deve perguntar quais evidências a PagerDuty pode fornecer aos clientes afetados para que eles possam reconstruir suas próprias linhas do tempo: registros de aceitação, respostas de rejeição, carimbos de data/hora de entrega, comportamento de retry, identificadores de duplicatas e escopo da região de serviço.

Os clientes retinham alguns controles, mas não equivalentes. Um cliente podia monitorar seus próprios sistemas de forma independente, preservar filas de eventos locais, implementar lógica de retry para respostas 502, tornar os consumidores de webhook idempotentes, manter contatos de escalonamento alternativos e evitar tratar a página de status de um fornecedor como a única fonte de verdade. Esses são controles prudentes de dependência. Eles não transferem a responsabilidade por um defeito de produtor por requisição para o cliente. Os clientes podiam mitigar sua exposição; não podiam inspecionar ou reverter o recurso interno da PagerDuty.

A mesma assimetria se aplica ao atraso de notificação. Os clientes decidem quais eventos entram na PagerDuty e como suas equipes respondem. A PagerDuty controla se um evento aceito passa por sua plataforma a tempo. Um relato maduro de responsabilidade compartilhada deve identificar ambos os lados sem criar falsa equivalência. O fornecedor possui a confiabilidade do processamento interno e a evidência verídica do incidente. O cliente possui o design de contingência para a possibilidade residual de que o fornecedor esteja prejudicado, especialmente quando o fornecedor faz parte do próprio caminho de emergência do cliente.

O Kafka não deve ser atribuído como uma falha de produto neste registro. O postmortem da PagerDuty descreve o rastreamento de metadados e o comportamento de memória do Kafka como o ambiente no qual o erro do recurso se tornou destrutivo. Não diz que o Kafka violou uma garantia documentada ou continha um defeito que causou o evento. Chamar isso de "falha do Kafka" pode ser operacionalmente conveniente, porque os brokers Kafka esgotaram a heap, mas é incompleto como conclusão de responsabilidade. A causa raiz acionável estava na criação de produtores pela PagerDuty e na ausência de uma restrição eficaz sobre esse padrão.

O problema da página de status também pertence à PagerDuty. Os clientes não controlavam se os rascunhos internos apareciam publicamente. Um design de comunicação resiliente não deve assumir que as mesmas condições que prejudicam o serviço deixarão intacta toda dependência de publicação. A evidência não nos diz se o processo de backup da PagerDuty era testado rotineiramente. Diz que o backup foi necessário e que as atualizações foram atrasadas por cerca de 100 minutos.

A responsabilidade após o evento exige mais do que dizer que a postagem manual funcionou no final; exige evidência de que o caminho independente é rápido o suficiente sob condições realistas de falha.

Há também um dever de responsabilidade na medição. O postmortem da PagerDuty é excepcionalmente específico sobre porcentagens de erro e durações. Essa precisão ajuda as organizações afetadas a evitar uma interpretação de tudo ou nada. Também cria perguntas de acompanhamento. As porcentagens foram calculadas em todas as requisições relevantes ou em uma população delimitada? Os clientes podem obter dados específicos do locatário? Como as saídas atrasadas, descartadas, rejeitadas e duplicadas foram classificadas? O resumo publicado não responde a essas perguntas.

Levantá-las é legítimo porque a medição controla o limite entre uma narrativa geral de incidente e uma reconstrução utilizável pelo cliente.

Finalmente, a responsabilidade se estende da explicação à prova de reparo durável. Reverter o código parou o gatilho documentado. Não prova, por si só, que um erro semelhante de ciclo de vida de objeto não pode alcançar outra fila compartilhada ou que o monitoramento correlacionará a próxima anomalia no nível da aplicação com a pressão de recursos do broker.

A evidência durável incluiria uma restrição na criação de produtores, testes que falham na cardinalidade anormal de produtores, alertas vinculados a taxas em vez de apenas morte de broker, verificações de implantação ligadas à saúde da infraestrutura e um caminho de comunicação verificado independentemente da plataforma primária de incidentes. Esses são requisitos baseados em evidências derivados da falha, não alegações de que a PagerDuty implementou ou não cada item.

O que o Registro Público Não Pode Resolver

O postmortem não identifica todos os clientes afetados nem quantifica cada região. Diz que alguns clientes nas Regiões de Serviço dos EUA experimentaram interrupção ou atraso. Qualquer alegação mais ampla excederia o registro. Não enumera incidentes individuais para os quais uma notificação chegou tarde demais e não calcula independentemente a perda econômica. Essas lacunas não devem ser preenchidas com vítimas hipotéticas apresentadas como fato.

O registro também não expõe o histórico completo de governança do recurso. Não sabemos a discussão precisa da revisão de código, os casos de teste, a forma do teste de carga, os estágios de implantação, as transferências de plantão ou os limites de decisão usados entre 03:53 e 10:10. Sabemos o resultado: o recurso chegou à produção, a contagem de produtores disparou, os sinais iniciais se assemelhavam a uma falha de broker ou hardware, e o gatilho não foi identificado durante o primeiro incidente. Isso é suficiente para testar o design de controle, mas não suficiente para acusar um indivíduo de aceitar conscientemente o risco.

Não há aqui evidência de conduta criminosa, fraude, sabotagem ou degradação intencional do serviço. Não há base para afirmar que a PagerDuty ocultou perda de eventos aceitos; seu relato afirma expressamente que eventos e dados previamente aceitos não foram perdidos, enquanto relata separadamente rejeição e atraso. Essas declarações devem ser preservadas juntas. Uma análise crítica torna-se mais fraca, não mais forte, quando converte fatos operacionais cuidadosamente delimitados em alegações não fundamentadas.

A fonte também não verifica independentemente a conclusão da remediação de longo prazo. A reversão é uma ação de incidente confirmada. A estabilização do cluster é confirmada no relato da empresa. O processo de status usou uma rota manual de backup. Mas um aprendizado proposto ou implícito de um postmortem não é o mesmo que uma auditoria posterior mostrando controles operando ao longo do tempo. Os revisores devem distinguir intenção de reparo, evidência de implementação e evidência de eficácia. Apenas as intervenções do dia do incidente são encerradas pelo registro publicado.

A evidência do lado do cliente permanece outra incógnita. Um cliente com logs de requisição locais, códigos de resposta da PagerDuty, identificadores de webhook e carimbos de data/hora de notificação poderia reconstruir sua própria exposição mais precisamente. Essa evidência está fora do postmortem publicado. A ausência de um registro público cliente por cliente não deve ser mal interpretada como prova de que ninguém foi prejudicado, nem deve ser tratada como permissão para inventar dano. É uma razão para manter as conclusões no nível que a evidência suporta.

A Recuperação Está Completa Apenas Quando a Causa, a Fila e o Registro Estão Estáveis

As interrupções de 28 de agosto da PagerDuty mostram por que a restauração do serviço é apenas uma camada da recuperação. Às 10:10 UTC, os serviços estavam normais, mas o gatilho causal não havia sido identificado e removido. Durante a restauração, mensagens desatualizadas e saídas duplicadas ainda podiam alcançar os clientes. A comunicação pública de status já estava atrasada em relação à resposta interna. O sistema estava funcionando, mas a causa, a fila e o registro externo não estavam todos igualmente resolvidos.

No segundo incidente, os respondedores tinham um manual de estabilização conhecido. Mitigaram o impacto mais rapidamente, encontraram a fonte de tráfego anormal e reverteram o código ofensor. A restauração completa às 20:24 fechou o dia operacional em um estado mais forte do que a primeira restauração. Isso não apaga a falha anterior. Esclarece-a: a recuperação de capacidade e cluster pode ganhar tempo, mas a recuperação causal exige remover a carga de trabalho que tornou a capacidade inadequada.

O caso também mostra por que um provedor de gerenciamento de incidentes não pode definir confiabilidade apenas como entrega eventual. Seu produto está dentro dos relógios de resposta dos clientes. Uma notificação preservada, mas atrasada, um webhook duplicado, um evento rejeitado e uma atualização de status que permanece não publicada impõem riscos diferentes. Cada um precisa de sua própria evidência e comportamento de recuperação. Agregá-los em um único número de disponibilidade tornaria a cadeia de responsabilidade mais difícil de ver.

A publicação de métricas detalhadas e um mecanismo causal concreto pela PagerDuty faz parte da divulgação responsável. Torna o escrutínio possível. O teste restante é se a organização pode demonstrar que seus controles agora observam o comportamento que importava: taxa de criação de produtores, memória do broker e coleta de lixo em relação a mudanças, semântica de backlog, publicação independente de status e fechamento causal antes que um incidente seja declarado totalmente recuperado. Estas não são demandas por perfeição. São demandas por evidência alinhada com os controles que a empresa realmente detém.

A lição central é contida, mas exigente. Uma plataforma usada para gerenciar incidentes tornou-se uma fonte de incerteza durante dois de seus próprios. A causa raiz documentada foi um erro lógico no código de recurso da PagerDuty. A arquitetura Kafka compartilhada e a detecção incompleta entre camadas contribuíram. A primeira resposta restaurou o serviço sem remover o gatilho. A segunda vinculou o tráfego anormal ao recurso e o reverteu. Nenhuma alegação infundada é necessária.

A própria cronologia mostra onde a responsabilidade pertence: com as partes que podiam ver, restringir, comunicar e remover o risco — e a maioria desses controles decisivos eram da PagerDuty.

Fontes