Seguir as práticas recomendadas para casos de suporte ajuda a resolver problemas técnicos mais rapidamente ao trabalhar com o atendimento ao cliente. Ao incluir carimbos de data/hora claros, identificadores de projeto e detalhes de diagnóstico, você fornece aos engenheiros de suporte o contexto necessário para investigar seu caso imediatamente.
Criar um caso de suporte
Antes de criar um caso de suporte, consulte os problemas conhecidos para saber se o caso já foi registrado.
Para evitar confusão e para que possamos acompanhar sua solicitação em um único ponto, crie um caso de suporte por problema. Todos os casos duplicados criados são encerrados.
Como descrever o problema
Ao escrever um caso de suporte detalhado, você ajuda a equipe de atendimento ao cliente a responder com rapidez e eficiência. Quando seu caso de suporte não tem detalhes importantes, precisamos solicitar mais informações, o que leva mais tempo.
Os melhores casos de suporte são detalhados e específicos. Eles contam o que aconteceu e o que você esperava que acontecesse. Ao descrever o problema no caso de suporte, inclua os seguintes detalhes:
- Momento: a data e a hora específicas em que o problema começou.
- Produto:os produtos e recursos associados ao erro.
- Local:as zonas em que você encontra o problema.
- Identificadores:o ID do projeto ou o ID do aplicativo e outros identificadores concretos que nos ajudam a pesquisar o problema.
- Elementos úteis: qualquer detalhe que você possa fornecer para ajudar a diagnosticar o problema.
- Tipo de problema:o erro é intermitente, transitório ou consistente?
As seções a seguir descrevem esses conceitos em mais detalhes.
Hora
Usando o formato ISO 8601 para a data e o carimbo de data/hora, informe quando você notou o problema pela primeira vez e quanto tempo ele durou.
Exemplos:
- A partir de 2017-09-08T15:13:06+00:00 e terminando 5 minutos depois, observamos...
- Problema observado de maneira intermitente a partir de 2017-09-10 e observado de 2 a 5 vezes...
- Ocorre desde 2017-09-08T15:13:06+00:00...
- Entre 2017-09-08T15:13:06+00:00 e 2017-09-08T15:18:16+00:00...
É muito provável que o especialista do Atendimento ao Cliente que está resolvendo o problema não esteja no seu fuso horário. Portanto, frases genéricas como as seguintes dificultam o diagnóstico:
- "Isso começou em algum momento de ontem..." — Obriga nossos engenheiros a inferir a data implícita.
- "Percebemos o problema em 9/8..." (Ambíguo, já que alguns podem interpretar essa data como 8 de setembro e outros como 9 de agosto).
Produto
O formulário básico pede que você especifique o nome do produto, mas precisamos de informações específicas sobre qual recurso desse produto apresenta o problema. O ideal é que o relatório se refira a APIs específicas ou URLs do console do Google Cloud (ou capturas de tela). Para APIs, você pode adicionar o link para a página de documentação, que contém o nome do produto no URL.
Informe também o mecanismo que você está usando para iniciar a solicitação (por exemplo, API REST, Google Cloud CLI, console do Google Cloud ou talvez uma ferramenta como o Cloud Deployment Manager). Se houver vários produtos envolvidos, informe o nome de cada um deles.
Exemplos:
- "A API REST do Compute Engine retornou os seguintes erros..."
- "A interface de consulta do BigQuery em console.cloud.google.com está travando..."
As declarações a seguir não são específicas o suficiente para sabermos onde procurar ao diagnosticar o problema:
- "Não é possível criar instâncias...": precisamos saber qual método você está usando para criar instâncias.
- "O comando
gcloud compute create instancesestá apresentando um erro..."(A sintaxe do comando está incorreta, então não podemos executá-lo para reproduzir o erro. Além disso, não conseguimos saber qual erro você realmente viu.
Local
Precisamos saber a região e a zona do seu data center porque geralmente implantamos mudanças em uma região ou zona por vez. A região e a zona são representantes do número da versão do software subjacente. Essas informações nos ajudam a saber se as alterações interruptivas em uma versão específica do nosso software estão afetando seus sistemas.
Exemplos:
- "Em us-east1-b ..."
- "Tentei as regiões us-east1 e us-central1..."
Identificadores
Identificadores específicos nos ajudam a encontrar quais dos seus projetos de nuvem estão sendo afetados pelo problema. Sempre precisamos saber o ID alfanumérico do projeto ou do aplicativo. Nomes de projetos não são úteis. Se o problema estiver afetando vários projetos, inclua todos os códigos afetados.
Além dos IDs de projeto ou ID do aplicativo, vários outros identificadores nos ajudam a diagnosticar seu caso:
- IDs de instância
- códigos da tarefa ou nomes de tabelas do BigQuery.
- endereços IP
Ao especificar um endereço IP, informe também o contexto em que ele é usado. Por exemplo, especifique se o IP está conectado a uma instância de computação, um balanceador de carga, uma rota personalizada ou um endpoint de API. Informe também se o endereço IP não está relacionado aos sistemas do Google (por exemplo, se o endereço IP é da Internet da sua casa, de um endpoint de VPN ou de um sistema de monitoramento externo).
Exemplos:
- "No projeto robot-name-165473 ou my-project-id..."
- "Em vários projetos (incluindo my-project-id)..."
- "Conectando ao IP externo Google Cloud 218.239.8.9 pelo nosso gateway corporativo 56.56.56.56..."
Declarações como as seguintes são muito genéricas para diagnosticarmos o problema:
- "Uma das nossas instâncias está inacessível..."
- "Não conseguimos nos conectar a partir da Internet ..."
Elementos úteis
Informar quais elementos estão relacionados ao problema agilizará a solução de problemas e nos ajudará a ver exatamente o que você está vendo.
Exemplo:
- Use uma captura de tela para mostrar exatamente o que você vê.
- Para interfaces baseadas na Web, forneça todas as informações de rastreamento do navegador relevantes.
- Anexe a saída tcpdump, snippets de registros e exemplos de rastreamentos de pilha.
Tipo de problema
Intermitente: problemas intermitentes ocorrem aleatoriamente, sem padrões regulares de falha. Os problemas intermitentes são difíceis de solucionar porque a irregularidade dificulta a coleta de dados durante a falha. Nesse caso, você deve tentar identificar os gargalos na arquitetura e verificar se os recursos atingem o limite máximo de uso. Você também pode executar verificações frequentes em um job agendado usando automação e, se a verificação falhar, coletar informações de depuração durante a falha. Exemplos desse tipo de falha são falhas de resolução de DNS e perda de pacotes.
Transitório: os problemas transitórios são momentâneos ou existem apenas por um curto período de tempo. Se você tiver problemas que ocorrem apenas por um segundo ou alguns microssegundos, é possível verificar se há micro explosões de tráfego ou utilizações de pico de recursos. Na maioria dos casos, os problemas temporários podem ser ignorados se não ocorrerem com frequência e se o serviço for projetado para ser tolerante a falhas temporárias. Exemplos desse tipo de falha são picos de latência de rede que ocorrem apenas por alguns microssegundos e pequenas perdas de pacotes que causam esgotamentos de tempo limite. O protocolo TCP foi projetado para falhas, como pequenas perdas de pacotes e picos de latência, e pode lidar com esses problemas de maneira eficaz, a menos que seu aplicativo seja sensível à latência.
Consistente: problemas consistentes são problemas que falham completamente, por exemplo, quando seu site não está funcionando. Problemas consistentes são relativamente fáceis de resolver problemas porque podem ser reproduzidos. Nesse caso, informe as etapas para reproduzir o problema, de modo que nossos especialistas em atendimento ao cliente possam replicar o ambiente e resolver o problema para você.
Exemplos de descrições
Os exemplos a seguir fornecem descrições detalhadas de casos de suporte.
Exemplo 1
JobName:
A_ATL_BIG1toBQ_big_04)201704202
00045_491
Source:
S3_avl-transfer
Destination:
CloudStorage: avl-transfer
Start time (ISO 8601 format): 2017-04-20 20:14:43 PDT
End time (ISO 8601 format): 2017-04-21 at 10:03:44 PDT
I started a file transfer at 2017-04-20 at 20:14:43 PDT using the transfer API.
This job normally takes 10 minutes to complete, but in this case the job was
still running when I canceled it the next day (2017-04-21 at 10:03:44 PDT). This
is not an isolated event; several other jobs involving the transfer API had
intermittent, significant delays.
Please investigate the cause of the delays and advise of any best practices that
we can implement to prevent these issues in the future.
Exemplo 2
Start time (ISO 8601 format): 2017-05-12 at 11:03:43
End time (ISO 8601 format): The issue is still happening as of the time of this
report.
Issue summary:
`/cron/payments-service/sync-v2-batch` cron using the App Engine Task Queue API
has stopped running since 2017-05-12 at 11:03:43. We rely on this job to handle
payments correctly.
We saw datastore and queue errors and then the cron stopped running. We
attempted unsuccessfully to fix the issue by re-uploading cron.xml. Here is the
error trace:
`[error trace]`
Please advise if the issue is with the API or our implementation and let us
know next steps.
Como definir a prioridade e escalonar
A prioridade ajuda a entender o impacto do problema na sua empresa e afeta a rapidez com que respondemos para que um problema seja resolvido. As prioridades são definidas na tabela a seguir. Saiba mais em Prioridade do caso de suporte.
| Definição de prioridade | Exemplo de situação |
|---|---|
| P1: impacto crítico, serviço inutilizável na produção | O aplicativo ou a infraestrutura não pode ser usado na produção, com uma taxa significativa de erros voltados ao usuário. O impacto nos negócios é crítico (perda de receita, possível problema de integridade de dados etc.). |
| P2: impacto alto, uso do serviço gravemente prejudicado | A infraestrutura está degradada na produção, com uma taxa perceptível de erros voltados ao usuário ou dificuldades para criar um novo sistema de produção. O impacto no negócio é moderado (perigo de perda de receita, queda na produtividade etc.). |
| P3: impacto médio, uso do serviço parcialmente prejudicado | A questão é limitada em escopo e/ou gravidade. O problema não tem impacto visível para o usuário. O impacto comercial é baixo (por exemplo, inconveniência ou pequenos processos comerciais afetados). |
| P4: impacto baixo, serviço totalmente utilizável | Impacto técnico no negócio mínimo ou inexistente. Recomendado para tickets consultivos em que análises detalhadas, solução de problemas ou consultoria são preferíveis a comunicações mais frequentes. |
Quando definir a prioridade mais alta
Se você enfrentar um problema que afete os principais serviços da empresa e precisar de atenção imediata do Google, escolha a prioridade "P1". Explique em detalhes por que você selecionou P1. Inclua uma breve descrição do impacto que esse problema está causando na sua empresa. Por exemplo, você pode considerar um problema com uma versão de desenvolvimento como P1, mesmo que nenhum usuário final seja afetado diretamente, se ele estiver bloqueando uma correção de segurança crítica.
Quando um caso é definido como P1, um especialista é alertado imediatamente para trabalhar exclusivamente no problema. Você recebe uma resposta inicial rápida para participar de uma chamada de solução de problemas ao vivo pelo Google Meet. Se a organização não puder usar o Google Meet, inclua um link para o software de videoconferência de sua escolha para o especialista participar. Depois disso, você vai receber atualizações regulares pelo caso.
Agradecemos os comentários detalhados que dão suporte ao nível de priorização escolhido, isso nos ajuda a responder adequadamente.
O que esperar do suporte em casos P1
Novo caso P1
- Um especialista em suporte vai interagir com você pelo Google Meet ou por qualquer outra ponte que você fornecer. Esperamos que você participe da chamada em até 15 a 30 minutos. Informe ao especialista de suporte se você não puder participar da chamada por qualquer motivo.
- O caso "segue o sol" por padrão. Isso significa que os especialistas em suporte trabalham 24 horas por dia até que o caso seja mitigado ou despriorizado. Se a mitigação do caso for mais adequada em uma região específica, esse caso poderá ser bloqueado para um determinado fuso horário. Você pode nos informar sua preferência para esse efeito.
Aumento da prioridade para P1
- Se o problema começou a afetar seu ambiente de produção ou está prestes a fazer isso, aumente a prioridade de um caso P2 - P4 para P1.
- Quando você aumenta a prioridade de um caso para P1, ele pode ser reatribuído para que um especialista de suporte disponível possa dar atenção imediata.
Impacto fora da produção
Para garantir que os recursos adequados sejam alocados onde necessário, o suporte pode entrar em contato com você para reavaliar os casos marcados como P1 que não estão afetando a produção ou causando alto impacto nos negócios.
Tempos de resposta
Os níveis de prioridade de problemas têm tempos de resposta predefinidos nas Diretrizes de serviços de suporte técnico do Google Cloud Platform. Se você precisar de uma resposta até um horário específico, informe isso na descrição da denúncia. Se um problema P1 precisar ser resolvido 24 horas por dia, você pode solicitar o serviço de suporte contínuo. Esses casos são reatribuídos várias vezes ao dia a um especialista ativo do Atendimento ao Cliente. Enquanto resolvemos seu caso P1, recomendamos que você permaneça disponível para responder a perguntas até a resolução para facilitar a comunicação. Se você não responder por mais de 3 horas, poderemos reduzir a prioridade do caso para P2 até que você volte a interagir.
Encaminhamento
Quando as circunstâncias mudam, pode ser necessário encaminhar um problema. Bons motivos para encaminhamento são:
- Aumento do impacto no negócio
- Detalhes do processo de resolução. Por exemplo, você não recebeu uma atualização no período acordado ou o problema está "travado" sem progresso após a troca de várias mensagens.
Quando você tiver um problema de alto impacto, a melhor solução é definir o caso com a prioridade apropriada por um período adequado, em vez de encaminhá-lo. O encaminhamento não necessariamente resolve o caso mais rápido, e encaminhar logo após a mudança de prioridade pode até mesmo retardar a resolução do caso. Confira uma explicação mais detalhada no vídeo Quando você deve encaminhar.
Para mais informações, consulte Encaminhar um caso.
Encaminhar casos para o fuso horário necessário
Devido aos fatores em que a disponibilidade do Atendimento ao Cliente se baseia, seu caso de suporte pode ser atribuído a um especialista que trabalha fora do seu horário de funcionamento. Também é possível que você queira interagir
com o Atendimento ao Cliente durante os dias úteis de um fuso horário específico. Nesses
casos, recomendamos que você peça ao Atendimento ao Cliente para encaminhar seu
caso de suporte para um fuso horário conveniente. É possível adicionar essa
solicitação à descrição ou à resposta do seu caso. Por exemplo, Please route this
case to the Pacific time zone (GMT-8). Os casos P1 são transferidos para o atendimento ao cliente da próxima região porque seguem o sol, enquanto outros casos permanecem com o proprietário atual para continuar trabalhando no caso no dia seguinte.
Enviar feedback com a pesquisa do CES
Quando um caso é resolvido, uma pesquisa de Pontuação de trabalho do cliente (CES, na sigla em inglês) sobre sua opinião sobre o processo foi enviada por e-mail. Agradecemos se você puder dedicar alguns minutos para preenchê-lo, para que possamos saber o que fizemos bem e quais foram os desafios para melhorar esses aspectos.
Cada formulário de feedback é analisado manualmente pela equipe de Experiência do Cliente e resulta em ações correspondentes para melhorar sua experiência futura. A pontuação será de 5. Uma pontuação de 3 ou menos é considerada difícil para o cliente. Por outro lado, uma pontuação de 4 ou mais significa que a interação não foi difícil para o cliente e é considerada uma experiência positiva.
Para mais informações, assista ao vídeo Como enviar feedback sobre os serviços do Google Cloud com o CES.
Problemas difíceis ou de longa duração
Problemas que demoram a ser resolvidos podem se tornar confusos e obsoletos. A melhor maneira de evitar isso é coletar informações usando nosso modelo de problemas de longa duração, com o estado mais recente resumido na parte superior.
Para usar o modelo, abra o link acima e faça uma cópia. Inclua links para todos os casos relevantes e bugs de rastreamento interno. Compartilhe este documento com o grupo da equipe de conta e peça que eles o compartilhem com especialistas específicos do Atendimento ao Cliente.
Este documento inclui:
- um resumo do estado atual reduzido na parte superior;
- uma lista das hipóteses potencialmente verdadeiras;
- os testes ou ferramentas que você pretende usar para validar cada hipótese.
Tente manter cada caso com um único problema especificado e evite reabrir um caso para apresentar um novo problema.
Como informar uma interrupção de produção
Se o problema fez com que o aplicativo parasse de exibir tráfego para os usuários ou tivesse um impacto crítico semelhante para os negócios, pode ser uma interrupção de produção. É importante informar essa situação o quanto antes. Em contrapartida, problemas que afetam um pequeno número de desenvolvedores não são considerados como interrupções de produção.
Quando recebemos um relatório de interrupção de produção, realizamos uma triagem da situação rapidamente:
- Verificar imediatamente se há problemas conhecidos que afetam a infraestrutura do Google Cloud .
- Confirmamos a natureza do problema.
- Estabelecemos canais de comunicação.
Você vai receber uma resposta com uma mensagem breve, que contém:
- problemas conhecidos relacionados que afetam vários clientes;
- um aviso de que podemos observar o problema que você informou ou uma solicitação para fornecer mais detalhes;
- Como pretendemos nos comunicar.
Portanto, é importante criar um caso rapidamente, incluindo momento, produto, identificadores e local, e depois iniciar uma solução de problemas mais detalhada. Sua organização pode ter um processo de gerenciamento de incidentes definido, e essa etapa precisa ser executada logo no início dele.
O processo de gerenciamento de incidentes do Google define um papel fundamental: o representante do incidente Essa pessoa envolve os grupos certos, coleta continuamente o status mais recente e resume periodicamente o estado do problema. Ela atribui outras pessoas para solucionar problemas e aplicar alterações. Essas atribuições de tarefas nos permitem investigar várias hipóteses em paralelo. Recomendamos que você estabeleça um processo semelhante na sua organização. A pessoa que abriu o caso é geralmente a mais indicada a ser o representante do incidente, porque tem mais informações sobre o contexto.
Como informar um problema de rede
O tamanho e a complexidade da rede do Google podem dificultar a identificação de qual equipe é a responsável pelo problema. Para diagnosticar problemas de rede, precisamos identificar as principais causas específicas. Como as mensagens de erro de rede geralmente são genéricas (como "Não é possível se conectar ao servidor"), precisamos coletar informações detalhadas de diagnóstico para restringir as eventuais hipóteses.
Os diagramas de fluxo de pacotes fornecem uma excelente estrutura para informar problemas. Esses diagramas descrevem os saltos importantes de um pacote ao longo de um caminho da origem ao destino, além das transformações significativas que sofre.
Comece identificando os endpoints de rede afetados pelo endereço IP da Internet ou pelo endereço privado RFC 1918, além de um identificador para a rede. Por exemplo, 2.3.4.5 ou 10.2.3.4 na rede padrão do projeto do Compute Engine.
Informe tudo que parecer significativo sobre os pontos de extremidade, como:
- quem os controla;
- Se estão associados a um nome de host DNS.
- Qualquer encapsulamento ou indireção intermediária, ou ambos, como túneis de VPN, proxies e gateways NAT.
- qualquer filtragem intermediária, como firewalls, CDN ou WAF.
Muitos problemas que se manifestam como alta latência ou perda intermitente de pacotes exigem uma análise de caminho ou uma captura de pacotes, ou ambas, para diagnóstico.
- A análise de caminho é uma lista de todos os saltos pelos quais os pacotes são transferidos e é conhecida como "traceroute". Costumamos usar o MTR ou o tcptraceroute, ou ambos, porque eles têm um poder de diagnóstico melhor. Recomendamos que você se familiarize com essas ferramentas.
- A captura de pacotes (também conhecida como "pcap", do nome da biblioteca "libpcap") é uma observação do tráfego de rede real. É importante fazer uma captura de pacotes para os dois endpoints ao mesmo tempo, o que pode ser complicado. É uma boa ideia praticar com as ferramentas necessárias (por exemplo, tcpdump ou Wireshark) e verificar se elas estão instaladas antes de precisar delas.
Informar um problema no console do Google Cloud
Ao informar um problema com o console do Google Cloud baseado na Web, além das orientações anteriores, forneça as seguintes informações para nos ajudar a identificar as possíveis causas do problema:
- URLs das páginas afetadas do console
- IDs dos projetos afetados
- Número de usuários afetados
- Se o problema ocorre em máquinas diferentes
- Navegadores afetados
- Extensões de navegador ou sistemas de firewall em uso
Além disso, incluir informações relevantes de rastreamento do navegador nos ajuda a entender e investigar o problema.