Falha óptica da OVH em 2017: independência da redundância em

Resumo

A fronteira do evento é estreita:Este artigo cobre apenas a falha da rede óptica de Roubaix em 9 de novembro de 2017. A interrupção elétrica simultânea em Estrasburgo foi um incidente separado, com mecanismo e cadeia de controle diferentes.
A falha visível foi ampla, mas não universal:Relatos contemporâneos descreveram a perda de conectividade de Roubaix em direção a seis pontos de presença da rede da OVH. Isso não prova que todas as rotas, clientes ou cargas de trabalho da OVH falharam da mesma forma.
A diversidade nominal não proporcionou independência operacional:A OVH descreveu conectividade óptica redundante, mas os enlaces de Roubaix ficaram indisponíveis em conjunto após a perda de configuração e precisaram ser restaurados a partir da configuração salva.
A causa raiz pública tem duas camadas:A OVH atribuiu o evento imediato a um defeito de software e à perda de configuração do equipamento óptico. A perda correlacionada também expôs um domínio de falha compartilhado de configuração ou supervisão que a diversidade de caminhos físicos não eliminou.
Configuração salva não é um sistema de recuperação independente:Uma configuração salva permitiu a restauração, mas sua existência não manteve o sistema óptico em execução disponível. Disponibilidade de backup, autoridade de restauração e recuperabilidade testada devem ser medidas separadamente.
Responsabilidade segue o controle:A OVH controlava arquitetura, implantação, proteção de configuração, monitoramento, restauração e comunicação com clientes. O fabricante do equipamento controlava a investigação do defeito do produto e a correção de software. Pares, redes de trânsito e clientes controlavam sua própria diversidade externa, mas não o estado óptico interno da OVH.
O reparo anunciado separou corretamente dois problemas:A OVH planejou uma atualização de software com o fabricante do equipamento e a divisão do sistema de multiplexação óptica em dois sistemas. O primeiro tratava de um defeito; o segundo visava limitar o raio de impacto de recorrências.
Um reparo não é comprovado por um anúncio:O encerramento confiável exige evidências de topologia e configuração, testes de injeção de falhas, medições independentes de alcançabilidade e prova de que uma única falha de controle não pode mais remover todos os caminhos externos de Roubaix.

Congele o evento de Roubaix antes de atribuir responsabilidade

A OVH sofreu duas falhas graves no mesmo dia. Uma falha de energia afetou seu site em Estrasburgo, enquanto uma falha de rede óptica afetou Roubaix. A declaração posterior da OVH descreveu explicitamente os incidentes como simultâneos, mas não relacionados. Essa distinção é o ponto de partida para a responsabilização, não um detalhe a ser colapsado em uma história maior. [1]

Combinar os incidentes produziria uma cadeia causal imprecisa. Estrasburgo envolveu suprimento elétrico, equipamentos de transferência, geradores e reinício de serviços. Roubaix envolveu transporte óptico, perda de configuração e conectividade em direção a localizações externas da rede. Os sistemas responsáveis, operadores, fornecedores, sinais de detecção, ações de recuperação e testes de prevenção eram diferentes.

Este artigo, portanto, começa na falha óptica de Roubaix e termina quando os enlaces relevantes e a conectividade do site de hospedagem foram restaurados, seguidos pela remediação específica de Roubaix anunciada pela OVH. Exclui o evento de energia de Estrasburgo, um incidente de armazenamento de julho de 2017, um incidente de rede posterior de dezembro de 2017, o incêndio de Estrasburgo de 2021 e um evento de roteamento separado de 2021. Esses eventos podem informar uma história mais ampla da OVH, mas não podem ser usados como evidência para a causa ou o reparo da falha óptica de Roubaix.

A cronologia pública tem dois níveis úteis. A declaração formal da OVH disse que o site de Roubaix voltou a operar em menos de duas horas e meia. Um provedor de serviços afetado registrou separadamente a inalcançabilidade visível aos clientes durante a mesma manhã e descreveu a restauração após a recuperação da configuração óptica. [1][4]

Esses relatos descrevem a janela de recuperação óptica em níveis diferentes. Eles não estabelecem que todos os serviços de clientes se recuperaram em um único momento exato. Um site de hospedagem é uma pilha: enlaces de transporte retornam, sessões de roteamento se restabelecem, caminhos convergem, balanceadores de carga e dependências de aplicações se recuperam, filas de e-mail escoam, monitoramento se normaliza e clientes tentam novamente. A evidência pública não fornece uma tabela completa de restauração serviço por serviço.

