Capítulo 47 — Ensaio de falha e recuperação
Mapa da aula
Aula 47 publicada. Mapa, exemplo, EX139.
flowchart TD
N0["47.1 Propósito"]
N1["47.2 Planejamento"]
N2["47.3 Métricas"]
N3["47.4 Revisão pós-ação"]
N4["47.6b Compartilhando o que o ensaio ensinou"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX139"]
Desenho lógico
flowchart LR
N0["47.1 Propósito"]
N1["47.2 Planejamento"]
N2["47.3 Métricas"]
N3["47.4 Revisão pós-ação"]
N4["47.6b Compartilhando o que o ensaio ensinou"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX139"]
[47.1 Propósito]
|
v
[47.2 Planejamento]
|
v
[47.3 Métricas]
|
v
[47.4 Revisão pós-ação]
|
v
[47.6b Compartilhando o que o ensaio ensinou]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX139]
Objetivos de aprendizagem
Você vai (1) planejar e conduzir um ensaio controlado de falha e recuperação para um sistema de IA; (2) injetar falhas e ataques em um ambiente seguro; (3) medir os tempos de detecção, contenção e recuperação; e (4) melhorar runbooks e o projeto a partir das evidências do ensaio.
47.1 Propósito
Um plano de recuperação que nunca foi exercitado é uma hipótese. Um ensaio testa se pessoas, ferramentas e procedimentos detectam falhas e ataques realistas, contêm-nos e se recuperam deles dentro dos tempos-alvo. Os planos supõem coisas que podem não se sustentar sob pressão: que o engenheiro de plantão encontra o runbook, que as credenciais podem ser revogadas rapidamente, que há uma versão limpa do modelo disponível. Um ensaio verifica essas premissas com pessoas e ferramentas reais em um ambiente seguro. Falhas encontradas em um ensaio custam uma tarde; as mesmas falhas encontradas em um incidente custam muito mais, e os tempos medidos no ensaio se tornam a evidência de que as metas de recuperação são realistas.
47.2 Planejamento
Defina cenários (por exemplo: lote de treinamento envenenado descoberto; documento injetado provoca propostas de ferramenta; modelo assinado falha na verificação durante a implantação; serviço de monitoramento fora do ar durante uma tentativa de extração), objetivos, regras de segurança, observadores, critérios de sucesso e uma condição de parada. Execute em um ambiente de homologação com dados sintéticos. Informe os participantes sobre a janela do exercício, mas não sobre os detalhes do cenário, para que a detecção seja realista. Manter os detalhes do cenário longe dos participantes torna significativos os tempos de detecção. Uma condição de parada, como qualquer sinal de impacto fora da homologação, encerra o ensaio de imediato e é combinada com antecedência com os donos dos sistemas.
47.3 Métricas
Tempo até a detecção, tempo até a contenção, tempo até a recuperação, correção das ações, qualidade da comunicação e perda de dados. Compare com as metas dos requisitos (por exemplo, conter o uso indevido de ferramentas em até 15 minutos). Os tempos são tirados dos logs, e não da memória, para que possam ser conferidos. A correção das ações pergunta se os respondentes fizeram a coisa certa, e não apenas alguma coisa rapidamente: revogar a credencial certa importa mais do que revogar qualquer credencial depressa. A qualidade da comunicação cobre se os gestores e os usuários afetados ficaram sabendo a tempo do que precisavam saber, o que os observadores avaliam com base em um checklist combinado.
47.4 Revisão pós-ação
Em até uma semana, faça uma revisão sem culpados: o que aconteceu, o que funcionou, o que não funcionou, e ações com responsáveis. Atualize runbooks, monitoramento e projeto. Sem culpados não significa sem responsabilização: as ações têm responsáveis e datas, e o ensaio seguinte verifica se foram cumpridas. O foco está nas condições que tornaram os erros prováveis, como uma etapa de runbook pouco clara ou um alerta ausente, porque corrigi-las ajuda quem estiver de plantão da próxima vez. Um resumo escrito curto mantém as lições disponíveis depois que as pessoas envolvidas seguiram adiante.
47.5 Exemplo resolvido (caso sintético da NRS)
A equipe de Sam executou três cenários sobre o Bulletin Gate e o Wrench em homologação. O cenário A (boletim injetado) foi detectado em 6 minutos pela sinalização do classificador e contido em 11 com a revogação da credencial de ordens de serviço do Wrench. O cenário B (atualização envenenada do modelo de extração) foi bloqueado na implantação pela verificação do manifesto em 1 minuto. O cenário C (indisponibilidade do monitoramento mais raspagem) só foi detectado após 52 minutos, quando o monitoramento se recuperou — não cumprindo a meta de 30 minutos. A correção acrescentou um alerta de "heartbeat do monitoramento ausente" e uma limitação padrão quando o monitoramento está fora do ar.
47.6 Erros e limites
Três erros são comuns: ensaios que só testam a tecnologia, e não as pessoas e os procedimentos; revisões focadas em culpados, que desestimulam o relato; e nenhum acompanhamento das ações. Um ensaio que só testa se o software faz failover deixa de fora o telefonema demorado, o runbook pouco claro e o engenheiro que não encontra uma senha. Revisões que procuram alguém para culpar ensinam as pessoas a esconder problemas, o que torna o próximo incidente mais difícil de detectar. Ações sem acompanhamento fazem as mesmas lacunas aparecerem no ensaio do ano seguinte; o alerta de heartbeat do cenário C foi verificado no ensaio seguinte antes de qualquer outro resultado ser aceito.
47.6b Compartilhando o que o ensaio ensinou
O resumo pós-ação vai além da equipe de IA e chega aos gestores de manutenção ferroviária que dependem do TrackEye e do Wrench: o que falhou, quanto tempo a recuperação levou, o que muda e quando. Para eles, linguagem simples e datas importam mais que métricas. No ensaio de Sam, a versão para os gestores dizia três coisas. Um boletim malicioso foi pego em 6 minutos, e o acesso do Wrench às ordens de serviço foi cortado em 11. Uma atualização de modelo maliciosa foi bloqueada antes de entrar em operação. Quando o próprio monitoramento caiu, uma tentativa de raspagem passou despercebida por 52 minutos; a partir da próxima versão, o Wrench e o TrackEye ficam automaticamente mais lentos quando o monitoramento está fora do ar, então um gestor de manutenção ferroviária pode notar respostas mais lentas durante uma indisponibilidade assim.
Exercícios
- EX139 — Cenário. Escreva um cenário de ensaio com objetivo, método de injeção, detecção esperada e critério de sucesso. Rubrica: 3 = os quatro, de forma segura; 2 = três; 1 = vago; 0 = nenhum.
- EX140 — Métricas. Qual métrica falhou no cenário C, e que princípio de projeto a correção ilustra? Rubrica: 3 = tempo até a detecção (52 > 30 min); padrão de falha segura quando o monitoramento está fora do ar; 2 = uma parte; 1 = vago; 0 = errado.
- EX141 — Pós-ação. Liste quatro produtos de uma revisão pós-ação. Rubrica: 3 = linha do tempo, o que funcionou, lacunas, ações com responsáveis e datas; 2 = três; 1 = um ou dois; 0 = nenhum.
Síntese
Ensaios de falha e recuperação transformam planos de recuperação em evidências. Tempos medidos de detecção, contenção e recuperação impulsionam melhorias concretas.
Continue estudando — capítulo 47 de 50
← Capítulo 46 (rascunho) · Índice de capítulos do curso · Capítulo 48 (rascunho) →