Práticas recomendadas da comunicação de incidentes

Pontos principais: A comunicação de incidentes é o processo de informar clientes, funcionários e partes interessadas que um serviço está degradado ou fora do ar, o que está sendo feito a respeito e quando vamos atualizar novamente — desde o primeiro reconhecimento até a resolução e o post-mortem.

• O que é: Um conjunto pré-planejado de canais (página de status, e-mail, chat, SMS, redes sociais), públicos, modelos de mensagem e cadência de atualização que a equipe segue no momento em que um incidente é declarado.

• Por que isso importa: O silêncio durante o tempo de inatividade custa mais confiança do que a própria interrupção; clientes que são mantidos informados reagem de forma muito menos negativa e têm menos probabilidade de sair.

• Como o Jira Service Management ajuda: Gerencia incidentes e suas comunicações em um só lugar, sincroniza atualizações com o Slack e o Microsoft Teams, exibe anúncios no portal e se conecta ao Statuspage para atualizações voltadas aos clientes.

A comunicação de incidentes é o processo de informar as pessoas que dependem de um serviço — clientes, funcionários e partes interessadas internas — que ele está passando por uma interrupção ou queda de desempenho, o que a equipe está fazendo a respeito e quando esperar a próxima atualização. Para serviços de web e software em que se espera disponibilidade 24/7, ela é uma parte tão importante da resposta a incidentes quanto a própria correção.

É mais complexo do que um e-mail em massa. Públicos diferentes precisam de mensagens diferentes em canais diferentes, com expectativas diferentes sobre a frequência com que recebem notícias suas. Como algum tempo de inatividade é inevitável, o trabalho é se preparar antes de um incidente, não improvisar durante um.

Este é o guia para as práticas recomendadas de comunicação de incidentes. Você vai ver:

• Por que a comunicação de incidentes é importante

• Como se preparar para a comunicação de incidentes

• Como os profissionais de comunicação de incidentes lidam com a tarefa

• Por que a comunicação de incidentes não termina após o incidente

Por que a comunicação de incidente é importante

Seus clientes se importam. Seus colegas se importam. Você também deveria se importar. Um tempo de inatividade mal gerenciado pode ser uma experiência muito ruim para os seus clientes e suas equipes, o que pode afetar os seus resultados. Você perderá futuros clientes devido à falta de confiança. O moral da equipe pode ser prejudicado, levando a uma menor produtividade.

Por sorte, o tempo de inatividade não planejado não precisa se transformar em um pesadelo de atendimento ao cliente. Acontece que, se você apenas mantiver os clientes informados, comunicando o que está acontecendo e o que você está fazendo para corrigir o problema, eles vão entender e vão ter uma reação muito menos negativa a toda a situação.

Preparação para comunicação de incidentes

A preparação adequada evita o baixo rendimento. Se é um slogan bom o suficiente para ir à batalha, é bom o suficiente para a estratégia de comunicação de incidentes. Quando estiver no meio de um incidente, você vai agradecer por dedicar tempo à comunicação de incidentes.

Defina o que você considera incidente

Antes de comunicar incidentes, a gente precisa decidir o que constitui um incidente. Muitas empresas da web contam com um sistema padronizado de definição de gravidade de 4 níveis. Veja aqui um ótimo guia sobre as definições de gravidade do manual de incidentes.

Quaisquer que sejam os limites para a gravidade do incidente, é importante traçar uma linha clara (de preferência em torno de algum tipo de métrica mensurável). Se você designar um incidente como Grav-1, é importante para qualquer pessoa da equipe saber com exatidão o que significa.

Um sistema de gravidade também é útil para eliminar os problemas inerentes que vêm com o tempo de inatividade.

Seja qual for o sistema que você escolher, a gente recomenda um plano de comunicação de tolerância zero para quaisquer incidentes que envolvam itens de segurança ou perda de dados.

Escolha as soluções de comunicação, canais e templates de mensagens com antecedência

As equipes profissionais de suporte e os engenheiros de confiabilidade do site não decidem em tempo real em quais canais se comunicar. Eles fazem um plano com antecedência.

Existem cinco canais principais de comunicação para a comunicação de incidentes:

• Uma página de status dedicada;

• Status integrado;

• E-mail

• Ferramenta de bate-papo no local de trabalho;

• Redes sociais;

• SMS.

Página de status dedicada

A gente recomenda que as equipes usem uma página de status dedicada como a principal solução de comunicação de incidentes. Não importa se você vai criar uma página própria ou usar uma solução hospedada como o Statuspage, o importante é dar aos clientes e colegas uma fonte clara de informações durante um incidente. O Statuspage também oferece aos usuários a opção de se inscrever para receber atualizações assim que forem postadas. Assim, a carga de suporte é retirada das equipes, que devem estar focadas em corrigir o problema.

Status integrado;

O Statuspage também facilita a incorporação de informação de status direto de qualquer site operado pelos clientes. A gente sabe que a maioria dos visitantes costuma verificar a página inicial ou de suporte de um provedor antes de procurar uma página de status. O widget incorporado (veja aqui um exemplo) é um jeito fácil de informar os visitantes se um incidente estiver ocorrendo. Os visitantes também podem clicar no widget para acessar a página de status.

