Incidente: agora o negócio ficou sério

Já encontrou algum problema grave em um software?

À medida que os sistemas se tornam mais complexos, falhas são inevitáveis. Nenhum sistema tem um tempo de atividade perfeito. Esses problemas graves que afetam o software nós podemos chamar de incidentes — um acontecimento que impede o usuário de acessar seu produto ou, ainda pior, altera dados e informações sem o consentimento do cliente. Como você pode imaginar, agora o negócio ficou sério!

Nesse post vou contar como a Resultados Digitais cuida de um incidente para que ele tenha o menor impacto possível em seus clientes e para que o time aprenda sobre os erros de forma a garantir que eles não se repitam no futuro.

Incidente?

Um incidente nada mais é que a interrupção inesperada ou redução na qualidade de um serviço de TI.

De modo geral, as pessoas não gostam de problemas, seja na vida pessoal ou profissional. No entanto, nós precisamos aprender a enfrentar essas situações do dia-a-dia.

“Everything fails all the time” Werner Vogels (Amazon, CTO)

Até mesmo os gigantes do setor de TI como Facebook, Amazon e Google passam por incidentes.

Você deve estar pensando: eu uso os serviços do Google e nunca encontrei um problema. Acesso o Facebook todos os dias e funciona perfeitamente.

As empresas que eu citei acima resolvem os problemas graves o mais rápidopossível, causando o menor impacto nos clientes e aprendem com os erros para não repeti-los. Eles também abrem alterações mais críticas ou introduzem novas features de uma forma que disponibilizem o acesso a uma parcela dos usuários. Aqui na Resultados Digitais nós temos a mesma prática e chamamos isso de Rollout controlado.

No final do dia, o que vai fazer diferença para o negócio, é o quão preparadoo time está para lidar com os seus próprios incidentes.

Plano de tratamento de incidente

Ter um plano de tratamento de incidente ajuda a superar os dias difíceis nas empresas de tecnologia e causa um impacto significativo na experiência dos clientes.

Na RD, nosso plano de tratamento de incidentes conta basicamente com quatro frentes de trabalho: identificação, comunicação, solução e aprendizado/plano de ação.

Identificação do problema

Identifique o problema e tenha claro os critérios para considerar um problema como incidente. Cada time deve analisar o seu cenário e mapear os critérios específicos.

Por mais que existam particularidades de cada time, listamos um conjunto de critérios gerais para a identificação de um incidente que podem te ajudar:

• Downtime do sistema
• Degradação de um indicador além do limite tolerado
• Perda de dados de qualquer tipo
• Indisponibilidade de um dos serviços de terceiros conectados ao sistema
• Um defeito (bug) impeditivo no fluxo principal

Ao confirmar o incidente, o responsável deve notificar os stakeholders, repassando o conhecimento adquirido até o momento para dar início à frente de solução e à frente de comunicação.

Mas, antes disso, organize-se! Monte um canal de comunicação na ferramenta utilizada pela empresa — no caso da RD, criamos um canal no Slack. Neste canal, você pode adicionar o time responsável pelo incidente, o time de suporte e o time de operação — por exemplo.

Também é interessante abrir um documento compartilhado e ir reportando a investigação e a as ações realizadas em tempo real, para poder discutir mais tarde e extrair os aprendizados. O objetivo é centralizar e documentar todo o diálogo, evitando desalinhamento e re-trabalho.

Comunicação com o cliente

Agora que a comunicação interna já foi encaminhada, nós precisamos dar início à comunicação externa com o cliente.

Durante um incidente, é fácil esquecer que seus clientes muitas vezes estão em uma situação ainda pior. Eles também são impactados pela interrupção, mas possuem menos informações sobre o que está acontecendo.

Manter os clientes informados em momentos de interrupções do sistema traz confiança para o relacionamento. A confiança é o reflexo do conhecimento.

Os clientes precisam saber que a empresa está ciente do problema e que está trabalhando ativamente para corrigi-lo.

Na RD o PM (Product Manager) do time que acionou o problema deve focar totalmente seus esforços em dar assistência, seja alertando, acalmando ou estando disponível para Clientes e CS (Customer Success). Seu dever é proteger os interesses dos clientes repassando, de forma filtrada, os inputsinternos do time que está atuando na resolução do problema.

• Levante os dados segundo o impacto dos incidentes: com base no impacto do incidente, decidimos se deve ser aberto uma página de status.
• Alto: afeta mais de 30% da base de clientes
• Médio: afeta entre 5% e 20% da base de clientes
• Baixo: afeta menos de 5% da base de clientes

