A explosão em Chernobyl e o sistema mal testado
O que uma explosão em um reator nuclear RBMK tem a ver com processo de desenvolvimento de software?
Chernobyl (HBO, 2019)
A minissérie tem ganhado destaque positivo em grande parte das críticas, e me cativou de diversas formas — em especial, a atuação de Jared Harris como o físico nuclear Valery Legasov.
A forma com que ele detalha minunciosamente os impactos causados pela explosão e o cuidado para tentar minimizar os resultados que se propagariam por muitos anos, demonstram a sensibilidade de uma pessoa que entende sobre as consequências que determinados atos podem acarretar.
A trama discorre sobre o resultado e as consequências de um teste de segurança mal sucedido no reator nuclear número 4, que causou uma catástrofe ambiental imensurável. Sobre essa parte mais técnica, pude assimilar retratos de situações vivenciadas pelos operadores do reator que profissionais de outras áreas (que não da física nuclear) vivenciam no dia-a-dia — mais precisamente, a área de tecnologia da informação.
Neste artigo, faremos uma comparação específica entre o processo de desenvolvimento e qualidade de software. (atenção — SPOILER ALERT!)
Por que o teste falhou, operadores?
Mesmo que os operadores tenham afirmado até o fim que fizeram tudo certo, por que o reator RBMK explodiu?
A intriga é estudada por Ulana Khomyuk (Emily Watson), personagem fictícia que representou diversos físicos e cientistas que auxiliaram no caso durante e também nos anos seguintes ao acontecimento, e pelo físico Valery Legasov (Jared Harris), envolvido pelo governo para tentar auxiliar a minimização dos danos irreparáveis da tragédia.
No julgamento dos acusados pela explosão, Ulana e Valery retomam a história em dez horas antes do ocorrido no dia 26 de abril de 1986, para detalhar os fatos e os atos inconsequentes que teriam ocasionado a explosão.
Entrega de projeto com teste não executado
Boris Shcherbyna (Stellan Skarsgård), vice-presidente do Conselho de Ministros soviético, revela que o documento de conclusão do projeto do reator 4 era uma farsa: o documento afirmava que todos os testes de segurança haviam sido executados, o que não era verdade; ainda faltava um teste. A assinatura do documento pelo engenheiro Nikolai Fomin (Adrian Rawlins) e o chefe da usina Viktor Bryukhanov (Con O’Neill) fez com que eles ganhassem títulos de destaque profissional pela então “completude” do projeto no prazo estabelecido.
Pressão vindo de cima
O teste de segurança foi executado após o reator 4 já estar em funcionamento. Na primeira tentativa, o teste falhou. Foram feitas duas outras tentativas subsequentes, também sem sucesso. Para executar a quarta tentativa do teste, o engenheiro-chefe Anatoly Dyatlov (Paul Ritter) deveria esperar por pelo menos 24 horas para que o reator estabilizasse, devido a potência já estar reduzida. Alguns fatores fizeram com que esta regra fosse ignorada e o teste fosse executado ainda na noite do mesmo dia:
- os consumidores externos da energia gerada pelo reator tinham quotas de produtividade a cumprir;
- concretizar a realização de uma tarefa que já havia falhado 3 vezes faria com que Dyatlov, Bryukhanov e Fomin ganhassem destaque profissional.
Profissionais inexperientes
Embora estivessem sendo acompanhados pessoalmente por Dyatlov, os operadores do reator no turno da noite da explosão não foram avisados antecipadamente sobre o teste, tão pouco sabiam do que se tratava e como deveriam executá-lo. Toptunov, um dos operadores que foi ordenado a executar uma tarefa de um operador sênior, estava trabalhando na usina há aproximadamente 4 meses, apenas.
Documentação incompleta
Um manual com algumas informações sobre a execução do teste foi cedido aos operadores para que pudessem ter uma noção do que deveria ser feito. Muitos tópicos estavam riscados. Dyatlov os pressionava para realizar o teste mais rápido, com ordens que impunham medidas fora das normas exigidas. Além de serem obrigados a seguir ordens inconsequentes para não serem demitidos, os operadores executaram as ações baseando-se em uma documentação incompleta, fato que nem Dyatlov sabia.
Por que o teste falhou, testadores?
Se tudo foi executado conforme planejado, por que falhou em produção?
É inevitável não fazer certas comparações sobre as tomadas de decisão no teste de segurança em Chernobyl com o que ocorre em muitas empresas nos dias de hoje.
No processo de desenvolvimento e qualidade de software, muitos projetos são entregues sem que os testes das funcionalidades do caminho crítico do projeto tenham sido executados. Comumente, presume-se que executá-los depois da entrega não fará grande diferença.
Entregar no prazo acaba sendo uma obsessão tão forte, que muitas vezes acaba fazendo com que instruções incorretas sejam seguidas de forma imperceptível. E mesmo quando são percebidas, acabam sendo executadas, de qualquer forma, por conta da pressão da entrega.
Profissionais com pouca experiência ou mal orientados são elencados para auxiliar na execução de testes críticos do sistema, geralmente por falta de pessoal ou até mesmo desconhecimento sobre a criticidade e teor que o teste envolve.
O fato de existir alguma documentação já é uma boa notícia para quem trabalha com sistemas. Mas se não há cuidado em mantê-la atualizada, atuar sobre algo incompleto e/ou impreciso pode ser catastrófico.
Conclusão
O desastre em Chernobyl ocorreu em 1986, mas suas consequências são sentidas até os dias de hoje. Um acidente nuclear pode impactar a vida de pessoas tanto quanto um sistema mal testado.
— Ah, mas não vemos por aí pessoas morrendo de ARS se o botão “Salvar” do sistema não funciona…
De fato, não. Mas quando sistemas críticos/de tempo real falham, o avião pode cair. A tomografia pode mostrar um falso positivo. Trens podem se chocar… e diversas outras coisas podem acontecer, tão graves quanto um vazamento de U-235 na atmosfera.