E-mail

Com um produto como o Statuspage à disposição, você pode dar ao público a opção de se inscrever para receber atualizações por e-mail. Seja enviando a mensagem direto da sua ferramenta de e-mail ou usando uma página de status para acionar os envios, é um canal confiável para a comunicação de incidentes.

Ferramentas de bate-papo

Reduza a mudança de contexto e a falta de informações para funcionários e agentes com o chat do Jira Service Management. O chat do Jira Service Management sincroniza as conversas no Slack ou no Microsoft Teams com os tickets. A conversa ininterrupta entre ferramentas de bate-papo consagradas e o suporte ajuda a dar informações de contexto robustas sobre problemas, levando a uma resolução rápida.

Redes sociais;

Muitas equipes usam canais sociais como o Twitter como meio de comunicação durante um incidente. É bom usar como parte da estratégia, mas não conte só com este tipo de canal como o único meio de comunicação.

SMS.

Receber um SMS, ou mensagem de texto, em geral é uma maneira mais imediata de entrar em contato com alguém e uma preferência para muitas pessoas quando se trata de alertas críticos de entrada, como um aviso de tempo de inatividade. Também é um canal em que as pessoas podem ficar cansadas de receber mensagens muito rápido, fazendo com que cancelem a inscrição se virem muitas mensagens que não sejam relevantes para elas.

Nenhum desses canais é uma solução milagrosa para a comunicação de incidentes. Todos eles têm diferentes pontos fortes, e o verdadeiro potencial aparece quando você os coloca em camadas. Por exemplo, na Atlassian, a gente publica incidentes em uma página de status, mas também envia essas atualizações para o Twitter. Os avisos sobre incidentes também ficam visíveis no portal do Jira Service Management. Essas mensagens direcionam o usuário de volta à página de status para obter mais informações sobre o incidente. Com o gerenciamento de incidentes no Jira Service Management, você tem vários pontos de comunicação sem cruzamentos ou perda da confiança dos clientes na tradução.

Personalize alertas e comunicados para o público certo

Quando surge um incidente, você precisa saber a quem comunicar, como entrar em contato e como passar por essas etapas com o mínimo de atrito e o menor número de recursos possível para evitar pesadelos do atendimento ao cliente e/ou desastres de comunicação. É melhor começar internamente, com uma equipe de resposta imediata, e trabalhar na direção externa, selecionando mensagens para o público certo.

Embora toda empresa seja diferente, em geral, é útil pensar nesses públicos como cinco grupos distintos que precisam ser comunicados:

1. Equipe de plantão principal: a primeira a saber que algo está errado, quase imediatamente após o impacto (em geral com ferramentas de monitoramento e alerta). Equipes internas trabalham nos bastidores para detectar, abordar, contextualizar e resolver incidentes com ferramentas de comunicação colaborativas.

2. Equipe de suporte de linha de frente: aqueles que vão responder às dúvidas dos clientes e disponibilizar atualizações durante o incidente. Essa é uma função muito importante, então a equipe precisa ter as informações certas para transmitir aos usuários finais.

3. Gerentes e equipe executiva: a equipe principal precisa se comunicar com esse grupo para informar o que está acontecendo, quais são os possíveis impactos para os próximos dois grupos e, se possível, uma estimativa de quanto tempo o incidente pode durar.

4. População geral de funcionários: os funcionários precisam ser informados quando os serviços dos quais eles dependem deixam de funcionar ou voltam ao normal. A comunicação proativa com esses usuários gera menos perguntas do tipo "qual é o status desse problema?", menos tickets de suporte de TI duplicados e mais foco para corrigir o problema iminente.

5. Clientes externos: se o incidente afetar clientes externos, é preciso enviar algum tipo de comunicado para explicar o problema e dar uma previsão de correção — ou pelo menos uma atualização de tempos em tempos. Para problemas que ainda estão afetando a capacidade dos clientes usarem seu produto, a gente recomenda nunca passar mais de uma hora sem enviar uma atualização. Sempre indique quando a próxima atualização deve chegar. Se o incidente for grave o bastante, em especial aqueles que envolvem segurança ou perda de dados, o ideal é enviar comunicados externos e acionar as outras equipes necessárias (jurídica, RH, segurança, etc.).

Configure templates para comunicação de incidentes e interrupções

No calor de um incidente, a última coisa com que você quer se preocupar é como escrever um anúncio de incidente. Descrever o incidente do jeito errado é um prato cheio para gerentes não técnicos que ficam caçando motivos para criticar o processo de resposta da equipe.

Decida a linguagem com antecedência, consiga a aprovação dos gerentes e salve em um template, para facilitar a inserção de informações relevantes e disparar um incidente no mesmo dia.

Veja aqui dois dos templates de incidentes que a gente usa para nossa própria página de status:

• O site apresenta uma carga maior do que o normal e pode fazer com que as páginas fiquem lentas ou não respondam. A gente está investigando a causa teremos uma atualização assim que possível.

