Falha curta de rota e prova de responsabilização da KDDI

Resumo

A KDDI informa que uma falha de comunicação começou em 1h35 (JST) em 2 de julho de 2022 e que o uso do serviço retornou ao nível da semana anterior às 15h00 de 4 de julho. O período de efeito informado foi de 61 horas e 25 minutos, em todo o Japão. [1][5][7]
O início da interrupção foi muito mais curto. Durante a manutenção de um roteador da rede de transporte nacional no centro de rede de Tama, uma configuração de rota incorreta interrompeu o tráfego por aproximadamente quinze minutos. Reverter a configuração não encerrou o incidente. [1][5]
Dispositivos e equipamentos reenviaram repetidamente solicitações de registro de localização. Os nós VoLTE ficaram congestionados, o processamento distribuído espalhou pressão para nós VoLTE em outros locais pelo transporte nacional, e o tráfego autenticado repetido sobrecarregou o banco de dados de assinantes. [1][5][9]
A KDDI estimou que cerca de 22,78 milhões de usuários de voz e pelo menos 7,65 milhões de usuários de dados foram afetados em base não consolidada. Incluindo a Okinawa Cellular, as estimativas foram de cerca de 23,16 milhões de usuários de voz e pelo menos 7,75 milhões de usuários de dados. São estimativas de impacto de serviço, não uma contagem de pessoas únicas. [1][5][14]
A resposta de novembro à orientação administrativa diz que o trabalho usou um documento de procedimento incorreto, que os controles de aprovação e rollback precisavam de revisão, que o controle automático de congestionamento foi insuficiente, que estado de backup danificado afetou algumas reinicializações e que inconsistências de sessão de assinante complicaram a recuperação. [8][9]
O registro oficial da Dieta diz que 119 volumes de chamada originados na KDDI ficaram cerca de 63% abaixo do normal e 110 ficaram cerca de 45% abaixo do normal durante o incidente, enquanto outras rotas carregaram mais chamadas. São mudanças de volume observadas, não prova de que cada tentativa de chamada de emergência tenha falhado. [20]
A KDDI anunciou reembolsos com base em termos e um reembolso de desculpas e estimou um efeito financeiro de aproximadamente 7,5 bilhões de ienes. Contas de reembolso, estimativas de impacto de serviço, assinaturas e pessoas únicas devem permanecer como métricas separadas. [1][11]
A responsabilização não termina com a identificação de uma configuração incorreta. Ela depende de controle prático sobre custódia de procedimento, revisão técnica, evidência de aprovação, tempo de rollback, teste em estado anômalo, observabilidade de congestionamento, integridade de backup, recuperação de estado de assinante e prova de restauração específica por serviço.
A KDDI publicou diversas medidas corretivas, incluindo controles de procedimento mais rígidos, ferramentas de congestionamento, controle de fluxo habilitado, mudanças de topologia, trabalho de automação de recuperação, governança de qualidade e melhorias de comunicação. A publicação de uma medida é evidência de compromisso ou de alegação de implementação, não prova independente de que toda classe relevante de falha tenha sido eliminada. [9][10][15][17]
O serviço de roaming de emergência criado depois pelo Japão cria uma rota alternativa durante grandes interrupções. Deve ser avaliado como controle de resiliência limitado, não como substituto para corrigir fragilidade dentro da própria rede da operadora ou como política causada exclusivamente por esse evento. [22]

O primeiro fato de responsabilização é o descompasso temporal

A cronologia pública da KDDI usa dois relógios muito diferentes.

O primeiro relógio cobre a interrupção inicial de roteamento. Durante a manutenção de um roteador na rede de transporte nacional, uma rota incorreta interrompeu parte do tráfego atravessando esse roteador. A KDDI descreve a interrupção como com duração aproximada de quinze minutos. A configuração foi revertida. [1][5]

O segundo relógio cobre o efeito em clientes e serviços. A KDDI diz que a falha de comunicação começou em 1h35 de 2 de julho de 2022 (sábado). Diz também que o uso de voz e dados retornou a um nível comparável ao mesmo período da semana anterior às 15h00 de 4 de julho (segunda-feira). Isso soma 61 horas e 25 minutos. Uma verificação adicional em nível de grupo do uso de clientes e normalidade de tráfego foi reportada em 5 de julho. [1][7]

Chamar isso de erro de roteamento de 61 horas seria falso. Chamar de interrupção de quinze minutos também seria falso.

O erro de rota foi o gatilho. O incidente prolongado foi um problema de recuperação envolvendo carga de sinalização, nós VoLTE, autenticação de assinantes, estado inconsistente, material de backup danificado e decisões operacionais sobre quais componentes isolar e quando. A distinção é central porque responsabilidade por um gatilho e responsabilidade pela amplificação não são necessariamente idênticas.

Um operador pode fazer uma alteração incorreta e ainda assim contê-la rapidamente se a mudança for delimitada, as premissas de rollback forem realistas e os sistemas a jusante tolerarem a falha temporária. Também pode causar uma falha de curta duração que cria uma condição persistente em outro ponto. Dispositivos repetem tentativas. Filas crescem. Bancos de dados recebem consultas repetidas. Estados replicados divergem. As ações de recuperação também aumentam a carga. Componentes reiniciam em estado anômalo. A observabilidade se degrada porque todos os alarmes disparam ao mesmo tempo.

A pergunta responsável não é apenas: "Quem inseriu a configuração errada?"

É:

Quem aprovou o trabalho e com que evidência?
Qual modelo de impacto definiu o limite para rollback?
Quais comportamentos a jusante haviam sido testados?
Que telemetria mostrou que o rollback não restaurou o serviço?
Quem tinha autoridade para isolar nós e reduzir carga?
Qual estado conhecido e íntegro estava disponível para a recuperação?
Quais testes de serviço definiram restauração?

