Figura 26-4. O percurso de um objeto desde a eliminação suave até à destruição

Primeira camada: Eliminação suave

Quando a velocidade é elevada e a privacidade é importante, os bugs nos aplicativos são responsáveis pela grande maioria dos eventos de perda e corrupção de dados. Na verdade, os bugs de eliminação de dados podem se tornar tão comuns que a capacidade de recuperar dados por um tempo limitado se torna a principal linha de defesa contra a maioria das perdas de dados permanentes e inadvertidas.

Qualquer produto que sustente a privacidade dos seus usuários deve permitir aos usuários apagar subconjuntos selecionados e/ou todos os seus dados. Tais produtos incorrem num encargo de apoio devido à eliminação acidental. Dar aos usuários a capacidade de anular a eliminação dos seus dados (por exemplo, através de uma pasta de lixo) reduz mas não pode eliminar completamente esta carga de suporte, particularmente se o seu serviço também suporta add-ons de terceiros que também podem apagar dados.

A eliminação suave pode reduzir drasticamente ou mesmo eliminar completamente esta carga de suporte. A eliminação suave significa que os dados apagados são imediatamente marcados como tal, tornando-os inutilizáveis por todos exceto pelos caminhos de código administrativo do aplicativo. Os caminhos de código administrativo podem incluir descoberta legal, recuperação de conta desviada, administração de empresas, apoio ao usuário, e resolução de problemas e suas características relacionadas. Conduza eliminação suave quando um usuário esvazia o seu lixo, e forneça uma ferramenta de apoio ao usuário que permita aos administradores autorizados anular qualquer item apagado acidentalmente pelos usuários. A Google implementa esta estratégia para os nossos aplicativos de produtividade mais populares; caso contrário, a carga de engenharia de apoio ao usuário seria insustentável.

É possível alargar ainda mais a estratégia de eliminação suave, oferecendo aos usuários a opção de recuperar os dados eliminados. Por exemplo, a lixeira do Gmail permite que os usuários acessem mensagens que foram excluídas há menos de 30 dias.

Outra fonte comum de eliminação de dados indesejados ocorre como resultado de sequestro de conta. Em cenários de sequestro de conta, um sequestrador apaga normalmente os dados do usuário original antes de utilizar a conta para fins de spam e outros fins ilícitos. Quando se combina a uniformidade da eliminação acidental do usuário com o risco de eliminação de dados por sequestradores, torna-se claro o caso de uma interface programática de eliminação suave e de anulação de eliminação dentro e/ou por baixo de seu aplicativo.

A eliminação suave implica que, uma vez marcados como tal, os dados são destruídos após um atraso razoável. A duração do atraso depende das políticas e leis aplicáveis de uma organização, dos recursos e custos de armazenamento disponíveis, dos preços dos produtos e do posicionamento no mercado, especialmente em casos que envolvam muitos dados de curta duração. As escolhas comuns de atrasos de eliminação suaves são 15, 30, 45, ou 60 dias. Na experiência da Google, a maioria dos desvios de conta e problemas de integridade de dados são comunicados ou detectados no prazo de 60 dias. Por conseguinte, o caso de apagamento suave de dados por mais de 60 dias pode não ser forte.

O Google descobriu também que os casos mais devastadores de eliminação aguda de dados são causados por criadores de aplicativos não familiarizados com o código existente, mas que trabalham em códigos relacionados com a eliminação, especialmente pipelines de processamento de lotes (por exemplo, um pipeline MapReduce ou Hadoop offline). É vantajoso projetar as suas interfaces para impedir os programadores não familiarizados com o seu código de contornar as características de eliminação suave com novo código. Uma forma eficaz de conseguir isso é implementar ofertas de computação em nuvem que incluam APIs de eliminação suave built-in e anulação de eliminação, assegurando a ativação da referida funcionalidade. Mesmo a melhor armadura é inútil se não a colocar.

As estratégias de eliminação suave abrangem funcionalidades de eliminação de dados em produtos de consumo como o Gmail ou Google Drive, mas e se, em vez disso, suportar uma oferta de computação em nuvem? Assumindo que a sua oferta de computação em nuvem já suporta uma funcionalidade de eliminação e anulação programática com padrões razoáveis, os restantes cenários de eliminação acidental de dados terão origem em erros cometidos pelos seus próprios programadores internos ou pelos seus clientes programadores.

