Esta é a parte 2 da visualização geral 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 (este artigo)
- 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
Nesta parte 2, você entenderá como as equipes da Zendesk respondem a incidentes de serviço em nossos produtos com base nos níveis de gravidade. A Zendesk adota uma abordagem abrangente para entender um incidente, desde sua causa raiz até o impacto total para os clientes afetados, e comunica o nível apropriado de detalhes.
Este artigo abrange as seguintes seções:
- Gravidade do incidente
- Equipe de resposta a incidentes
- Tempos de comunicação para incidentes
- Processo de incidente de baixa gravidade
Gravidade do incidente
Uma das decisões principais tomadas quando um incidente de serviço é criado é atribuir a gravidade do incidente. A gravidade de um incidente determina como e quais equipes da Zendesk lidam com o problema e como ele é comunicado aos clientes afetados.
A Zendesk usa um sistema que agrupa os incidentes de serviço em 5 níveis de gravidade com base nas características do incidente:
Sistema de classificação de gravidade do Zendesk
Diferentes caminhos de transferência e equipes são envolvidas para investigar, comunicar e corrigir o incidente com base no nível de gravidade. Isso garante que o nível certo de rigor seja dado a cada incidente. O diagrama abaixo descreve as principais atividades que ocorrem durante e após a limpeza de um incidente com base no seu nível de gravidade:
Processo por nível de gravidade
Enquanto os incidentes de alta gravidade passam por uma análise rigorosa e atividades de reparação, cada incidente - independentemente do nível de gravidade - passa por um processo de resposta e investigação em tempo real. Isso produz:
- Atualizações na página de status do Zendesk quando o incidente é público
- Análise de causas raízes e correções de incidentes
- Relatório de incidente (interno) do Zendesk
Exemplo de incidente de disponibilidade do serviço do Zendesk
Apresentamos a seguir um exemplo de como a gravidade do incidente é definida pela Zendesk e como as equipes da Zendesk respondem internamente:
Exemplo de descoberta e resposta de incidentes
No exemplo, você vê o fluxo de trabalho a seguir:
- O Zendesk Network Operations Center (ZNOC) identificou um problema quando os alertas do sistema mostraram que os nós de serviço no Pod 17 não podiam ser alcançados pelas solicitações. A equipe de engenharia de rede da Zendesk verificou que os problemas de acesso estavam afetando diretamente os serviços do cliente e rapidamente percebeu que os serviços do soporte, Guide e Talk para vários clientes não estavam funcionando conforme o esperado. Um novo incidente de serviço do Zendesk foi criado.
- Esse incidente era conhecido por afetar dois clientes quando foi criado inicialmente, mas devido à natureza da interrupção, mais clientes estavam tendo o problema e começaram a apresentar seus problemas com o Suporte ao cliente Zendesk. O incidente recebeu uma classificação de gravidade de 1 pela equipe de engenharia - um incidente de alta prioridade que requer atenção imediata.
- A equipe de resposta a incidentes foi pagada imediatamente. Dentro de minutos da criação do incidente, um Gerente de incidentes coletou informações e montou recursos de engenharia adicionais para solucionar o problema e corrigir o incidente de serviço.
Equipe de resposta a incidentes
A Zendesk tem uma equipe global dedicada à Resposta a Incidentes para garantir que cada incidente seja acompanhado pelo processo de gerenciamento de incidentes de serviço e encaminhado para os níveis apropriados de liderança da Zendesk, conforme necessário.
Funções e responsabilidades da gestão de incidentes
Essa estrutura de equipe permite que a Zendesk faça uma análise completa do incidente com recursos técnicos e se comunique em tempo real com os clientes por meio do Suporte ao cliente da Zendesk.
Tempos de comunicação para incidentes
A Zendesk investe em garantir que os incidentes sejam devidamente comunicados e resolvidos em prazos adequados para o cliente. Estabelecemos cronogramas internos para a distribuição dos detalhes do incidente. O cronograma é baseado no nível de gravidade do incidente e nas etapas de gestão do incidente de serviço.
| Estágio | Tempo de resposta |
| Anúncio público | Dentro de 15 minutos do incidente ligou |
| Atualizações de incidente | A cada 30 minutos até que o serviço seja restaurado ou quando novas informações forem disponibilizadas. |
|
Análise de eventos (para incidentes de gravidade 0 e 1) |
Dentro de 48 horas da resolução do incidente |
| Análise de causa principal | Dentro de 72 horas da resolução do incidente |
| Retrospectiva pública do incidente | Dentro de mais de 96 horas de resolução de incidente |
Os incidentes com uma classificação de gravidade de 0 a 2 são considerados incidentes de alta gravidade. Quando ocorre um incidente de alta gravidade, a equipe global de resposta a incidentes está disponível 24 horas por dia, 7 dias por semana, para responder a esses incidentes. A equipe é composta pelas seguintes funções:
Funções da equipe de resposta a incidentes
Locais globais da equipe de resposta a incidentes
Como a equipe de chamada é pagada, o diagnóstico do incidente começa minutos após o incidente ser declarado. Um canal do Slack e uma chamada do Zoom são criados para permitir a comunicação da equipe de resposta em tempo real. Conforme a equipe de resposta a incidentes faz a triagem e o escopo do incidente, as equipes de engenharia em chamada são paginadas com base nos produtos e serviços afetados.
Uma publicação pública na página de status do Zendesk é feita dentro de 15 minutos da criação do incidente para manter os clientes informados sobre o incidente conhecido. As atualizações são publicadas a cada 30 minutos até a resolução, pois novas informações ficam disponíveis. Dependendo do problema e da quantidade de novas informações identificadas, essa cadência pode ser reduzida ou estendida conforme necessário. Os clientes podem monitorar incidentes de serviço ativos na página Zendesk Status - esse processo é descrito na parte 3 deste guia.
Além de nossas equipes globais de resposta a incidentes de chamada, a Zendesk estabeleceu processos para notificação e encaminhamento de líderes. Se um incidente de alta gravidade atender a certos critérios, ativamos o próximo nível de resposta, que é o Gerenciamento de crises.
Exemplo de incidente de disponibilidade de serviço do Zendesk continuado
Em seguida, usando o incidente de disponibilidade do serviço , veja como a resposta a incidentes progrediu pelo processo de gerenciamento de incidentes na Zendesk:
Tempo de resposta a incidentes de disponibilidade do serviço
Como você pode ver no exemplo, uma vez que o incidente foi criado no portal de incidentes do Zendesk, uma série de ações automatizadas foram executadas:
- A equipe de resposta a incidentes foi chamada para responder ao incidente.
- Um canal do Slack de incidente foi criado automaticamente e a equipe de resposta a incidentes foi adicionada ao canal dedicado do Slack.
- Uma chamada do Zoom foi iniciada automaticamente e publicada no canal do Slack para todos os respondentes participarem
- Um documento de resumo do evento foi criado automaticamente para documentar o incidente e compartilhar o progresso internamente com o Zendesk.
Na chamada do Zoom, o Gerente de incidentes validou a gravidade inicial e confirmou o escopo e o impacto do problema.
Foi rapidamente determinado que vários nós de contêiner no Pod 17 não estavam acessíveis e não podiam ser usados por serviços dependentes, incluindo os produtos Support, Guide e Talk. Um tipo específico de nó não tinha réplicas disponíveis em outros pods. Isso eventualmente faria com que esses produtos não respondessem a vários clientes.
O ZNOC encaminhou a equipe de engenharia de rede apropriada para a chamada do Zoom para começar a investigar como resolver o problema imediato de restaurar o serviço e o acesso à API para os clientes. As PME de engenharia de borda também foram pagas e participaram da chamada. Dentro de 5 minutos, uma correção foi identificada e implantada para que os nós afetados pudessem novamente acessar chamadas e serviços da API.
O suporte ao cliente da Zendesk criou um ticket de problema para acompanhar os relatórios dos clientes. Esse ticket foi adicionado ao canal do Slack de incidente para permitir que novos relatórios sejam adicionados rapidamente.
Enquanto a investigação continuava, o Incident Escalation Manager criou e publicou a primeira atualização pública da página de status do Zendesk 12 minutos após a criação do incidente.
Publicação do primeiro incidente de disponibilidade de serviço na página de status do sistema do Zendesk
Enquanto as equipes investigaram o incidente, os relatórios de clientes que chegaram foram vinculados ao principal ticket de problema associado ao incidente. Isso permitiu que a equipe de resposta a incidentes enviasse atualizações para todos os clientes afetados quando fizessem notificações públicas.
A equipe de engenharia de rede determinou que uma alteração na forma como os certificados foram gerados e usados foi responsável pelo incidente e tomou as seguintes ações para restaurar o serviço aos clientes afetados:
- Nodos inacessíveis desativados
- Criação de novos nós de serviço com certificados devidamente referenciados
- Verificou se os novos nós de serviço estavam acessíveis para serviços e por chamadas da API.
- Monitoramento do tráfego recebido para verificar se as solicitações recebidas agora estavam sendo tratadas adequadamente.
À medida que o incidente progrediu, mais duas atualizações públicas foram feitas: Um 14 minutos após a criação do incidente e outro 63 minutos após a criação do incidente. O histórico de comunicação pública junto com informações retrospectivas do incidente publicadas podem ser encontradas na página Notificações de serviço para o incidente.
Como mostrado no exemplo, os incidentes de alta gravidade passam por um processo rigoroso em que as causas raízes são determinadas e itens de reparação são criados para as equipes de engenharia de produto corrigirem o problema subjacente que causou o incidente. Essa análise acontece durante nossa retrospectiva de incidentes e é discutida em mais detalhes na seção Análise de incidentes após resolução.
Processo de incidente de baixa gravidade
Os incidentes de serviço de menor gravidade (níveis 3-4) são menos críticos porque afetam um número menor de clientes e não impedem que esses clientes usem funções críticas de negócios dos produtos Zendesk. Esses incidentes são tratados de acordo com as diretrizes acima, mas não são publicados em canais públicos.
Os incidentes de gravidade 3 são tratados da mesma maneira que os incidentes de gravidade 0-2. Os tempos de reação esperados são estendidos devido ao menor impacto nos negócios. Mesmo que a equipe de chamada não seja pagada, esses incidentes são gerenciados por canais específicos do Slack de incidentes do Zendesk associados às equipes de engenharia de produto de suporte e as equipes tendem a responder tão rapidamente quanto incidentes de maior gravidade. A maioria dos incidentes de gravidade 3 não usa canais de comunicação pública. Em vez disso, as equipes de suporte ao cliente do Zendesk Reach usam notificações proativas se forem necessárias ações específicas de um subconjunto de clientes.
Os incidentes de gravidade 4 não afetam diretamente o uso dos serviços da Zendesk pelo cliente, mas podem fazer isso se não forem resolvidos. Esses incidentes são criados como respostas proativas a possíveis problemas. As equipes de engenharia de produto interagem da mesma maneira que fazem com o processo de gravidade 3.
Saiba mais
Isso completa a Parte 2, Como a Zendesk gerencia incidentes de serviço, da visão geral do gerenciamento de incidentes na Zendesk.
Se você quiser saber mais, vá para a próxima parte deste guia: Parte 3: Monitoramento de um incidente público de serviço do Zendesk.
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.