Uma investigação centrada em culpa tende a reduzir essa cadeia à pessoa mais próxima da linha de comando. Uma investigação centrada em controle examina as instituições que desenharam o trabalho, aprovaram o risco, construíram o comportamento anômalo da rede e decidiram quando os clientes poderiam ser informados de que o serviço estava restaurado.

O próprio relatório regulatório da KDDI aponta nessa direção. Ele descreve gestão de documentos de procedimento, verificações técnicas, evidência de aprovação, critérios de rollback, projeto de congestionamento, procedimentos de recuperação e governança de qualidade. [9] O relato do operador, portanto, reforça uma lição mais ampla: uma mudança de rede não é a digitação de um único técnico. É um objeto de controle organizacional.

Como uma mudança de rota virou uma cascata de sinalização

O serviço móvel depende de uma grande quantidade de sinalização que os clientes não veem.

Um aparelho precisa se anexar à rede e identificar a área em que pode ser localizado. Um serviço de voz baseado em VoLTE precisa que a rede saiba onde o assinante está registrado e quais funções de controle podem estabelecer uma chamada de entrada ou saída. O serviço de dados também depende de autenticação de assinante e estado de sessão. Essas operações envolvem mensagens entre aparelhos, funções da rede móvel, nós VoLTE e bancos de dados de assinantes.

Em condições normais, essa sinalização é uma fração pequena do valor percebido pelo cliente. O serviço visível é uma ligação, mensagem ou sessão de dados. O pré-requisito oculto é uma sequência de registros, autenticações, políticas e trocas de roteamento bem-sucedidas.

O relato técnico da KDDI diz que a configuração incorreta de rota fez com que solicitações de registro de localização fossem abandonadas. Dispositivos e equipamentos então reenviaram as solicitações. As retransmissões cresceram rapidamente. Nós VoLTE em Tama ficaram congestionados, e o processamento distribuído pela rede de transporte nacional espalhou a pressão para nós VoLTE em outros locais. [1][5]

O banco de dados de assinantes passou então a fazer parte da cascata. A KDDI explica que nós VoLTE e equipamentos da rede móvel consultam o banco para autenticação. A sinalização repetida, portanto, criou tráfego repetido para o banco. O sistema não tinha apenas muitas chamadas de clientes. Tinha muitas solicitações de controle geradas por registro incompleto e comportamento de retransmissão.

Essa distinção importa para engenharia e responsabilização.

O planejamento de capacidade comum pode perguntar quantas chamadas, sessões de dados ou assinantes simultâneos um nó suporta. O planejamento em estado anômalo pergunta como o sistema se comporta quando mensagens falham no meio de uma transação e são retransmitidas por milhões de aparelhos. O segundo pode produzir uma forma de carga diferente da demanda máxima do tráfego normal.

Um mecanismo de retransmissão costuma ser um recurso de confiabilidade. Ele protege o usuário de um pacote perdido ou interrupção temporária. Em escala nacional, retransmissões sincronizadas ou insuficientemente limitadas podem se tornar um multiplicador de carga. Uma solicitação falha; o aparelho tenta novamente; a função de rede tenta novamente; o banco de dados vê tráfego de autenticação repetido; respostas lentas mantêm mais transações abertas; e a fila crescente gera mais timeouts e novas retransmissões.

Assim, a falha atravessa várias superfícies de controle:

Controle de roteamento:se o tráfego atinge o caminho pretendido.
Controle de retransmissão:como aparelhos e sistemas respondem quando as respostas esperadas não chegam.
Controle de admissão:se nós saturados rejeitam, atrasam ou modelam com segurança novas cargas.
Proteção de banco de dados:se autenticação e sistemas de estado de assinante conseguem limitar a demanda repetida.
Controle de distribuição:se o compartilhamento de carga contém a falha ou a propaga.
Controle de recuperação:se os respondentes conseguem identificar e isolar rapidamente as fontes de sinalização excessiva.

A KDDI diz que aplicou controles de taxa de fluxo para reduzir congestionamento de banco de dados, mas a sinalização excessiva continuou. Em último caso, separou seis de dezoito nós VoLTE associados às solicitações anômalas persistentes. [1][5]

Essa ação ilustra uma troca difícil na recuperação. Remover capacidade pode reduzir carga prejudicial se nós específicos a estiverem gerando, mas também pode deixar menos capacidade para serviço legítimo. A decisão precisa de telemetria confiável e autoridade. Os respondentes devem saber se um nó é vítima de congestionamento a jusante, fonte de solicitações repetidas ou ambos.

O registro público não revela todos os caminhos de pacotes, timers ou limites. Ele estabelece que o comportamento em estado anômalo do sistema foi decisivo. O incidente pertence à responsabilização de infraestrutura de rede porque o dano seguiu da interação de roteamento de transporte, controle de sinalização, funções de voz e estado de assinante.

Por que reverter a rota não foi recuperação

Rollback costuma ser tratado como resposta mais segura para uma mudança falhada. O incidente da KDDI mostra por que essa premissa precisa de limite.

Reverter uma configuração pode restaurar a condição que existia antes da mudança. Não apaga automaticamente o estado criado enquanto a mudança esteve ativa.

Durante a interrupção, dispositivos e sistemas experimentaram registro incompleto e geraram retransmissões. Filas e carga de banco de dados mudaram. Alguns nós entraram em congestionamento. A informação de sessão de assinantes tornou-se inconsistente. A resposta posterior da KDDI diz que alguns nós VoLTE carregaram arquivos de backup danificados e reiniciaram em condição anômala, o que causou novas retransmissões de registro de localização. [9]

Assim, a rede após o rollback não era a rede anterior à mudança.

Essa é uma propriedade geral de infraestrutura com estado. Uma entrada de rota sem estado pode ser restaurada rapidamente, mas os serviços dependentes dessa rota podem manter:

transações pendentes;
timers de retransmissão;
sessoes antigas;
réplicas inconsistentes;
estado de autenticação parcial;
filas corrompidas;
falhas em cache;
processos sobrecarregados;
ações de recuperação já em andamento.