A mesma disciplina se aplica ao início do incidente. Um provedor de serviços afetado descreveu acessibilidade a partir de algumas redes, mas não de outras, durante a interrupção da manhã, enquanto a OVH descreveu a falha óptica no lado do provedor e a posterior restauração. Essas perspectivas não são necessariamente contraditórias. Uma registra o efeito observado por um cliente externo; a outra registra um evento no sistema óptico do provedor. Observadores, relógios e caminhos de rede diferentes podem enxergar fronteiras diferentes. [4]

A responsabilização exige preservar essas distinções em vez de forçar um horário perfeito. Um registro robusto de incidente alinharia sondas externas, alarmes ópticos, transições de interface, logs do controlador, mudanças de sessão de roteamento e relatos de clientes contra um relógio comum. O material público não fornece esse alinhamento completo, então este artigo não o inventa.

O que a rede em execução expôs

O site de Roubaix dependia do transporte óptico que o conectava a seis pontos de presença da rede da OVH, segundo o relato do provedor de serviços afetado. O registro público descreve múltiplos caminhos ópticos e ampla perda de conectividade externa, mas não fornece uma topologia completa verificada para cada circuito, caminho de cliente ou dependência. [4]

Esses detalhes importam porque mostram que o evento não foi apresentado como um corte rotineiro de fibra única. A OVH e os relatos contemporâneos descreveram, em vez disso, uma falha de software e configuração afetando o sistema óptico, seguida por trabalho de recuperação com o fabricante do equipamento. As fontes disponíveis não expõem a sequência diagnóstica completa nem o estado interno do plano de gerenciamento. [1][4]

A descrição pública da causa raiz identificou perda de configuração no equipamento óptico. A OVH recuperou a configuração salva e restaurou a conectividade afetada. A empresa atribuiu o evento imediato a um defeito de software, enquanto a perda correlacionada de caminhos expôs uma questão mais ampla sobre dependências compartilhadas de configuração e supervisão. [1][4]

Esse é um relato significativo, mas não é um relatório forense completo. Ele não divulga a versão exata do software, a mudança de estado inicial, a falha de processo, a sequência de armazenamento, a semântica de replicação, a eleição no plano de controle, o comando humano, a cronologia de alarmes ou o registro interno do incidente. Ele não prova se a configuração perdida foi a única causa inicial ou uma consequência visível de uma falha de controle mais profunda.

A afirmação mais defensável é mais estreita: o equipamento óptico da OVH entrou em um estado no qual os enlaces externos de Roubaix ficaram indisponíveis; a OVH atribuiu esse estado a um defeito de software e à configuração ausente; a restauração da configuração salva devolveu a conectividade; e a OVH propôs posteriormente tanto a remediação de software quanto a separação arquitetural.

A rede em execução é a evidência primária. Registros de inventário podem dizer que fibras, caminhos, placas e backups existem. Documentos de projeto podem dizer que os enlaces são redundantes. O que importou durante o incidente foi que o sistema óptico deixou de fornecer a conectividade externa necessária para a alcançabilidade de Roubaix. O estado operacional prevaleceu sobre o diagrama nominal.

Esta é a questão central de responsabilização da infraestrutura de rede. A redundância não deve ser contada apenas por componentes. Ela deve ser avaliada pelos domínios de falha que podem remover o serviço.

Diversidade física não é independência de domínio de controle

O modelo visual comum de transporte resiliente é duas linhas entre duas localizações. Se uma fibra for cortada, o tráfego usa a outra. Esse modelo é útil para um risco físico estreito. Ele é incompleto quando ambos os caminhos compartilham software, autoridade de configuração, hardware de supervisão, sincronização, energia, acesso de gerenciamento, lógica de ativação ou um procedimento de recuperação comum.

Dois caminhos ópticos geograficamente distintos ainda podem ocupar um único domínio de falha operacional. Eles podem terminar em placas governadas pelo mesmo banco de dados. Podem depender do mesmo controlador ou par de supervisão. Podem receber a mesma imagem de software defeituosa. Podem herdar uma única transação de configuração. Podem exigir uma única rede de gerenciamento para diagnóstico. Podem falhar de forma segura quando um estado comum de segurança é acionado.

O relato da OVH é um exemplo concreto dessa distinção. O provedor descreveu conectividade óptica redundante, mas os enlaces de Roubaix ficaram indisponíveis em conjunto quando a configuração foi perdida. Os controles destinados a preservar a conectividade não contiveram a falha compartilhada de estado de configuração que de fato ocorreu. [1][4]

