Ce guide vous présente les bonnes pratiques à suivre pour proposer une assistance efficace. . Le respect de ces bonnes pratiques nous aide à résoudre votre problème d'assistance technique de votre application.
Créer une demande d'assistance
Avant de créer une demande d'assistance, consultez les problèmes pour voir si la 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 tickets en double créés sont fermé.
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. Lorsque votre demande d'assistance est s'il manque des détails critiques, nous devons demander plus d'informations, ce qui 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:l'ID du projet ou de l'application et d'autres identifiants concrets qui nous aident à é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.
Heure
Au format ISO 8601 Pour la date et l'heure, indiquez la date et l'heure auxquelles vous avez remarqué le problème pour la première fois et il a duré très longtemps.
Exemples :
- À partir du 2017-09-08T15:13:06+00:00 et jusqu'à cinq minutes plus tard, nous 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…
Il est très probable que le spécialiste du service client qui résolve le problème ne soit pas votre fuseau horaire. Par conséquent, les déclarations relatives telles que les suivantes compliquent le problème. à diagnostiquer:
- "Le problème a commencé hier…" (Nous sommes obligés de déduire la date)
- "Nous avons remarqué le problème le 08/09..." (Ambigu, car certains pourraient interpréter cela la date du 8 septembre, tandis que d'autres pourraient l'interpréter 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 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 initier la demande (par par exemple, l'API REST, Google Cloud CLI, la console Google Cloud ou un outil comme Cloud Deployment Manager. Si plusieurs produits sont concernés, indiquez-nous chacun en particulier.
Exemples :
- "L'API REST Compute Engine a renvoyé les erreurs suivantes..."
- "L'interface de requête BigQuery disponible sur la page console.cloud.google.com CANNOT TRANSLATE
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..." syntaxe de commande est incorrecte, nous ne pouvons donc pas l'exécuter nous-mêmes pour reproduire le . 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. Pour 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-nous également si l'adresse IP n'est pas aux systèmes de Google (par exemple, si l'adresse IP correspond à celle de votre 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 serveur passerelle 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, indiquez un .HAR (Http) ARchive). Le rapport HAR "Analyzer", pour les trois principaux navigateurs.
- 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 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 se répètent souvent et si votre service est conçu pour tolérer les d'échecs. 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 tels que de légères pertes de paquets et des pics de latence, et peut gérer ces 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 à car ils peuvent être reproduits. Dans ce cas, indiquez-nous les étapes pour reproduire le problème afin que les spécialistes de notre service client puissent de répliquer l'environnement et de résoudre le problème à votre place.
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 plus d'informations, consultez la section Demande d'assistance priorité.
| 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, avec une fréquence d'erreurs avec les utilisateurs ou de difficultés à créer 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 métier mineurs concernés). |
| P4 : impact faible – Service entièrement utilisable | Incidence technique ou répercussions sur les activités de l'entreprise minimes, voire nulles. Recommandé pour demandes d'assistance 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 expliquer en détail pourquoi vous avez sélectionné P1. Décrivez brièvement l'impact du problème sur votre activité. Prenons l'exemple d'un problème avec un développeur en tant que version P1, même si aucun utilisateur final n'est directement concerné, un correctif de sécurité critique.
Lorsqu'une demande est définie sur P1, un expert est immédiatement averti qu'il doit travailler exclusivement sur le problème. Vous recevez rapidement une première réponse pour participer à un direct. résoudre les problèmes d'appel dans 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 le rejoindre. Vous recevrez ensuite des informations régulières via .
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 toute autre que vous fournissez. Vous devriez rejoindre l'appel entre 15 et 30 heures minutes. Informez l'expert de l'assistance si vous ne pouvez pas participer à l'appel pour ou motif.
- L'étui "suit le soleil" par défaut. Cela signifie que les experts de l'assistance 24 heures sur 24 jusqu'à ce que la demande soit atténuée ou non prioritaire. Si le cas l'atténuation des risques est préférable dans une région spécifique, 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 s'il concerne 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 à un expert de l'assistance disponible votre attention.
Impact hors production
Pour s'assurer que les ressources appropriées sont allouées si nécessaire, l'assistance peut Échangez avec vous pour réévaluer les cas de priorité P1 qui n'ont pas d'impact de production ou d'impact sur l'activité.
Temps de réponse
Les niveaux de priorité des problèmes ont des temps de réponse prédéfinis définis dans le Centre d'aide Instructions relatives aux services d'assistance technique Cloud Platform. Si vous avez besoin une réponse dans un délai précis, indiquez-le-nous dans la description du rapport. Si une P1 problème doit être traité 24h/24, vous pouvez demander "suivre les "sun". Ces les demandes sont réattribuées plusieurs fois par jour à un service client actif spécialiste. Pendant que nous résolvons le problème lié à votre demande P1, à répondre aux questions jusqu'à leur résolution, afin de faciliter l'utilisation de la communication. Si vous ne répondez plus 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. Bonnes raisons pour escalader les problèmes:
- L'impact du problème sur votre entreprise est devenu plus important.
- Détail du processus de résolution. Par exemple, si vous n'avez reçu aucun mise à jour dans les délais convenus ou si votre problème est "bloqué" sans après avoir échangé plusieurs messages.
Lorsque vous rencontrez un problème à impact majeur, la meilleure solution consiste à définir le paramètre vers la priorité appropriée pendant une durée suffisante, plutôt que faire remonter le problème. L'escalade ne résout pas nécessairement le problème plus rapidement et le fait d'escalader la demande peu de temps après le changement de priorité peut même entraîner la résolution être plus lente. Vous trouverez une explication plus détaillée dans la section Quand devez-vous faire remonter la vidéo.
Pour plus d'informations sur l'escalade d'une demande d'assistance, consultez la section Escalader une demande cas d'utilisation.
Acheminer les cas vers le fuseau horaire requis
En raison des facteurs sur lesquels Customer Care
votre disponibilité,
une 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 engager
avec Customer Care pendant les jours ouvrés d'un fuseau horaire donné. Dans
nous vous recommandons de demander au service client de router
vers le 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 suivant
Customer Care pour cette région, car il suit les
Dim
tandis que les autres demandes restent avec le propriétaire actuel pour qu'il continue à travailler sur
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 aimerions vraiment Nous vous serions reconnaissants de prendre quelques minutes pour y répondre. ce que nous avons bien fait et quels étaient les difficultés 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 est considéré comme difficile côté client et nous vous recontacterons à ce sujet. De l'autre un score de 4 ou plus signifie que l'interaction n'a pas été difficile 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 (Envoyer des commentaires sur les services Google Cloud) vidéo sur 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 faites-en une copie. Inclure des liens vers toutes les demandes pertinentes et les bugs de suivi internes. Partager ce document avec le groupe de l'équipe chargée de votre compte et demandez-lui de le partager avec Spécialistes 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 auprès des utilisateurs par votre application ; a un impact similaire critique pour l'entreprise, il peut s'agir d'une panne 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 entreprise peut avoir un processus de gestion des incidents défini et cette étape doit être exécutée très près du début.
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 leur adresse IP Internet ou par Adresse privée RFC 1918 plus 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édiaire, ou les deux, comme un tunnel VPN, les proxys et les 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 ont besoin d'une analyse du chemin et/ou d'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 MTR ou tcptraceroute, ou les deux, car elles présentent de meilleures performances de diagnostic. Nous vous recommandons de vous familiariser avec ces outils.
- 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 suivre une capture de paquets pour les deux points de terminaison, en même temps, ce qui peut être délicat. Il est conseillé de s'entraîner avec les outils nécessaires (par exemple, tcpdump ou Wireshark) et faire en sorte vous assurer qu’ils sont installés avant que vous n’en ayez besoin.