• O provedor de armazenamento de dados públicos de métricas está enfrentando problemas de infraestrutura. As atualizações vão ser disponibilizadas conforme a situação se desenrolar ou recebermos mais informações.

Gerenciamento da comunicação durante um incidente

É bem provável que o ciclo de vida de um incidente inclua vários pontos de contato. Bem executado, existe uma estrutura conhecida de três estágios para um incidente: primeiro contato, atualizações durante o incidente, resolução e post-mortem.

Prólogo: comunicação de equipe interna centralizada

 Antes de mais nada, as equipes internas na retaguarda de um incidente devem ter uma plataforma de comunicação estabelecida e estar prontas para agir quando ocorrer um incidente.

A centralização e a filtragem de alertas em ferramentas de monitoramento, registro e CI/CD garantem uma resposta rápida da sua equipe. Com uma plataforma como o Jira Service Management, as equipes conseguem abordar o incidente, obter contexto e se manter em contato durante toda a ocorrência.

Parte 1: Primeiro contato

A primeira atualização é a mais importante. Tudo o que você diz, como e quando diz, define o tom de como a resposta vai ser percebida. Então é útil ter um template definido com antecedência.

O objetivo deve ser reconhecer o problema com rapidez, resumir o impacto conhecido em poucas palavras, prometer mais atualizações e, se você puder, atenuar quaisquer preocupações sobre segurança ou perda de dados. É importante reconhecer que há um problema, mesmo que você ainda não saiba as informações exatas.

Parte 2: Atualizações regulares durante o incidente

A comunicação durante os incidentes é fundamental.

As equipes de SRE do Google listam o líder de comunicação como uma das principais funções que alguém deve supervisionar durante um incidente.

Do livro do Google "Engenharia de Confiabilidade do Site" sobre a função do líder de comunicação:

"Essa pessoa é a imagem pública da força-tarefa de resposta a incidentes. As atividades desses profissionais incluem a emissão de atualizações periódicas para a equipe de resposta a incidentes e interessados (em geral, por e-mail) e podem se estender a tarefas como manter o documento de incidentes preciso e atualizado."

Essa pessoa também vai ser responsável por continuar a atualizar a página de status ou postar atualizações em outros canais conforme a situação evolui. Até mesmo uma atualização como "A gente ainda está trabalhando no problema, não há novidades." é melhor do que não dizer nada e deixar o público esperando. Pessoas sem informações imaginam o pior.

A comunicação com os usuários afetados e outras partes interessadas é fundamental. Use seus canais predeterminados para dizer aos usuários o que está acontecendo. Na página inicial, pode ser um alerta do Statuspage para que os clientes vejam que sua equipe está ciente do problema. Esse recurso também poupa o tempo dos agentes, evitando que eles lidem com redundância. Mantenha os clientes informados usando vários canais de notificação, como SMS, e-mail e mensagens por push em dispositivos móveis. 

Seja qual for a ferramenta escolhida, a gente recomenda que você identifique um meio como seu veículo de comunicação principal e centralize todas as pessoas dos outros canais. O gerenciamento das comunicações de incidentes com o Jira Service Management garante que as mensagens certas cheguem às pessoas certas.

Parte 3: Resolução, análise retrospectiva e próximas etapas

Em 2010, o Facebook sofreu uma interrupção de 2,5 horas que afetou o que, na época, era meio bilhão de usuários. Quando terminou, um engenheiro do Facebook publicou um resumo de 395 palavras no blog de engenharia da empresa sobre o incidente.

Do blog:

Hoje cedo, o Facebook ficou fora do ar ou inacessível para muitos de vocês por cerca de 2,5 horas. Esta é a pior interrupção em mais de quatro anos e, em primeiro lugar, a gente pede desculpas pelo ocorrido. A gente também queria dar mais informações técnicas sobre o que aconteceu e compartilhar uma grande lição aprendida.

A descrição da análise retrospectiva é simples:

• Reconheça o problema, tenha empatia com os afetados e peça desculpas.

• Explique o que deu errado e por quê.

• Explique o que foi feito para corrigir o incidente e o que foi feito para evitar incidentes repetidos.

• Reconheça, tenha empatia e peça desculpas mais uma vez.

Não há necessidade de linguagem floreada ou afirmações pomposas em uma comunicação assim. Mantenha a simplicidade e vá direto ao ponto. Por exemplo, do blog do Facebook:

A gente pede desculpas mais uma vez pela interrupção do site. Saiba que levamos o desempenho e a confiabilidade do Facebook muito a sério.

Uma linguagem assim facilita que os clientes e colegas confiem que você comanda uma equipe equilibrada e ao mesmo tempo mantém os olhos no que está acontecendo. Procure pelo template post-mortem de resposta a incidentes para ver mais ideias.

A realidade de executar serviços sempre disponíveis é que, às vezes, as coisas param de funcionar do nada. A comunicação eficaz durante o tempo de inatividade pode construir a confiança de colegas e clientes. Responder bem pode fazer toda a diferença. A gente também criou esta ferramenta simples para ajudar você a escrever comunicações eficazes com rapidez durante incidentes.