Isso não significa que a diversidade física foi inútil. Significa que ela tratava de um risco diferente. Alegações de resiliência devem nomear a classe de risco que contêm:

um único corte de fibra;
uma falha de duto ou de rota geográfica;
perda de um amplificador óptico ou nó;
perda de uma placa de linha ou chassis;
falha de um controlador ou placa de monitoramento;
configuração corrompida ou ausente;
um defeito de software comum;
perda de conectividade de gerenciamento;
erro de operador propagado entre sistemas redundantes;
falha de restauração em condições de incidente.

Um projeto pode passar nos três primeiros e falhar no sexto ou sétimo. Chamar o resultado deredundantesem nomear a classe de falha protegida oculta a questão mais importante.

A RFC 3439 alerta, em termos arquiteturais gerais, que a complexidade tem custos reais e que sistemas frequentemente falham em interações inesperadas. Ela não foi escrita sobre o incidente da OVH e não prova o projeto interno do provedor. Oferece uma disciplina analítica útil: adicionar componentes, cópias e automação pode criar estado compartilhado e modos adicionais de falha, a menos que seu comportamento seja limitado e observável. [14]

A orientação de sistemas ciber-resilientes do NIST trata a resiliência de forma semelhante, como uma capacidade projetada de antecipar, resistir, recuperar e adaptar-se. É um framework posterior, não evidência do que a OVH implantou em 2017. Aplicado com cuidado, sugere que uma rede deve ser julgada não apenas por alegações de prevenção, mas por limites de degradação, autoridade de recuperação, preservação de evidências e adaptação após a falha. [17]

A arquitetura de transporte óptico descrita pelas recomendações da ITU fornece vocabulário para camadas, relações de trilha e proteção. Ela não pode reconstruir a topologia privada da OVH a partir de fatos públicos. Seu valor aqui é reforçar um ponto geral: o transporte óptico é uma rede gerenciada com funções de controle, supervisão e recuperação, não apenas vidro passivo. [18]

O teste de responsabilização, portanto, é independência, não duplicação. Um operador deve ser capaz de identificar quais elementos são independentes, quais são intencionalmente compartilhados e o que acontece quando cada elemento compartilhado falha.

Configuração salva não equivalia a disponibilidade operacional

O relato do incidente da OVH diz que a configuração salva foi restaurada. Esse detalhe ilustra um problema recorrente na garantia de infraestrutura: a presença de backup é frequentemente tratada como equivalente à recuperabilidade.

Um backup pode existir e ainda assim não preservar o serviço. Ele pode estar armazenado dentro do mesmo domínio de falha. Suas réplicas podem estar sujeitas ao mesmo software defeituoso. Ele pode conter o mesmo estado corrompido. O sistema pode não conseguir selecioná-lo ou carregá-lo automaticamente. O acesso de gerenciamento pode estar indisponível. Operadores podem precisar de intervenção física. Procedimentos de restauração podem ser lentos, ambíguos ou não testados sob uma falha comum.

A narrativa de Roubaix indica que os engenheiros finalmente recuperaram a configuração salva. Essa foi uma ação de recuperação bem-sucedida. Ela também mostra que o sistema em execução não manteve disponibilidade apenas porque existia uma configuração recuperável. [1][4]

Os controles relevantes, portanto, são mais precisos do quehavia um backup:

Que objeto exato foi copiado: um banco de dados completo, uma configuração gerada, o estado do dispositivo ou o log de transações?
Qual processo gravou cada cópia, e um único defeito de software poderia corromper todas elas?
As cópias eram imutáveis ou versionadas de forma independente?
Elas estavam armazenadas em sistemas física e logicamente separados?
Que regra de consistência determinava se uma cópia era utilizável?
Era possível selecionar uma versão reconhecidamente boa sem o componente de gerenciamento que falhou?
A restauração era automática, aprovada por operador ou dependente de acesso local?
Quanto tempo levou uma restauração completa no último teste?
A restauração recriou o estado pretendido ou apenas o último estado replicado?
Que evidência confirmou que cada nó óptico e enlace voltado para roteadores retornou corretamente?

O material público responde apenas parte da lista. Ele mostra que a restauração de configuração era possível. Ele não mostra que a recuperação era independente, pré-autorizada, exercitada regularmente ou medida contra um objetivo de serviço.

