Esta é a parte 2 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 (este artigo)
- 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
Neste artigo, parte 2, você entenderá hAgora, as equipes do Zendesk respondem aos incidentes de serviço em nossos produtos com base nos níveis de gravidade. O Zendesk adota uma abordagem abrangente para entender um incidente - desde sua causa raiz até o impacto total nos clientes afetados - e comunica o nível adequado de detalhes.
Este artigo abrange as seguintes seções:
- Gravidade do incidente
- Estrutura da equipe de resposta a incidentes
- Linhas do tempo de comunicação para incidentes
- Processo de incidente de baixa gravidade
Gravidade do incidente
Uma das principais decisões tomadas quando um incidente de serviço é criado é a atribuição da gravidade do incidente. A gravidade de um incidente determina como e quais equipes do Zendesk abordam o problema e como ele é comunicado aos clientes afetados.
O 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 escalonamento e equipes são engajados para investigar, comunicar e corrigir o incidente com base no nível de gravidade. Isso garante que o nível certo de rigor seja fornecido a cada incidente. O diagrama abaixo descreve as principais atividades que acontecem durante e após a resolução de um incidente com base em seu nível de gravidade:
Processar por nível de gravidade
Enquanto os incidentes de alta gravidade passam por análises rigorosas e atividades de correção, todos os incidentes, independentemente do nível de gravidade, passam 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 causa raiz e correções de incidentes
- Relatório de incidente do Zendesk (interno)
Exemplo de incidente de disponibilidade de serviço do Zendesk
Aqui está um exemplo de como a Gravidade do Incidente é definida pelo Zendesk e como as equipes do 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 mostravam que os nós de serviço no pod 17 não podiam ser acessados por solicitações. A equipe de engenharia de rede da Zendesk verificou que os problemas de acesso estavam afetando diretamente o atendimento ao cliente e percebeu rapidamente que os serviços Support, 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 reportá-los ao Suporte ao cliente do Zendesk. O incidente recebeu uma classificação de gravidade 1 pela equipe de engenharia - um incidente de alta prioridade que requer atenção imediata.
- A equipe de plantão de resposta a incidentes foi comunicada imediatamente. Poucos minutos após a criação do incidente, um gerente de incidente coletou informações e reuniu recursos de engenharia adicionais para solucionar problemas e corrigir o incidente de serviço.
Estrutura da equipe de resposta a incidentes
A Zendesk tem uma equipe global de resposta a incidentes dedicada para garantir que todos os incidentes sejam conduzidos pelo processo de gerenciamento de incidentes de serviço e transferidos para os níveis apropriados de liderança da Zendesk, conforme garantido.
Funções e responsabilidades do gerenciamento de incidentes
Essa estrutura de equipe permite que o Zendesk conduza 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 do Zendesk.
Linhas do tempo de comunicação para incidentes
A Zendesk investe em garantir que os incidentes sejam comunicados adequadamente e resolvidos em prazos adequados para o cliente. Estabelecemos cronogramas internos para a distribuição dos detalhes do incidente. A linha do tempo tem base no nível de gravidade do incidente e nos estágios de gerenciamento de incidentes de serviço.
|
Estágio |
Linhas do tempo de resposta |
|
Anúncio público |
Até 15 minutos após o incidente, ligou para |
|
Atualizações de incidentes |
A cada 30 minutos, até que o serviço seja restaurado ou novas informações sejam disponibilizadas |
|
Análise de eventos (para incidentes de gravidade 0 e 1) |
Até 48 horas após a resolução do incidente |
|
Análise da causa raiz |
Até 72 horas após a resolução do incidente |
|
Retrospectiva de incidentes públicos |
Até 96 horas após a resolução do incidente |
Os incidentes com uma classificação de gravidade de 0 a 2 são considerados altos incidentes de 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 consiste das seguintes funções:
Funções da equipe de resposta a incidentes
Locais globais da equipe de resposta a incidentes
À medida que a equipe de plantão é acionada, o diagnóstico do incidente começa minutos após a declaração do incidente. Um canal do Slack e uma chamada do Zoom são criados para permitir a comunicação da equipe de resposta em tempo real. À medida que a equipe de resposta a incidentes faz a triagem e o escopo do incidente, as equipes de engenharia de plantão recebem mensagens com base nos produtos e serviços afetados.
Uma publicação pública na página de status do Zendesk é feita até 15 minutos após a 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 conforme novas informações são disponibilizadas. Dependendo do problema e da quantidade de novas informações identificadas, essa cadência pode ser reduzida ou aumentada conforme necessário. Os clientes podem monitorar os incidentes de serviço ativos na página Status do Zendesk. Esse processo é descrito em parte 3 deste guia.
Além de nossas equipes globais de resposta a incidentes de plantão, a Zendesk estabeleceu processos para notificação e encaminhamento da liderança. Se um incidente de alta gravidade atender a determinados 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 (continuação)
Continuando a usar o incidente de disponibilidade de serviço como exemplo, é assim que a resposta ao incidente progrediu pelo processo de gerenciamento de incidentes no Zendesk:
Linha do tempo de resposta a incidentes de disponibilidade de serviço
Como você pode ver no exemplo, depois que o incidente foi criado no portal de incidentes do Zendesk, uma série de ações automatizadas foram tomadas:
- A equipe de plantão de resposta a incidentes foi chamada para responder ao incidente
- Um canal de incidente do Slack foi criado automaticamente e a equipe de resposta a incidentes de plantão 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 de nó em particular não tinha réplicas disponíveis em outros pods. Isso acabaria fazendo com que esses produtos parassem de responder a vários clientes.
O ZNOC enviou um pager para 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. Os especialistas em engenharia de borda também foram chamados e participaram da chamada. Em 5 minutos, uma correção foi identificada e implementada para que os nós afetados estivessem novamente acessíveis para chamadas e serviços da API.
O Suporte ao cliente Zendesk criou um ticket de problema para acompanhar os relatórios do cliente. Esse ticket foi adicionado ao canal de incidente do Slack para permitir que novos relatórios sejam adicionados rapidamente à medida que chegam.
Enquanto a investigação continuava, o gerente de escalonamento de incidentes criou e publicou a primeira atualização pública na página de status do Zendesk 12 minutos após a criação do incidente.
Primeira publicação de incidente de disponibilidade de serviço na página de status do sistema do Zendesk
Enquanto as equipes investigavam o incidente, os relatórios de clientes recebidos eram vinculados ao ticket de problema principal associado ao incidente. Isso permitiu que a equipe de resposta a incidentes enviasse atualizações para todos os clientes afetados quando eles fizessem notificações públicas.
A equipe de engenharia de rede determinou que uma alteração em como os certificados eram gerados e usados era responsável pelo incidente e tomou as seguintes ações para restaurar o serviço para os clientes afetados:
- Nós inacessíveis desativados
- Novos nós de serviço criados com certificados referenciados corretamente
- Verificou que os novos nós de serviço estavam acessíveis para serviços e por meio de chamadas da API
- Monitoramento do tráfego de entrada para verificar se as solicitações recebidas estavam sendo tratadas adequadamente
À medida que o incidente avançava, mais duas atualizações públicas foram feitas: Uma 14 minutos após a criação do incidente e outra 63 minutos após a criação do incidente. O histórico de comunicação pública, juntamente com as informações retrospectivas de incidentes publicadas, pode ser encontrado 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 no qual as causas principais são determinadas e os itens de remediação são criados para que as equipes de engenharia de produto corrijam 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 incidente pós-resolução.
Processo de incidente de baixa gravidade
Os incidentes de serviço de menor gravidade (níveis 3 a 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 para os negócios dos produtos Zendesk. Esses incidentes são abordados 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 resposta esperados são estendidos devido ao impacto comercial reduzido. Mesmo que a equipe de plantão não seja chamada, esses incidentes são tratados por meio de 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 os incidentes de gravidade mais alta. A maioria dos incidentes de gravidade 3 não usa canais de comunicação públicos. Em vez disso, as equipes de suporte ao cliente do Zendesk entram em contato com os clientes usando notificações proativas se uma ação específica for necessária de um subconjunto de clientes.
Os incidentes de gravidade 4 não afetam diretamente o uso dos serviços do Zendesk pelos clientes, mas têm o potencial de fazê-lo se não forem abordados. 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 conclui a Parte 2, Como o Zendesk gerencia incidentes de serviço, da Visão geral do gerenciamento de incidentes no Zendesk.
Se você quiser saber mais, pode avançar para a próxima parte deste guia: Parte 3: Monitoramento de um incidente de serviço público 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.