Bonnes pratiques relatives à l'utilisation de l'assistance Cloud

La rédaction d'une demande d'assistance détaillée permet à l'équipe d'assistance Google de vous répondre de manière rapide et efficace. Lorsque votre demande d'assistance manque de détails importants, nous devons vous demander des compléments d'informations, ce qui prend plus de temps. Ce guide vous présente les renseignements dont nous avons besoin dans votre demande d'assistance technique afin de résoudre votre problème plus rapidement.

Décrire le problème

Un rapport de signalement de problème doit être à la fois détaillé et spécifique. Il doit indiquer ce qu'il s'est passé et le résultat que vous attendiez. Pour être pertinent, un rapport de signalement de problème doit contenir les éléments suivants :

  • Heure : l'horodatage spécifique à l'apparition du problème
  • Produit : le ou les produits et fonctionnalités associés au problème
  • Emplacement : la ou les zones où survient le problème
  • Identifiants : l'ID du projet/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.

Données temporelles

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 l'ingénieur du service d'assistance 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 Cloud Console (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 moyen que vous utilisez pour lancer la demande (par exemple : l'API REST, l'outil gcloud, Cloud Console ou encore un outil tel que Deployment Manager). Si plusieurs produits sont concernés, précisez le nom de chacun d'eux.

Exemples :

  • "L'API REST de Google 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 instances renvoie 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, précisez si l'adresse IP est connectée à une instance Compute, un équilibreur de charge, un routage personnalisé 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 est destinée à 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 GCP 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 comprend des instructions 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 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. Notez que le protocole de transmission (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 ingénieurs de l'assistance puissent répliquer l'environnement et diagnostiquer le problème.

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 page Procédures d'assistance Cloud.

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, risques au niveau de l'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 faites face à un nombre considérable d'erreurs avec les utilisateurs ou vous rencontrez des difficultés pour lancer rapidement 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 concernés, etc.).
P4 : impact faible – Service entièrement utilisable Incidence technique ou répercussions sur les activités de l'entreprise minimes, voire nulles. Ce niveau de priorité est 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 ce niveau de priorité. Rédigez une brève description de l'impact du problème sur votre entreprise. Par exemple, vous pouvez évaluer un problème lié à une version de développement comme étant de niveau P1, même si aucun utilisateur final n'est directement affecté, car 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 recevez rapidement une première réponse (sous 15 minutes pour les clients Enterprise et une heure pour les clients bénéficiant de la formule d'assistance Role-based et dotés du rôle Production). Vous êtes ensuite régulièrement informé de l'évolution de la situation.

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écrits dans les instructions relatives aux services d'assistance technique de Google Cloud Platform. Si vous avez besoin d'une réponse à une heure précise, 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 ingénieur d'assistance actif.

Augmenter la priorité

Lorsque les circonstances évoluent, il peut être nécessaire d'augmenter la sévérité du problème afin d'attirer l'attention de notre équipe. Vous pouvez faire remonter un problème pour les raisons suivantes :

  • L'impact du problème sur votre entreprise est devenu plus important.
  • Le problème doit être résolu plus rapidement.
  • Le problème est "bloqué" sans aucune progression après que vous avez échangé plusieurs messages.

Lorsqu'un changement de priorité est effectué sur une demande d'assistance GCP, un responsable de l'assistance est immédiatement averti et vous informe de la situation dans un délai maximal d'une heure. Le gestionnaire des changements de priorité prend en charge la demande jusqu'à son terme. Il identifie et traite l'origine de l'augmentation de la priorité, et signale les actions préventives à mener afin d'éviter tout changement similaire à l'avenir.

Vous pouvez demander le changement de la priorité d'une demande en cours dans ses commentaires, ou en cliquant sur le bouton Augmenter la priorité de la demande qui apparaît 60 minutes après sa création.

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 ce modèle, cliquez simplement sur le lien ci-dessus et faites-en une copie. Incluez des liens vers toutes les demandes pertinentes et les bugs de suivi internes. Partagez cette documentation avec le groupe de votre équipe de gestion du compte et demandez-leur de la transmettre aux ingénieurs du service d'assistance concernés.

Cette documentation comprend 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 en question empêche votre application de diffuser du trafic auprès des utilisateurs ou a un impact tout aussi 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 :

  • recherchant immédiatement des problèmes connus affectant l'infrastructure GCP ;
  • confirmant la nature du problème ;
  • mettant en place des canaux de communication.

Vous recevrez une réponse avec 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 d'utiliser (par exemple : par téléphone, via Hangout ou par demande)

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. 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 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
  • Les encapsulations et/ou indirections intermédiaires, 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 paquet intermittente nécessitent une analyse de chemin et/ou une capture de paquets à des fins de 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 présentent de meilleures performances en termes de diagnostic. Nous vous invitons donc à vous familiariser avec ces outils.
  • La capture de paquets (ou "pcap", en référence au 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. Vous pouvez vous entraîner à l'aide des outils nécessaires (par exemple, tcpdump ou Wireshark) et vous assurer qu'ils sont installés pour pouvoir les utiliser quand vous en aurez besoin.

Exemples de demandes

Exemple 1

Nom de la tâche :

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Source :

S3_avl-transfer

Destination :

CloudStorage : avl-transfer

Heure de début (format ISO 8601) : 2017-04-20 à 20:14:43 PDT

Heure de fin (format ISO 8601) : 2017-04-21 à 10:03:44 PDT

J'ai commencé un transfert de fichier à la date du 2017-04-20 à 20:14:43 PDT à l'aide de l'API Transfer. L'exécution de cette tâche prend normalement 10 minutes. Or, elle était toujours en cours d'exécution lorsque je l'ai annulée le lendemain (2017-04-21 à 10:03:44 PDT). Il ne s'agit pas d'un événement isolé. D'autres tâches impliquant l'API Transfer ont présenté des retards importants et intermittents.

Veuillez identifier la cause de ces retards et indiquer les bonnes pratiques à suivre pour éviter ces problèmes à l'avenir.

Exemple 2

Heure de début (format ISO 8601) : 2017-05-12 à 11:03:43

Heure de fin (format ISO 8601) : le problème persiste au moment de la rédaction du présent rapport

Résumé du problème :

La tâche Cron /cron/payments-service/sync-v2-batch utilisant l'API App Engine Task Queue ne fonctionne plus depuis la date du 2017-05-12 à 11:03:43. Cette tâche nous permet de gérer les paiements correctement.

Nous avons constaté des erreurs liées au datastore et à la file d'attente, puis la tâche Cron a cessé de fonctionner. Nous avons tenté, mais en vain, de résoudre le problème en important à nouveau le fichier cron.xml. Voici la trace de l'erreur :

[error trace]

Veuillez indiquer si le problème concerne l'API ou notre mise en œuvre, et nous préciser la procédure à suivre.