Planos de mudança devem distinguir rollback de configuração e rollback de serviço.

Um teste de rollback de configuração pergunta se os antigos bytes ou comandos foram restaurados. Um teste de rollback de serviço pergunta se os usuários conseguem registrar novamente, autenticar, ligar e estabelecer sessões de dados sem erro anômalo ou carga excessiva. Um teste de rollback de estado pergunta se bancos de dados, filas, caches e backups de nó estão consistentes o suficiente para suportar esse serviço.

Esses testes podem produzir respostas diferentes ao mesmo tempo.

As medidas publicadas da KDDI incluem revisar o tempo permitido antes do rollback para que o congestionamento em serviços a jusante fosse considerado. [9] Esse é um ajuste de controle significativo. Reconhece que esperar demais pode permitir que uma condição de rede inicialmente reversível vire uma crise de estado.

Mesmo assim, um limite de rollback mais cedo não basta por si só.

O operador também precisa de um modelo do que pode se acumular durante o intervalo permitido. Quantas retransmissões de registro podem ser geradas? Qual banco de dados satura primeiro? Qual parte da rede pode ser isolada? Qual serviço permanece disponível durante o isolamento? O que acontece quando a rota retorna, mas milhões de aparelhos retransmitem juntos?

O plano de recuperação deve especificar gatilhos baseados na saúde do serviço, não apenas no estado do roteador:

perda abrupta de sucesso de registro;
crescimento de requisições incompletas;
profundidade de fila de nós VoLTE;
tempo de resposta do banco de dados de assinantes;
taxa de rejeição de autenticação;
volume de retransmissão por região ou nó;
estabelecimento e conclusão de chamadas;
estabelecimento de sessão de dados;
sucesso em chamadas de emergência.

O rollback permanece essencial. A lição é que seu escopo deve corresponder ao sistema.

Para uma rede móvel nacional com estado, "a rota antiga voltou" é um fato técnico intermediário. Não é um certificado de restauração.

Um documento de procedimento é parte do plano de controle de produção

O relatório de novembro da KDDI diz que foi usado um procedimento de trabalho incorreto. Ele descreve revisões em gestão de documento de procedimento, revisão técnica e aprovação de trabalho. [9]

Isso pode soar administrativo. Na prática, é concreto.

O comando inserido durante a manutenção é produzido por uma cadeia:

um resultado pretendido da rede;
uma solicitação de mudança ou projeto;
um modelo de procedimento;
instruções específicas de dispositivo;
revisão por par ou especialista;
aprovação;
agendamento;
execução;
verificação;
rollback.

Se o procedimento errado pode ser selecionado, o sistema de produção fica exposto antes de qualquer operador fazer login no roteador. A custódia de documentos é, portanto, parte do plano de controle.

Um sistema de procedimento confiável deve responder:

Qual modelo era autoritativo?
Qual modelo de rede e versão de software ele assumia?
Quem criou e revisou as instruções finais?
O que mudou em relação à versão aprovada anteriormente?
Para qual dispositivo ou topologia o procedimento foi destinado?
Que evidência comprovou que resultados de simulação ou laboratório correspondiam à produção?
Qual classe de risco e nível de aprovação se aplicavam?
Quais verificações precisavam passar antes do próximo passo?
Como o procedimento seria interrompido ou revertido?

A palavra central é evidência.

Uma segunda revisão pode virar formalidade se o revisor vê apenas o documento final sem o estado pretendido, a topologia, o diff ou os resultados esperados. A aprovação pode virar formalidade se o aprovador vê apenas uma caixa de seleção, e não as consequências de uma falha.

A KDDI diz que alterou o processo para que equipe técnica experiente verificasse procedimentos, preservasse evidência dessa checagem e permitisse que aprovadores confirmassem a evidência. Também descreveu trabalho em um sistema de gestão de procedimento. [9]

Essas medidas devem ser avaliadas por aquilo que impedem.

Um sistema de gestão deve dificultar:

usar um procedimento para classe de dispositivo errada;
executar uma versão obsoleta;
pular revisão técnica obrigatória;
aprovar uma sequência de comandos sem testes;
alterar instruções após aprovação sem invalidar a aprovação;
seguir adiante quando as saídas esperadas diferem;
perder o registro do que foi realmente executado.

Operações de alto impacto também precisam de uma camada verificável por máquina, quando for prática. Mudanças de rota pretendidas podem ser comparadas com topologia e política. Diferenças de configuração podem ser verificadas por lint. Testes de laboratório ou digital twin podem exercer caminhos esperados e anômalos. Provas pré e pós-alteração podem ser automatizadas. Limites podem impedir comandos que atinjam mais nós ou prefixos do que o autorizado.

Automação não remove accountability humana. Ela muda a evidência disponível para as pessoas.

O operador continua responsável por decidir o que o controle automatizado precisa provar, como exceções são autorizadas e o que ocorre quando o estado observado difere do plano. Um sistema que confirma apenas sintaxe ainda pode aprovar uma rota semanticamente perigosa.

O evento da KDDI torna a governança de procedimento visível como governança de infraestrutura. O documento não era papel ao lado da rede. Era a descrição executável da autoridade de produção.

A classificação de risco deve seguir o raio de impacto, não a familiaridade com manutenção

Trabalhos de rotina podem carregar risco excepcional.

Uma tarefa pode ser familiar para uma equipe experiente, usar um comando conhecido e ocorrer em janela de manutenção agendada. Nenhum desses fatores define o potencial impacto ao cliente.

A KDDI diz que revisou avaliação de risco de trabalho e níveis de aprovação conforme a escala de dano caso a tarefa falhasse. Também ampliou períodos em que certos trabalhos seriam suprimidos em torno de eventos importantes. [9]

Esse é um deslocamento importante, da probabilidade isolada à consequência.

A classificação de risco para um roteador de transporte nacional deve considerar:

o número e tipo de serviços que o atravessam;
se a falha pode afetar registro ou autenticação;
como retransmissões se propagam;
se o compartilhamento de carga espalha a falha;
a independência de caminhos redundantes;
dependências de chamadas de emergência;
dependências de MVNO e empresas;
a capacidade de observar e isolar a mudança;
o tempo antes de o estado se tornar difícil de recuperar;
a capacidade testada de sistemas de contingência.

Uma tarefa com baixa probabilidade estimada de erro ainda pode exigir o padrão mais alto de aprovação e testes se sua falha pode criar dano comum em escala nacional.

A classificação também deve considerar risco temporal. Uma janela de manutenção escolhida para baixo tráfego ordinário pode não minimizar risco de sinalização. Muitos dispositivos podem reagir a uma falha ao mesmo tempo, independentemente de pessoas estarem fazendo chamadas.

Da mesma forma, um calendário de supressão por evento é apenas um controle. Grandes eventos públicos, clima severo ou eleições podem aumentar consequências de uma interrupção, mas noites comuns ainda têm chamadas de emergência, logística, dispositivos conectados, operações de transporte e atendimento essencial.

O controle mais forte é um orçamento explícito de raio de impacto.

Antes do início do trabalho, o operador deve declarar:

máximo de nós afetados;
máxima geografia afetada;
máximo de interrupção de serviço;
máximo de falha de registro;
máximo de tempo para rollback;
máximo de tempo de recuperação a jusante;
condições que exigem isolamento imediato;
capacidade de contingência disponível durante o trabalho.

Métricas observadas devem ser comparadas com esse orçamento em tempo real. Se a mudança exceder qualquer limite, a continuidade deve exigir nova autoridade em vez de assumir que a aprovação original ainda vale.

Essa abordagem transforma "manutenção de rotina" em experimento delimitado. Reconhece que o público não experiencia a familiaridade da tarefa. Ele experiencia se a rede funciona.

O controle de congestionamento deve ser testado no estado que a falha cria

O relatório da KDDI diz que o controle de congestionamento automático não funcionou como necessário durante condição anômala. Mais tarde, habilitou ou revisou funções de controle de fluxo, desenvolveu ferramentas de detecção mais detalhadas e alterou projeto de tráfego VoLTE e acomodação relevante. [9][10]

O controle de congestionamento não pode ser avaliado apenas em carga normal elevada.

Tráfego de pico normal contém muitas solicitações válidas com temporização e distribuição esperadas. Um incidente pode gerar solicitações repetidas, incompletas ou correlacionadas. Pode enviar metade de uma transação por um caminho e perder a resposta. Pode concentrar carga em componentes que o balanceamento ordinário distribui de forma uniforme. Pode levar várias funções da rede a retransmitir contra o mesmo banco de dados de assinante.

Os testes devem incluir semântica de falha:

perda parcial de rota;
alcance assimétrico;
respostas atrasadas;
solicitações duplicadas;
retransmissões sincronizadas de dispositivos;
falha de um em dois caminhos;
latência e inconsistência de banco de dados;
reinício de nó com carga alta;
monitoramento perdido;
contenção de ferramentas de recuperação.

O objetivo é degradação elegante.

Quando uma rede não consegue atender cada solicitação, ela deve proteger funções de controle essenciais e preservar capacidade suficiente para recuperação. Pode ser necessário rejeitar trabalho cedo, aplicar backoff, separar regiões, priorizar serviço de emergência ou isolar um domínio defeituoso.

A KDDI relatou mudar uma configuração VoLTE relevante de uma topologia full mesh nacional para um design separado leste-oeste e habilitar uma função de regulação de fluxo para reduzir a chance de congestionamento se espalhar. [9]

O princípio é contenção de falhas.

Distribuição pode melhorar resiliência quando cria capacidade independente. Pode piorar resiliência quando todo nó participa da mesma falha. Um full mesh pode oferecer muitos caminhos em condição normal e permitir que sinalização anômala se propague nacionalmente. A separação regional pode sacrificar alguma flexibilidade em troca de um domínio de falha comum menor.

O relatório público não prova a topologia completa atual nem o resultado de todos os testes. Ele identifica, sim, uma questão de remediação mensurável:

Se a mesma falha parcial de rota ocorrer hoje, quantos nós, regiões e assinantes podem entrar em congestionamento antes dos limites de controle serem ativados?

Uma resposta com accountability incluiria condições de teste, limites observados, comportamento de rejeição, desempenho em serviço de emergência e tempo máximo para isolar o domínio afetado.

Sem essa evidência, "mudamos a topologia" é uma declaração de projeto. Com ela, a mudança vira um controle de resiliência.

Integridade de backup e estado de assinante pertencem ao planejamento de interrupções

Backups são discutidos com frequência como controle de cibersegurança ou perda de dados. A resposta da KDDI mostra seu papel na disponibilidade da rede.

O relatório de novembro diz que alguns nós VoLTE leram arquivos de backup danificados e iniciaram em estado anômalo. Também descreve inconsistências de sessão do banco de assinantes. [9]

Isso torna central a proveniência do estado de recuperação.

Um nó não se recupera apenas porque reinicia. Ele recupera quando o software, a configuração e o estado operacional carregados no reinício são conhecidos como íntegros e compatíveis com o restante do sistema.

Um processo de recuperação confiável deve estabelecer:

quando o backup foi criado;
quais versões de software e configuração ele contém;
se foi produzido durante congestionamento ou falha parcial;
se sua integridade foi verificada;
se é consistente com nós pares e com o estado de assinante;
quem autorizou seu uso;
quais testes de serviço passaram após carga.

Backups criados automaticamente durante um incidente podem preservar o próprio incidente.

Se um nó grava um estado anômalo e esse estado vira a próxima imagem de recuperação, reiniciar pode reproduzir a falha. Se bancos de dados de assinantes replicados divergem, restaurar uma cópia pode invalidar sessões ou provocar mais registro. Se respondentes não conseguem determinar qual estado é autoritativo, cada ação corretiva carrega novo risco.