Essa distinção deve afetar os relatórios para clientes e conselhos.A configuração tinha backupé uma declaração de inventário.Uma configuração reconhecidamente boa pode ser restaurada por um caminho de controle independente dentro de um tempo testado, preservando evidências e impedindo a reintrodução do estado ruimé uma declaração de controle operacional.

O transporte óptico fazia parte do serviço de hospedagem

A responsabilização de hospedagem é frequentemente discutida no nível de servidor ou data center. A falha de Roubaix mostra por que essa fronteira é estreita demais. Um servidor pode permanecer energizado e saudável enquanto se torna inalcançável porque o transporte óptico que conecta seu site a pontos de interconexão externos falhou.

O material público de peering da OVH e os registros atuais do PeeringDB e do RIPE identificam o AS16276 e uma pegada substancial de interconexão. Esses registros são úteis para identidade de rede e atribuição de operador. Eles ajudam um cliente ou investigador a distinguir a rede da OVH de outro provedor e a identificar localizações onde a interconexão pode ocorrer. Eles não provam o estado operacional de um circuito de Roubaix em 2017, o caminho usado por um determinado pacote ou a independência de quaisquer dois serviços de clientes. [8][9][10][11]

Esta é uma distinção da camada de realidade. Um registro ou diretório pode registrar quem opera um sistema autônomo. Uma página de peering pode descrever política. Um coletor de rotas pode preservar observações BGP selecionadas. Nenhum deles pode fazer um sistema óptico com falha transportar tráfego.

Inversamente, a falha óptica não apagou a identidade da rede. O número de AS, as rotas e as relações externas permaneceram evidências significativas para diagnosticar qual rede deveria originar e transportar tráfego. Registros e infraestrutura em execução servem a funções de responsabilização diferentes: registros identificam e preservam autoridade; sistemas em execução determinam se os pacotes se movem.

Clientes que compram hospedagemredundanteou múltiplos serviços de um provedor precisam perguntar se suas dependências convergem dentro do provedor. Duas máquinas virtuais em clusters separados podem compartilhar o mesmo transporte do site. Dois serviços em edifícios diferentes podem compartilhar um sistema óptico metropolitano. Dois caminhos anunciados podem convergir em um controlador ou banco de dados de configuração. Nomes de produtos e contagens de recursos não revelam essas dependências.

O relatório da Actility fornece uma visão externa instrutiva. Ele disse que alguns serviços ficaram inalcançáveis, enquanto uma oferta SaaS hospedada em outro data center não foi afetada. Também descreveu acessibilidade a partir de algumas localizações ou redes, mas não de outras. [4] Esse padrão é consistente com diversidade de dependências e caminhos, embora os dados públicos não sejam suficientes para mapear cada rota ou serviço.

A lição para o cliente não é simplesmenteuse dois provedores. O design com múltiplos provedores pode reduzir a concentração, mas cria sua própria complexidade de DNS, roteamento, consistência de dados, segurança e operação. O requisito mais forte é documentar fronteiras de dependência e testar a falha que importa.

O impacto deve permanecer ligado a evidências observáveis

A OVH reconheceu consequências diretas para outros serviços e disse que receber e-mails de clientes foi especialmente difícil. A empresa pediu desculpas e disse que suas equipes permaneceram mobilizadas. [1] A cobertura contemporânea descreveu um impacto significativo para clientes em todo o ambiente de Roubaix. [5][6][7]

As fontes públicas não fornecem uma contagem completa de clientes afetados, uma série temporal de perda de pacotes, uma análise rota por rota, um inventário de serviços, impacto de receita ou tabela final de SLA. Elas não estabelecem que todas as cargas de trabalho em Roubaix ficaram inalcançáveis durante todo o intervalo óptico. Também não estabelecem que um serviço estava saudável apenas porque uma sonda pública obteve sucesso.

Redes diferentes podem ter observado comportamentos diferentes. Políticas de roteamento, respostas DNS em cache, sessões existentes, localizações alternativas de serviço e lógica de repetição de aplicações podem afetar o impacto visível. Alguns clientes podem ter perdido todo o acesso. Outros podem ter alcançado um serviço por um caminho remanescente ou site separado. E-mails podem ficar na fila e chegar mais tarde, tornando a falha de transporte visível como atraso em vez de perda permanente.

A declaração correta de impacto tem três camadas:

Impacto de infraestrutura relatado pelo provedor:o site de Roubaix perdeu os enlaces ópticos externos descritos no relato da OVH.
Impacto de serviço observado externamente:clientes e pelo menos um provedor hospedado relataram inalcançabilidade parcial ou ampla e interrupção específica de serviço.
Impacto completo desconhecido:o registro público não enumera cada cliente, fluxo, rota, serviço ou consequência financeira afetada.

