Este guia oferece práticas recomendadas para escrever um registo de apoio técnico eficaz. Seguir estas práticas recomendadas ajuda-nos a resolver o seu registo de apoio técnico mais rapidamente.
Criar um registo de apoio ao cliente
Antes de criar um registo de apoio técnico, reveja os problemas conhecidos para ver se já foi apresentado um registo.
Para evitar confusões e para que possamos acompanhar a sua solicitação num único ponto, crie um registo de apoio técnico por problema. Todos os registos duplicados criados são encerrados.
Descrever o problema
Escrever um registo de apoio técnico detalhado facilita a resposta rápida e eficiente da equipa de apoio ao cliente. Quando o seu registo de apoio técnico não tem detalhes críticos, temos de pedir mais informações, o que demora mais tempo.
Os melhores registos de apoio técnico são detalhados e específicos. Indicam-nos o que aconteceu e o que esperava que acontecesse. Quando descrever o problema no seu registo de apoio técnico, inclua os seguintes detalhes:
- Hora: a indicação de tempo específica em que o problema começou.
- Produto: os produtos e as funcionalidades associados ao problema.
- Localização: as zonas onde está a ver o problema.
- Identificadores: o ID do projeto ou o ID da aplicação e outros identificadores concretos que nos ajudam a investigar o problema.
- Artefactos úteis: quaisquer detalhes que possa fornecer para nos ajudar a diagnosticar o problema.
- Tipo de problema: o problema é intermitente, passageiro ou consistente.
As secções seguintes descrevem estes conceitos mais detalhadamente.
Hora
Usando o formato ISO 8601 para a data e a data/hora, diga-nos quando notou este problema pela primeira vez e quanto tempo durou.
Exemplos:
- A partir de 2017-09-08T15:13:06+00:00 e terminando 5 minutos depois, observámos…
- Observado intermitentemente, a partir de 10/09/2017, e observado 2 a 5 vezes...
- Em curso desde 2017-09-08T15:13:06+00:00…
- From 2017-09-08T15:13:06+00:00 to 2017-09-08T15:18:16+00:00...
É muito provável que o especialista do serviço de apoio ao cliente que está a resolver o problema não esteja no seu fuso horário. Por isso, as declarações relativas, como as seguintes, dificultam o diagnóstico do problema:
- "Isto começou ontem…" (Obriga-nos a inferir a data implícita.)
- "Reparámos no problema a 08/09..." (Ambiguidade, uma vez que alguns podem interpretar esta data como 8 de setembro e outros como 9 de agosto.)
Produto
Embora o formulário de registo do caso básico lhe peça para especificar um nome do produto, precisamos de informações específicas sobre a funcionalidade desse produto que está a ter o problema. Idealmente, o seu relatório deve referir-se a APIs específicas ou URLs da Google Cloud consola (ou capturas de ecrã). Para APIs, pode criar um link para a página de documentação, que contém o nome do produto no URL.
Indique-nos também o mecanismo que está a usar para iniciar o pedido (por exemplo, API REST, Google Cloud CLI, Google Cloud consola ou, talvez, uma ferramenta como o Cloud Deployment Manager. Se estiverem envolvidos vários produtos, indique-nos o nome de cada um especificamente.
Exemplos:
- "A API REST do Compute Engine devolveu os seguintes erros…"
- "A interface de consulta do BigQuery em console.cloud.google.com está a bloquear…"
As seguintes declarações não são suficientemente específicas para saber onde procurar ao diagnosticar o problema:
- "Não é possível criar instâncias…" (Precisamos de saber o método que está a usar para criar instâncias.)
- "O comando
gcloud compute create instancesestá a gerar um erro…"(A sintaxe do comando está incorreta, pelo que não podemos executá-lo para reproduzir o erro. Além disso, não sabemos que erro viu efetivamente.)
Location
Precisamos de saber a região e a zona do seu centro de dados porque, muitas vezes, implementamos alterações numa região ou numa zona de cada vez. A região e a zona são um proxy para o número da versão do software subjacente. Estas informações ajudam-nos a saber se as alterações significativas numa versão específica do nosso software estão a afetar os seus sistemas.
Exemplos:
- "In us-east1-b ..."
- "Experimentei as regiões us-east1 e us-central1…"
Identificadores
Os identificadores específicos ajudam-nos a identificar qual dos seus projetos do Google Cloud está a ter o problema. Precisamos sempre de saber o projeto alfanumérico ou o ID da aplicação. Os nomes dos projetos não são úteis. Se o problema estiver a afetar vários projetos, inclua todos os IDs afetados.
Além dos IDs de projetos ou aplicações, vários outros identificadores ajudam-nos a diagnosticar o seu registo:
- IDs da instância.
- IDs de tarefas ou nomes de tabelas do BigQuery.
- Endereços IP.
Quando especificar um endereço IP, indique-nos também o contexto em que é usado. Por exemplo, especifique se o IP está ligado a uma instância do Compute, a um balanceador de carga, a um encaminhamento personalizado ou a um ponto final da API. Indique também se o endereço IP não está relacionado com os sistemas da Google (por exemplo, se o endereço IP for para a sua Internet doméstica, um ponto final de VPN ou um sistema de monitorização externo).
Exemplos:
- "In project robot-name-165473 or my-project-id..." (No projeto robot-name-165473 ou my-project-id…)
- "Em vários projetos (incluindo my-project-id)..."
- "A estabelecer ligação ao IP externo 218.239.8.9 a partir do nosso gateway corporativo 56.56.56.56..." Google Cloud
As declarações gerais, como as seguintes, são demasiado gerais para ajudar a diagnosticar o problema:
- "Uma das nossas instâncias está inacessível…"
- "Não é possível estabelecer ligação a partir da Internet…"
Artefactos úteis
O envio de artefactos relacionados com o problema acelera a resolução de problemas, pois ajuda-nos a ver exatamente o que está a ver.
Por exemplo:
- Use uma captura de ecrã para mostrar exatamente o que vê.
- Para interfaces baseadas na Web, faculte todas as informações de rastreio do navegador relevantes.
- Anexe a saída do tcpdump, fragmentos de registos e exemplos de rastreios de pilha.
Tipo de problema
Intermitente: os problemas intermitentes ocorrem aleatoriamente sem padrões de falha regulares. Os problemas intermitentes são difíceis de resolver porque a sua irregularidade dificulta a recolha de dados durante a falha. Neste caso, deve tentar identificar gargalos na arquitetura e verificar se os seus recursos estão a atingir os limites máximos de utilização. Também pode executar verificações frequentes numa tarefa agendada através da automatização e, se a verificação falhar, recolher informações de depuração durante a falha. Exemplos deste tipo de falha são falhas de resolução de DNS e perda de pacotes.
Temporário: os problemas temporários são momentâneos ou existem apenas durante um curto período. Se tiver problemas que ocorrem apenas durante um segundo ou alguns microssegundos, pode verificar se existem microexplosões de tráfego ou picos de utilização de recursos. Na maioria dos casos, os problemas transitórios podem ser ignorados se não ocorrerem com frequência e se o seu serviço for concebido para tolerar falhas transitórias. Exemplos deste tipo de falha são picos de latência da rede que ocorrem apenas durante alguns microssegundos e pequenas perdas de pacotes que causam limites de tempo. O Protocolo de controlo de transmissão (TCP) foi concebido para falhas, como pequenas perdas de pacotes e picos de latência, e consegue resolver estes problemas de forma eficaz, a menos que a sua aplicação seja sensível à latência.
Consistente: os problemas consistentes são problemas que falham completamente, como quando o seu Website está em baixo. Os problemas consistentes são relativamente fáceis de resolver porque podem ser reproduzidos. Neste caso, indique-nos os passos para reproduzir o problema, para que os nossos especialistas do apoio ao cliente possam replicar o ambiente e resolver o problema por si.
Exemplos de descrições
Os exemplos seguintes apresentam descrições detalhadas para registos de apoio técnico.
Exemplo um
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 dois
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.
Definir a prioridade e encaminhar
A prioridade ajuda-nos a compreender o impacto que este problema está a ter na sua empresa e afeta a rapidez com que respondemos para o resolver. As prioridades estão definidas na tabela seguinte. Pode encontrar mais informações em Prioridade do registo de apoio técnico.
| Definição de prioridade | Situação de exemplo |
|---|---|
| P1: impacto grave — serviço inutilizável em produção | A aplicação ou a infraestrutura não são utilizáveis em produção, tendo uma taxa significativa de erros visíveis para o utilizador. O impacto empresarial é crítico (perda de receita, potencial problema de integridade dos dados, etc.). |
| P2: impacto elevado — utilização do serviço gravemente afetada | A infraestrutura está degradada em produção, com uma taxa notória de erros ou dificuldades para os utilizadores na implementação de um novo sistema de produção. O impacto empresarial é moderado (perigo de perda de receita, diminuição da produtividade, etc.). |
| P3: impacto médio — utilização do serviço parcialmente afetada | O problema tem um âmbito e/ou uma gravidade limitados. O problema não tem qualquer impacto visível para o utilizador. O impacto na empresa é baixo (por exemplo, inconveniência ou processos empresariais menores afetados). |
| P4: impacto reduzido — serviço totalmente utilizável | Impacto empresarial ou técnico reduzido ou inexistente. Recomendado para pedidos de consulta em que se prefere uma análise detalhada, a resolução de problemas ou a consultoria a comunicações mais frequentes. |
Quando deve definir a prioridade mais elevada
Se tiver um problema que afete serviços importantes para a empresa e necessite de atenção imediata da Google, escolha "P1" como prioridade. Explique-nos detalhadamente por que motivo selecionou P1. Inclua uma breve descrição do impacto que este problema está a ter na sua empresa. Por exemplo, pode considerar um problema com uma versão de desenvolvimento como P1, mesmo que nenhum utilizador final seja diretamente afetado, se estiver a bloquear uma correção de segurança crítica.
Quando um registo é definido como P1, um especialista é imediatamente alertado para trabalhar exclusivamente no problema. Recebe uma resposta inicial rápida para participar numa chamada de resolução de problemas em direto através do Google Meet. Se a sua organização não puder usar o Google Meet, inclua um link para o software de videoconferência da sua escolha para o especialista participar. Depois disso, recebe atualizações regulares através do registo.
Agradecemos os comentários detalhados que apoiam o nível de prioridade escolhido, porque nos ajudam a responder adequadamente.
O que esperar do apoio técnico em registos P1
Novo registo de P1
- Um especialista do apoio técnico vai interagir consigo através do Google Meet ou de qualquer outra ponte que indicar. Esperamos que participe na chamada dentro de 15 a 30 minutos. Informe o especialista do apoio técnico se não puder participar na chamada por qualquer motivo.
- A capa "segue o sol" por predefinição. Isto significa que os especialistas do apoio técnico interagem 24 horas por dia até que o registo seja resolvido ou tenha a prioridade reduzida. Se a mitigação de registos for melhor prosseguida numa região específica, esse registo pode ser bloqueado para um determinado fuso horário. Pode comunicar-nos a sua preferência para este efeito.
Aumento da prioridade P1
- Se o problema começou a afetar o seu ambiente de produção ou está prestes a fazê-lo, pode aumentar a prioridade de um registo P2 a P4 existente para P1.
- Quando aumenta a prioridade de um registo existente para P1, o registo de apoio técnico pode ser reatribuído para permitir que um especialista de apoio técnico disponível preste atenção imediata.
Impacto na não produção
Para garantir que são alocados recursos adequados onde for necessário, o apoio técnico pode entrar em contacto consigo para reavaliar os registos marcados como P1 que não estejam a afetar a produção nem a causar um elevado impacto empresarial.
Tempos de resposta
Os níveis de prioridade dos problemas têm tempos de resposta predefinidos definidos nas Diretrizes dos Serviços de Apoio Técnico do Google Cloud Platform. Se precisar de uma resposta até uma hora específica, informe-nos na descrição da denúncia. Se for necessário resolver um problema de P1 durante todo o dia, pode pedir o serviço follow-the-sun. Estes registos são reatribuídos várias vezes por dia a um especialista do apoio ao cliente ativo. Enquanto resolvemos o seu registo P1, recomendamos que continue a interagir para responder a perguntas até à resolução, de modo a facilitar uma comunicação eficiente. Se não responder durante mais de 3 horas, podemos reduzir a prioridade do registo para P2 até voltar a interagir.
Encaminhamento
Quando as circunstâncias mudam, pode ter de encaminhar um problema. Os bons motivos para o encaminhamento são:
- Aumento do impacto no negócio.
- Análise detalhada do processo de resolução. Por exemplo, não recebeu uma atualização no período acordado ou o seu problema está "bloqueado" sem progressos após a troca de várias mensagens.
Quando tem um problema de alto impacto, a melhor solução é definir a prioridade adequada para o registo durante um período suficiente, em vez de o encaminhar. O encaminhamento não resolve necessariamente o registo mais rapidamente e, se o fizer pouco depois da alteração da prioridade, pode até fazer com que a resolução do registo seja mais lenta. Pode encontrar uma explicação mais detalhada no vídeo Quando deve encaminhar.
Para mais informações, consulte o artigo Encaminhe um registo.
Encaminhe registos para o fuso horário necessário
Devido aos fatores em que a disponibilidade do serviço de apoio ao cliente
se baseia, o seu registo de apoio técnico pode ser atribuído a um especialista do serviço de apoio ao cliente que trabalha
fora do seu horário de funcionamento. Também é possível que queira interagir com o apoio ao cliente durante os dias úteis de um fuso horário específico. Nestes casos, recomendamos que peça ao apoio ao cliente para encaminhar o seu registo de apoio técnico para um fuso horário conveniente para o seu caso. Pode adicionar este pedido na descrição ou na resposta do registo. Por exemplo, Please route this
case to the Pacific time zone (GMT-8). Os registos de prioridade 1 são transferidos para o apoio ao cliente da região seguinte, uma vez que segue o
sol, enquanto os outros registos permanecem com o proprietário do registo atual para continuar a trabalhar no registo no dia seguinte.
Envie feedback com o inquérito CES
Quando um registo é resolvido, é enviado por email um inquérito de pontuação do esforço do cliente (CES) relativamente à sua opinião sobre o processo. Agradecemos que reserve alguns minutos para o preencher, para sabermos o que fizemos bem e quais foram os desafios, de modo a melhorar estes aspetos.
Todos os formulários de feedback são revistos manualmente pela equipa de experiência do cliente e resultam em ações correspondentes para melhorar a sua experiência futura. A pontuação vai ser de 5. Uma pontuação de 3 ou inferior seria considerada difícil do ponto de vista do cliente. Por outro lado, uma classificação de 4 ou mais significa que a interação não foi difícil para o cliente e foi considerada uma experiência positiva.
Para mais informações, veja o vídeo Como enviar feedback sobre os serviços Google Cloud com o CES.
Problemas difíceis ou de longa duração
Os problemas que demoram muito tempo a resolver podem tornar-se confusos e desatualizados. A melhor forma de evitar esta situação é recolher informações através do nosso modelo de problema 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. Inclua links para todos os registos relevantes e erros de acompanhamento internos. Partilhe este documento com o grupo da sua equipa de conta e peça-lhe que o partilhe com especialistas específicos do apoio ao cliente.
Este documento inclui:
- Um resumo do estado atual resumido na parte superior.
- Uma lista das hipóteses potencialmente verdadeiras.
- Os testes ou as ferramentas que pretende usar para testar cada hipótese.
Tente manter cada registo focado num único problema e evite reabri-lo para abordar um novo problema.
Denunciar uma indisponibilidade de produção
Se o problema fez com que a sua aplicação deixasse de publicar tráfego para os utilizadores ou tiver um impacto crítico semelhante para a empresa, pode tratar-se de uma indisponibilidade de produção. Queremos saber o mais rapidamente possível. Por outro lado, os problemas que bloqueiam um pequeno número de programadores não são considerados interrupções de produção.
Quando recebemos uma denúncia de uma indisponibilidade de produção, avaliamos rapidamente a situação através do seguinte:
- Verificar imediatamente se existem problemas conhecidos que afetam a Google Cloud infraestrutura.
- Confirmar a natureza do problema.
- Estabelecer canais de comunicação.
Vai receber uma resposta com uma mensagem breve que contém:
- Quaisquer problemas conhecidos relacionados que afetem vários clientes.
- Uma confirmação de que podemos observar o problema que denunciou ou um pedido de mais detalhes.
- Como pretendemos comunicar.
Por isso, é importante criar rapidamente um registo que inclua a hora, o produto, os identificadores e a localização, e, em seguida, iniciar uma resolução de problemas mais detalhada. A sua organização pode ter um processo de gestão de incidentes definido e este passo deve ser executado muito perto do início do mesmo.
O processo de gestão de incidentes da Google define uma função principal: o comandante de incidentes. Esta pessoa envolve as pessoas certas, recolhe continuamente o estado mais recente e resume periodicamente o estado do problema. Delega a resolução de problemas e a aplicação de alterações a outras pessoas. Esta delegação permite-nos investigar várias hipóteses em paralelo. Recomendamos que estabeleça um processo semelhante na sua organização. Normalmente, a pessoa que abriu o registo é a melhor escolha para ser o responsável pelo incidente, uma vez que tem o contexto mais completo.
Comunicar um problema de rede
A dimensão e a complexidade da rede da Google podem dificultar a identificação da equipa responsável pelo problema. Para diagnosticar problemas de rede, temos de identificar causas principais muito específicas. Uma vez que as mensagens de erro de rede são frequentemente gerais (por exemplo, "Não é possível estabelecer ligação ao servidor"), temos de recolher informações de diagnóstico detalhadas para restringir as possíveis hipóteses.
Os diagramas de fluxo de pacotes oferecem uma excelente estrutura para o relatório de problemas. Estes diagramas descrevem os saltos importantes que um pacote dá ao longo de um caminho da origem para o destino, juntamente com quaisquer transformações significativas ao longo do caminho.
Comece por identificar os pontos finais 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 predefinida do projeto do Compute Engine.
Tome nota de tudo o que for significativo acerca dos pontos finais, como:
- Quem os controla.
- Se estão associados a um nome do anfitrião de DNS.
- Qualquer encapsulamento ou indireção intermédios, ou ambos, como túneis VPN, proxies e gateways NAT.
- Qualquer filtragem intermédia, como firewalls, CDN ou WAF.
Muitos problemas que se manifestam como latência elevada ou perda de pacotes intermitente requerem uma análise do caminho ou uma captura de pacotes, ou ambos, para diagnóstico.
- A análise do caminho é uma lista de todos os saltos que os pacotes atravessam e é conhecida como "traceroute". Usamos frequentemente o MTR ou o tcptraceroute, ou ambos, porque têm uma melhor capacidade de diagnóstico. Recomendamos que se familiarize com estas 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 ambos os pontos finais ao mesmo tempo, o que pode ser complicado. É aconselhável praticar com as ferramentas necessárias (por exemplo, o tcpdump ou o Wireshark) e certificar-se de que estão instaladas antes de precisar delas.
Comunicar um Google Cloud problema da consola
Quando comunicar um problema com a Google Cloud consola baseada na Web, além das orientações anteriores, faculte as seguintes informações para nos ajudar a restringir as potenciais causas do problema:
- URLs das páginas da consola afetadas
- IDs dos projetos afetados
- Número de utilizadores afetados
- Se o problema ocorre em diferentes máquinas
- Navegadores afetados
- Quaisquer extensões do navegador ou sistemas de firewall em utilização
Além disso, a inclusão de informações de rastreio do navegador relevantes ajuda-nos a compreender e investigar o seu problema.