Incidents et tableau de bord Google Cloud Service Health

Le tableau de bord Google Cloud Service Health (CSH) fournit des informations sur l'état des produits Google Cloud organisés par région et par paramètre régional.

Incident grave

Google Cloud définit un incident comme un incident majeur s'il remplit toutes les conditions suivantes:

  • Champ d'application élevé : l'incident a un impact mondial ou affecte un pourcentage important de projets clients dans une ou plusieurs régions.
  • Gravité élevée : un ou plusieurs produits sont indisponibles ou fortement dégradés.

Dans les rares cas où un incident majeur se produit, nous prenons des mesures d'urgence pour résoudre les problèmes.

En cas d'incident majeur, l'état du problème est communiqué via le tableau de bord Google Cloud Service Health. Un incident majeur est marqué comme Interruption de service dans les tableaux de bord d'état. Une fois le problème résolu, nous publions un rapport d'incident public détaillant les facteurs qui ont contribué à l'incident, ainsi que les mesures que nous prévoyons de prendre pour éviter que de tels incidents ne se reproduisent.

Dans le cas d'incidents de plus petite portée, un rapport non public peut être mis à la disposition des clients.

Cycle de vie d'un incident

Lorsqu'une dégradation d'un produit est détectée, l'équipe d'assistance Google Cloud et l'équipe d'ingénierie produit collaborent pour résoudre l'incident et vous fournissent des informations.

Le schéma suivant illustre les responsabilités des équipes d'ingénierie et d'assistance produit:

Schéma du cycle de vie

Vous pouvez en savoir plus sur chacune de ces responsabilités dans les sections suivantes.

Détection

Google Cloud utilise une surveillance interne et par boîte noire pour détecter les incidents. Pour en savoir plus, consultez le chapitre 6 du manuel d'ingénierie en fiabilité des sites.

Si vous bénéficiez de l'assistance Premium, Advanced ou Standard, vous pouvez signaler un incident en créant une demande d'assistance dans la console Google Cloud. Sinon, vous pouvez utiliser ce formulaire.

Réponse initiale

Lorsqu'un incident est détecté, l'équipe Google Cloud Customer Care gère les communications avec les clients. 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 :

Schéma des communications

Nous vous recommandons d'utiliser Personalized Service Health comme premier arrêt en cas d'interruption de service pour des produits spécifiques. Grâce à Personalized Service Health, vous pouvez afficher les interruptions liées à vos projets. Apprenez-en plus sur Personalized Service Health et découvrez comment l'intégrer à votre workflow de gestion des incidents.

Le tableau de bord Google Cloud Service Health affiche les incidents majeurs et est conçu pour être disponible dans les rares cas où Personalized Service Health est indisponible ou subit une interruption.

Si vous n'avez pas activé Personalized Service Health pour votre projet ou si le produit n'est pas encore compatible avec Personalized Service Health, nous vous recommandons de rechercher les interruptions actives dans les éléments suivants:

Les problèmes connus affichés sur la page "Assistance" de la console Google Cloud incluent également les incidents mineurs et les incidents à champ d'application limité.

Les demandes d'assistance sont adaptées aux problèmes qui ne sont pas considérés comme des incidents ou pour lesquels une intervention humaine individuelle est nécessaire. La page "Problèmes connus" vous permet de créer une demande à partir d'un incident publié afin d'obtenir des informations régulières et de pouvoir parler à l'équipe d'assistance.

Examiner

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. Atténuer un problème consiste à réduire l'impact ou l'étendue d'un problème, par exemple en fournissant temporairement des ressources supplémentaires à un produit 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é. La rédaction et la publication des analyses post-mortem par Google vise à être transparentes et à démontrer notre engagement à créer des produits stables pour nos clients.

Modèle de données sur les incidents

Un incident a un impact sur un ou plusieurs produits dans une ou plusieurs zones géographiques. Les incidents ont une heure de début et une heure de fin, ainsi qu'une gravité globale. Un incident comporte des mises à jour qui décrivent son évolution au fil du temps, y compris son état et les emplacements concernés. Les informations sur l'incident sont mises à disposition via un schéma JSON.

Le schéma JSON comporte des champs marqués Stable et Instable. En général, les champs d'ID sont considérés comme étant stable, tandis que les champs tels que les noms à afficher sont considérés comme Instable et peuvent être modifiés sans avertissement préalable. Utilisez les champs Stable uniquement en cas d'intégration à un système externe ou d'automatisation des bâtiments. Consultez la section Puis-je créer des intégrations pour utiliser les données affichées dans le tableau de bord Google Cloud Service Health de manière automatisée ?.

Questions fréquentes

Quel type d'informations d'état puis-je trouver dans le tableau de bord Google CSH ?

Le tableau de bord Google CSH fournit des informations sur l'état des produits faisant partie de Google Cloud. Il peut s'agir d'interruptions de produits, de pannes ou de messages d'information sur un problème temporaire.

À quel moment un incident est-il publié sur le tableau de bord Google CSH ?

Les incidents correspondant à l'un des critères suivants apparaissent dans le tableau de bord CSH:

Où puis-je trouver des informations sur les interruptions et pannes passées du produit ?

