Esta página foi traduzida pela API Cloud Translation.

Práticas recomendadas para trabalhar com atendimento ao cliente

Este guia fornece as práticas recomendadas para escrever um plano de suporte eficaz caso. Seguir estas práticas recomendadas nos ajuda a resolver problemas de suporte caso mais rápido.

Criar um caso de suporte

Antes de criar um caso de suporte, consulte as problemas para saber se caso já tenha sido registrado.

Para evitar confusão e acompanhar sua solicitação em um só ponto, criar um caso de suporte por problema. Todos os casos duplicados criados fechadas.

Descrição do problema

Ao escrever um caso de suporte detalhado, você ajuda a equipe do Customer Care a responder com rapidez e eficiência. Quando seu caso de suporte é faltam detalhes críticos, precisamos pedir 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. Quando você descreve o problema no seu 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 problema.
Localização:as zonas em que você encontra o problema.
Identificadores: o ID do projeto ou 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 problema é intermitente, transitório ou consistente?

As seções a seguir descrevem esses conceitos em mais detalhes.

Hora

Usar o formato ISO 8601 para a data e o carimbo de data/hora, informe quando você notou o problema pela primeira vez e como quanto tempo ela durou.

Exemplos:

Começando em 2017-09-08T15:13:06+00:00 e terminando 5 minutos depois, observado...
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 em atendimento ao cliente que resolva o problema não consiga em seu fuso horário, portanto, declarações relativas como a seguinte tornam o problema mais difícil para diagnosticar:

"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 isso como 8 de setembro, enquanto outros podem interpretar 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 seu relatório mencione APIs ou URLs específicos 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 qual mecanismo 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, forneça cada especificamente.

Exemplos:

"A API REST do Compute Engine retornou os seguintes erros..."
"A interface de consulta do BigQuery em console.cloud.google.com está

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 instances está apresentando um erro..." (O A sintaxe do comando está incorreta e, por isso, não podemos executá-la 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, já que geralmente implantamos alterações 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 em uma determinada versão do nosso software afetam 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. Precisamos sempre 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 códigos de projetos ou aplicativos, vários outros identificadores nos ajudam a diagnosticar seu caso, como:

IDs de instância
IDs de jobs ou nomes de tabelas do BigQuery
endereços IP

Ao especificar um endereço IP, informe também o contexto em que ele é usado. Para especifique se o IP está conectado a uma instância do Compute, um balanceador de carga uma rota personalizada ou um endpoint de API. Informe também se o endereço IP não for relacionadas aos sistemas do Google (por exemplo, se o endereço IP for da sua um endpoint de VPN ou um sistema de monitoramento externo).

Exemplos:

"No projeto robot-name-165473 ou my-project-id..."
"Em vários projetos (incluindo my-project-id)..."
"Conectando-se ao IP externo do Google Cloud 218.239.8.9 de nossos gateway 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 um .HAR (http) ARchive). A HAR analisador tem de instruções para os três principais navegadores.
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 vão ocorrer com frequência e se o serviço for desenvolvido para ser tolerante a de segurança. 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 consegue lidar com esses 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. Os problemas consistentes são relativamente simples porque elas podem ser reproduzidas. Nesse caso, informe as etapas reproduzir o problema para que nossos especialistas do atendimento ao cliente possam replicar o ambiente e resolver o problema para você.

Exemplos de descrições

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. Encontre mais informações em Caso de suporte prioridade.

