Ce guide présente les bonnes pratiques à suivre pour 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 si une demande a déjà été déposée.
Pour éviter toute confusion et nous permettre de suivre votre demande de façon centralisée, créez une demande d'assistance par problème. Tous les doublons créés sont clôturés.
Décrire 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 détails critiques dans votre demande d'assistance, nous devons vous demander davantage 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:les zones dans lesquelles le problème survient.
- Identifiants:ID du projet ou de l'ID application, et 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-nous à quel moment vous avez remarqué le problème pour la première fois et pendant combien de temps.
Exemples :
- À partir du 2017-09-08T15:13:06+00:00 et jusqu'à cinq minutes plus tard, nous avons observé...
- 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…
Le spécialiste Customer Care qui résout le problème n'est probablement pas dans votre fuseau horaire. Par conséquent, les affirmations relatives telles que les suivantes rendent le problème plus difficile à diagnostiquer:
- "Ça 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-nous également le mécanisme que vous utilisez pour lancer la demande (par exemple, l'API REST, Google Cloud CLI, la console Google Cloud ou un outil tel que Cloud Deployment Manager). Si plusieurs produits sont concernés, donnez-nous chacun un nom spécifique.
Exemples :
- "L'API REST Compute Engine a renvoyé les erreurs suivantes..."
- "L'interface de requête BigQuery sur 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 pour 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 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, spécifiez 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-nous é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'analyseur HAR comporte 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 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. Les problèmes cohérents sont relativement simples à résoudre, car ils peuvent être reproduits. Dans ce cas, indiquez-nous les étapes à suivre pour reproduire le problème afin que nos spécialistes Customer Care puissent répliquer l'environnement et résoudre le problème pour vous.
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 revenu, risque de 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, vous rencontrez un nombre notable d'erreurs avec les utilisateurs ou vous rencontrez des difficultés pour lancer 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 ou processus mineurs concernés, par exemple). |
| P4 : impact faible – Service entièrement utilisable | Incidence technique ou répercussions sur les activités de l'entreprise minimes, voire nulles. Recommandée 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 lié à 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 demande est définie sur P1, un expert est immédiatement averti qu'il doit s'occuper exclusivement de la résolution du problème. Vous recevez rapidement une première réponse pour rejoindre un appel de dépannage en direct via Google Meet. Si votre organisation ne peut pas utiliser Google Meet, incluez un lien vers le logiciel de visioconférence de votre choix pour que l'expert puisse y participer. Vous recevrez ensuite des informations régulières via la demande.
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.
Déroulement de l'assistance concernant les demandes P1
Nouvelle demande P1
- Un expert de l'assistance vous contactera via Google Meet ou tout autre pont que vous fournissez. Vous devriez rejoindre l'appel dans un délai de 15 à 30 minutes. Informez l'expert de l'assistance si vous ne pouvez pas participer à l'appel pour une raison quelconque.
- Par défaut, la requête "suit le soleil" Cela signifie que les experts de l'équipe d'assistance s'engagent 24 heures sur 24 jusqu'à ce que la demande soit atténuée ou non prioritaire. Si l'atténuation des risques est préférable dans une région spécifique, ce cas peut être verrouillé sur un certain fuseau horaire. Vous pouvez nous indiquer votre préférence à cet égard.
Augmentation de la priorité P1
- Si le problème a commencé à affecter votre environnement de production ou est sur le point de disparaître, vous pouvez augmenter la priorité d'une demande P2-P4 existante à P1.
- Lorsque vous définissez la priorité d'une demande existante sur P1, la demande d'assistance peut être réaffectée pour permettre à un expert de l'assistance disponible de vous apporter une attention immédiate.
Impact hors production
Pour s'assurer que les ressources appropriées sont allouées si nécessaire, l'assistance peut vous contacter afin de réévaluer les cas marqués comme P1 qui n'affectent pas la production ou n'ont pas d'impact important sur votre activité.
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 avant un délai spécifique, veuillez nous l'indiquer dans la description de votre 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 actif du service client. Pendant que nous résolvons votre demande P1, nous vous recommandons de rester disponible pour répondre à vos questions jusqu'à ce qu'elles soient résolues afin de faciliter une communication efficace. Si vous ne répondez pas pendant plus de trois heures, nous pouvons réduire la priorité de la demande à P2 jusqu'à ce que vous réengagez le client.
Augmenter la priorité
Lorsque les circonstances évoluent, il se peut que vous deviez faire remonter un problème. Une escalade peut s'expliquer par les raisons suivantes:
- L'impact du problème sur votre entreprise est devenu plus important.
- Détail 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 progression après avoir échangé plusieurs messages.
Lorsque vous rencontrez un problème à impact majeur, la meilleure solution consiste à lui attribuer le niveau de priorité approprié pendant un laps de temps adéquat, plutôt que d'escalader la demande. L'escalade ne résout pas nécessairement le problème plus rapidement, et sa résolution peut même être plus lente après un changement de priorité. Vous trouverez une explication plus détaillée dans la vidéo Quand devez-vous escalader la demande.
Pour en savoir plus sur l'escalade d'une demande, consultez Escalader une demande.
Acheminer les cas vers le fuseau horaire requis
En raison des facteurs sur lesquels repose la disponibilité du service client, votre demande d'assistance peut être attribuée à un spécialiste Customer Care qui travaille en dehors de vos horaires d'ouverture. Il est également possible que vous souhaitiez contacter le service client les jours ouvrés dans un fuseau horaire spécifique. Dans de tels 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. Exemple :Please route this
case to the Pacific time zone (GMT-8) Les demandes P1 sont transmises au service client de la région suivante, car il suit le soleil, tandis que les autres demandes restent avec le propriétaire actuel pour continuer à travailler sur la demande 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. Nous saurions donc 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 inférieur ou égal à 3 serait considéré comme difficile du côté du client. Nous vous recontacterons au sujet de ces réponses. En revanche, un score de 4 ou plus signifie que l'interaction n'a pas été difficile pour le client et considérée comme une expérience positive.
Pour en savoir plus, regardez la vidéo How to Submit Google Cloud Services Feedback with CES (Envoyer des commentaires sur les services Google Cloud avec 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 faites-en une copie. Ajoutez 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 spécifiques du service client.
Ce document inclut:
- 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 a entraîné l'arrêt de la diffusion du trafic par votre application auprès des utilisateurs ou si ce problème a un impact critique sur l'entreprise, 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 concernés par l'adresse IP Internet ou par l'adresse privée RFC 1918, ainsi qu'un identifiant pour le 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édiaires, 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 se traduisant par une latence élevée ou une perte de paquets intermittente nécessitent une analyse du chemin et/ou une capture de paquets pour le diagnostic.
- 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 l'outil MTR et/ou tcptraceroute, car ils offrent de meilleurs résultats 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.