Le tableau de bord Google CSH conserve un enregistrement des perturbations et des interruptions des produits Google Cloud pendant une durée maximale de cinq ans. L'onglet Overview (Aperçu) du tableau de bord indique l'état actuel des produits par langue. Pour afficher des informations sur les perturbations et les interruptions de produits survenues au cours de l'année écoulée, cliquez sur Afficher l'historique dans le tableau de bord. Pour afficher l'historique des interruptions d'un produit au cours des cinq dernières années, cliquez sur le bouton Voir plus correspondant à ce produit.

Comment afficher des informations d'état régionalisées pour les produits Google Cloud ?

Le tableau de bord Google CSH affiche l'état de tous les produits Google Cloud organisés par région et par paramètre régional. Pour afficher l'état d'un emplacement multirégional, cliquez sur son onglet.

Puis-je créer des intégrations pour consommer les données affichées dans le tableau de bord Google Cloud Service Health de manière automatisée ?

Oui, vous pouvez utiliser les données affichées sur le tableau de bord Google CSH de différentes manières:

  • Via un flux RSS

  • Via un fichier d'historique JSON

    Vous pouvez télécharger le schéma du fichier JSON ici.

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.

Utilisez les champs marqués Stable dans le fichier d'historique JSON au lieu des champs marqués Instable. Exemple: Si vous essayez d'identifier de manière programmatique les incidents affectant un ensemble de produits spécifique, utilisez les ID produit (affected_products>id), et non leur nom à afficher.

ID produit et noms de produits

Auparavant, le tableau de bord Google Cloud Service Health ne fournissait pas de mécanisme permettant de localiser l'ID d'un produit donné. Depuis début 2023, le tableau de bord Service Health de Google Cloud a mis à disposition un catalogue de produits qui fournit ce mappage pour tous les produits. Un ID produit fournit un champ stable à utiliser tout en permettant la modification du nom à afficher d'un produit. Il est préférable de référencer l'ID produit lorsque vous identifiez de manière automatisée les incidents affectant un ensemble de produits.

Que se passe-t-il si j'ai des intégrations prédéfinies basées sur le tableau de bord d'état du service Google Cloud avant le lancement des rapports d'état régionalisés et le changement de nom du tableau de bord Service Health Google Cloud ?

Dans le flux RSS et le fichier JSON, les informations d'état régional s'ajoutent aux informations déjà publiées avant l'introduction de la création de rapports d'état régionalisés et la modification du nom de tableau de bord d'état du service Google Cloud. Par conséquent, vos intégrations existantes devraient continuer à fonctionner. Toutefois, si vous souhaitez utiliser les informations d'é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

    L'information sur l'état régional vient compléter les informations de flux fournies avant l'introduction de l'état régionalisé. Tous les établissements signalés comme concerné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 dans lequel chaque incident contenait une liste des produits concernés et une liste des mises à jour de l'état pour chacun, le cas échéant. Ces mises à jour d'état contenaient un champ de chaîne non structurée contenant ou non les informations sur l'établissement.

    Désormais, Google Cloud publie un flux d'incidents comme auparavant. Cependant, pour chaque incident, chaque mise à jour d'état contient les nouveaux champs suivants:

    • updates.affected_locations: contient une liste structurée des établissements concernés au moment de la publication de la mise à jour. Chaque enregistrement de mise à jour et l'enregistrement most_recent_update contiennent ce champ.
    • currently_affected_locations: contient les informations les plus récentes sur les établissements activement touchés par l'incident. Contrairement à updates.affected_locations, cette liste devient vide une fois l'incident résolu (c'est-à-dire lorsque end est défini sur une valeur non vide).
    • previously_affected_locations: contient la liste des emplacements qui ont été précédemment affectés par un incident, mais qui ne le sont pas actuellement. Au fur et à mesure de la progression de l'incident, les pannes de certains sites peuvent être résolues. Ces emplacements seront toujours présents dans le previously_affected_locations field. Une fois l'incident résolu (c'est-à-dire, lorsque end est défini sur une valeur non vide), ce champ contient la liste de tous les emplacements affectés par cet incident.

Que faire si je rencontre un problème, mais qu'il ne figure pas dans le tableau de bord ?

Le tableau de bord Service Health de Google Cloud fournit des informations sur l'état actuel et l'historique de tout incident majeur affectant les produits et services Google Cloud. Si vous rencontrez un problème qui ne figure pas dans le tableau de bord, il peut ne concerner que vos projets ou instances, ou affecter un nombre limité de clients. Vous pouvez répertorier les incidents moins importants sur Customer Care Portal. Vous pouvez contacter le service client pour tout problème que vous rencontrez et qui ne figure pas dans le tableau de bord.

Si vous utilisez déjà le tableau de bord Personalized Service Health, vérifiez si le problème y figure pour déterminer si votre projet ou votre instance est concerné.

Si vous utilisez la console Google Cloud, vous pouvez cliquer sur l'outil Envoyer des commentaires situé dans l'angle supérieur droit pour signaler des problèmes.

Qui met à jour le tableau de bord ?

L'équipe mondiale Customer Care surveille l'état des produits à l'aide de nombreux 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.