Em tais casos, pode ser útil introduzir uma camada adicional de eliminação suave, que designaremos por “eliminação lenta”. Pode pensar na eliminação lenta como eliminação nos bastidores, controlado pelo sistema de armazenamento (enquanto a eliminação suave é controlada e expressa para o aplicativo ou serviço do cliente). Num cenário de eliminação lenta, os dados que são apagados por um aplicativo de nuvem tornam-se imediatamente inacessíveis ao aplicativo, mas são preservados pelo fornecedor do serviço de nuvem por até algumas semanas antes da destruição. A eliminação lenta não é aconselhável em todas as estratégias de defesa em profundidade: um longo período de eliminação lenta é caro em sistemas com muitos dados de curta duração, e impraticável em sistemas que devem garantir a destruição dos dados eliminados dentro de um prazo razoável (ou seja, aqueles que oferecem garantias de privacidade).

Para resumir a primeira camada de defesa em profundidade:

• Uma pasta de lixo que permite aos usuários anular os dados é a principal defesa contra o erro do usuário.
• A eliminação suave é a defesa primária contra erro do programador e a defesa secundária contra erro do usuário.
• Nas ofertas do desenvolvedor, a eliminação lenta é a principal defesa contra erros internos do desenvolvedor e a defesa secundária contra erros externos do desenvolvedor

E o histórico da revisão? Alguns produtos fornecem a capacidade de reverter itens para estados anteriores. Quando tal recurso está disponível para os usuários, é uma forma de lixo. Quando disponível para os criadores, pode ou não substituir a eliminação suave, dependendo da sua implementação.

No Google, o histórico de revisões revelou-se útil na recuperação de certos cenários de corrupção de dados, mas não na recuperação da maioria dos cenários de perda de dados envolvendo eliminação acidental, programática ou outra. Isto porque algumas implementações do histórico de revisões tratam a eliminação como um caso especial em que os estados anteriores devem ser removidos, por oposição à alteração de um item cujo histórico pode ser retido durante um determinado período de tempo. Para proporcionar proteção adequada contra eliminação indesejada, aplicar os princípios de eliminação lenta e/ou suave também ao histórico de revisões.

Segunda camada: Backups e seus métodos de recuperação relacionados

Os backups e a recuperação de dados são a segunda linha de defesa após a eliminação suave. O princípio mais importante nesta camada é que os backups não importam; o que importa é a recuperação. Os fatores que apoiam uma recuperação bem sucedida devem orientar as suas decisões de backup, e não o contrário.

Em outras palavras, os cenários em que pretende que os seus backups o ajudem a recuperar devem ditar o seguinte:

• Quais os métodos de backup e recuperação a utilizar
•  Com que frequência você estabelece pontos de restauração fazendo backups completos ou incrementais de seus dados
• Onde se guardam os backups 
• Por quanto tempo se mantêm os backups 

Quantos dados recentes você pode perder durante um esforço de recuperação?  Quanto menos dados você puder perder, mais sério você deve ser sobre uma estratégia de backup incremental.  Em um dos casos mais extremos do Google, usamos uma estratégia de backup de streaming quase em tempo real para uma versão mais antiga do Gmail.

Mesmo que o dinheiro não seja uma limitação, backups completos frequentes são caros de outras maneiras. Sobretudo, impõem uma carga computacional sobre os datastores ativos do seu serviço enquanto este serve os usuários, aproximando o seu serviço da sua escalabilidade e limites de desempenho. Para aliviar essa carga, você pode fazer backups completos fora do horário de pico, e depois uma série de backups incrementais quando o seu serviço estiver mais ocupado.

Com que rapidez precisa se recuperar? Quanto mais rápido os seus usuários precisarem ser resgatados, mais locais seus backups deverão ser. Muitas vezes, o Google retém snapshots caros, mas rápidos de recuperar durante períodos de tempo muito curtos dentro da instância de armazenamento, e armazena backups menos recentes em armazenamento distribuído de acesso aleatório dentro do mesmo (ou próximo) datacenter durante um tempo ligeiramente mais longo. Tal estratégia por si só não protegeria de falhas ao nível do site, portanto, esses backups são frequentemente transferidos para locais próximos ou offline durante um período de tempo mais longo antes de expirarem em favor de backups mais recentes.

