Esta é a parte 4 da visão geral do gerenciamento de incidentes no Zendesk. Este guia contém as seguintes partes:
- Parte 1: Como os problemas de serviço do Zendesk se tornam incidentes de serviço
- Parte 2: Como o Zendesk gerencia incidentes de serviço
- Parte 3: Monitoramento de um incidente de serviço público do Zendesk
- Parte 4: Análise e relatórios de incidentes pós-resolução (este artigo)
Neste artigo, parte 4, você aprenderácomo a equipe de resposta a incidentes conduz uma retrospectiva que inclui a análise da causa raiz e a correção de incidentes de serviço e, em seguida, atribui itens de correção às equipes de engenharia responsáveis.
Ao conduzir essas atividades, o Suporte ao cliente Zendesk pode compartilhar detalhes do incidente e as próximas etapas com os clientes afetados.
Este artigo contém as seguintes seções:
- Realização de uma retrospectiva de incidentes de serviço
- Atribuição de itens de correção
- Encerramento de um incidente de serviço
Realização de uma retrospectiva de incidentes de serviço
O Zendesk realiza um exercício de reflexão com todos os membros da equipe envolvidos no incidente para examinar e documentar as causas do incidente, o impacto do incidente nos clientes e as ações tomadas para mitigá-lo ou resolvê-lo. A equipe analisa as causas principais identificadas e acompanha as ações que evitarão que o incidente se repita. Isso é conhecido como retrospectiva interna de incidente de serviço. As retrospectivas de incidentes são compartilhadas publicamente apenas para incidentes de alta gravidade.
Para garantir a transparência e a inclusão de todas as equipes do Zendesk, um calendário de retrospectivas internas do Zendesk está disponível para que eles possam participar da reunião de retrospectiva interna e obter mais informações sobre incidentes de serviço e causas principais. Os resultados dos incidentes são compartilhados com todas as equipes de engenharia e os resultados significativos dos incidentes são destacados e revisados na reunião semanal de engenharia do Zendesk.
Há quatro atividades principais realizadas em uma retrospectiva de incidente de serviço:
- Revise os detalhes do incidente contidos no documento do incidente para ancorar e orientar os participantes sobre o incidente
- Revise e valide as descobertas da análise de causa raiz contidas no documento do incidente
- Identifique e categorize qualquer trabalho de correção necessário para que as equipes de engenharia do Zendesk tratem totalmente das causas principais que levaram ao incidente de serviço. Todos os itens de correção são acordados em consenso pelos participantes da retrospectiva
- Atribua o trabalho de correção às equipes de engenharia apropriadas com SLAs claros e apropriados definidos.
Análise de incidentes de alta gravidade
Depois que um incidente de alta gravidade é resolvido, o gerente de incidentes agenda uma reunião retrospectiva que inclui:
- Todos os membros da equipe que participaram da resposta ao incidente
- Engenheiros de equipes cujos produtos ou serviços foram afetados pelo incidente
- Equipes que têm responsabilidade ou interesse investido, como:
- Suporte ao cliente Zendesk
- Equipes de produto
- Líderes proprietários de produtos, serviços e áreas de suporte afetados
Todo esforço é feito para realizar a reunião retrospectiva do incidente dentro de 72 horas após a resolução do incidente, entendendo que o momento da reunião dependerá da complexidade da causa raiz e da disponibilidade dos membros da equipe em todas as regiões geográficas.
Após programar a retrospectiva do incidente, o responsável pela engenharia documenta a análise da causa raiz e cria o Documento do Incidente com base nas seguintes categorias:
- Visão geral do incidente
- Impacto no cliente
- Descrição técnica
- Causa raiz e informações de serviço
- Detalhes e tempos do incidente
- Correções
O documento do incidente orienta a retrospectiva do incidente e captura qualquer trabalho de remediação identificado para resolver completamente os problemas subjacentes que causaram o incidente.
Há uma fase de análise adicional realizada para incidentes de gravidade 0-3, conhecida como Análise de causa raiz. Essa análise dá à equipe de engenharia a chance de entender e documentar o incidente e definir o trabalho necessário para corrigir totalmente os problemas. Essas informações são capturadas no documento do incidente.
Processo de análise da causa raiz de incidentes do Zendesk
Análise de incidentes de baixa gravidade
Os incidentes de baixa gravidade passam por uma causa raiz e uma fase de relatórios mais enxuta do que os incidentes de alta gravidade. Enquanto uma reunião retrospectiva de incidente formal não é concluída (a menos que solicitado pelo responsável pela engenharia de produto) para incidentes de baixa gravidade, um documento do incidente é criado pelo responsável pela engenharia de produto.
As causas principais são identificadas, classificadas e compartilhadas com as equipes de engenharia, e os itens de correção são adicionados à lista de pendências da equipe de engenharia de produto com SLAs. Como acontece com os incidentes de gravidade mais alta, a Zendesk busca aprender e melhorar nossos processos de engenharia como resultado de uma investigação minuciosa dos incidentes de baixa gravidade.
Como os incidentes de gravidade 3 têm um impacto menor nos clientes, o status do problema e as correções identificadas são compartilhados com os clientes afetados que entraram em contato sobre o incidente pelo Suporte ao cliente do Zendesk por meio de um ticket do Zendesk.
Os incidentes de gravidade 4, por definição, não têm impacto direto no cliente. A análise pós-incidente não é comunicada aos clientes, mas as causas principais são identificadas e as correções são abordadas internamente usando os processos e procedimentos descritos acima.
Atribuição de itens de correção
Para garantir que os itens de correção sejam concluídos, a equipe de engenharia de produto analisa os itens de correção validados na retrospectiva e realiza as seguintes ações:
- Classificar correções como preventivas ou gerais:
- Itens preventivos são aqueles que evitariam ativamente a recorrência do incidente
- Os itens gerais não são apenas preventivos por conta própria, mas resolveriam uma parte essencial das circunstâncias do incidente
- Priorize as correções para definir os SLAs de resposta. Este exercício abrange as seguintes atividades:
- Identifique as equipes de engenharia responsáveis por trabalhar no item de correção
- Vincule o item de correção à causa raiz identificada que ele aborda
- Adicionar o item de correção à lista de pendências de trabalho da equipe de engenharia responsável
- Adicione o item de correção ao relatório de SLA de engenharia para acompanhar a realização do SLA
Abaixo está um gráfico que as equipes de engenharia de produto usam para determinar quando uma correção é priorizada e planejada para seu esforço de trabalho.
SLA de prioridade de item de correção do Zendesk
A equipe de suporte ao cliente do Zendesk que participa da retrospectiva cria as descrições do incidente, das causas principais e das correções identificadas para o cliente. Isso foi publicado no Artigo da Central de Ajuda associado ao incidente.
Exemplo de incidente de disponibilidade de serviço (continuação)
Veja como uma retrospectiva de incidente foi conduzida para esse incidente.
Quatro dias úteis após a ocorrência do incidente, a equipe de resposta a incidentes e os engenheiros se reuniram para analisar o incidente, colaborar nas causas principais e criar ou atualizar os itens de remediação. Todos os itens de correção são acordados por consenso dos participantes da reunião.
Cada pessoa envolvida no incidente desempenhou um papel na retrospectiva do incidente:
Os detalhes revisados e discutidos na reunião incluem:
|
Área |
Exemplo |
|
Linha do tempo |
|
|
Causas principais |
|
|
Fatores de influência |
|
|
Correções |
|
Para que houvesse uma análise completa que gerasse ações concretas para a equipe de engenharia, todos os membros da equipe forneceram informações para relatar o incidente e desenvolver tarefas de correção. Depois que todas as perguntas ou problemas foram abordados pela equipe de resposta a incidentes, a retrospectiva do incidente foi considerada concluída.
A líder de suporte ao cliente do Zendesk responsável pela retrospectiva do incidente voltado para o público foi perguntada, no final da reunião de retrospectiva interna, se ela tinha dúvidas ou precisava de informações adicionais da equipe para criar a documentação pública. Ela não teve mais perguntas e adicionou as informações retrospectivas abaixo ao artigo de incidente de serviço público na seção Notificações de serviço em nossa central de ajuda.
Informações retrospectivas públicas para o Incidente de VM de disponibilidade de serviço
Três resultados importantes dessa retrospectiva de incidentes que melhoraram os produtos e serviços da Zendesk foram:
- As causas principais do incidente foram identificadas e serão consideradas por todas as equipes de produto da Zendesk no desenvolvimento futuro
- As correções foram identificadas e atribuídas às equipes de engenharia com SLAs
- A retrospectiva pública foi publicada pelo Suporte ao cliente Zendesk na Central de Ajuda e enviada aos clientes afetados que enviaram tickets
Encerramento de um incidente de serviço
Como prática recomendada, o Zendesk fecha todos os tickets abertos com os clientes para garantir que tudo seja documentado e comunicado adequadamente para o incidente.
Todos os incidentes de serviço concluídos são resumidos em um relatório semanal de resumo de incidentes de serviço, que é amplamente compartilhado em todo o Zendesk. Descrições de incidentes, impacto no cliente e correções importantes estão incluídos nesse relatório e também em um relatório de revisão de operações quinzenal que é compartilhado com a equipe executiva do Zendesk.
Depois que as informações retrospectivas são publicadas na Central de Ajuda e os tickets abertos são atualizados com os resultados da retrospectiva, a fase de análise e relatórios do incidente de serviço é considerada concluída. O Suporte ao cliente Zendesk vincula esses tickets ao incidente de serviço e eles são marcados como fechados.
Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.
Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.