Preservar essas camadas evita tanto o eufemismo quanto o exagero. Dizer que o impacto completo é desconhecido não minimiza o evento. Perder os principais enlaces ópticos de um site é inerentemente grave. Também é desnecessário alegar uma interrupção universal quando a evidência não sustenta uma.

Um relatório de impacto responsável publicaria alcançabilidade delimitada no tempo a partir de redes independentes, estado de sessões BGP, disponibilidade de enlaces, tráfego agregado, backlog de e-mail, saúde dos principais serviços, volume de tickets de clientes e distribuições de restauração. Descreveria limites de amostragem e relógios. Separaria a recuperação de transporte da recuperação de aplicações.

Alocação de controle: responsabilidade distribuída não é responsabilidade ausente

A infraestrutura de rede cruza fronteiras organizacionais. Isso pode levar a uma conclusão vaga de que a responsabilidade foicompartilhada. Um método melhor aloca responsabilidade conforme o controle.

OVH

A OVH controlava a arquitetura de sua rede óptica de Roubaix, a relação entre caminhos físicos e sistemas de controle, a implantação de software dentro de seu escopo, a proteção de configuração, o monitoramento, a escalada de incidentes, a intervenção local, o sequenciamento de restauração, a comunicação com clientes e a decisão de mudar o design.

Esse controle cria obrigações específicas. A OVH precisava identificar domínios de falha comuns, implantar software com segurança, preservar configuração reconhecidamente boa, manter um caminho diagnóstico independente, testar restauração, definir expectativas de clientes e produzir evidências de que o design corrigido continha a recorrência.

A OVH não criou necessariamente o defeito de software do equipamento. Isso não remove sua responsabilidade arquitetural. Operadores escolhem como um defeito de fornecedor pode afetar seu serviço. Eles decidem se um defeito atinge todos os caminhos redundantes, se o rollback é possível e se um controlador com falha pode ser contornado.

O fabricante do equipamento

O fabricante do equipamento controlava a engenharia do produto, a análise do defeito, o software corrigido, os diagnósticos do fornecedor e a divulgação disponível para a OVH. O registro público diz que a OVH estava investigando com o fabricante e planejava atualizar o software afetado. [1][4]

Sem um relatório público do fornecedor, este artigo não pode alocar o erro exato de software nem afirmar se o defeito era conhecido anteriormente. O fabricante, no entanto, possuía a tarefa do lado do produto de identificar por que a configuração desapareceu ou se tornou inutilizável e demonstrar que o código corrigido impedia a falha.

Pares e provedores de trânsito

Operadores de rede externos controlavam seus próprios enlaces, sessões BGP, preferência de rota, monitoramento e escalada. Eles podiam observar a perda de alcançabilidade da OVH e se adaptar onde existisse interconexão alternativa. Não podiam restaurar a configuração óptica interna da OVH.

Práticas operacionais de BGP, como políticas explícitas de importação e exportação, são essenciais nas fronteiras interdomínios. A RFC 7454 e a RFC 8212 fornecem salvaguardas de roteamento posteriores ou gerais, não um diagnóstico deste evento óptico. Elas importam porque a restauração da luz não prova por si só a troca correta de rotas. Depois que as interfaces retornam, uma política de roteamento explícita ajuda a manter a recuperação de caminhos limitada. [15][16]

Clientes

Clientes controlavam a seleção do provedor, a localização do serviço, o monitoramento externo, o DNS e o failover de aplicações, a replicação de dados e sua própria comunicação de incidentes. Um cliente que comprou vários produtos da OVH poderia pedir evidências de que esses produtos não compartilhavam o domínio de falha óptica de Roubaix.

Clientes não controlavam o estado interno do equipamento óptico, o sistema de configuração nem a topologia óptica da OVH. Seria errado transferir a falha interna de transporte do provedor para os clientes porque eles poderiam ter comprado mais redundância. Resiliência do cliente e responsabilização do provedor são complementares, não substitutas.

Reguladores, diretórios e observadores

Registros, números de ASN e registros de peering apoiam a atribuição e a análise histórica. Plataformas de medição podem preservar observações de roteamento selecionadas. Organismos de normalização definem princípios úteis de design e operação. Nenhum deles operava o sistema de Roubaix nem podia restaurá-lo.

