Incidents et tableau de bord Google Cloud Service Health

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

Incident grave

Google Cloud définit un incident comme un incident majeur s'il répond à toutes les exigences les conditions suivantes:

  • Portée élevée : l’incident a un impact mondial ou affecte un pourcentage 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 signalé comme Interruption de service s'affiche dans les tableaux de bord d'état. Une fois le problème résolu, publier un rapport d'incident public décrivant en détail les facteurs ont contribué à l'incident et les mesures que nous prévoyons de prendre pour éviter que d'incidents récurrents.

Dans le cas d’incidents de plus petite portée, un rapport non public peut être créé à 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 de produits collaborent pour résoudre l'incident et vous fournir avec des mises à jour.

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

Schéma du cycle de vie

Pour en savoir plus sur chacune de ces responsabilités, consultez .

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, Enhanced ou Standard, vous pouvez signaler un incident en créant une demande d'assistance Console Google Cloud Sinon, vous pouvez utilisez ce formulaire.

Réponse initiale

Lorsqu'un incident est détecté, l'équipe Google Cloud Customer Care gère les communications. 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 en cas d'interruption de service produits spécifiques. Jusqu'à Personalized Service Health, vous pouvez afficher les perturbations pertinentes pour vos projets. En savoir plus sur Personalized Service Health et comment l'intégrer à votre incident de gestion des menaces.

La Tableau de bord Google Cloud Service Health affiche des incidents majeurs et est conçu pour être disponible dans les rares cas Personalized Service Health lui-même n'est pas disponible ou est affecté par une interruption.

Si vous n'avez pas activé Personalized Service Health pour votre projet, ou si le produit n'est pas encore pris en charge par Personalized Service Health, recommandez de vérifier 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 d’incidents mineurs et à portée limitée.

Les demandes d'assistance sont adaptées aux problèmes qui ne sont pas considérés comme des incidents ou où une intervention humaine est nécessaire. La page "Problèmes connus" vous permet créer une demande à partir d'un incident posté afin d'obtenir des informations régulières 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. On parle d'atténuation lorsque l'impact ou la portée problème peut être réduit, par exemple en fournissant temporairement des ressources à 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é. L'objectif de Google dans la rédaction et la publication des analyses post-mortem est de faire preuve de transparence et de 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 comment l’incident évolue au fil du temps, y compris son état et les emplacements concernés par la suite. Les informations sur l'incident est disponible via un schéma JSON.

Le schéma JSON comporte des champs marqués Stable et Instable. En général, l'identifiant les champs sont considérés comme stables, tandis que les champs comme les noms à afficher est considéré comme Instable et peut être modifié sans avertissement préalable. Utiliser Stable que lors de l'intégration à un système externe ou de l'automatisation des bâtiments. Consultez la section Puis-je créer des intégrations pour utiliser les données affichées dans la Google Cloud Service Health Dashboard 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 font partie de Google Cloud. Il peut s'agir d'interruptions de produits, les pannes ou les 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 CSH de Google conserve un enregistrement des perturbations et des interruptions pour le produits Google Cloud jusqu'à cinq ans. La Onglet Aperçu de la tableau de bord affiche l'état actuel des produits par langue. Pour afficher des informations sur les perturbations et indisponibilités du produit au cours de l'année écoulée, cliquez sur Consultez 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 Voir plus. pour ce produit.

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

Le tableau de bord Google CSH indique l'état de tous les produits Google Cloud organisées par région et locale. Pour afficher l'état d'un emplacement multirégional : cliquez sur l'onglet spécifique à la région.

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 Dashboard dans 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, ce qui peut par le biais d'intégrations.

Utilisez les champs marqués comme Stable dans le fichier d'historique JSON, plutôt que les champs marquée comme Instable. Exemple: si vous essayez d'identifier de manière programmatique d'incidents ayant une incidence sur un ensemble spécifique de produits, utilisez leur ID (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 permettant de localiser l'identifiant d'un produit donné. Depuis début 2023, les Le tableau de bord Service Health de Google Cloud a mis à disposition catalogue de produits, qui fournit ce mappage pour tous les produits. Un ID produit fournit un champ stable pour la clé tout en permettant la modification du nom à afficher d'un produit. Il est préférable de référencer l'ID produit lors de l'identification programmatique des incidents ayant un impact sur un 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 sur l'état régional sont qui s'ajoutent aux informations déjà publiées avant la Introduction de la création de rapports d’état régionalisés et modification du nom des Tableau de bord d'état du service Google Cloud Par conséquent, nous nous attendons à ce que vos données pour continuer à fonctionner. Toutefois, si vous souhaitez utiliser l'état régional des informations via vos intégrations, vous devez les modifier.

Voici une description détaillée de la présentation des informations régionales Flux RSS et fichier JSON:

  • Flux RSS

    L'information sur l'état régional vient s'ajouter aux informations du flux. étaient fournies avant l'introduction du statut régionalisé. Tous les établissements signalées comme affectées sont ajoutées au message RSS.

  • Fichier JSON

    Avant la mise à jour de l'état régional, Google Cloud publiait un flux de incidents pour lesquels chaque incident contenait une liste des produits concernés et une liste de mises à jour de statut pour chacune, le cas échéant. Ces mises à jour de statut contenaient champ de chaîne non structurée contenant ou non l'emplacement des informations.

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

    • updates.affected_locations: contient une liste structurée des lieux au moment de la publication de la mise à jour. Chaque enregistrement de mise à jour L'enregistrement most_recent_update contient ce champ.
    • currently_affected_locations: contient les informations les plus récentes sur le les lieux qui sont activement concernés par l’incident. Retirer le "J’aime" updates.affected_locations, cette liste est vide dès que l'incident résolu (c'est-à-dire, lorsque end est défini sur une valeur non vide).
    • previously_affected_locations: contient la liste des établissements qui ont été précédemment touchées lors d’un incident, mais ce n’est pas le cas actuellement. En tant que la progression de l’incident, il se peut que la panne de certains sites soit résolue. Ces zones géographiques seront toujours présentes 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 toutes les zones géographiques concernées l'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 dans la en haut à droite 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 différents et met à jour le tableau de bord un 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.