7 problemas identificados no caso da exclusão de 16 mil aposentadorias no TCE-Amazonas

Por Dani Monteiro (@DaniMonteiroDBA)

Em todos os cursos de bancos de dados relacionais, onde o assunto envolve comandos de alteração ou exclusão (UPDATE e DELETE) de dados eu costumo dizer “WHERE é vida!”. E repito isso várias vezes, na esperança de que meus alunos nunca esqueçam de criar as condições antes de escreverem os comandos UPDATE e DELETE.

Esta semana soube que foram excluídos da base de dados do TCE-Amazonas os registros de 16 mil aposentadorias, e tive certeza (total e absoluta) que esta frase mágica será dita muitas e muitas vezes nos meus cursos!

Quais os problemas que eu vi no caso do TCE…

1 — O script não foi testado

Todo script antes de ser executado no ambiente de produção precisa ser testado em um ambiente de testes, que deve ser similar ao ambiente de produção.

2 — Desenvolvedor acessando ambiente de produção

Normalmente desenvolvedores não acessam ambientes produtivos. Deve existir uma equipe responsável por monitorar e se necessário fazer alguma intervenção neste ambiente.

Se você é desenvolvedor e tem acesso ao ambiente de produção, abra mão deste poder! Como Tio Ben disse ao Homem Aranha… “Grandes poderes trazem grandes responsabilidades!” E você está preparado para este poder? Sabe justificar porque você o possui?

3 — Falta de uma estratégia de backup

Quando as alterações nos dados são muito significativas, convém solicitar aos DBAs que façam um backup dos dados. Contudo vivemos em uma tempestade de dados. Tabelas gigantes não são raras e nem sempre é viável pedir um backup do banco de dados antes da execução de um script. Por isso é preciso que a empresa elabore uma estratégia efetiva para fazer o backup dos dados, de forma que em caso de problemas a indisponibilidade do ambiente seja a menor possível.

4 — Aprovação da execução do script

Na sua organização existe o papel de Data Steward? Se sim ele deve aprovar a execução de scripts de manipulação dos dados. Se não existe, o usuário de negócio da aplicação deve saber da necessidade de atualizar os dados, deve conhecer as condições e aprovar a execução.

Tenha calma, não estou dizendo que a equipe de negócio irá validar seu script e avaliar se ele está correto… (embora eu amaria que eles fizessem isso!) Estou dizendo que eles devem estar cientes e aprovar a atualização dos dados das compras feitas entre os anos de 2010 a 2015 (por exemplo).

…………………………..…WHERE is life ……………………………

5 — Penalizarem os desenvolvedores

Cada um dos desenvolvedores considerados culpados terão que pagar 33 mil. Mas eu pergunto se a estratégia está toda errada, é certo somente os desenvolvedores serem penalizados? Eles erraram propositalmente?

Se eles erraram propositalmente, então agiram de forma criminosa e merecem ser punidos pela justiça. Agora se foi um erro sem intenção, se eles agiram “conforme a conduta” normal da empresa até aquele momento, então a empresa toda deve ser punida…

Sejamos justos, a culpa não foi só de quem pressionou o botão… E quem autorizou? E quem não validou? E quem validou? E quem deu acesso?

6 — Julgamentos

Vi vários desenvolvedores criticando a conduta dos colegas. Não estou defendendo a execução de um script em ambiente de produção, estou questionando a nossa postura quanto categoria profissional.

Quem nunca foi pressionado para cumprir prazos impossíveis?

Amigos, sejamos menos duros nos julgamentos. Vamos nos colocar no lugar destes profissionais que estão enfrentando vários problemas por um erro que não é só deles.

7 — Falta de Governança de Dados

Me preocupa imensamente as pessoas que foram afetadas por este erro… Imagina uma senhora de 80 anos que sai de casa com uma super dificuldade, vai receber a aposentadoria e não tem dinheiro para receber, porque infelizmente os dados referentes a aposentadoria dela foram excluídos.

Dados são o maior bem das organizações e devem ser tratados como tal! Veja no caso da senhora de 80 anos (hipotética), o impacto que a exclusão de um registro pode ter na vida de uma pessoa! Os dados representam alguma aspecto da realidade, e no caso do TCE representam aspectos importantes da vida de algumas pessoas. Estamos então “cuidando”de pessoas quando cuidamos dos dados referentes a elas.

O problema na exclusão das aposentadorias não foi só o script errado… Foi a demonstração da ausência total de governança de dados, uma vez que ela teria evitado que um erro tão grave acontecesse.

Conclusão

1- WHERE é vida!

2- Que os erros dos colegas sirvam de aprendizados para nós!

Dicas e Links

Se quiser saber mais sobre governança de dados, já escrevi sobre este assunto no blog Code Like a Girl. (https://code.likeagirl.io/governança-de-dados-b67aca69a5ff)

Sobre o caso do TCE escrevi no meu blog: http://db4beginners.com/index.php/2017/10/04/delete-without-where/

Sobre a autora

Dani Monteiro

Desde que terminei o mestrado em engenharia da computação venho me dedicando a ministrar, cursos, treinamentos, palestras e afins… Porque sempre achei que o conhecimento precisa ser distribuído para que ser multiplicado. Sou apaixonada por Banco de Dados… e por isso decidi que ensinaria banco de dados para desenvolvedores iniciantes.

DB4Beginners.com / @DaniMonteiroDBA / facebook.com/DB4Beginners