Até onde seus backups devem chegar?  Sua estratégia de backup se torna mais cara à medida que você recua, enquanto os cenários dos quais você pode esperar para recuperar aumentam (embora esse aumento esteja sujeito a retornos decrescentes).

Na experiência do Google, os bugs de baixo grau de mutação ou eliminação de dados dentro no código do aplicativo exigem o maior alcance no tempo, uma vez que alguns desses bugs foram notados meses após o início da primeira perda de dados. Esses casos sugerem que você gostaria de poder voltar no tempo o máximo possível.

Por outro lado, num ambiente de desenvolvimento de alta velocidade, alterações no código e no esquema podem tornar os backups mais antigos caros ou impossíveis de usar. Além disso, é um desafio recuperar diferentes subconjuntos de dados para diferentes pontos de restauração, pois isso envolveria vários backups. No entanto, este é exatamente o tipo de esforço de recuperação exigido por cenários de corrupção ou eliminação de dados de baixo grau.

As estratégias descritas na Terceira Camada: A detecção precoce destina-se a acelerar a detecção de bugs de mutação ou eliminação de dados de baixo grau no código do aplicativo, evitando, pelo menos em parte, a necessidade deste tipo de esforço complexo de recuperação. Ainda assim, como se confere proteção razoável antes de saber quais tipos de problemas detectar? O Google escolheu traçar a linha entre 30 e 90 dias de backups para muitos serviços. Onde um serviço se enquadra nessa janela depende da sua tolerância à perda de dados e dos seus relativos investimentos na detecção precoce.

Para resumir o nosso conselho de proteção contra as 24 combinações de modos de falha de integridade de dados: abordar uma vasta gama de cenários a um custo razoável exige uma estratégia de backup por camadas. A primeira camada compreende muitos backups frequentes e rapidamente restaurados, armazenados mais perto dos datastores ativos, talvez utilizando as mesmas ou similares tecnologias de armazenamento das fontes de dados. Isso confere proteção contra a maioria dos cenários envolvendo bugs de software e erros do desenvolvedor. Devido a despesas relativas, os backups são retidos neste nível durante horas a dias de um dígito, e podem levar alguns minutos para serem restaurados.

A segunda camada compreende menos backups retidos por dias de um ou dois dígitos, em sistemas de ficheiros distribuídos localmente para o site. Esses backups podem levar horas para serem restaurados e conferir proteção adicional contra acidentes que afetam tecnologias de armazenamento específicas na sua pilha de servidores, mas não as tecnologias utilizadas para conter os backups. Esta camada também protege contra bugs em seu aplicativo que são detectados tarde demais para depender do primeira camada da sua estratégia de backup. Se estiver introduzindo novas versões do seu código para produção duas vezes por semana, pode fazer sentido manter esses backups por pelo menos uma semana ou duas antes de excluí-los.

As camadas subsequentes aproveitam o armazenamento próximo da linha, tais como bibliotecas de fitas dedicadas e armazenamento externo dos suportes de backup (por exemplo, fitas ou unidades de disco). Os backups nestas camadas conferem proteção contra problemas ao nível do site, tais como uma falha de energia do datacenter ou corrupção do sistema de ficheiros distribuídos devido a um bug.

É caro mover grandes quantidades de dados de e para as camadas. Por outro lado, a capacidade de armazenamento nas camadas mais avançadas não compete com o crescimento das instâncias de armazenamento de produção ativos do seu serviço. Como resultado, os backups nestss camadas tendem a ser feitos com menos frequência, mas retidos por mais tempo.

Camada superior: Replicação

Num mundo ideal, cada instância de armazenamento, incluindo as instâncias que contêm seus backups, seriam replicadas. Durante um esforço de recuperação de dados, a última coisa que quer é descobrir que seus próprios backups perderam os dados necessários ou que o datacenter que contém o backup mais útil está em manutenção.

