Método ágil para quando tudo dá errado: a peça que faltava em seu plano de resposta a incidentes

As metodologias ágeis estão sendo cada vez mais usadas fora do ambiente tradicional de desenvolvimento de software em todas as áreas de negócios – até em marketing! Então, começamos a pensar, como é o método ágil no ambiente de gerenciamento de incidentes? Na Atlassian, definimos o método ágil como uma abordagem iterativa e estruturada para o gerenciamento de projeto e de produto. Ele fornece à sua equipe a capacidade de responder às mudanças sem sair dos trilhos.

Já que erros em produção, incidentes e tempo de inatividade podem com certeza ser classificados como momentos em que as coisas "saíram dos trilhos", a gente imaginou que uma metodologia como a ágil (criada para ajudar as equipes a ficarem nos trilhos) teria um papel natural no gerenciamento de incidentes (especificamente, comunicação de incidentes).

Embora haja muitas ferramentas para ajudar as equipes a detectar, alertar, analisar e resolver incidentes, as ferramentas sozinhas não conseguem substituir uma comunicação clara às partes interessadas. E para ser realista: o risco pode ser alto. Reputação, atrito com clientes, tempo gasto no controle de danos, só para citar alguns. As metodologias ágeis podem ajudar a manter esses riscos os mais baixos possíveis.

Muitos de vocês estão, provavelmente, familiarizados com os quatro valores principais do manifesto ágil: 1) indivíduos e iterações em processos e ferramentas, 2) trabalho com software com uma documentação abrangente, 3) colaboração do cliente em relação à negociação do contrato e 4) resposta à mudança ao seguir um plano. Vamos detalhar um pouco mais e ver como isso pode ser usado para comunicações de incidentes mais ágeis.

Esse princípio é baseado no valor ágil, pessoas e interações mais do que processos e ferramentas. Processos e ferramentas são importantes para qualquer processo de gerenciamento de incidentes, mas eles não significam nada quando vistos como algo separado das pessoas que estão tentando fazer uso deles e da cultura que foi formada em relação a eles. O que preenche as lacunas entre pessoas, processos e ferramentas? Comunicação, é claro!

A comunicação é fundamental quando ocorre um problema, seja um bug pequeno de produção ou uma falha no sistema. Até mesmo o plano de incidentes mais completo exige comunicação frequente para ser resolvido e manter a confiança.

Durante um incidente, os usuários afetados estão, provavelmente, obtendo erros frustrantes – se não estiverem totalmente debilitados – e precisam saber o que está acontecendo assim que possível. Muitos enviam e-mails, publicam tweets e/ou abrem tíquetes sobre o problema, então é do interesse de todos o conhecimento rápido da situação com uma mensagem que mostre que você sabe que algo está errado e que isso será corrigido. Na Atlassian, usamos o Statuspage para comunicação com as partes interessadas internas e externas durante tempos de inatividade e pense que você também encontrará valor rapidamente ao tentar transmitir as informações do incidente aos seus usuários de modo rápido e escalável. De fato, o Statuspage ajudou os usuários a aumentarem a velocidade da comunicação de incidentes em 50%.

Mas independentemente da ferramenta que está usando para informar seus clientes, a comunicação com empatia percorre um longo caminho. Há pessoas do outro lado do problema que confiam no seu serviço e em você para mantê-las informadas se algo der errado. Embora templates sejam ótimos em um mundo ideal, serão necessárias pessoas que consigam se comunicar de modo claro, conciso e com empatia para ganhar a confiança dos clientes até mesmo nos piores momentos. Tomemos a Dyn, por exemplo. Eles tiveram uma enorme paralisação durante um dos maiores ataques de DDoS na história, mas mesmo assim os usuários agradeceram a eles peça sinceridade demonstrada durante a interrupção do serviço.

Como Werner Vogels, executivo de tecnologia da AWS, disse ao discutir a grande paralisação da AWS S3 em fevereiro de 2017:

"Os clientes não gostam de conselhos que digam: 'não faça nada'. Não é o que eles querem, então você precisa entregar a eles informações úteis, fazer com que entendam o que está acontecendo, dar uma expectativa de quando o serviço vai voltar a ficar disponível se tiver essa informação".

Para esse princípio, a gente usa o valor ágil Software funcional mais do que documentação abrangente. A documentação sobre o produto deve ser clara e fácil, assim como as atualizações de incidentes. Os usuários não devem ler entre as linhas (ou analisar parágrafos longos) para saber o que está acontecendo e para quando podem esperar uma correção. Você precisa pensar sobre as atualizações de incidente e garantir que está tendo empatia e solidariedade na comunicação, mas não deve deixar que controles de aprovação ou várias revisões atrapalhem as atualizações frequentes e honestas.

Analisando de novo o incidente da Dyn, é possível ver que a equipe não desperdiçou tempo comunicando as atualizações aos usuários. Ao longo das mais de 11 horas de incidente, eles atualizaram a página de status 11 vezes (uma média de 61 minutos entre as atualizações). A página de status possibilitou que eles tivessem um único local para comunicação sobre o incidente, em vez de desperdiçar tempo procurando listas de correspondência para enviar e-mail ou tentando comunicar as atualizações em 140 caracteres no Twitter. Ou seja, eles entenderam o que deviam fazer enquanto mantinham o foco em fazer o serviço voltar a funcionar.

A beleza de uma ferramenta de comunicação de status diferenciada na qual você não precisa passar muito tempo para que sua página funcione. Leva menos de 30 minutos para criar uma página de status e, como no método ágil, sua página de status pode e deve ser iterativa. Pense sobre disponibilizar uma página para seus clientes e faça ainda melhor. Depois de ter passado por alguns incidentes com a página de status, como parte do processo, você pode fazer ajustes para melhorar.

