Esta é a parte 4 da visualização do gerenciamento de incidentes na Zendesk. Este guia contém as seguintes partes:
- Parte 1: Como os problemas de serviço da Zendesk se tornam incidentes de serviço
- Parte 2: Como a Zendesk gerencia incidentes de serviço
- Parte 3: Monitoramento de um incidente público de serviço da Zendesk
- Parte 4: Análise e relatórios de incidentes após a resolução (este artigo)
Neste artigo, parte 4, você aprenderá a como a equipe de resposta a incidentes realiza 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 que têm a responsabilidade.
Ao realizar essas atividades, o Suporte ao cliente Zendesk pode compartilhar detalhes do incidente e as próximas etapas com os clientes afetados.
Este artigo abrange as seguintes seções:
- Realizar uma retrospectiva de incidente de serviço
- Atribuição de itens de correção
- Encerramento de um incidente de serviço
Realizar uma retrospectiva de incidente de serviço
A Zendesk realiza um exercício reflexivo 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 as ações de acompanhamento que evitarão a recorrência do incidente. Isso é conhecido como uma retrospectiva interna de incidente de serviço. As retrospectivas de incidentes são compartilhadas publicamente apenas para incidentes de alta gravidade.
Para garantir transparência e inclusão para todas as equipes do Zendesk, um calendário retrospectivo interno do Zendesk está disponível para que elas possam participar da reunião 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 de incidentes significativos são destacados e analisados na reunião de engenharia semanal do Zendesk.
Existem quatro atividades principais realizadas em retrospectiva de um incidente de serviço:
- Revise os detalhes do incidente contidos no Documento de Incidente para ancorar e orientar os participantes para o incidente
- Revisar e validar as conclusões da análise da causa raiz contidas no Documento de Incidente
- Identifique e categorize qualquer trabalho de reparação necessário para que as equipes de engenharia da Zendesk resolvam completamente as causas principais que levaram ao incidente de serviço. Todos os itens de correcção são acordados por consenso pelos participantes retrospectivos
- Atribuir trabalhos de reparaçã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 for resolvido, o Gerente de incidentes agendará 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 propriedade ou interesse investido, como:
- Suporte ao cliente Zendesk
- Equipes de produto
- Líderes que possuem produtos, serviços e áreas de Support afetados
Todos os esforços são feitos 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 de membros da equipe nas regiões geográficas.
Depois de programar a retrospectiva do incidente, o proprietário de engenharia documenta a análise da causa raiz e cria o Documento de Incidente com base nas seguintes categorias:
- Visão geral do incidente
- Impacto no cliente
- Descrição técnica
- Causa principal e informações de serviço
- Detalhes e cronogramas do incidente
- Correções
O Documento de Incidente orienta a retrospectiva do incidente e captura qualquer trabalho de reparação que seja identificado para resolver totalmente os problemas subjacentes que causaram o incidente.
Existe uma fase de análise adicional realizada para incidentes de gravidade 0-3 conhecidos como Análise da 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 completamente os problemas. Esta informação é capturada no Documento de Incidente.
Processo de análise da causa principal do incidente do Zendesk
Análise de incidente de baixa gravidade
Os incidentes de baixa gravidade passam por uma causa raiz e fase de relatórios mais fracos do que os incidentes de alta gravidade. Embora uma reunião retrospectiva formal de incidentes não seja concluída (a menos que solicitada pelo responsável pela engenharia de produto) para incidentes de baixa gravidade, um Documento de Incidente é criado pelo responsável pela engenharia de produto.
As causas raízes 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. Assim como acontece com incidentes de maior gravidade, a Zendesk busca aprender e melhorar nossos processos de engenharia como resultado da investigação completa de incidentes de baixa gravidade.
Como os incidentes de Severidade 3 têm um pequeno impacto nos clientes, o status do problema e as soluções identificadas são compartilhados com os clientes afetados que entraram em contato sobre o incidente por meio do Suporte ao cliente Zendesk por meio de um ticket do Zendesk.
Por definição, os incidentes de gravidade 4 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 soluçõ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 reparação sejam concluídos, a equipe de engenharia de produto analisa os itens de reparação validados retrospectivamente e executa as seguintes ações:
-
Classifique as soluções como preventiva ou geral:
- Artigos preventivos são aqueles que evitariam ativamente uma recorrência do incidente
- Os pontos gerais não são apenas preventivos por si só, mas resolverão uma parte essencial das circunstâncias do incidente.
- Priorize as correções para definir os SLAs de resposta. Este exercício passa pelas seguintes atividades:
- Identificar as equipes de engenharia responsáveis pelo trabalho do item de reparação
- Vincular o item de correção à causa principal identificada que ele resolve
- Adicionar o item de reparação à lista de pendências de trabalho da equipe de engenharia responsável
- Adicionar o item de correção ao relatório de SLA de engenharia para acompanhar o cumprimento de SLA
Apresentamos a seguir um gráfico que as equipes de engenharia de produto usam para determinar quando uma reparação é priorizada e planejada para o esforço de trabalho.
SLA de prioridade do item de correção do Zendesk
A equipe de suporte ao cliente Zendesk que participa da retrospectiva cria as descrições voltadas para o cliente de incidentes, causas raízes e quaisquer soluções identificadas. Isso é publicado na seção de Notificações de serviço da nossa central de ajuda.
Exemplo de incidente de disponibilidade do serviço Continuar
Assim foi realizada uma retrospectiva do incidente.
4 dias úteis após o incidente, a equipe de resposta a incidentes e os engenheiros se reuniram para analisar o incidente, colaborar nas causas raízes e criar ou atualizar os itens de reparaçã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 analisados e discutidos na reunião incluíram:
| Área | Exemplo |
| Linha do tempo |
|
| Causas principais |
|
| Fatores de influência |
|
| Correções |
|
Para que haja uma análise completa para gerar ações concretas para a equipe de engenharia, todos os membros da equipe forneceram contribuições para relatar o incidente e desenvolver tarefas de reparação. Depois que todas as perguntas ou questões foram abordadas pela equipe de resposta a incidentes, a retrospectiva do incidente foi considerada completa.
A líder de suporte ao cliente Zendesk responsável pela retrospectiva do incidente com o público foi perguntada no final da reunião retrospectiva interna se ela tinha perguntas ou precisava de informações adicionais da equipe para criar a documentação pública. Ela não tinha mais perguntas e adicionou as informações retrospectivas abaixo à seção Notificações de serviço, na central de ajuda.
Informação retrospectiva pública sobre o incidente de VM de disponibilidade de serviço
Três resultados importantes desta 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 a equipes de engenharia com SLAs
- A retrospectiva pública foi publicada pelo Suporte ao cliente Zendesk para a Central de Ajuda e foi enviada para clientes afetados que enviaram tickets.
Encerramento de um incidente de serviço
Como prática recomendada, a Zendesk fecha todos os tickets abertos com os clientes para garantir que tudo esteja devidamente documentado e comunicado sobre 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 é compartilhado amplamente na Zendesk. Descrições de incidentes, impacto no cliente e soluções importantes estão incluídas neste relatório e também estão em um relatório de revisão de operações bi-semanal que é compartilhado com a equipe executiva da Zendesk.
Depois que a informação retrospectiva for publicada na Central de Ajuda e os tickets abertos forem atualizados com os resultados da retrospectiva, a fase de análise e de relatórios do incidente de serviço é considerada concluída. O Suporte ao cliente Zendesk vincula esses tickets ao incidente de serviço e os marca 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.