À medida que o volume de dados aumenta, a replicação de cada instância de armazenamento nem sempre é viável. Nesses casos, faz sentido escalonar backups sucessivos em sites diferentes, cada um dos quais pode falhar independentemente, e gravar seus backups usando um método de redundância, como RAID, códigos de eliminação Reed-Solomon ou replicação no estilo GFS.

Ao escolher um sistema de redundância, não confie num esquema pouco utilizado, cujos únicos “testes” de eficácia são as suas próprias tentativas esporádicas de recuperação de dados. Em vez disso, escolha um esquema popular que seja de uso comum e contínuo por muitos dos seus usuários.

1T Versus 1E: Não “Apenas” um Backup Maior

Os processos e práticas aplicados a volumes de dados medidos em T (terabytes) não são bem dimensionados para dados medidos em E (exabytes). Validar, copiar, e executar testes de ida e volta em alguns gigabytes de dados estruturados é um problema interessante. No entanto, assumindo que tem conhecimento suficiente do seu esquema e modelo de transação, este exercício não apresenta quaisquer desafios especiais. Normalmente só precisa obter os recursos da máquina para iterar sobre os seus dados, executar alguma lógica de validação, e delegar armazenamento suficiente para manter algumas cópias dos seus dados.

Agora vamos aumentar a aposta: em vez de alguns gigabytes, vamos tentar assegurar e validar 700 petabytes de dados estruturados. Assumindo um desempenho SATA 2.0 ideal de 300 MB/s, uma única tarefa que itera todos os seus dados e executa mesmo as verificações de validação mais básicas demorará 8 décadas. Fazer alguns backups completos, assumindo que tem os meios de comunicação, vai demorar pelo menos o mesmo tempo. O tempo de restauração, com algum pós-processamento, demorará ainda mais tempo. Agora, estamos analisando quase um século inteiro para restaurar um backup que tinha até 80 anos quando começou a restauração. Obviamente, uma tal estratégia precisa ser repensada.

A técnica mais comum e largamente eficaz utilizada para fazer o backup de enormes quantidades de dados é estabelecer “pontos de confiança” nas suas porções de dados armazenados que são verificados depois de se tornarem imutáveis, geralmente com o passar do tempo. Quando sabemos que um determinado perfil de usuário ou transação é fixo e não será sujeito a mais alterações, podemos verificar o seu estado interno e fazer cópias adequadas para efeitos de recuperação. Poderá então fazer backups incrementais que apenas incluem dados que tenham sido modificados ou adicionados desde o seu último backup. Esta técnica alinha o seu tempo de backup com o seu tempo de processamento “principal”, o que significa que os backups incrementais frequentes podem salvá-lo do trabalho de verificação e cópia monolítica de 80 anos.

No entanto, lembre-se que nos preocupamos com restaurações, não com backups. Digamos que fizemos um backup completo há três anos e desde então fazemos backups incrementais diários. Uma restauração completa dos nossos dados processará em série uma cadeia de mais de 1.000 backups altamente interdependentes. Cada backup independente incorre em risco adicional de falha, para não mencionar o fardo logístico da programação e o custo do tempo de execução desses trabalhos.

Outra maneira de reduzir o tempo total de nossos trabalhos de cópia e verificação é distribuir a carga. Se partirmos bem os nossos dados, é possível executar N tarefas em paralelo, sendo cada tarefa responsável pela cópia e verificação de 1/N dos nossos dados. Fazer isso requer alguma premeditação e planejamento no design do esquema e na implantação física de nossos dados para:

• Equilibrar corretamente os dados
• Assegurar a independência de cada fragmento
• Evitar a contenda entre as tarefas irmãs paralelas 

Entre distribuir a carga horizontalmente e restringir o trabalho a fatias verticais dos dados demarcados pelo tempo, podemos reduzir essas oito décadas de tempo total  em várias ordens de magnitude, tornando as nossas restaurações relevantes.

Terceira camada: Detecção precoce

Os dados “ruins” não ficam parados, se propagam. As referências a dados ausentes ou corrompidos são copiadas, os links se espalham e, a cada atualização, a qualidade geral do seu datastore diminui. As transações dependentes subsequentes e as possíveis alterações no formato de dados tornam a restauração de um determinado backup mais difícil à medida que o relógio avança. Quanto mais cedo souber de uma perda de dados, mais fácil e completa poderá ser a sua recuperação. 