Ligue a página de Status: a página de status ajuda mapear quais funcionalidades do sistema estão operando normalmente e quais estão com problema. Ao cadastrar um incidente, deve-se informar a descrição detalhada do problema, as funcionalidades afetas e o status (investigando, identificado, monitorando, resolvido).

Certifique-se de que seus clientes saibam onde procurar por informações. Eles precisam entender que a situação está sendo levada a sério para que possam continuam a utilizar as outras funcionalidades do sistema que estão operando normalmente.

Resolução do incidente

A frente de solução deve deve ser composta pelo time que causou o incidente e uma equipe cuja quantidade de integrantes esteja de acordo com o tamanho do esforço necessário para corrigir o problema.

Inicialmente, devemos conter o incidente, impedindo que mais clientes sejam afetados, mesmo que o serviço fique parcialmente ou totalmente indisponível.

Feito isso, corrigimos ou contornamos o problema para que o serviço possa voltar a operar em condições aceitáveis para o cliente. Em alguns casos, uma solução paliativa pode ser uma boa opção.

Paliativo pode ser uma medida tomada para determinada situação que apenas disfarça e não resolve o problema.

Digamos que o seu sistema acessa uma URL provida por serviço externo para retornar alguns gráficos que são mostrados para os clientes. Em um belo dia essa URL é alterada e não é feito nenhum tipo de comunicação para você. Os gráficos não são mais mostrados em tela e aí temos claro um início de incidente!

Para resolver o problema do cliente o mais rápido possível, o time entra em contato com a provedora do serviço externo para descobrir a nova URL e realiza o ajuste no sistema.

Pronto, agora tudo voltou a funcionar normalmente. Contudo, se a URL for alterada novamente teremos outro incidente. Ou seja, a solução encontrada foi paliativa. Por esse motivo, após contornar a situação, devemos corrigir o problema com excelência e de forma definitiva, refatorando e reconstruindo o que for necessário.

Aprender e agir

Uma vez que um serviço foi restaurado, a empresa deve possuir algum tipo de processo para avaliar o que aconteceu. Provavelmente, qualquer resolução de um problema não é verdadeiramente completa até que uma equipe tenha documentado e refletido sobre ela.

Nesse caso, o post-mortem surge com o intuito de criar uma cultura positiva onde as pessoas discutem e aprendem com os problemas.

O post-mortem é basicamente uma reunião com duração de mais ou menos 1 hora, a qual deve ser agendada no prazo máximo de uma semana após a resolução do incidente.

Nessa reunião os participantes constróem um documento contando uma história que inclui basicamente os seguinte pontos:

• Resumo de como o incidente foi identificado
• Análise da causa raiz
• Passos para avaliar, diagnosticar e resolver
• Linha do tempo das atividades
• Aprendizado e próximos passos

Nós precisamos sair do post-mortem com um plano de ação contendo as ações que irão prevenir que o incidente aconteça novamente no futuro.

É interessante que nessas ações contenham o máximo de automação possível, pois a nossa memória é curta e pessoas novas podem entrar no time e elas não detém o conhecimento.

Tendo como base o exemplo anterior, onde a URL é alterada pelo provedor do serviço externo, podemos pensar que uma ação de prevenção interessante para evitar o problema futuramente, seria automatizar alertas para receber notificação de quando a URL for alterada.

Também é necessário ter um ou mais responsáveis para executar as ações e uma data de resolução. Você pode registrar as tarefas em um ferramenta como Trello ou Jira para facilitar o gerenciamento.

Processo visual

Por último, algo que aprendemos com o tempo é que não adianta ter um processo completo se as pessoas não o conhecem. Então torne o processo visual!

Você pode criar um workflow do processo de incidente contendo as macro tarefas e seus respectivos responsáveis e posteriormente disponibilizar em um lugar acessível para todos do time.

Na nossa experiência, ter o workflow com o plano de tratamentos de incidente colado na parede tornou o processo muito mais ágil! ❤

Conclusão

Demonstrar competência ao recuperar-se de um incidente no sistema pode levar a um maior nível de satisfação do cliente do que nunca ter falhado.

Além disso, a possibilidade de investigar o porquê do incidente, como foi que aconteceu e o quê fazer para evitar novas ocorrências é uma experiência de aprendizagem para o seu time. Um erro se torna uma boa lição se escolhemos aprender com ele.

E você, anda tratando do seus incidentes de forma cuidadosa e eficiente? Possui um processo diferente do mostrado aqui? Conta pra gente!

Referência recomendada

• Site Reliability Engineering

Informações adicionais

Palestra apresentada no Agile Testers Conference Floripa 2017, Incidente: agora o negócio ficou sério!