◇ OpenCyber Academy
Engenharia · Capítulo 47 · Português

Capítulo 47 — Ensaio de falha e recuperação

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 47 — Ensaio de falha e recuperação

Mapa da aula

Aula 47 publicada. Mapa, exemplo, EX139.

flowchart TD
  N0["47.1 Finalidade"]
  N1["47.2 Cenário"]
  N2["47.4 Execução"]
  N3["47.5 Correção durante o ensaio"]
  N4["47.6 Reunião de avaliação"]
  N5["47.7 Registro"]
  N6["47.8 Frequência"]
  N7["Papel da observadora"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX139"]

Desenho lógico

flowchart LR
  N0["47.1 Finalidade"]
  N1["47.2 Cenário"]
  N2["47.4 Execução"]
  N3["47.5 Correção durante o ensaio"]
  N4["47.6 Reunião de avaliação"]
  N5["47.7 Registro"]
  N6["47.8 Frequência"]
  N7["Papel da observadora"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX139"]

[47.1 Finalidade]
    |
    v
[47.2 Cenário]
    |
    v
[47.4 Execução]
    |
    v
[47.5 Correção durante o ensaio]
    |
    v
[47.6 Reunião de avaliação]
    |
    v
[47.7 Registro]
    |
    v
[47.8 Frequência]
    |
    v
[Papel da observadora]
    |
    v
[Exemplo resolvido] --> [Exercício EX139]

Objetivos de aprendizagem

Você vai (1) desenhar um ensaio de falha controlado; (2) executar a recuperação sob observação; (3) medir a recuperação em relação aos objetivos; (4) melhorar os procedimentos a partir dos resultados.

47.1 Finalidade

Os testes de restauração conferem os backups; um ensaio de falha confere a resposta da organização inteira: pessoas, procedimentos e sistemas juntos. Um teste de restauração pode passar e, ainda assim, uma interrupção real correr mal: a pessoa que conhece o procedimento está de licença, falta uma peça no hardware reserva ou ninguém avisa os tribunais sobre os atrasos. Um ensaio expõe essas lacunas ao fazer as pessoas que de fato responderiam executarem o trabalho em condições realistas. Ele é planejado com antecedência, para que nenhuma evidência real seja posta em risco, mas é levado a sério o bastante para mostrar fraquezas genuínas.

47.2 Cenário

Num sábado planejado, o servidor do EvidenceDesk é declarado perdido (desligado e tratado como destruído). O responsável de TI, com Priya apenas observando, precisa restaurar o serviço numa máquina reserva, verificar todos os registros contra as âncoras e retomar a entrada. Tratar o servidor como destruído significa que nada pode ser copiado dele, nem mesmo um arquivo de configuração rápido, porque um incêndio ou um furto não permitiria esse atalho. Escolher um sábado deixa os casos sem impacto. Priya observa sem ajudar, porque sua presença como autora do sistema esconderia se a documentação sozinha é suficiente. Ela registra o início e o fim de cada passo e cada ponto em que o responsável de TI hesita ou consulta suas anotações.

47.3 Objetivos

Recuperação em até quatro horas; zero perda de registros; as âncoras conferem; os peritos conseguem retomar o trabalho. Quatro horas corresponde à meta de restauração definida antes para a confiabilidade, então o ensaio testa um compromisso real, e não um número arbitrário. A perda zero de registros é conferida comparando o comprimento e o último elo da cadeia restaurada com a última âncora. Retomar o trabalho significa que um perito de teste consegue abrir um registro, verificar uma cópia de trabalho e acrescentar uma entrada, o que mostra que todo o fluxo, e não só o banco de dados, voltou a funcionar.

47.4 Execução

O responsável de TI segue o procedimento. A restauração a partir do backup de gravação única mais recente leva 40 minutos; a verificação da cadeia, 3 minutos. A última âncora coincide. Um passo falha: o relógio da máquina reserva está 9 minutos atrasado, o que carimbaria as novas entradas de forma errada. Quarenta minutos para a restauração e três para a verificação da cadeia deixam uma folga ampla em relação à meta de quatro horas. O problema do relógio é o resultado mais instrutivo: nada no procedimento de restauração conferia a hora, e um relógio atrasado teria produzido entradas de custódia que parecem vir antes de eventos que na verdade seguiram. Esse tipo de erro de ordenação é exatamente o que um perito da defesa procuraria, então ele importa mesmo sem nenhuma perda de dados.

47.5 Correção durante o ensaio

O responsável de TI sincroniza a hora antes de retomar a entrada, como a lista de verificação deveria ter exigido. Tempo total até a retomada: 2 horas e 10 minutos. Corrigir o relógio na hora foi o certo, porque o objetivo era retomar o serviço corretamente, e de outro modo o ensaio terminaria com uma falha conhecida ainda presente. O responsável de TI registra o desvio encontrado, a fonte usada para a sincronização e o horário em que a correção foi feita. Duas horas e dez minutos ficam bem dentro da meta, e o relatório do ensaio observa que cerca de metade desse tempo foi para trabalho de configuração não planejado na máquina reserva.

47.6 Reunião de avaliação

O que deu certo, o que não deu, ações. Ação: acrescentar uma verificação de sincronização da hora à lista de verificação da recuperação e à inicialização do EvidenceDesk (recusar gravações se o desvio passar de um minuto). A reunião de avaliação acontece na mesma tarde, com as lembranças ainda frescas, com o responsável de TI, o gerente da qualidade e Priya. Cada ação tem um responsável e uma data. Colocar a verificação de desvio no próprio EvidenceDesk, e não só na lista de verificação, significa que a salvaguarda funciona mesmo que um administrador futuro pule um passo. O limite de um minuto foi escolhido porque as entradas são registradas com precisão de minuto, então um desvio menor não mudaria a sua ordem.

47.7 Registro

O relatório do ensaio registra os tempos, os desvios e as ações, assinado pelo responsável de TI e pelo gerente da qualidade. Os tempos mostram se os objetivos foram atingidos; os desvios mostram onde a realidade se afastou do procedimento escrito; as ações mostram o que vai mudar. Duas assinaturas confirmam que tanto o operador quanto a função da qualidade aceitam o relato como exato. O relatório é arquivado com os registros de confiabilidade, para que o próximo ensaio possa comparar seus próprios tempos e conferir se todas as ações anteriores foram de fato concluídas. Cópias vão para Hugo.

47.8 Frequência

Ensaios de falha anuais, e também depois de mudanças importantes. Um ensaio anual mantém a habilidade viva à medida que a equipe muda e a memória se apaga. Mudanças importantes, como um novo hardware de servidor, uma nova plataforma de armazenamento ou uma troca da mídia de backup, disparam um ensaio extra, porque alteram exatamente aquilo de que uma recuperação depende. O gerente da qualidade mantém o calendário e garante que cada ensaio seja conduzido por alguém que não conduziu o anterior, para que o conhecimento se espalhe pela equipe. As datas são fixadas no início de cada ano.

Papel da observadora

Priya observa sem ajudar, cronometrando cada passo e anotando as hesitações. Seu silêncio é deliberado: se a autora corrige os problemas durante o ensaio, isso mostra apenas que a autora consegue recuperar o sistema, e não que o laboratório consegue. Suas anotações alimentam a reunião de avaliação ao lado do relato do responsável de TI.

Exemplo resolvido

A verificação de desvio na inicialização é implementada: na máquina reserva com o relógio atrasado, o EvidenceDesk agora recusa gravações e exibe o desvio. Depois da sincronização, ele inicia normalmente. Um teste de regressão simula o desvio.

Caso sintético. O ensaio é inventado.

Erros e limites

Um ensaio planejado não tem o estresse de uma falha real; varie os cenários e os horários.

Exercícios

Síntese

Os ensaios de recuperação do sistema inteiro revelam lacunas que os testes de componentes deixam passar; leve cada lacuna de volta às ferramentas e às listas de verificação.

Continue estudando — capítulo 47 de 50

← Capítulo 46 (rascunho) · Índice de capítulos do curso · Capítulo 48 (rascunho) →