Desafios enfrentados pelos criadores de cloud

Em ambientes de alta velocidade, os serviços de aplicativos e infraestruturas em nuvem enfrentam muitos desafios de integridade de dados em tempo de execução, como por exemplo:

• Integridade referencial entre datastores
• Alterações do esquema
• Código de Envelhecimento
• Migrações de dados sem tempo de inatividade
• Pontos de integração evolutivos com outros serviços

Sem um esforço de engenharia consciente para acompanhar as relações emergentes nos seus dados, a qualidade dos dados de um serviço bem sucedido e em crescimento degrada-se com o tempo.

Muitas vezes, o desenvolvedor de nuvem iniciante que escolhe um API de armazenamento consistente distribuído (como a Megastore) delega a integridade dos dados do aplicativo ao algoritmo consistente distribuído implementado sob o  API (como o Paxos; ver Capítulo 23). As razões do programador são que só o API selecionado irá manter os dados do aplicativo em boa forma. Como resultado, eles unificam todos os dados do aplicativo numa única solução de armazenamento que garante a consistência distribuída, evitando problemas de integridade referencial em troca de um desempenho e/ou escala reduzidos.

Embora tais algoritmos sejam infalíveis em teoria, as suas implementações são muitas vezes repletas de hacks, otimização, bugs, e suposições educadas. Por exemplo: em teoria, Paxos ignora nós de computação com falhas e pode fazer progressos desde que se mantenha um quórum de nós funcionais. Na prática, contudo, ignorar um nó com falha pode corresponder a timeouts, novas tentativas, e outras abordagens de tratamento de falhas sob a implementação particular de Paxos . Por quanto tempo o Paxos deve tentar entrar em contato com um nó que não responde antes de expirar?  Quando uma determinada máquina falha (talvez intermitentemente) de uma certa forma, com um determinado tempo, e num determinado datacenter, o resultado é um comportamento imprevisível.  Quanto maior a escala de um aplicativo, mais frequentemente o aplicativo é afetado, sem o conhecimento, por tais inconsistências. Se esta lógica se mantém verdadeira mesmo quando aplicada a implementações do Paxos (como tem sido verdade para o Google), então deve ser mais verdadeira para implementações eventualmente consistentes, tais como a Bigtable (que também se tem mostrado verdadeira). Os aplicativos afetados não têm como saber se 100% de seus dados são bons até que verifiquem: confie nos sistemas de armazenamento, mas verifique!

Para complicar este problema, a fim de recuperar de cenários de corrupção ou eliminação de dados de baixo grau, devemos recuperar diferentes subconjuntos de dados para diferentes pontos de restauração usando backups diferentes, enquanto alterações no código e no esquema podem tornar os backups mais antigos ineficazes em ambientes de alta velocidade.

Validação de dados fora da banda

Para evitar que a qualidade dos dados se degrade perante os olhos dos usuários, e para detectar cenários de corrupção ou perda de dados de baixo grau antes que se tornem irrecuperáveis, é necessário um sistema de verificações e equilíbrios fora da banda, tanto dentro como entre os datastores de um aplicativo.

Na maioria das vezes, esses pipelines de validação de dados são implementados como coleções de reduções de mapa ou trabalhos do Hadoop. Frequentemente, tais pipelines são adicionados como uma consideração posterior a serviços que já são populares e bem sucedidos. Às vezes, esses pipelines são tentados pela primeira vez quando os serviços atingem os limites de escalabilidade e são reconstruídos do zero. A Google construiu validadores em resposta a cada uma destas situações.

Desviar alguns desenvolvedores para trabalhar em um pipeline de validação de dados pode diminuir a velocidade da engenharia no curto prazo. No entanto, dedicar recursos de engenharia à validação de dados dá a outros programadores a coragem de avançar mais rapidamente a longo prazo, porque os engenheiros sabem que os bugs de corrupção de dados têm menos probabilidades de entrar furtivamente na produção sem serem notados. Semelhante aos efeitos desfrutados quando os testes de unidades são introduzidos no início do ciclo de vida do projeto, um pipeline de validação de dados resulta numa aceleração global dos projectos de desenvolvimento de software.