Essa alocação evita dois erros. O primeiro é tratar um bug de fornecedor como desculpa completa para a falha do provedor. O segundo é atribuir toda consequência à OVH sem reconhecer os controles de clientes e de interconexão fora de sua fronteira. A responsabilização segue a capacidade de prevenir, detectar, conter, recuperar e comprovar.

Detecção e diagnóstico fazem parte da superfície de controle

O registro público não divulga o primeiro alarme interno, seu timestamp, severidade, responsável ou qualidade diagnóstica. Sabemos que clientes viram inalcançabilidade e que a OVH mobilizou equipes. Não sabemos se o monitoramento identificou primeiro a perda de transporte óptico, a falha de gerenciamento, a perda de sessões de roteamento, o colapso de tráfego ou os sintomas dos clientes.

Essa evidência ausente importa porque o design da detecção influencia a duração da interrupção. Um alarme que dizhost inalcançávelé menos útil do que um registro correlacionado mostrando estado do controlador óptico, saúde do banco de dados, modo da placa, alcançabilidade de gerenciamento, estado da interface do roteador e perda de caminhos externos.

Falhas de controle comum também podem comprometer o monitoramento. Se a placa de monitoramento, a rede de gerenciamento ou o serviço de configuração compartilham o mesmo domínio de falha, o sistema pode perder tanto o serviço quanto a telemetria explicativa. Os engenheiros enfrentam então uma falha escura: sintomas amplos, acesso remoto incompleto e pressão para reiniciar equipamentos antes que evidências voláteis sejam preservadas.

Um caminho diagnóstico independente não deve significar apenas uma segunda interface no mesmo plano de controle. Ele deve ter acesso alimentado e gerenciado separadamente, dependências mínimas, uma fronteira de segurança conhecida e a capacidade de capturar estado quando o sistema primário estiver comprometido.

O design também precisa de autoridade operacional. Quem pode redefinir a configuração? Quais evidências devem ser capturadas primeiro? Qual versão reconhecidamente boa pode ser carregada? Quando a intervenção local é necessária? Como o risco de um reinício é ponderado contra a continuidade da interrupção? Um plano de recuperação que existe, mas não pode ser autorizado rapidamente, não é um controle eficaz.

A narrativa de Roubaix mostra que restaurar o sistema óptico exigiu mais do que observar que um backup existia. [4] Isso transforma o tempo de recuperação em um parâmetro arquitetural. Se a restauração depende de reiniciar e sequenciar vários componentes, essas dependências devem aparecer nos testes de resiliência e nos objetivos de serviço.

O reparo anunciado separou correção de defeito de controle de raio de impacto

O plano de ação formal da OVH para Roubaix tinha duas partes. A empresa planejava investigar e corrigir o defeito de software com o fabricante do equipamento por meio de uma atualização. Também acelerou um projeto para distribuir o sistema de multiplexação óptica em dois sistemas separados para limitar o escopo da falha. [1]

Essa separação é tecnicamente importante. A correção de software trata de um defeito conhecido. A separação arquitetural trata da incerteza, incluindo a possibilidade de outro defeito ou de uma falha diferente de controle comum.

Um patch de software não pode provar que uma classe inteira de falhas desapareceu. Ele pode corrigir um caminho no código enquanto deixa inalteradas as dependências compartilhadas de configuração, supervisão ou gerenciamento. Inversamente, dividir sistemas sem corrigir um defeito conhecido pode produzir dois sistemas que falham de forma independente se o mesmo software e estado forem implantados de forma idêntica.

Um programa de remediação forte testaria, portanto, ambas as dimensões.

Correção de defeito

Vincular o aviso ou registro de defeito do fornecedor à versão de software afetada.
Identificar a condição exata de falha, os componentes afetados e o comportamento corrigido.
Implantar a imagem corrigida em um sistema representativo.
Verificar migração de configuração, rollback e preservação de estado.
Exercitar a condição que anteriormente causava a perda de configuração.
Preservar logs mostrando que a falha não ocorre mais.

Separação de domínios de falha

Documentar quais caminhos ópticos terminam em cada sistema.
Separar controle, monitoramento, armazenamento de configuração e acesso de gerenciamento quando necessário.
Impedir que uma transação de configuração desabilite os dois sistemas.
Garantir que uma implantação de software possa ser canarizada e interrompida antes de atingir todos os caminhos.
Provar que a perda de um sistema deixa capacidade externa e alcançabilidade suficientes para o objetivo de serviço definido.
Testar o movimento de tráfego e a convergência de roteamento sob a topologia reduzida.

Evidências de recuperação

