Incidentes de tecnologia: como
lidar com eles e como evitá-los

Em tecnologia, incidentes inevitavelmente acontecem e são até bem-vindos em certa medida, porque, quando encarados de forma responsável do momento que são detectados ao momento em que são resolvidos, acabam por melhor preparar o time para lidar com situações potencialmente mais sérias no futuro. 

Isso não significa, porém, que se deva cruzar os braços e esperar que as coisas deem errado. É preciso trabalhar ativamente para prevenir incidentes e para conter suas consequências.

E como se faz isso? Em primeiro lugar, contando com uma estrutura bem organizada de ferramentas de engenharia automatizadas para minimizar os incidentes. Fundamental também é contar com diretrizes de liderança claras para que sejam cumpridos ações e protocolos objetivos de mitigação, de investigação e de resolução de incidentes, além de uma cultura estabelecida de isenção de culpas.

Por que ocorrem incidentes de tecnologia?

Incidentes muitas vezes ocorrem porque alguma parte diferente de um sistema é mexida, levando a um outro caminho de execução de um código e desencadeando um problema.

Um princípio básico da engenharia de software é que se um código não foi testado ele tem bugs.

Em sistemas de larga escala é impossível testar todas as interações, o que significa que bugs dormentes sempre aparecem.

Mesmo em uma empresa onde a cultura de testes é forte, não há como prever todas as situações e desdobramentos do futuro. Os processos de engenharia são criados para minimizar incidentes, e o ideal é que esses processos sejam bons e rigorosos para diminuir a dimensão de um incidente.

O pior dos casos é um incidente acontecer, ninguém fazer nada e ele se repetir. Esse tipo de situação, aliás, nem pode mais ser considerado um incidente, e sim um problema recorrente, que vira um débito técnico.

Quando um incidente é identificado, devem ser ativadas ações estruturantes de curto, médio e longo prazo para que ele não se repita. 

• Exemplo de ação de curto prazo: criar um sistema de alerta caso o mesmo tipo de incidente volte a ocorrer.
• Exemplo de ação de médio prazo: criar mais instruções no sistema de gestão de mudanças para que ele não consiga ser contornado ou burlado.
• Exemplo de ação de longo prazo: sanar um débito técnico antigo de grande porte – isso requer uma ação mais estruturante e planejada.

Normalmente as empresas e instituições já contam com uma lista de débitos técnicos que precisam ser monitorados e resolvidos em algum momento, e quando a liderança faz o planejamento leva esses assuntos pendentes em consideração.

Quando se identifica que a causa de um incidente é a falta de testes suficientes, é urgente reforçar a cultura de testes e integrá-los ao máximo às ferramentas de engenharia para evitar bugs. Se um programador não testa o código antes de colocá-lo em produção, o erro pode passar despercebido e se perpetuar.

Incidente detectado: e agora?

Toda e qualquer instituição precisa ter alertas automáticos e monitoramento de sistemas para que ela própria detecte incidentes e bugs antes que eles transpareçam ao público. O pior dos mundos é uma organização vir a saber de um incidente por notificação ou reclamação de clientes ou usuários. 

Os alertas internos precisam também ser suficientemente bons para garantir que a liderança de engenharia esteja recebendo um fluxo constante de informações de que um incidente aconteceu. A partir daí é necessário um processo estruturado de gestão de incidentes para poder contê-lo e cuidar dele conforme a cronologia abaixo:

Quando se fala de alertas, no entanto, o excesso é ruim. Ter mil alertas é a mesma coisa que ter zero alertas. O que se quer são alertas que sejam relevantes, que chamem a atenção de fato. Por exemplo, para provedores de nuvem não faz sentido alertar todas as vezes que discos rígidos falharem, pois, dado o número de discos que eles têm em data centers no mundo todo e a probabilidade de falhas em disco, alertas disparariam sem parar. Melhor ter um sistema automatizado para lidar com essas falhas.

Desfazer uma mudança que causou um incidente nem sempre é fácil ou possível. As modificações precisam levar em conta essa eventual necessidade, como a inclusão da capacidade de a equipe realizar um rollback automático, que significa desfazer a mudança, quando possível. Idealmente os sistemas contam com testes que validam o estado de como o sistema está rodando em produção, provendo um indicador de saúde que é monitorado. Pode-se também criar um dashboard geral de saúde. 

O caminho é limitar o escopo de um problema e ter mecanismos ágeis para desfazer mudanças que causam incidentes. Uma boa prática para um aplicativo, por exemplo, é fazer um rollout da novidade não para todo mundo, mas para uma base inicial de usuários de 1% e pegar feedback para verificar se está tudo bem. Se está, passa-se para 5% de usuários, depois 25% e assim por diante, até chegar a todos os usuários. Vale a pena engatinhar no começo e, quando o projeto estiver andando suficientemente bem, acelerar depois.

Incidentes evitáveis e inevitáveis

Raramente é um evento externo que causa um incidente. Há aqueles que acontecem, como foi o “bug do milênio” (Y2K): na virada do ano 2000, havia uma grande preocupação de incidentes de computação, porque se temia que sistemas pudessem se confundir com a mudança para o ano com dígitos “00”. O trabalho preventivo de engenheiros evitou proativamente incidentes. 

Tirando casos excepcionais assim de causa externa, previsíveis ou imprevisíveis, é mesmo uma alteração interna que costuma gerar um incidente de tecnologia. Dessa forma, a ação de mitigação do incidente envolve localizar o mais rápido possível a mudança que causou o problema e revertê-la o quanto antes, voltando para o estado anterior do sistema. Uma vez nesse estado anterior, tudo deveria voltar a funcionar. 

Por isso é que testes, validações e alertas são tão importantes: com eles, quando se coloca uma mudança em produção, antes de dar problema, testes automáticos que monitoram a saúde do sistema podem apontar falhas para que se possa executar um rollback e retomar ao que estava antes da mudança indesejada. 

Quando um código é aprovado pelo processo de code review, ele segue para um pipeline para entrar em produção pelo sistema de continuous integration, continuous delivery (CI/CD). Esse pipeline tem validações que rodam mais testes e mais validações. Na fase de produção, testes automáticos precisam continuar monitorando o estado das coisas, como se fosse uma pessoa que a cada cinco minutos tem sua temperatura medida para detectar uma possível febre. Esses testes automatizados estão rodando o tempo inteiro, e, uma vez que se perceba que algum sistema está com a saúde ruim, pode-se entender o que está acontecendo para tentar evitar um incidente maior. 

Em muitos casos, quando o problema foi deflagrado por uma mudança, uma vez que você a reverta, o problema se resolve. Casos mais complicados podem envolver outros aspectos. Por exemplo, se alguma mudança levou o sistema de transações de uma empresa de cartão de crédito a ficar fora do ar, você pode voltar ao que estava antes, mas e o que acontece com todas as transações que não foram processadas naquele meio-tempo? 

Possivelmente uma ação paliativa teria que ser adotada para permitir que as pessoas concluam o pagamento, o que pode resultar em casos de duplicidade. Se isso ocorrer com vários usuários, no dia seguinte a empresa terá uma fila enorme de gente ligando para reclamar, o que vira um incidente de atendimento ao cliente.

Situações assim são uma reação em cadeia de incidentes, porque envolvem problemas técnicos e problemas de serviços. A empresa, pública ou privada, precisa ter um plano de emergência e estar preparada para lidar com esse tipo de consequência.