Para citar um exemplo específico: O Gmail dispõe de uma série de validadores de dados, cada um dos quais detectou problemas reais de integridade de dados na produção. Os programadores do Gmail obtêm conforto do conhecimento de que os erros que introduzem inconsistências nos dados de produção são detectados em 24 horas, e tremem só de pensar em utilizar os seus validadores de dados com menos frequência do que diariamente. Estes validadores, juntamente com uma cultura de testes unitários e de regressão e outras melhores práticas, deram aos programadores do Gmail a coragem de introduzir alterações de código na implementação de armazenamento de produção do Gmail com mais frequência do que uma vez por semana.

A validação de dados fora da banda é complicada de implementar corretamente. Quando alterações muito rigorosas, mesmo simples e apropriadas, fazem com que a validação falhe. Como resultado, os engenheiros abandonam completamente a validação de dados. Se a validação de dados não for suficientemente rigorosa, a experiência do usuário – que afeta a corrupção de dados – pode passar despercebida. Para encontrar o equilíbrio certo, valide invariantes que causam devastação aos usuários.

Por exemplo, o Google Drive valida periodicamente o conteúdo do ficheiro alinhado com as listagens nas pastas do Drive. Se estes dois elementos não se alinharem, alguns ficheiros ficariam sem dados – um resultado desastroso. Os criadores de infraestruturas do Drive investiram tanto na integridade dos dados que também aprimoraram seus validadores para corrigir automaticamente essas inconsistências. Esta salvaguarda transformou uma potencial situação de emergência “todos-se-empenhem-arquivos-omigosh-estão-desaparecendo!!” de perda de dados em 2013 numa situação de “vamos para casa e corrigir a causa raiz na segunda-feira”. Ao transformar emergências em negócios como sempre, os validadores melhoram o moral da engenharia, a qualidade de vida e a previsibilidade.

Os validadores fora da banda podem ser caros em escala. Uma parte significativa do volume de recursos de computação do Gmail é compatível com uma coleção de validadores diários. Para agravar esta despesa, estes validadores também reduzem as taxas de acerto da cache do lado do servidor, reduzindo a capacidade de resposta do lado do servidor experimentada pelos usuários. Para atenuar esse impacto na capacidade de resposta, o Gmail fornece vários botões para limitar a taxa de seus validadores e refatora periodicamente os validadores para reduzir a contenção do disco. Num desses esforços de refatoração, reduzimos a contenção de fusos de disco em 60% sem reduzir significativamente o âmbito dos invariantes que cobriam. Embora a maioria dos validadores do Gmail seja executada diariamente, a carga de trabalho do maior validador é dividida em 10 a 14 fragmentos, com um fragmento validado por dia por motivos de escala.

O Google Compute Storage é outro exemplo dos desafios que a escala implica para a validação de dados. Quando os seus validadores fora da banda já não podiam terminar dentro de um dia, os engenheiros da Compute Storage tiveram de conceber uma forma mais eficiente de verificar os seus metadados do que apenas a utilização da força bruta. Semelhante à sua aplicação na recuperação de dados, uma estratégia por níveis também pode ser útil na validação de dados fora da banda. À medida que um serviço cresce, sacrifique o rigor nos validadores diários. Certifique-se de que os validadores diários continuam a capturar os cenários mais desastrosos dentro de 24 horas, mas continue com uma validação mais rigorosa com uma frequência reduzida para conter os custos e a latência.

A resolução de problemas de validação com falha pode exigir um esforço significativo. As causas de uma validação com falha intermitente podem desaparecer em minutos, horas, ou dias. Por conseguinte, a capacidade de pesquisar rapidamente nos logs de auditoria de validação é essencial. Os serviços maduros do Google fornecem aos engenheiros de plantão documentação abrangente e ferramentas para a resolução de problemas. Por exemplo, são fornecidos engenheiros de plantão para o Gmail:

• Um conjunto de entradas de playbook descrevendo como responder a um alerta de falha de validação
• Uma ferramenta de investigação do tipo BigQuery
• Um painel de validação de dados

