O incidente
Uma terça-feira à tarde. O Rocky instala-se em cima de um portátil, como os gatos fazem. Doze minutos depois, um ficheiro de configuração num repositório de produção tinha sido substituído por algo que só se pode descrever como jjjjjjjjjjjjj4, feito commit (gravação automática mais um atalho de teclado muito infeliz) e publicado pela nossa pipeline — que não validava nada.
O serviço foi abaixo. O rollback demorou 40 minutos porque nunca o tínhamos ensaiado. O Rocky dormiu durante toda a recuperação.
O que o gato pôs a nu
Todas as partes daquela falha eram nossas, não dele. A pipeline publicava alterações de configuração sem validação de esquema. Nada nos alertou até os utilizadores o fazerem. E o nosso rollback era uma página de wiki atualizada pela última vez dois trimestres antes. O Rocky não partiu o sistema — revelou que ele já estava partido, e saiu mais barato do que uma falha a sério com um cliente a sério a ver.
O que mudou
Os ficheiros de configuração passam agora por validação de esquema antes de qualquer deploy — um valor malformado faz falhar a pipeline, não o serviço. Os deploys são faseados, com rollback automático quando os health checks falham. E uma vez por mês fazemos um «simulacro Rocky»: alguém estraga intencionalmente um ambiente de staging, sem aviso, e medimos quanto tempo demoram a deteção e a recuperação. No primeiro simulacro precisámos de 35 minutos só para dar por isso. Agora estamos abaixo dos quatro.
A lição honesta
A maioria das equipas pequenas salta o trabalho de resiliência porque nunca parece urgente — até à falha, quando de repente é a única coisa que importa. Não precisa de ferramentas à escala da Netflix. Precisa de barreiras de validação, rollbacks ensaiados e algo imprevisível a fazer pressão. Essa última parte, por acaso, temos cá em casa: ruivo e fundamentalmente sem remorsos.
Quer uma pipeline à prova de gatos? Fale connosco — auditorias de DevOps são um dos nossos trabalhos favoritos e, sim, o Rocky dá consultoria.