A resposta não é eliminar backup automatizado. O ponto é distinguir checkpoints operacionais de pontos de recuperação validados independentemente.

Funções críticas de rede devem ter:

configuração conhecida e íntegra imutável ou com proteção de gravação;
manifests de software e configuração assinados;
verificações de consistência entre estados replicados;
quarentena para backups criados em condições anômalas;
procedimentos de reinício testados;
caminho de gestão limpo;
reinício por etapas com sondas de serviço;
rollback explícito a partir da própria ação de recuperação.

A KDDI diz que revisou procedimentos de reset de nó e desenvolveu ferramentas para detectar e aliviar congestionamento em múltiplos nós VoLTE. [9] Essas medidas tratam velocidade de recuperação. O dever de evidência é mostrar que também protegem integridade de estado.

Para uma operadora móvel, configuração, estado de assinante e autoridade de recuperação são todos ativos de disponibilidade. Um backup que não pode ser confiável sob estresse não é inventário de resiliência.

As cifras de impacto exigem interpretação disciplinada

Grandes incidentes produzem vários números grandes. Eles respondem perguntas diferentes.

A KDDI estimou cerca de 22,78 milhões de usuários de voz afetados e pelo menos 7,65 milhões de usuários de dados afetados em base não consolidada. Com a Okinawa Cellular incluída, as estimativas foram de cerca de 23,16 milhões de usuários de voz e pelo menos 7,75 milhões de usuários de dados. A operadora explica que estimativas de voz e dados usaram métodos diferentes, com base em diferenças de chamada ou de registro em comparação com período de referência. [1][5][14]

Esses números não devem ser somados para afirmar mais de trinta milhões de pessoas únicas.

Uma pessoa pode usar voz e dados. Uma conta pode conter várias linhas. Uma estimativa de impacto de dados baseada em diferença de registro não é idêntica a uma contagem de clientes que tentaram e falharam em uma sessão. "Afetado" pode cobrir serviço degradado, intermitente ou indisponível, não uma condição uniforme.

As cifras de reembolso respondem outra pergunta.

A KDDI anunciou reembolsos por termos para 2,71 milhões de clientes KDDI e 70 mil clientes Okinawa Cellular que atenderam às condições especificadas de serviço. Também anunciou reembolso de pedido de desculpas de 200 ienes para 35,89 milhões de clientes KDDI e 660 mil clientes Okinawa Cellular em classes de serviço cobertas. [1]

Essas populações refletem decisões contratuais e de política. Não são medida técnica de impacto simultâneo da interrupção.

O efeito financeiro de aproximadamente 7,5 bilhões de ienes divulgado pela KDDI é outra dimensão. [11] Ele captura as consequências empresariais esperadas sob seus pressupostos contábeis e de reembolso. Não mede toda transação perdida, contato de emergência perdido, entrega atrasada, dispositivo conectado interrompido ou custo de tempo do cliente.

Uma conta de impacto sólida preserva as quatro dimensões:

Impacto de serviço:quais funções estiveram indisponíveis ou degradadas.
Uso observado:chamadas, registros e transações comparados ao normal.
Remédio do cliente:quais contas se qualificaram para qual reembolso.
Consequência econômica:custo direto do operador e perda social mais ampla.

Inflar um número enfraquece a análise. A conclusão mais forte não requer inflação.

O incidente foi nacional, prolongado e com consequências porque uma falha de controle central afetou serviços móveis críticos e sistemas dependentes. Medição exata deve tornar essa conclusão mais crível, não menos dramática.

Chamadas de emergência transformam disponibilidade em dever público

Interrupções móveis tornam-se eventos de segurança pública quando as pessoas não conseguem alcançar serviços de emergência com confiabilidade.

O registro oficial da Dieta fornece evidência concreta. Ele diz que os volumes de chamada 119 da KDDI ficaram cerca de 63% abaixo do normal durante o incidente. Chamadas de telefones móveis não KDDI e outros caminhos aumentaram. Ele diz que os volumes de chamada 110 da KDDI ficaram cerca de 45% abaixo do normal, enquanto chamadas de outras operadoras e telefones públicos aumentaram. [20]

Essas cifras exigem linguagem cuidadosa.

Eles mostram uma grande mudança em volumes observados por origem de caminho. Não revelam cada chamada tentada, a intenção de cada chamador, se um aparelho exibiu erro, se toda alternativa ligou ou o resultado de cada atendimento de emergência.

Elas, no entanto, demonstram dependência.

Quando uma rede móvel nacional falha, a demanda de emergência não desaparece. Alguns usuários emprestam outro telefone, usam linha fixa ou procuram um telefone público. Outros podem não ter alternativa. A carga adicional em redes e centrais sobreviventes pode virar risco secundário.

Assim, continuidade de chamadas de emergência precisa de evidência além da disponibilidade de voz comum:

estabelecimento de chamada para 110, 118 e 119;
tratamento de localização do chamador;
capacidade de retorno de chamada;
tratamento de prioridade e congestionamento;
acesso por MVNOs;
acessibilidade para pessoas com deficiência;
desempenho geográfico;
instruções ao usuário quando a rede principal falha;
carga transferida para redes alternativas.

A resposta da KDDI descreve comunicação mais forte com organizações de chamadas de emergência e participação em trabalho sobre comunicações alternativas e roaming entre operadoras. [9][10]

Esses controles atendem problemas diferentes.

Melhor notificação ajuda autoridades e usuários a compreender a falha. Caminhos alternativos ajudam chamadas a saírem da rede falhada. Nenhum deles remove a responsabilidade da operadora de manter seu próprio caminho de emergência resiliente.

O padrão de accountability pública deve ser proporcional à consequência. Uma operadora pode relatar restauração comercial de voz enquanto localização, retorno de chamada ou congestionamento de emergência ainda estiverem comprometidos. A matriz de serviço deve isolar funcionalidades de emergência em vez de tratá-las como uma linha dentro do tráfego total de voz.

