Ce guide vous explique comment rédiger une demande d'assistance efficace. Le respect de ces bonnes pratiques nous aide à résoudre votre demande d'assistance technique plus rapidement.
Créer une demande d'assistance
Avant de créer une demande d'assistance, examinez les problèmes connus pour vérifier que la demande n'a pas déjà été transmise.
Pour éviter toute confusion et nous permettre de suivre votre demande depuis un point unique, créez une demande d'assistance par problème. Toutes les demandes créées en double sont clôturées.
Décrire votre problème
Rédiger une demande d'assistance détaillée permet à l'équipe Customer Care de vous répondre de manière rapide et efficace. Si vous formulez une demande d'assistance en omettant des détails importants, nous devons alors vous demander des compléments d'informations, ce qui prend plus de temps.
Dans l'idéal, une demande d'assistance est à la fois détaillée et spécifique. Elle doit indiquer ce qu'il s'est passé et le résultat que vous attendiez. Lorsque vous décrivez votre problème dans votre demande d'assistance, incluez les informations suivantes :
- Heure : le code temporel spécifique à l'apparition du problème
- Produit : le ou les produits et fonctionnalités associés au problème
- Emplacement : les zones où survient le problème
- Identifiants : l'ID du projet ou de l'application, et d'autres identifiants concrets qui peuvent nous aider à étudier le problème
- Artefacts utiles : tous les détails que vous pouvez fournir pour nous aider à diagnostiquer le problème
- Type de problème : le problème est-il intermittent, passager ou persistant ?
Ces concepts sont décrits plus en détail dans les sections suivantes.
Heure
En utilisant le format ISO 8601 pour la date et l'heure, indiquez le moment où vous avez observé le problème pour la première fois, ainsi que sa durée.
Exemples :
- À partir du 2017-09-08T15:13:06+00:00 et pendant cinq minutes, nous avons remarqué…
- Problème survenu par intermittence, au plus tôt le 2017-09-10 et constaté deux à cinq fois…
- Problème en cours depuis le 2017-09-08T15:13:06+00:00…
- Du 2017-09-08T15:13:06+00:00 au 2017-09-08T15:18:16+00:00…
Il y a de fortes chances pour que le spécialiste Customer Care en charge de la résolution du problème se trouve dans un fuseau horaire différent du vôtre. Par conséquent, les déclarations semblables aux suivantes compliquent le diagnostic du problème :
- "Le problème a commencé hier…" (Nous sommes obligés de déduire la date)
- "Nous avons observé le problème le 9/8…" (Ambigu, car il pourrait s'agir du 8 septembre comme du 9 août)
Produit
Le formulaire de demande de base vous demande de préciser le nom du produit, mais ce n'est pas suffisant : nous avons également besoin d'informations spécifiques sur la fonctionnalité présentant le problème. Dans l'idéal, votre rapport doit faire référence à des API spécifiques ou à des URL de la console Google Cloud (ou inclure des captures d'écran). Pour les API, vous pouvez ajouter un lien vers la page de documentation, qui contient le nom du produit dans l'URL.
Indiquez également le moyen que vous utilisez pour lancer la demande (par exemple : l'API REST, Google Cloud CLI, la console Google Cloud ou encore un outil tel que Cloud Deployment Manager). Si plusieurs produits sont concernés, précisez le nom de chacun d'eux.
Exemples :
- "L'API REST de Compute Engine a renvoyé les erreurs suivantes…"
- "L'interface de requête BigQuery dans console.cloud.google.com est suspendue…"
Les déclarations suivantes ne sont pas assez spécifiques pour nous aider à diagnostiquer le problème :
- "Impossible de créer des instances…" (Nous avons besoin de connaître la méthode que vous employez pour créer des instances.)
- "La commande
gcloud compute create instancesrenvoie une erreur…" (La syntaxe de la commande est incorrecte. Nous ne pouvons donc pas l'exécuter nous-mêmes afin de reproduire l'erreur. De plus, nous n'avons pas d'informations sur l'erreur que vous avez constatée.)
Emplacement
Nous devons connaître la région et la zone du centre de données, car nous apportons souvent des modifications à une région ou à une zone à la fois. La région et la zone correspondent à un proxy pour le numéro de version du logiciel sous-jacent. Ces informations nous aident à savoir si des modifications importantes apportées à une version particulière de notre logiciel affectent vos systèmes.
Exemples :
- "Dans la région us-east1-b…"
- "J'ai essayé les régions us-east1 et us-central1…"
Identifiants
Des identifiants spécifiques nous aident à identifier le projet Cloud auquel le problème est associé. Il nous est primordial de connaître l'ID alphanumérique du projet ou de l'application. Les noms de projet ne sont pas utiles. Si le problème concerne plusieurs projets, incluez tous les ID concernés.
En plus des ID application ou de projet, d'autres identifiants peuvent s'avérer utiles pour diagnostiquer le problème que vous rencontrez :
- ID d'instances
- ID de tâche BigQuery ou noms de table
- Adresses IP
Lorsque vous spécifiez une adresse IP, indiquez également le contexte dans lequel elle est utilisée. Par exemple, précisez si l'adresse IP est connectée à une instance Compute, un équilibreur de charge, une route personnalisée ou un point de terminaison de l'API. Indiquez également si l'adresse IP n'est pas liée aux systèmes de Google (par exemple, si elle correspond à votre réseau Internet personnel, à un point de terminaison VPN ou à un système de surveillance externe).
Exemples :
- "Dans le projet robot-name-165473 ou my-project-id…"
- "Dans plusieurs projets (y compris my-project-id)…"
- "Connexion à l'adresse IP externe 218.239.8.9 de Google Cloud depuis notre passerelle d'entreprise 56.56.56.56…"
Les déclarations de ce type sont trop vagues pour nous aider à diagnostiquer le problème :
- "Une de nos instances est inaccessible…"
- "Nous n'arrivons pas à nous connecter depuis Internet…"
Artefacts utiles
En nous fournissant des artefacts liés au problème, vous nous aidez à voir l'écran tel que vous le voyez et accélérez ainsi le dépannage.
Exemple :
- Envoyez une capture d'écran pour montrer exactement ce que vous voyez.
- Pour les interfaces Web, fournissez toute information de trace du navigateur pertinente.
- Joignez le résultat tcpdump, des extraits de journaux et des exemples de traces de pile.
Type de problème
Intermittent : les problèmes intermittents surviennent de manière aléatoire, sans modèle de défaillance régulier apparent. Ces problèmes sont difficiles à résoudre, car leur irrégularité complique la collecte de données pendant la défaillance. Dans ce cas, essayez d'identifier les goulots d'étranglement dans l'architecture et vérifiez si vos ressources atteignent leur seuil maximal d'utilisation. Vous pouvez également lancer des vérifications fréquentes dans un job planifié via l'automatisation. Si la vérification échoue, recueillez les informations de débogage pendant la défaillance. Les échecs de résolution DNS et la perte de paquets sont des exemples de ce type de défaillance.
Passager : les problèmes passagers sont momentanés ou ne durent qu'une courte période. Si vous rencontrez des problèmes qui ne durent qu'une seconde ou quelques microsecondes, vous pouvez vérifier la présence de micro-pics de trafic ou d'utilisation des ressources. Dans la plupart des cas, les problèmes passagers peuvent être ignorés s'ils ne se produisent pas fréquemment et si votre service est conçu pour tolérer les pannes temporaires. Les pics de latence du réseau qui ne durent que quelques microsecondes, ainsi que les faibles pertes de paquets entraînant des dépassements de délai, constituent des exemples de ce type de défaillance. Le protocole TCP est conçu pour les défaillances telles que les petites pertes de paquets et les pics de latence. Il peut gérer ces problèmes efficacement, sauf si votre application est sensible à la latence.
Persistant : les problèmes persistants sont des problèmes qui entraînent une défaillance totale, telle que l'inaccessibilité de votre site Web. Ils sont relativement faciles à résoudre, car ils peuvent être reproduits. Dans ce cas, indiquez la procédure permettant de reproduire la défaillance afin que les spécialistes Customer Care puissent répliquer l'environnement et résoudre le problème.
Exemples de descriptions
Les exemples suivants fournissent des descriptions détaillées pour les demandes d'assistance.
Exemple 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.