A validação eficaz de dados fora da banda exige tudo o que se segue:

• Gestão de trabalhos de validação
• Monitorização, alertas, e painéis de bordo
• Características limitadoras da taxa
• Ferramentas de resolução de problemas
• Playbook de produção
• APIs de validação de dados que facilitam a adição e refatoração de validadores

A maioria das pequenas equipes de engenharia que operam a alta velocidade não se podem dar ao luxo de conceber, construir e manter todos estes sistemas. Se forem pressionadas a fazê-lo, o resultado é muitas vezes frágil, limitado, e desperdiçador, que rapidamente cai em desuso. Portanto, estruture as suas equipes de engenharia de modo que uma equipe central de infraestruturas forneça um quadro de validação de dados para múltiplas equipes de engenharia de produtos. A equipe central de infraestruturas mantém a estrutura de validação de dados fora da banda, enquanto as equipes de engenharia de produtos mantêm a lógica comercial personalizada no coração do validador para acompanharem a evolução dos seus produtos.

Sabendo que a recuperação de dados irá funcionar

Quando é que uma lâmpada quebra? Ao acender o interruptor não liga a luz? Nem sempre – muitas vezes a lâmpada já tinha falhado, e você simplesmente percebe a falha ao apertar o interruptor sem resposta. Nessa altura, a sala já está escura e o dedo do pé já se encontra preso.

Da mesma forma, as suas dependências de recuperação (ou seja, na sua maioria, mas não só, o seu backup), podem estar num estado latente quebrado, do qual não tem conhecimento até tentar recuperar os dados.

Se descobrir que o seu processo de recuperação está quebrado antes de precisar dele, pode resolver a vulnerabilidade antes de ser vítima: pode fazer outro backup, fornecer recursos adicionais, e alterar o seu SLO. Mas para realizar essas ações de forma proativa, primeiro tem de saber que elas são necessárias. Para detectar estas vulnerabilidades:

• Teste continuamente o processo de recuperação como parte das suas operações normais
• Estabeleça alertas que disparam quando um processo de recuperação não fornece uma indicação do seu sucesso

O que pode dar errado no seu processo de recuperação? Tudo e qualquer coisa – e é por isso que o único teste que deve deixá-lo dormir à noite é um teste completo de ponta a ponta. Que a prova esteja no pudding. Mesmo que tenha tido uma recuperação bem sucedida recentemente, partes do seu processo de recuperação ainda podem quebrar. Se retirar apenas uma lição deste capítulo, lembre-se que só sabe que pode recuperar o seu estado recente se o fizer de fato.

Se os testes de recuperação forem um evento manual, encenado, o teste se torna um trabalho indesejável que não é realizado com profundidade ou frequência suficiente para merecer sua confiança. Portanto, automatize estes testes sempre que possível e depois execute-os continuamente.

Os aspectos do seu plano de recuperação que deve confirmar são inúmeros:

• As suas cópias de segurança são válidas e completas, ou estão vazias?
• Tem recursos de máquina suficientes para executar todas as tarefas de configuração, restauração e pós-processamento que compõem a sua recuperação?
• O processo de recuperação é concluído em tempo total razoável?
• É capaz de monitorizar o estado do seu processo de recuperação à medida que este avança?
• Está livre de dependências críticas de recursos fora do seu controle, tais como o acesso a um cofre de armazenamento de meios fora do local que não está disponível 24 horas por dia, 7 dias por semana?

Os nossos testes descobriram as falhas acima mencionadas, bem como falhas de muitos outros componentes de uma recuperação de dados bem sucedida. Se não tivéssemos descoberto estas falhas em testes regulares – isto é, se nos deparássemos com as falhas apenas quando precisássemos recuperar dados de usuários em situações de emergência reais – é bem possível que alguns dos produtos mais bem sucedidos da Google hoje em dia possam não ter resistido ao teste do tempo.

As falhas são inevitáveis. Se esperarmos para as descobrir quando estiver sob a mira, enfrentando uma perda real de dados, estará brincando com fogo. Se o teste forçar as falhas a acontecerem antes que ocorra uma catástrofe real, você pode corrigir os problemas antes que qualquer dano se concretize.