Ce guide présente les bonnes pratiques à suivre pour rédiger une demande d'assistance efficace. Le respect de ces bonnes pratiques nous aide à traiter 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 si une demande a déjà été déposée.
Pour éviter toute confusion et afin que nous puissions suivre votre demande en un seul point, créez une demande d'assistance par problème. Les demandes en double créées sont clôturées.
Décrivez votre problème
La rédaction d'une demande d'assistance détaillée permet à l'équipe Customer Care de vous répondre de manière rapide et efficace. S'il manque des informations critiques dans votre demande d'assistance, nous devons vous demander plus d'informations, ce qui prend plus de temps.
Les meilleures demandes d'assistance sont à la fois détaillées et spécifiques. Il 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 : l'horodatage spécifique à l'apparition du problème
- Produit:produits et fonctionnalités associés au problème.
- Emplacement:zones où se situe le problème
- Identifiants:l'ID du projet ou de l'ID application, ainsi que 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, temporaire ou constant ?
Ces concepts sont décrits plus en détail dans les sections suivantes.
Temps
En utilisant le format ISO 8601 pour la date et l'horodatage, indiquez le moment où vous avez remarqué le problème pour la première fois et sa durée.
Exemples :
- Du 2017-09-08T15:13:06+00:00 au 5 minutes plus tard, nous avons constaté que...
- 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 est très probable que le spécialiste du service client en charge du problème ne se trouve pas dans votre fuseau horaire. Par conséquent, les déclarations comme celles-ci rendent le problème plus difficile à diagnostiquer:
- "Cela a commencé hier..." (nous oblige à déduire la date implicite).
- "Nous avons remarqué le problème le 08/09" (Ambiguë, car certains pourraient interpréter cette date comme le 8 septembre, et d'autres comme le 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 à 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 mécanisme que vous utilisez pour lancer la requête (par exemple, l'API REST, Google Cloud CLI, la console Google Cloud ou un outil tel que Cloud Deployment Manager). Si plusieurs produits sont impliqués, donnez-nous le nom de chacun d'eux.
Exemples :
- "L'API REST Compute Engine a renvoyé les erreurs suivantes..."
- "L'interface de requête BigQuery dans console.cloud.google.com se bloque..."
Les déclarations suivantes ne sont pas assez spécifiques pour nous aider à diagnostiquer le problème :
- "Impossible de créer des instances..." (Nous devons connaître la méthode que vous utilisez 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-a…"
- "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, indiquez si l'adresse IP est connectée à une instance Compute, un équilibreur de charge, une route personnalisée ou un point de terminaison d'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 domestique, à 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 Google Cloud 218.239.8.9 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 un fichier .HAR (Http ARchive). L'outil d'analyse HAR fournit des instructions pour les trois principaux navigateurs.
- Joignez le résultat tcpdump, des extraits de journaux et des exemples de traces de pile.
Problem type
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 une tâche planifiée 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 temporaires peuvent être ignorés s'ils ne se produisent pas souvent et si votre service est conçu pour tolérer les défaillances 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 (Transmission Control Protocol) est conçu pour les défaillances telles qu'une petite perte de paquets et des pics de latence. Il peut gérer ces problèmes de manière efficace, 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. Les problèmes récurrents sont relativement simples à résoudre, car ils peuvent être reproduits. Dans ce cas, indiquez-nous les étapes permettant de reproduire le problème afin que nos spécialistes du service client puissent reproduire l'environnement et résoudre le problème.
Exemples de descriptions
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.
Exemple 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.
Définir et augmenter la priorité d'un problème
Le niveau de priorité nous aide à comprendre l'impact du problème sur votre entreprise et influe sur la rapidité de sa résolution. Les priorités sont définies dans le tableau ci-dessous. Pour en savoir plus, consultez la section Priorité des demandes d'assistance.
| Définition de la priorité | Exemple de situation |
|---|---|
| P1 : impact critique – Service inutilisable en production | L'application ou l'infrastructure ne peut pas être utilisée en production en raison d'un taux élevé d'erreurs avec les utilisateurs. Les répercussions sur les activités de l'entreprise sont très importantes (perte de chiffre d'affaires, éventuel problème d'intégrité des données, etc.). |
| P2 : impact important – Utilisation du service très perturbée | L'infrastructure est dégradée en production, avec un taux notable d'erreurs avec les utilisateurs ou des difficultés à démarrer un nouveau système de production. Les répercussions sur les activités de l'entreprise sont modérées (risque de perte de revenu, baisse de la productivité, etc.). |
| P3 : impact moyen – Utilisation du service partiellement perturbée | Le problème a une portée et/ou une gravité limitée. Il n'a pas d'incidence visible pour les utilisateurs. Les répercussions sur les activités de l'entreprise sont faibles (désagrément, processus mineurs, etc.). |
| P4 : impact faible – Service entièrement utilisable | Incidence technique ou répercussions sur les activités de l'entreprise minimes, voire nulles. Recommandé pour les demandes d'informations pour lesquelles une analyse approfondie, un dépannage plus poussé ou des conseils détaillés sont préférables à des communications plus fréquentes. |
Quand définir la priorité la plus élevée
Si vous rencontrez un problème qui affecte les services critiques de votre entreprise et qui nécessite une attention immédiate de Google, sélectionnez "P1". Expliquez-nous en détail pourquoi vous avez choisi P1. Décrivez brièvement l'impact du problème sur votre entreprise. Par exemple, vous pouvez considérer qu'un problème avec une version de développement est de type P1, même si aucun utilisateur final n'est directement affecté, s'il bloque un correctif de sécurité critique.
Lorsqu'une vous définissez une demande sur le niveau P1, un membre de l'équipe d'assistance en service est immédiatement averti. Celui-ci recherche alors l'expert approprié qui œuvrera exclusivement à la résolution du problème. Vous recevrez une première réponse rapide. Vous recevrez ensuite des informations régulières.
Nous vous invitons à fournir des commentaires détaillés expliquant le niveau de priorité choisi afin de nous aider à y répondre comme il se doit.
Temps de réponse
Les niveaux de priorité des problèmes ont des temps de réponse prédéfinis définis dans les instructions relatives aux services d'assistance technique de Google Cloud Platform. Si vous avez besoin d'une réponse dans un délai précis, indiquez-le-nous dans la description du rapport. Si un problème de niveau P1 doit être traité 24h/24, vous pouvez demander le service de suivi des fuseaux horaires. Ces demandes sont réattribuées plusieurs fois par jour à un spécialiste du service client actif.
Augmenter la priorité
Lorsque les circonstances changent, vous devrez peut-être faire remonter un problème. Vous pouvez escalader les problèmes pour les raisons suivantes:
- L'impact du problème sur votre entreprise est devenu plus important.
- Analyse détaillée du processus de résolution. Par exemple, vous n'avez pas reçu de mise à jour dans le délai convenu ou votre problème est "bloqué" sans progresser après avoir échangé plusieurs messages.
Lorsque vous rencontrez un problème à fort impact, la meilleure solution consiste à définir la priorité appropriée pendant un certain temps, plutôt que de faire remonter le problème. Le fait de remonter ne permet pas nécessairement de résoudre la demande plus rapidement. Le fait de remonter peu de temps après un changement de priorité peut même ralentir la résolution de la demande. Pour en savoir plus, regardez la vidéo Quand devez-vous faire remonter le problème.
Pour savoir comment escalader une demande, consultez Escalader une demande.
Rediriger les demandes vers le fuseau horaire requis
En raison des facteurs sur lesquels la disponibilité du service client est basée, votre demande d'assistance peut être confiée à un spécialiste du service client qui travaille en dehors de vos horaires d'ouverture. Vous pouvez également contacter le service client pendant les jours ouvrés d'un fuseau horaire spécifique. Dans ce cas, nous vous recommandons de demander au service client d'acheminer votre demande d'assistance vers un fuseau horaire qui vous convient. Vous pouvez ajouter cette requête dans la description ou la réponse de votre demande. Par exemple, Please route this
case to the Pacific time zone (GMT-8). Les demandes P1 sont transférées au service client dans la région suivante, car celui-ci suit le soleil tandis que les autres demandes restent accessibles au propriétaire actuel de la demande pour continuer à travailler dessus le lendemain.
Envoyer des commentaires avec l'enquête CES
Une fois un problème résolu, une enquête de satisfaction client (CES) est envoyée par e-mail à propos de votre avis sur le processus de traitement. Nous vous serions très reconnaissants si vous pouviez prendre quelques minutes pour le remplir, afin que nous sachions ce que nous avons bien fait et quels ont été les défis pour améliorer ces aspects.
Chaque formulaire de commentaires est examiné manuellement par l'équipe d'expérience client, après des actions sont mises en œuvre pour améliorer votre expérience future. Le score fourni est un score sur 5. Un score de 3 ou moins serait considéré comme difficile côté client. Nous vous recontacterons concernant ces réponses. D'un autre côté, un score de 4 ou plus signifie que l'interaction n'a pas été difficile pour le client et qu'elle a été considérée comme une expérience positive.
Pour en savoir plus, regardez la vidéo Comment envoyer des commentaires sur les services Google Cloud via le CES.
Problèmes de longue durée ou complexes
Les problèmes longs à résoudre peuvent devenir flous et obsolètes. Le meilleur moyen d'éviter une telle situation consiste à collecter des informations à l'aide de notre modèle de problème de longue durée avec l'état le plus récent indiqué en haut de l'écran.
Pour utiliser le modèle, ouvrez le lien précédent et créez-en une copie. Incluez des liens vers toutes les demandes pertinentes et les bugs de suivi internes. Partagez ce document avec le groupe de l'équipe chargée de votre compte et demandez-leur de le partager avec des spécialistes du Service client spécifiques.
Ce document inclut les éléments suivants:
- Un récapitulatif de l'état actuel indiqué en haut de l'écran
- Une liste des hypothèses potentiellement vraies
- Les tests ou outils que vous comptez utiliser pour tester chaque hypothèse
Essayez de centrer chaque demande sur un seul problème. Évitez de rouvrir une demande à chaque nouveau problème.
Signaler une interruption de production
Si le problème empêche votre application de diffuser du trafic auprès des utilisateurs ou a un impact tout aussi critique pour votre activité, il peut s'agir d'une interruption de production. Nous souhaitons en être informés dès que possible. En revanche, les problèmes qui bloquent un petit nombre de développeurs ne sont pas considérés comme des interruptions de production.
Lorsque nous recevons un rapport signalant une interruption de production, nous évaluons rapidement la situation en :
- Recherche immédiate des problèmes connus affectant l'infrastructure Google Cloud
- confirmant la nature du problème ;
- mettant en place des canaux de communication.
Vous devriez recevoir une réponse accompagnée d'un bref message contenant les éléments suivants:
- Tous les problèmes connus associés qui affectent d'autres clients
- La confirmation que nous pouvons constater le problème que vous avez signalé ou une demande d'informations supplémentaires
- Le mode de communication que nous envisageons
Par conséquent, il est important de créer rapidement une demande comprenant l'heure, le produit, les identifiants et l'emplacement, puis de lancer un dépannage plus approfondi. Votre organisation peut avoir un processus de gestion des incidents défini, et cette étape doit être exécutée très tôt.
Le processus de gestion des incidents de Google définit un rôle clé : le chargé d'incidents. Il met en lien les bonnes personnes impliquées, collecte continuellement le dernier état et synthétise périodiquement l'état du problème. Il délègue à d'autres personnes la résolution des problèmes et l'application des modifications. Cette délégation nous permet d'examiner plusieurs hypothèses en parallèle. Nous vous recommandons d'établir un processus similaire au sein de votre organisation. La personne qui a généré la demande est généralement la plus apte à endosser le rôle de chargé d'incidents, car elle dispose de plus de contexte.
Signaler un problème de réseau
L'équipe responsable du problème peut être difficile à identifier en raison de la taille et de la complexité du réseau de Google. Afin de diagnostiquer les problèmes liés au réseau, nous devons déterminer les causes très spécifiques à l'origine de ces problèmes. Comme les messages d'erreur de réseau sont souvent d'ordre général (exemple : "Impossible de se connecter au serveur"), nous devons collecter des informations de diagnostic détaillées afin d'affiner les hypothèses.
Les schémas des flux de paquets constituent une excellente structure pour le rapport de signalement du problème. Ces schémas décrivent les sauts importants qu'un paquet emprunte tout au long d'un chemin d'accès, allant de la source à la destination, ainsi que les éventuelles transformations importantes intervenues en cours de route.
Commencez par identifier les points de terminaison du réseau affectés à l'aide de l'adresse IP Internet ou de l'adresse privée RFC 1918, plus un identifiant du réseau. Par exemple, 2.3.4.5 ou 10.2.3.4 sur le réseau par défaut du projet Compute Engine.
Notez toutes les informations utiles liées aux points de terminaison. Exemple :
- Les personnes qui les contrôlent
- S'ils sont associés à un nom d'hôte DNS
- toute encapsulation ou indirection intermédiaire, ou les deux, telles qu'un tunnel VPN, des proxys et des passerelles NAT.
- Les filtres intermédiaires, comme les pare-feu, CDN ou WAF
De nombreux problèmes qui se traduisent par une latence élevée ou une perte de paquets intermittente nécessitent une analyse du chemin d'accès ou une capture de paquets, ou les deux.
- L'analyse de chemin constitue une liste de tous les sauts que les paquets traversent et est connue sous le nom de "traceroute". Nous utilisons souvent MTR ou tcptraceroute, ou les deux, car ils offrent de meilleures performances en termes de diagnostic. Nous vous recommandons de vous familiariser avec ces outils.
- La capture de paquets (également appelée "pcap", en raison du nom de la bibliothèque "libpcap") est une observation du trafic réseau réel. Il est important de prendre une capture de paquets pour les deux points de terminaison en même temps, ce qui peut s'avérer délicat. Nous vous recommandons de vous entraîner avec les outils nécessaires (par exemple, tcpdump ou Wireshark) et de vous assurer qu'ils sont installés avant d'en avoir besoin.