Práticas recomendadas para trabalhar com o suporte do Google Cloud

Ao escrever um caso de suporte detalhado, você ajuda a equipe de suporte do Google 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. Neste guia, você conhecerá as informações necessárias para resolver seu caso de suporte técnico mais rapidamente.

Como descrever o problema

Os melhores relatórios de problemas são detalhados e específicos. Eles contam o que aconteceu e o que você esperava que acontecesse. Um bom relatório de problemas contém os seguintes detalhes:

  • Momento: a data e a hora específicas em que o problema começou.
  • Produto: os produtos e recursos afetados pelo problema.
  • Localização: as zonas em que você encontra o problema.
  • Identificadores: o código do projeto/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.

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

Momento

Use o formato especificado na ISO 8601 para informar quando percebeu esse problema pela primeira vez, especificando a data e a hora, e por quanto tempo ele durou.

Exemplos:

  • Começou em 2017-09-08T15:13:06+00:00 e se encerrou 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...

O engenheiro de suporte que cuidará do seu problema provavelmente não estará no mesmo fuso horário, então frases genéricas, como as seguintes, dificultam o diagnóstico do problema:

  • "Isso começou em algum momento de ontem...": obriga nossos engenheiros a inferir a data implícita.
  • "Percebemos o problema em 9/8...": frase ambígua, já que alguns podem interpretá-la como 8 de setembro ou 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. É recomendado que seu relatório informe as APIs ou os URLs específicos do Console do Cloud (ou que inclua 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, a API REST, a ferramenta gcloud, o Console do Cloud ou uma ferramenta como o Deployment Manager. Se vários produtos estiverem envolvidos, informe os nomes de todos.

Exemplos:

  • "A API REST do Google 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 instances está apresentando erro.": a sintaxe do comando está incorreta, 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-a ..."
  • "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 código ou ID alfanumérico do projeto ou 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:

  • códigos de instância
  • códigos 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. Por exemplo, especifique se o IP está conectado a uma instância do Compute, um balanceador de carga, uma rota personalizada ou um ponto de extremidade da API. Informe também se o endereço IP não está relacionado aos sistemas do Google (por exemplo, se o endereço IP for para sua Internet doméstica, um ponto de extremidade 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)..."
  • "Conexão ao IP externo do GCP 218.239.8.9 a partir do 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 um arquivo .HAR (Http ARchive). O HAR Analyzer tem instruções para os três navegadores mais usados.
  • Anexe a saída tcpdump, snippets de registros e exemplos de rastreamentos de pilha.

Como definir e aumentar a prioridade

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. Para ver uma lista de definições de prioridade, consulte a referência de procedimentos.

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 detalhadamente por que você selecionou P1. Inclua uma breve descrição do impacto que esse problema está causando na sua empresa. Por exemplo, se o problema em uma versão de desenvolvimento estiver bloqueando uma correção de segurança crítica, você pode considerá-lo como P1, mesmo que nenhum usuário final esteja sendo diretamente afetado.

Tempos de resposta

Os níveis de prioridade do problema têm tempos de resposta predefinidos descritos 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 na descrição do seu relatório. Se um problema P1 precisar ser resolvido em 24 horas, você pode solicitar o suporte contínuo. Esses casos são atribuídos várias vezes por dia para um engenheiro de suporte em atividade.

Como escalar a prioridade

Quando a situação muda, pode ser necessário escalar o problema para que ele receba atenção imediata. Veja abaixo algumas boas razões para escalar:

  • aumento do impacto no negócio
  • necessidade de rapidez na resolução do problema
  • projeto com andamento paralisado após a troca de várias mensagens

Para escalar o caso, basta alterar a prioridade dele. Por exemplo, você pode alterar a prioridade de um problema de P3 para P2. Se fizer isso, informe por que essa alteração é necessária. Nosso sistema de processamento de casos notificará um agente, que analisará seu caso e fará o acompanhamento. É importante que você envie comentários detalhados explicando por que a escalação é necessária para nos ajudar a responder adequadamente.

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, basta abrir o link acima e fazer uma cópia. Inclua links para todos os casos relevantes e erros de rastreamento interno. Compartilhe esse documento com o grupo da sua equipe de conta e solicite que ele seja compartilhado com engenheiros de suporte específicos.

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 faz com que seu aplicativo pare de veicular tráfego para os usuários ou tem um impacto crítico semelhante nos negócios, isso pode ser considerado 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:

  • Verificamos imediatamente problemas conhecidos que afetam a infraestrutura do GCP.
  • Confirmamos a natureza do problema.
  • Estabelecemos canais de comunicação.

Você pode esperar 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 (por exemplo, telefone, Hangout ou caso).

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 deve ser executada praticamente no mesmo momento do início desse processo.

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 pontos de extremidade da rede afetados pelo endereço IP da Internet ou pelo endereço privado da 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 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 e/ou indireto, como tunelamento 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 exigirão uma análise de caminho e/ou uma captura de pacotes 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 e/ou tcptraceroute porque eles têm mais capacidade de diagnóstico. Por isso, é importante estar familiarizado 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 levar uma captura de pacote para ambos os pontos de extremidade ao mesmo tempo, o que pode ser complicado. Recomendamos que você pratique com as ferramentas necessárias (por exemplo, tcpdump ou Wireshark) e verifique se elas estão instaladas antes de precisar delas.

Casos de amostra

Exemplo 1

Nome do job:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Fonte:

S3_avl-transfer

Destino:

CloudStorage: avl-transfer

Horário de início (formato ISO 8601): 2017-04-20 20:14:43 PDT

Horário de término (formato ISO 8601): 2017-04-21 at 10:03:44 PDT

Comecei uma transferência de arquivos em 2017-04-20 às 20:14:43 PDT usando a API de transferência. Normalmente, esse job leva 10 minutos, mas, nesse caso, o job ainda estava em execução quando eu o cancelei no dia seguinte (2017-04-21 às 10:03:44 PDT). Esse não é um evento isolado. Vários outros jobs envolvendo a API de transferência tiveram atrasos significativos e intermitentes.

Investigue a causa dos atrasos e avise sobre as práticas recomendadas que podemos implementar para evitar esses problemas no futuro.

Exemplo 2

Horário de início (formato ISO 8601): 2017-05-12 11:03:43

Horário de término (formato ISO 8601): o problema ainda está acontecendo no momento do envio deste relatório.

Resumo do problema:

O cron /cron/payments-service/sync-v2-batch que está usando a API App Engine Task Queue parou de funcionar desde 2017-05-12 às 11:03:43. Contamos com esse job para lidar corretamente com os pagamentos.

Enfrentamos erros de armazenamento de dados e de fila e, em seguida, o cron parou de ser executado. Tentamos, sem sucesso, corrigir o problema fazendo o upload novamente do cron.xml. Aqui está o rastreamento do erro:

[error trace]

Especifique se o problema está na API ou na nossa implementação e informe as próximas etapas.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…