O controle prático estava dividido, mas não igualmente

Incidentes de rede envolvem muitos atores. A responsabilização deve seguir o que cada um poderia de fato prevenir, detectar, limitar, divulgar ou reparar.

KDDI

A KDDI controlou o processo de manutenção, a custódia de procedimento, a aprovação de trabalho, a configuração de rota, critérios de rollback, monitoramento de rede, operação de nós VoLTE, recuperação do banco de assinantes, medição de serviço, comunicação com clientes e evidência entregue ao regulador.

Isso não significa que a KDDI controlou todo comportamento de produto ou que pudesse prevenir toda falha. Significa que a operadora manteve a maior autoridade prática sobre o ambiente de produção e a recuperação.

Fornecedores de equipamentos e software

Fornecedores podem ter controlado software de nós, comportamento de banco de dados, características de retransmissão em carga alta, formatos de backup e suporte técnico. A resposta da KDDI diz que obteve informações de fornecedores e testou comportamento de alta carga. [9]

O registro congelado não divulga o mapa completo de fornecedores, contratos ou achados de defeito. Seria irresponsável atribuir culpa a uma operadora nomeada. O requisito de accountability é que o operador saiba de que evidência de fornecedor precisa e mantenha autoridade para proteger serviço quando um produto se comporta de modo inesperado.

Ministério e órgãos de revisão

O Ministério das Comunicações recebeu o relatório de acidente grave, emitiu orientação administrativa e usou estruturas de revisão para examinar o incidente e problemas mais amplos de acidentes em telecom. [3][8][9][21]

Autoridade regulatória inclui exigir evidência, definir expectativas de reporte e desenvolver regras setoriais de resiliência. Não opera os roteadores da KDDI nem recupera estado de assinante.

Serviços de emergência, MVNOs e clientes corporativos

Esses atores detêm evidência de dependência e impacto. Uma MVNO pode observar incapacidade de anexar ou ligar de seus usuários. Uma empresa pode relatar dispositivos conectados ou funções logísticas falhas. Organizações de emergência podem medir mudanças em volumes e localizações de chamadas.

Elas não controlam o núcleo da KDDI que falhou. Seu planejamento de continuidade pode reduzir danos, mas não transfere a responsabilidade principal da infraestrutura para fora do operador.

Clientes

Usuários podem manter métodos alternativos de contato quando prático, mas muitos não podem duplicar economicamente um serviço móvel nacional. Telefones públicos, Wi-Fi, uma segunda operadora ou linha fixa ajudam. São mitigaçãoções delimitadas, não resposta justa a falha sistêmica do núcleo.

Essa alocação evita dois erros.

O primeiro é culpar a pessoa ou componente mais próximo em um sistema moldado por muitas decisões de controle. O segundo é dispersar responsabilidade tão amplamente que nenhuma instituição continue responsável.

A KDDI carregou o maior ônus de accountability para mostrar por que um problema de roteamento curto virou incidente nacional prolongado e como essa cadeia está agora delimitada.

A remediação deve ser testada como pacote de evidências vinculado

A KDDI publicou um programa corretivo substancial. O relatório de novembro e divulgações posteriores descrevem:

gestão de documento de procedimento mais forte;
revisão técnica com evidência preservada;
métodos de aprovação revisados;
critérios de normalidade de serviço mais claros;
tempo de rollback considerando congestionamento;
classificação de risco de trabalho baseada em impacto;
regras de supressão de trabalho mais amplas;
ferramentas mais detalhadas de detecção de congestionamento;
mudanças de caminho de tráfego e topologia;
ativação de regulação de fluxo;
inspeção de outros sistemas móveis para modos de falha semelhantes;
procedimentos de reset e recuperação revisados;
ferramentas multi nó para alívio de congestionamento;
mudanças de governança de qualidade;
exercícios em larga escala;
comunicação pública e com partes interessadas melhorada. [9][10][15][17]

A lista é significativa. Não deve ser confundida com prova por enumeração.

Os controles interagem entre si. Um processo de procedimento mais forte pode evitar o mesmo erro de rota, mas não um comando semanticamente diferente. Controle de fluxo pode proteger nós VoLTE, mas não outro sistema com comportamento de retransmissão similar. Separação regional pode reduzir propagação enquanto permanece compartilhamento de banco de dados ou identidade de gestão. Uma ferramenta de recuperação pode agir mais rápido, mas carregar o mesmo estado não confiável.

O pacote de remediação deve conectar cada falha observada a um controle e a um teste:

Falha observada	Controle corretivo	Prova exigida
Procedimento selecionado incorretamente	Custódia de procedimento versionado e revisão técnica	Uso de procedimento obsoleto ou para dispositivo incorreto é bloqueado
Risco subestimado	Classificação baseada em impacto	Trabalho de alcance nacional e comum recebe aprovação e profundidade de teste exigidas
Rollback tardio para estado a jusante	Limite de rollback orientado por serviço	Teste mostra rollback antes de exceder limites de retransmissão e banco de dados
Falha parcial de rota gerou sinalização repetida	Controles de retransmissão e fluxo em estado anômalo	Teste de carga mostra retransmissões limitadas e funções essenciais protegidas
Congestionamento espalhou-se nacionalmente	Domínios de falha regionais e mudança de topologia	Teste de injeção de falha permanece dentro da região ou orçamento definido
Nós causadores foram difíceis de identificar	Telemetria incompleta por nó	Detecção identifica a origem em tempo definido
Recuperação carregou estado danificado	Pontos de recuperação e procedimentos de reset validados	Reinício em etapas rejeita estado corrompido e preserva consistência
Sessões de assinantes divergiram	Controles de consistência e reconciliação de banco de dados	Teste de recuperação prova estado autoritativo e rerregistro delimitado
Informação pública foi insuficiente	Templates de comunicação de incidente e equipe dedicada	Exercício produz informação oportuna de serviço, emergência e recuperação
Comunicação alternativa limitada	Roaming entre operadoras e outros caminhos	Teste de ativação prova voz, dados, SMS e emergência com limites definidos