Pronto para criar sua própria página de status? Faça o cadastro ou entre no Statuspage >>

Não espere até o próximo incidente para criar uma página de status. Coloque-se na melhor posição para quando houver alguma inatividade. Lembre-se: você não precisa passar muito tempo configurando uma página para isso:

• Saiba como personalizar sua página de status
• Veja exemplos de excelente design e personalização da página de status para se inspirar

O valor ágil Colaboração do cliente em uma negociação de contrato trata do trabalho com os clientes para fornecer o melhor produto e experiência possíveis. Para nós, isso significa ter canais de feedback adequados para que os clientes possam expor suas preocupações e alertar sobre quaisquer problemas que possam ter (usando ferramentas como Jira Service Management, Twitter, etc.). As empresas de classe mundial entendem que os clientes esperam uma resposta aos seus feedbacks e querem estar envolvidos quando se trata de fazer melhorias no produto e no processo de resposta de incidente. Empatia e explicação passam por um longo caminho – e os clientes não deixam de pedir isso – como é possível ver nesses tweets:

Outro aspecto importante é manter a transparência sobre o tempo de atividade para que os usuários saibam exatamente o que estão adquirindo ao fazer a inscrição. Ao se inscrever para um serviço de nuvem, você acredita que o serviço vai ser confiável. Nem sempre é um contrato físico, mas um contrato inerente, negociado entre o cliente e o provedor de serviços, que afirma que, quando algo der errado, as duas partes vão colaborar para que tudo se resolva logo e todos fiquem atualizados, desde a investigação até a resolução. E assim a gente chega ao valor final em relação à resposta a alterações...

Até mesmo os melhores planos... bem, você sabe o resto. O último valor ágil, Responder à mudança ao seguir um plano, sabemos que até mesmo os melhores planos precisarão, inevitavelmente, ser alterados durante e após um incidente. O método ágil é sobre conseguir ser capaz de se levantar após uma queda e obter feedbacks rápidos e constantes que melhoram o produto e a cultura.

A Wistia, uma empresa de hospedagem de análise e vídeos da internet, aprendeu sobre a importância de permanecer ágil durante um incidente inesperado em 2013 que deixou sua infraestrutura de estatísticas paralisada. Eles não estavam preparados, o que fez com que eles recebessem milhares de tickets de clientes insatisfeitos. O primeiro momento decisivo foi a criação de sua própria página de status para ajudar a facilitar o trabalho em situações como essa. Mas, ao criar sua própria ferramenta de comunicação de status, eles precisavam dar suporte a um novo produto além do produto principal. Ficou claro que essa escolha representava um custo para a equipe de 20 pessoas, e eles não podiam arcar com esse custo na época. O segundo momento decisivo foi parar de usar sua própria solução e migrar para o Statuspage.

Jordan Munson, engenheiro de suporte na Wistia, descreveu a jogada: "Após vários meses de frustração em relação à nossa solução útil, mas quase sem recursos, decidimos que precisávamos de algo a mais, algo que não exigisse tanto. Foi quando começamos a usar o Statuspage. Desde que migramos para o Statuspage, conseguimos fazer o que queríamos -- manter nossos clientes atualizados, de modo rápido e fácil, sobre o status de nosso aplicativo. Para conseguir isso, foi preciso apenas uma grande paralisação e a criação de um novo produto. Após alguns anos, nossa solução é muito mais suave. As pessoas recebem atualizações diretamente de nós quando há uma paralisação, sabem onde procurar por atualizações e as atualizações feitas em nossa página de status são enviadas para vários locais".

A equipe de Munson pegou limões (a interrupção de 2013) e fez uma limonada (um processo de comunicação de incidentes novo — escalável — e aprimorado). Essa é uma excelente resposta ágil à mudança.

As retrospectivas também fazem parte desse valor ágil. Uma retrospectiva oferece à equipe a chance de parar e discutir o que funcionou bem durante a comunicação do incidente, o que não funcionou muito bem e, o mais importante, o que vocês vão fazer para evitar que os mesmos problemas aconteçam de novo. Não ceda à tentação de não fazer uma retrospectiva depois que um incidente é marcado como "resolvido" ou se achar que a equipe se saiu bem. Há sempre oportunidades de melhoria quando se trata de comunicação de incidente e, bem como uma chance de melhorar o relacionamento de ganhar a confiança de seus usuários.

Revisitando o primeiro manifesto ágil, as retrospectivas definitivamente exigem comunicação com empatia para ter êxito e proporcionar resultados duradouros. Veja abaixo algumas linguagens para considerar ao discutir como a resolução de incidente se saiu em uma reunião de retrospectiva. Algumas das linguagens também devem estar na revisão pós-incidente (PIR) enviada aos usuários após o serviço voltar a funcionar. Usar o método ágil significa melhorar continuamente não apenas em como você executa as tarefas relacionadas aos incidentes, mas também em como você se relaciona com os colegas de equipe e executa a função durante uma situação estressante.

A gente falou bastante sobre confiança no método ágil, e esse caso de uso não é diferente. A comunicação de incidente efetiva requer confiança e capacitação. As equipes de toda a empresa devem se sentir capacitadas com a aprovação e o conhecimento necessários para comunicar os usuários sobre os incidentes. As pessoas também devem poder confiar que todos vão fazer os deveres atribuídos a eles durante uma resposta a um incidente e não vão hesitar em fazer o que podem quando algo inesperado ocorrer. Confiar a tarefa de comunicação efetiva durante os incidentes às equipes vai permitir que os clientes sejam informados de modo rápido e, em troca, vai aumentar a confiança do usuário e a fidelidade ao serviço (67% dos clientes do Statuspage afirmam que essa ferramenta ajudou a aumentar a confiança dos usuários). Todo mundo sai ganhando.