Definição de prioridade	Exemplo de situação
P1: impacto crítico, serviço inutilizável na produção	O aplicativo ou a infraestrutura é inutilizável na produção, apresentando uma taxa significativa de erros que afetam o usuário. O impacto no negócio é crítico (perda de receita, possível problema de integridade dos 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 enfrentados pelo usuário ou dificuldades na criação de 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 tíquetes de consulta em que análise, solução de problemas ou consultoria aprofundadas 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 para nós em detalhar por que você selecionou P1. Inclua uma breve descrição do impacto desse problema tem na sua empresa. Por exemplo, imagine um problema com um seja P1, mesmo que nenhum usuário final seja diretamente afetado, se estiver bloqueando uma correção de segurança crítica.

Quando um caso é definido como P1, um especialista é imediatamente alertado para trabalhar exclusivamente sobre o problema. Você recebe uma resposta inicial rápida para participar de uma transmissão ao vivo de solução de problemas no Google Meet. Caso sua organização não possa usar Google Meet, inclua um link para o software de videoconferência de sua preferência para o especialista participar. Depois disso, você recebe atualizações regulares por meio do 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 de suporte vai entrar em contato com você pelo Google Meet ou por qualquer outro ponte que você fornece. Esperamos que você entre na chamada entre 15 e 30 dias. minutos. Informe o especialista de suporte se você não conseguir participar da chamada e por um bom motivo.
- O caso "follows the sun" por padrão. Isso significa que os especialistas de suporte envolver 24 horas por dia até que o caso seja atenuado ou despriorizado. Se for o caso que a mitigação seja melhor realizada em uma região específica, esse caso pode ser trancado para em um determinado fuso horário. Você pode nos informar sua preferência quanto a esse efeito.
Aumento da prioridade P1
- Se o problema começou a afetar seu ambiente de produção ou está relacionado é possível aumentar a prioridade de um caso P2 a P4 existente para P1.
- Quando você aumenta a prioridade de um caso existente para P1, o caso de suporte poderá ser reatribuído para permitir que um especialista de suporte disponível forneça atenção.
Impacto da não produção

Para garantir que os recursos apropriados sejam alocados quando necessário, o suporte pode Entrar em contato com você para reavaliar casos marcados como P1 que não estão afetando na produção ou causando grande impacto nos negócios.

Tempos de resposta

Os níveis de prioridade do problema têm tempos de resposta predefinidos definidos na página do Google Diretrizes de Serviços de Suporte Técnico do Cloud Platform. Se você precisar até um prazo específico, informe na descrição do relatório. Se uma prioridade P1 problema precisa ser resolvido em tempo integral, você pode solicitar "siga o sun". Esses os casos são reatribuídos várias vezes por dia a um Atendimento ao cliente ativo especialista. Enquanto solucionamos seu caso P1, recomendamos que você continue empenhados em responder a perguntas até a resolução para facilitar a eficiência e comunicação. Se você parar de responder por mais de três 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 para um supervisor. Bons motivos para encaminhamento são:

Aumento do impacto no negócio
Detalhamento do processo de resolução. Por exemplo, você não recebeu um seja atualizado no tempo acordado ou seu problema fica "travado" sem o progresso após a troca de várias mensagens.

Quando você estiver enfrentando um problema de alto impacto, a melhor solução é definir o caso à prioridade adequada por um período adequado, em vez de encaminhar para um supervisor. O encaminhamento para um supervisor não necessariamente resolve o caso mais rápido e o encaminhamento logo após a alteração de prioridade pode até fazer com que a resolução do caso seja ser mais lento. Você encontra uma explicação mais detalhada na seção Quando usar encaminhar o vídeo.

Para mais informações sobre como encaminhar um caso, consulte Encaminhar um caso.

Rotear casos para o fuso horário obrigatório

Devido aos fatores nos quais o Atendimento ao cliente disponibilidade for baseado, seus o caso de suporte pode ser atribuído a um especialista do Customer Care que trabalha fora do seu horário de funcionamento. Você também pode querer envolver com o atendimento ao cliente durante os dias úteis de um fuso horário específico. Em nesses casos, recomendamos que você solicite ao Atendimento ao cliente para encaminhar o caso de suporte para um fuso horário conveniente para o seu caso. É 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 próximo o Atendimento ao cliente da região porque segue sol enquanto outros ficavam com o proprietário atual para continuar o trabalho. o 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. Nós realmente Agradecemos se você puder reservar alguns minutos para preenchê-la. Assim, vamos 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 seria considerada difícil da lado do cliente, e entraremos em contato com você quanto a essas respostas. No outro lado, uma pontuação 4 ou mais significa que a interação não foi difícil para o e considerada uma experiência positiva.

Para mais informações, assista ao vídeo Como enviar feedback sobre serviços do Google Cloud com a 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 anterior e faça uma cópia. Incluir links para todos os casos relevantes e bugs de rastreamento interno. Compartilhar este documento com o grupo da sua equipe de conta e peça que compartilhem com Especialistas em atendimento ao cliente.

Esse 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 seu aplicativo parar de atender tráfego aos usuários; ou tem um impacto crítico semelhante nos negócios, como uma interrupção na 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:

Verificação imediata de 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 breve mensagem contendo:

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. Seu organização deve ter um processo de gestão de incidentes definido, e essa etapa deve ser executada bem perto do início dela.

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 da rede afetados pelo endereço IP da Internet ou Endereço privado RFC 1918 mais é 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 eles estão associados a um nome de host DNS;
Qualquer encapsulamento intermediário ou indireção, ou ambos, como encapsulamento 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 que exigem uma análise de caminho, uma captura de pacote 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". Muitas vezes usamos MTR ou tcptraceroute ou ambos, porque têm mais capacidade de diagnóstico. Recomendamos que você se familiarize com essas ferramentas.
Captura de pacotes (também conhecida como "pcap", do nome da biblioteca) "libpcap") é uma observação do tráfego de rede real. É importante levar uma captura de pacote 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 criar se eles estão instalados antes que você precise deles.