A evidência deve ser atual e vinculada à implantação.

Uma política aprovada após incidente não prova implementação na produção. Um teste de laboratório de uma versão de software não prova topologia posterior. Um registro de participação em treinamento não prova que respondentes conseguem isolar nós com telemetria ambígua.

Evidências úteis incluem:

versões assinadas de procedimento;
registros de aprovação;
hashes de configuração e topologia;
manifests de teste;
resultados de injeção de falha;
sondas por serviço;
medições de tempo de recuperação;
registros de exceção;
revisão independente;
decisões de risco residual.

O desafio não é segredo absoluto versus divulgação total. A KDDI pode manter sintaxe de comando, credenciais e topologia sensível em sigilo, enquanto publica classe de falha, objetivo de controle, escopo de teste e resultado de garantia.

Para uma operadora nacional, a reparação durável deve ser legível para reguladores, executivos, equipes técnicas e clientes críticos. Deve permanecer compreensível após mudanças de equipe e fornecedores.

"Restaurado" precisa de uma matriz por serviço

A KDDI usou níveis de tráfego comparados ao mesmo período de uma semana anterior como parte da confirmação de recuperação. [1][7]

Isso é útil e incompleto.

O tráfego agregado pode retornar enquanto transações importantes permanecem prejudicadas. O volume de dados pode parecer normal porque usuários ativos geram mais tráfego, mesmo que alguns aparelhos não consigam registrar. Os minutos de voz podem recuperar enquanto o setup de chamada falha em uma região ou o retorno de chamada de emergência permanece afetado.

Uma matriz de restauração nacional deve incluir:

Domínio	Evidência mínima
Registro de aparelho	attach e atualização de localização por região, aparelho e geração de rede
Voz VoLTE	setup e conclusão de chamada, alcançabilidade de entrada, handover e taxas de erro
Chamadas de emergência	setup de 110, 118 e 119, localização, retorno de chamada e tratamento de congestionamento
Dados móveis	autenticação, criação de sessão, DNS e alcançabilidade público/privada
SMS	submissão, idade de fila, entrega e motivo de falha
Banco de dados de assinantes	latência, consistência, reconciliação de sessão e saúde de réplica
Serviço MVNO	attach, voz, dados, SMS e medições de caminho de suporte
IoT e empresa	registro de dispositivo representativo, telemetria e alcançabilidade de rede privada
Interconexão e roaming	transações de chamada e dados de entrada/saída entre parceiros
Comunicação com clientes	página de status, canais de suporte e instruções acessíveis de alternativa

Cada domínio deve ter limiares funcionais e de capacidade.

Recuperação funcional significa uma transação representativa bem-sucedida. Recuperação de capacidade significa o serviço suporta carga esperada sem filas instáveis ou degradação repetida. Estabilidade significa resultado persistente. Remediação significa que a classe de falha iniciadora foi tratada e reproduzida em teste.

Essas etapas não devem compartilhar uma única hora.

Observação independente também é importante. Se o sistema de monitoramento depende do mesmo banco de dados ou plano de gestão em recuperação, pode reportar visão parcial. Sondas externas, medições de MVNO, operadoras interconectadas, organizações de emergência e transações de usuários amostrais fornecem evidência independente.

A descrição atual de qualidade de rede da KDDI diz que as condições de rede no país são monitoradas centralmente em centros de operação e que usa padrões de capacidade, redundância e instalações distribuídas. [19] A pergunta de accountability é como esses controles gerais mediram essa classe de falha após a remediação.

O objetivo não é negar recuperação até cada cliente confirmar serviço. É definir um limite estatisticamente e operacionalmente crível.

Quando o público ouve que "a rede voltou", essa afirmação deve significar mais que tráfego em alta. Deve significar que funções críticas passaram em testes nomeados, a capacidade está estável e exceções residuais estão visíveis.

O roaming de emergência é uma contingência, não absolvição

Em março de 2026, os principais operadores móveis do Japão anunciaram um serviço nacional de roaming de emergência para desastres e interrupções de grande escala. O serviço inclui modo completo com voz, dados limitados e SMS, e modo apenas para chamadas de emergência. [22]

Isso é evidência de resiliência adicional.

Cria um caminho alternativo quando a rede de uma operadora está indisponível. Pode reduzir a chance de um usuário com uma assinatura ficar totalmente isolado. Também reconhece um fato público exposto por vários incidentes: a competição varejista não dá a cada usuário acesso redundante de forma automática.

O serviço tem limites.

Uma operadora alternativa precisa ter cobertura e capacidade. Aparelhos devem suportar o comportamento exigido. O serviço de roaming pode oferecer menor velocidade de dados. O modo somente de emergência tem funções limitadas e não há retorno de chamada no caminho de saída descrito. A ativação exige coordenação e informação pública. Um desastre pode afetar várias redes simultaneamente.

O roaming de emergência também não repara a rede falhada.

Ele não deve enfraquecer:

controles internos de mudança;
proteção contra congestionamento;
recuperação de estado de assinante;
desenho de serviço de emergência;
evidência de restauração;
responsabilidade do operador pela interrupção primária.

O registro público não estabelece que o evento de 2022 da KDDI, sozinho, causou o serviço de 2026. O registro da Dieta mostra que roaming entre operadoras foi discutido após grandes incidentes de telecom, e o lançamento posterior reflete trabalho multianual, multiorganizacional e governamental. [20][22]

A visão de accountability trata roaming como uma camada no portfólio:

prevenir mudanças inseguras;
conter a falha dentro da rede primária;
recuperar estado confiável;
preservar serviço prioritário;
oferecer um caminho alternativo independente;
comunicar limitações com clareza.

Uma alternativa é mais valiosa quando testada sob a mesma carga de congestionamento e demanda pública que torna necessário acioná-la.

O que o registro público congelado não pode provar

