Le tableau de bord Google Cloud Service Health (CSH) fournit des informations sur l'état des services Google Cloud organisés par région et par région.
Incident majeur
L'impact d'un incident majeur s'étend à au moins deux des scénarios suivants:
- Services multiples
- Plusieurs régions
- Plusieurs heures
- Plusieurs clients
Dans les rares cas où un incident majeur se produit, nous réagissons rapidement pour résoudre tout problème.
En cas d'incident majeur, l'état du problème est communiqué via Google Workspace Status Dashboard et Google Cloud Service Health Dashboard. Un incident majeur est marqué comme Service interrompu sur les tableaux de bord d'état. Une fois le problème résolu, nous publions un rapport d'incident public contenant le détail des facteurs ayant contribué à l'incident, ainsi que les mesures que nous allons prendre pour éviter que ces incidents se reproduisent.
Dans le cas des incidents de plus petite portée, un rapport non public peut être mis à la disposition des clients.
Cycle de vie d'un incident
En cas de détection d'une dégradation d'un produit, les équipes du Cloud Customer Care et d'ingénierie du produit travaillent conjointement à la résolution de l'incident et communiquent avec vous à ce sujet.
Détection
Google Cloud détecte les incidents à l'aide de la surveillance interne et par boîte noire. Pour en savoir plus, consultez le chapitre 6 du manuel d'ingénierie en fiabilité des sites.
Si vous disposez d'une assistance Premium, Advanced ou Standard, vous pouvez signaler un incident en créant une demande dans la console Google Cloud. Sinon, vous pouvez utiliser ce formulaire.
Réponse initiale
Lorsqu'un incident est détecté, l'équipe du Cloud Customer Care dirige la communication avec vous. La notification initiale d'un incident est souvent sommaire, ne mentionnant généralement que le produit concerné. En effet, nous privilégions une notification rapide à l'apport de détails. Ces derniers peuvent être fournis dans les mises à jour ultérieures.
Différents canaux de communication sont utilisés en fonction de l'étendue et de la gravité d'un problème afin de vous fournir autant d'informations que possible, sans vous submerger de données qui ne vous concernent pas :
Lorsque vous constatez un problème, consultez en premier lieu le tableau de bord CSH Google. Ce tableau de bord indique les incidents qui concernent de nombreux clients. Par conséquent, si un incident est répertorié, il est probablement lié à votre problème. Pour indiquer la gravité, le tableau de bord marque les incidents comme une perturbation ou une interruption. Les problèmes moins importants, mais tout de même répandus, sont indiqués en tant que notifications temporaires.
Lorsqu'un produit ou service Google Cloud concerné signale un problème dans le tableau de bord CSH de Google, une notification d'indisponibilité peut également s'afficher dans Google Cloud Console. Si une notification d'indisponibilité s'affiche dans Google Cloud Console, vous pouvez cliquer dessus pour en savoir plus sur l'état du problème.
Certains produits Google Cloud disposent de groupes Google auxquels vous pouvez vous abonner pour recevoir des annonces et des notifications sur les nouveaux incidents dans le tableau de bord CSH de Google.
Les problèmes connus affichés dans le Centre d'assistance Google Cloud et sur la page d'assistance Google Cloud Console sont les plus complets. Ils incluent des problèmes qui affectent moins d'utilisateurs que ceux répertoriés dans le tableau de bord. Si vous suspectez un problème dans GCP, mais que vous ne voyez rien de correspondant sur le tableau de bord, consultez cette liste.
Les demandes d'assistance sont pertinentes pour les problèmes qui ne sont pas considérés comme des incidents ou pour lesquels une interaction humaine personnalisée est nécessaire. La page "Problèmes connus" vous permet de créer une demande à partir d'un incident publié afin d'obtenir des mises à jour régulières et de pouvoir communiquer avec l'équipe d'assistance.
Examen
Les ingénieurs produit sont chargés d'enquêter sur l'origine des incidents. La gestion des incidents est souvent assurée par des ingénieurs en fiabilité des sites, mais elle peut être confiée à des ingénieurs logiciels ou à d'autres spécialistes, en fonction de la situation et du produit. Pour en savoir plus, consultez le chapitre 12 du manuel d'ingénierie en fiabilité des sites.
Atténuation/Résolution
Un problème n'est considéré comme résolu que lorsque des modifications ont été apportées et que Google a la certitude qu'elles vont le régler définitivement. Par exemple, un rollback peut être effectué pour annuler une modification ayant déclenché un incident.
Tant qu'un incident est en cours, Customer Care et l'équipe produit tentent d'atténuer le problème. Cela permet de réduire l'impact ou l'étendue d'un problème, par exemple en fournissant temporairement des ressources supplémentaires à un service présentant une surcharge.
Si aucune mesure d'atténuation n'a été trouvée et si cela est possible, l'équipe Customer Care découvre des solutions de contournement et les communique. Les solutions de contournement sont des étapes que vous pouvez suivre pour répondre au besoin sous-jacent en dépit de l'incident. Une solution de contournement peut par exemple consister à utiliser des paramètres différents pour un appel d'API afin d'éviter un chemin de code problématique.
Suivi
Lorsqu'un incident est en cours, l'équipe Customer Care fournit des mises à jour régulières, lesquelles fournissent généralement les éléments suivants :
Davantage d'informations sur l'incident, par exemple les messages d'erreur, les zones ou régions concernées, les fonctionnalités affectées ou les pourcentages d'impact
L'avancement du processus d'atténuation, y compris les solutions de contournement
Le calendrier des communications, adapté à l'incident
Les changements d'état, par exemple lorsqu'un incident est résolu
Analyse post-mortem
Tous les incidents font l'objet d'une analyse post-mortem en interne pour bien les comprendre et identifier les améliorations de fiabilité que Google peut apporter. Ces améliorations font ensuite l'objet d'un suivi et d'une mise en œuvre. Pour en savoir plus sur les analyses post-mortem effectuées par Google, consultez le chapitre 15 du manuel d'ingénierie en fiabilité des sites.
Rapport d'incident
Lorsque les incidents ont des conséquences très graves et très étendues, Google fournit des rapports d'incident décrivant les symptômes, l'impact, l'origine, les mesures correctives et la prévention future de ces derniers. Comme pour les analyses post-mortem, nous accordons une attention particulière aux mesures que nous prenons pour tirer les leçons du problème et améliorer la fiabilité. L'écriture et la publication des analyses post-mortem témoignent de la volonté de transparence de Google, ainsi que de notre engagement à créer des services stables pour nos clients.
Questions fréquentes
Quel type d'informations d'état puis-je trouver sur le tableau de bord CSH de Google ?
Le tableau de bord CSH de Google fournit des informations sur l'état des services faisant partie de Google Cloud. Cet état peut être une perturbation ou une interruption de service, ou des messages d'information sur un problème passager.
Où puis-je trouver des informations sur les perturbations et interruptions de service antérieures ?
Le tableau de bord CSH de Google conserve un historique des interruptions et des interruptions des services Google Cloud pendant une période maximale de cinq ans. L'onglet Vue d'ensemble du tableau de bord indique l'état actuel des services par paramètre régional. Pour afficher des informations sur les perturbations et les interruptions de service de l'année écoulée, cliquez sur Afficher l'historique dans le tableau de bord. Pour afficher l'historique des interruptions d'un service au cours des cinq dernières années, cliquez sur Voir plus pour ce service.
Comment afficher les informations d'état régionalisées des services Google Cloud ?
Le tableau de bord CSH Google affiche l'état de tous les services Google Cloud organisés par région et par région. Pour afficher l'état du service d'un emplacement multirégional, cliquez sur l'onglet correspondant à la région concernée.
Puis-je créer des intégrations pour utiliser par programmation les données affichées dans le tableau de bord CSH de Google ?
Oui, vous pouvez utiliser les données affichées sur le tableau de bord CSH de Google de différentes manières:
- Via un flux RSS
Via un fichier d'historique JSON
Cliquez ici pour télécharger le schéma du fichier JSON.
Le flux RSS et le fichier d'historique JSON fournissent des informations sur l'état de l'incident, qui peuvent être utilisées via les intégrations.
Que faire si j'ai des intégrations prédéfinies basées sur Google Cloud Status Dashboard avant l'introduction des rapports d'état régionalisés et le changement de nom de Google Cloud Service Health Dashboard ?
Dans le flux RSS et le fichier JSON, les informations sur l'état régional s'ajoutent aux informations déjà publiées avant l'introduction des rapports d'état régionalisés et le changement de nom de Google Cloud Status Dashboard. Par conséquent, vos intégrations existantes devraient continuer à fonctionner. Toutefois, si vous souhaitez utiliser les informations sur l'état régional via vos intégrations, vous devez les modifier.
Voici une description détaillée de la présentation des informations régionales dans le flux RSS et le fichier JSON:
Flux RSS
Les informations sur l'état régional viennent compléter les informations sur le flux fournies avant l'introduction de l'état régionalisé. Tous les emplacements signalés comme affectés sont ajoutés au message RSS.
Fichier JSON
Avant la mise à jour de l'état régional, Google Cloud publiait un flux d'incidents où chaque incident contenait une liste des produits concernés et une liste des mises à jour de l'état de chaque incident, le cas échéant. Ces mises à jour d'état contenaient un champ de chaîne non structuré qui contenait ou non les informations d'emplacement.
Désormais, Google Cloud publie un flux d'incidents comme auparavant. Toutefois, pour chaque incident, chaque mise à jour d'état contient les nouveaux champs suivants:
updates.affected_locations: contient la liste structurée des emplacements concernés au moment de la publication de la mise à jour. Chaque enregistrement de mise à jour et l'enregistrementmost_recent_updatecontiennent ce champ.currently_affected_locations: contient les informations les plus récentes sur les emplacements activement affectés par l'incident. Contrairement àupdates.affected_locations, cette liste devient vide une fois l'incident résolu (c'est-à-dire, lorsqueendest défini sur une valeur non vide).previously_affected_locations: contient la liste des emplacements qui ont été affectés lors d'un incident, mais qui ne le sont pas actuellement. À mesure que l'incident progresse, certains emplacements peuvent avoir une résolution des interruptions de service. Ces emplacements existent toujours danspreviously_affected_locations field. Une fois l'incident résolu (c'est-à-dire, lorsqueendest défini sur une valeur non vide), ce champ contient la liste de tous les emplacements concernés par l'incident.
Que faire si je rencontre un problème, mais qu'il ne figure pas dans le tableau de bord ?
Le problème peut ne concerner que vos projets ou vos instances, ou affecter un nombre limité de clients. Vous pouvez contacter Customer Care si vous rencontrez des problèmes qui ne figurent pas dans le tableau de bord.
Si vous utilisez Google Cloud Console, vous pouvez cliquer sur l'outil Envoyer des commentaires en haut à droite pour signaler des problèmes.
Qui met à jour le tableau de bord ?
L'équipe d'assistance mondiale Customer Care surveille l'état des services par le biais de différents types de signaux, et met à jour le tableau de bord en cas de problème généralisé. Au besoin, elle publie un rapport d'analyse d'incident détaillé après la résolution de l'incident.
Quelle est la différence entre un incident et une panne ?
Bien que ces termes soient souvent utilisés de façon interchangeable, le tableau de bord CSH de Google et nos communications externes utilisent incident pour désigner toute période de dégradation de service et indisponibilité pour faire référence aux cas les plus graves, lorsqu'un produit ne fonctionne pas à grande échelle.