Restaurar uma configuração reconhecidamente boa sem depender do componente de controle que falhou.
Medir tempos de detecção, decisão, restauração, retorno de enlace e convergência de rotas.
Preservar somas de verificação e estado de topologia antes e depois.
Comparar o estado interno dos enlaces com sondas externas independentes.
Registrar erros residuais em vez de declarar tudo limpo no primeiro ping bem-sucedido.

A declaração pública da OVH documenta a intenção de fazer a divisão. As fontes congeladas para este artigo não fornecem data de conclusão, diagrama de implementação, teste independente ou exercício posterior de recorrência. A conclusão responsável é que a direção anunciada tratou da distinção de controle correta, embora sua eficácia permaneça não comprovada neste registro.

Como testar a independência da redundância

Um operador pode transformar o incidente em uma auditoria repetível construindo uma matriz de domínios de falha. Cada caminho relevante para o cliente é mapeado em relação a rota física, nós ópticos, placas de linha, chassis, sistemas de supervisão, armazenamentos de configuração, versão de software, rede de gerenciamento, energia, sincronização, grupo de operadores e autoridade de restauração.

A matriz deve responder a uma pergunta simples para cada par de caminhosredundantes: quais componentes ainda podem remover ambos?

Essa análise frequentemente revela dependências ocultas pelos diagramas de topologia. Fibras separadas podem entrar no mesmo edifício. Chassis separados podem usar um único controlador. Controladores separados podem compartilhar um cluster de banco de dados. Instâncias de software separadas podem receber uma configuração ruim de um pipeline de automação comum. Data centers separados podem depender de um serviço de DNS, identidade ou controle de rede.

A matriz é apenas uma hipótese até ser testada. Testes úteis incluem:

remover uma fibra física e verificar a proteção óptica automática;
remover um chassis e verificar se a capacidade permanece dentro do objetivo declarado;
isolar um controlador e verificar se o outro sistema continua sem convergência de estado insegura;
corromper ou reter uma réplica de configuração e verificar a seleção segura;
negar o caminho de gerenciamento primário e realizar o diagnóstico pelo caminho independente;
implantar uma imagem de software deliberadamente rejeitada em um canário e verificar a contenção da implantação;
restaurar uma configuração reconhecidamente boa sob pressão de tempo;
medir a convergência de BGP e do plano de dados a partir de redes independentes;
verificar se o status voltado ao cliente reflete o serviço observado, não apenas a saúde do dispositivo;
reter evidências suficientes para que um revisor externo reproduza a conclusão.

A condição de aprovação deve ser definida antes do teste.O tráfego se recuperoué vago demais. Uma condição útil declara capacidade mínima, perda máxima de alcançabilidade, perda de pacotes permitida, tempo de convergência, classes de serviço, pontos de observação externos e requisitos de retenção de evidências.

Os testes também devem considerar a manutenção. Muitas falhas comuns ocorrem durante atualizações ou mudanças de configuração, quando sistemas redundantes estão intencionalmente alinhados. Um design que sobrevive a uma perda aleatória de placa pode falhar quando um trabalho de automação comum empurra o mesmo estado ruim para ambos os lados.

Operação independente não exige que todos os componentes sejam diferentes. Heterogeneidade completa pode aumentar a complexidade e o erro. Exige que as dependências compartilhadas sejam explícitas, limitadas e compatíveis com a recuperação testada. O objetivo não é teatro de diversidade. É evidência de que uma falha plausível não pode silenciosamente derrotar todos os caminhos anunciados como redundantes.

Controles contrafactuais esclarecem as primeiras oportunidades perdidas

A análise contrafactual não deve fingir que um controle certamente teria evitado o evento. Ela pergunta onde controles observáveis poderiam ter mudado a sequência.

Se o defeito de software tivesse sido detectado antes da implantação

Um ambiente de staging representativo, uma implantação canário ou um teste de defeito do fornecedor poderiam ter exposto o estado de falha antes de alcançar o sistema de produção. A evidência pública não nos diz se o defeito exigia uma sequência rara impossível de reproduzir em staging. Esse contrafactual, portanto, é possível, não comprovado.

Se os sistemas ópticos tivessem estado de controle independente

Se dois grupos de caminhos tivessem autoridade de configuração e sistemas de supervisão separados, a perda de um banco de dados de configuração poderia ter deixado o outro grupo operacional. A divisão de sistema anunciada pela OVH sugere que a empresa viu valor em reduzir o escopo de falha comum. A topologia exata anterior ao incidente não é pública, de modo que a magnitude do contrafactual não pode ser calculada.