As fontes suportam uma análise detalhada de controle. Elas não suportam uma investigação privada completa.

Não é possível provar:

os comandos exatos de rota;
todos os prefixos ou caminhos de pacote afetados;
a identidade ou processo decisório do operador que executou o trabalho;
a cadeia de aprovação completa;
fornecedor e versão de cada nó ou banco de dados afetado;
se um defeito de fornecedor contribuiu;
todos os timers de retransmissão e limites de congestionamento;
disponibilidade de serviço por região;
todas as chamadas de emergência tentadas;
impacto total em MVNOs, roaming, IoT e empresas;
perda exata de clientes;
configuração de produção atual;
efetividade independente de toda remediação anunciada.

Essas lacunas não podem ser preenchidas com especulação responsável.

As perguntas não resolvidas podem ser testadas com evidência como:

tickets de mudança versionados e diferenças de procedimento;
simulação de topologia e política de rota;
telemetria de sinalização por nó;
logs de consistência de banco de dados;
hashes de backup e resultados de validação;
registros de suporte de fornecedores;
sondas por serviço;
relatórios de injeção de falha;
garantia de acompanhamento regulatório.

Incerteza não é motivo para abandonar accountability. Ela define o pedido de evidência.

Um teste reutilizável de accountability para mudança em rede móvel

O evento da KDDI sustenta um padrão prático para trabalho de telecom de alto impacto.

1. Vincular intenção a mudança executável.
O resultado aprovado, modelo de topologia, procedimento, alvos de dispositivo e diff de configuração exatos devem formar um único objeto versionado.

2. Tornar revisão técnica em evidência.
O revisor deve ver estado pretendido de rede, caminhos anômalos, saídas esperadas e condições de rollback, não apenas uma lista de comandos.

3. Classificar por dano máximo.
A profundidade de aprovação deve seguir o potencial de impacto de serviço, geográfico, de emergência e de modo comum.

4. Definir orçamento de raio de impacto.
Antes da execução, definir nós, regiões, usuários e tempo máximo e estado a jusante que podem ser afetados.

5. Testar falha parcial.
Exercitar solicitações perdidas, roteamento assimétrico, sinalização duplicada, respostas lentas e perda de um de dois caminhos.

6. Proteger sinalização e identidade.
Limitar retransmissões, admissão e demanda de banco de dados para que uma interrupção curta não vire congestionamento auto-sustentável.

7. Criar domínios de falha reais.
Distribuição deve conter carga anômala, não apenas compartilhar carga normal.

8. Tornar rollback consciente de serviço.
Critérios de rollback devem incluir registro, chamada, dados e saúde de banco, não apenas a configuração de roteador restaurada.

9. Preservar estado conhecido e íntegro.
Software, configuração e estado essencial de recuperação de assinante precisam de integridade e proveniência independentes.

10. Dar autoridade delimitada aos respondentes.
Equipes devem saber quando podem isolar nós, reduzir carga, separar regiões e acionar contingência.

11. Definir restauração por transação.
Medir registro, voz, chamadas de emergência, dados, SMS, MVNO, IoT, empresa, roaming e funções de suporte separadamente.

12. Observar de fora.
Usar sondas e parceiros que não dependem do mesmo plano de controle em recuperação.

13. Repetir a classe de incidente.
Testar variações semânticas da falha, não apenas o comando exato que acionou o incidente anterior.

14. Vincular remediação ao estado implantado.
Políticas e diagramas devem apontar para configuração atual, resultados de teste, exceções e decisões de risco residual.

15. Manter caminho alternativo delimitado.
Serviços de roaming de emergência, operadora alternativa, rede fixa, Wi-Fi ou telefones públicos podem reduzir danos, mas sua capacidade e limites devem ser testados e comunicados.

16. Publicar garantia proporcional.
Explicar o que falhou, qual classe de controle mudou, como foi testado e o que permanece incerto sem expor comandos ou arquitetura sensível.

Esse padrão não exige que uma rede nacional nunca falhe. Exige que autoridade acompanhe o raio de impacto e que declarações de restauração possam ser examinadas.

Conclusão

A interrupção de julho de 2022 da KDDI começou com uma configuração de rota incorreta durante manutenção. A configuração foi revertida após uma interrupção curta. O incidente continuou porque a rede mudou de estado.

Solicitações de registro de localização se repetiram. Nós VoLTE entraram em congestionamento. O tráfego de autenticação de assinantes cresceu. O banco de assinantes ficou sobrecarregado e inconsistente. Parte do estado de recuperação foi danificado. Seis de dezoito nós foram isolados enquanto os respondentes trabalhavam para reduzir a pressão de sinalização. Os clientes tiveram um efeito reportado de 61 horas e 25 minutos em serviços de voz e dados em escala nacional. [1][5][9]

A lição responsável não é que uma única pessoa cometeu um erro.

É que uma mudança de rede nacional é uma cadeia de controles institucionais. Custódia de procedimento, revisão técnica, aprovação, análise de raio de impacto, tempo de rollback, desenho em estado anômalo, observabilidade de congestionamento, integridade de backup, autoridade de recuperação e medição de serviço determinam se um erro curto permanece curto.

A KDDI publicou medidas corretivas em toda essa cadeia. Essas medidas merecem reconhecimento e verificação. O serviço de roaming de emergência posterior adiciona uma alternativa valiosa com limites claros. Nem uma longa lista sozinha, nem uma rede de contingência substituem a evidência de que a classe de falha primária está contida.

Para infraestrutura móvel crítica, restaurar a rota antiga não basta. O operador deve mostrar que o sistema de sinalização está estável, o estado de assinante é confiável, chamadas essenciais funcionam, a contingência é real e a próxima mudança de alto impacto não pode cruzar novamente esse mesmo limite sem ser percebida.

Esse é o teste de accountability criado pelas 61 horas após a rota já estar de volta.

KDDI: como uma falha curta de rota virou uma questão de responsabilidade de rede

Por que isso importa