Se a restauração de configuração tivesse um caminho independente

Configuração reconhecidamente boa e imutável e um mecanismo de restauração fora de banda poderiam ter reduzido o tempo de diagnóstico e recuperação. O relato do incidente diz que a configuração salva foi finalmente restaurada. Ele não mostra se existia um caminho de restauração independente, como ele foi testado ou quanto da recuperação dependeu do ambiente de controle afetado.

Se os clientes tivessem caminhos de hospedagem independentes

Um cliente usando outro data center ou provedor poderia ter evitado parte do impacto no serviço. A Actility relatou que uma oferta SaaS em outro data center não foi afetada. [4] Essa observação apoia a diversificação de dependências, mas não prova que todo design multissite teria sucesso.

Se evidências externas de alcançabilidade tivessem sido integradas

Sondas independentes e observações de roteamento poderiam ter ajudado a distinguir a recuperação local do dispositivo da alcançabilidade do cliente. Elas não teriam restaurado os enlaces ópticos. Seu valor teria sido diagnóstico mais rápido, comunicação delimitada e prova mais forte de encerramento.

A primeira oportunidade perdida não pode ser nomeada de forma conclusiva a partir de evidências públicas. Ela pode ter sido garantia de software, arquitetura, proteção do estado de configuração, monitoramento, design de recuperação ou uma combinação. Um registro privado do incidente deve identificar o controle mais precoce que tinha autoridade e que poderia razoavelmente ter agido.

Evidências que mudariam a conclusão

A conclusão é deliberadamente falseável. Ela deve mudar se evidências mais fortes se tornarem disponíveis.

Logs de dispositivos e controladores podem mostrar que a perda de configuração foi consequência, não causa. Um relatório do fornecedor pode identificar uma condição específica de hardware ou software. Registros de topologia podem mostrar que os caminhos ópticos eram mais independentes do que o relato público implica, ou que outro componente compartilhado os removeu. Históricos de configuração podem mostrar que uma mudança humana, um trabalho de automação ou uma transição de estado desencadeou o evento.

Dados de clientes e medições podem revisar a fronteira de impacto. Uma análise completa de alcançabilidade pode mostrar isolamento quase universal de Roubaix, ou conectividade remanescente substancial. Dados de coletores BGP podem estabelecer quais sessões e caminhos externos mudaram, mas ainda precisariam de medições do plano de dados para sustentar conclusões de encaminhamento.

Evidências de remediação podem fortalecer ou enfraquecer a conclusão de responsabilização. Uma divisão de sistema concluída, testada de forma independente sob falhas de controlador e configuração, mostraria que a OVH converteu a lição em contenção. Um teste posterior mostrando que os dois sistemas ainda compartilhavam um domínio de falha mostraria que a duplicação não entregou independência.

O artigo não exige esses registros para afirmar que ocorreu uma falha grave de rede. Exige-os para tornar a alegação de reparo completa.

Conclusão

A interrupção de Roubaix da OVH não foi uma lição de que redundância é fútil. Foi uma lição de que a redundância deve ser descrita em termos das falhas que ela pode conter.

O provedor tinha conectividade óptica redundante e configuração salva. Esses controles tratavam de riscos reais. Eles não impediram que uma falha compartilhada de controle óptico removesse a conectividade de Roubaix, e a restauração ainda dependeu da recuperação da configuração.

O plano de ação posterior da OVH reconheceu as duas camadas do problema: corrigir o defeito de software e dividir o sistema de multiplexação óptica para que uma falha tenha escopo menor. Essa foi a separação conceitual correta. As evidências públicas neste conjunto de fontes não comprovam conclusão nem resistência a recorrências.

Para operadores de hospedagem e rede, o padrão de responsabilização é concreto. Nomeie as classes de falha protegidas. Mapeie os domínios de controle compartilhados. Preserve diagnóstico independente e recuperação reconhecidamente boa. Teste a perda de um sistema enquanto o outro transporta tráfego. Meça a alcançabilidade de fora do provedor. Publique evidências suficientes para distinguir duplicação de componentes de independência operacional.

Registros de identidade de rede e inventários de topologia podem mostrar quem opera a infraestrutura e o que deveria existir. Somente evidências de código em execução, alcançabilidade observada e restauração testada mostram se a infraestrutura continua a funcionar.

Falha na rede óptica da OVH em 2017 tornou a independência da redundância um teste de responsabilização

Por que isso importa