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ètres régionaux mondiaux.
Incident majeur
Google Cloud définit un incident comme un incident majeur s'il remplit toutes les conditions suivantes:
- Portée élevée : l'incident a un impact global ou affecte un pourcentage important de projets clients dans une ou plusieurs régions.
- Gravité élevée : un ou plusieurs produits sont indisponibles ou très dégradés.
Dans les rares cas où un incident majeur se produit, nous agissons en urgence pour résoudre tout problème.
Lors d'un incident majeur, l'état du problème est communiqué via le tableau de bord de l'état du service Google Cloud. Un incident majeur est marqué comme Service indisponible dans les tableaux de bord d'état. Une fois le problème résolu, nous publions un rapport d'incident public qui détaille les facteurs qui ont contribué à l'incident et indique 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 du produit est détectée, l'équipe d'assistance Google Cloud et l'équipe d'ingénieurs produit collaborent pour résoudre l'incident et vous fournissent des mises à jour.
Le schéma suivant illustre les responsabilités des équipes d'assistance et d'ingénierie produit:
Pour en savoir plus sur chacune de ces responsabilités, consultez 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 disposez 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 :
En cas de perturbation, nous vous recommandons d'utiliser Personalized Service Health comme première étape. Grâce à Personalized Service Health, vous pouvez afficher les perturbations pertinentes pour vos projets, en fonction de vos projets et des produits Google Cloud que vous utilisez. Apprenez-en plus sur Personalized Service Health et sur la manière de l'intégrer à votre workflow de gestion des incidents.
Le tableau de bord de l'état du service Google Cloud affiche les incidents majeurs. Il est conçu pour être disponible dans les rares cas où l'état du service personnalisé lui-même est indisponible ou affecté par une perturbation.
Si vous n'avez pas activé ni intégré Personalized Service Health, nous vous recommandons de vérifier s'il existe des interruptions actives sur la page d'assistance de la console Google Cloud ou sur Customer Care Portal. Les problèmes connus affichés sur la page "Assistance" de la console Google Cloud et sur le portail Cloud Customer Care incluent également des incidents mineurs de 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 qui nécessitent une intervention humaine. 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 à en réduire l'impact ou la portée, 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é. En rédigeant et en publiant des analyses post-mortem, Google a pour objectif de faire preuve de transparence et de démontrer notre engagement à créer des produits stables pour ses clients.
Modèle de données d'incident
Un incident affecte un ou plusieurs produits situés dans un ou plusieurs emplacements. Les incidents ont une heure de début et une heure de fin, ainsi qu'une gravité globale. Un incident est accompagné de 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 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. N'utilisez les champs Stable que lors de l'intégration à un système externe ou de l'automatisation de bâtiments. Consultez la section Puis-je créer des intégrations pour utiliser les données affichées dans le tableau de bord de l'état du service Google Cloud 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. Cet état peut inclure des interruptions de produits, des pannes ou des messages d'information sur un problème temporaire.
À quel moment un incident est-il publié dans le tableau de bord Google CSH ?
Les incidents qui répondent à l'un des critères suivants apparaissent dans le tableau de bord CSH:
- Incidents majeurs
- Le tableau de bord Personalized Service Health n'est pas disponible.
- Produits Google Cloud pas encore disponibles sur Personalized Service Health.
Où puis-je trouver des informations sur les perturbations et les interruptions de service passées ?
Le tableau de bord Google CSH conserve un historique des perturbations et des pannes des produits Google Cloud pendant une durée maximale de cinq ans. L'onglet Présentation du tableau de bord indique l'état actuel des produits par paramètres régionaux. Pour afficher des informations sur les perturbations et les interruptions liées aux produits au cours de l'année écoulée, cliquez sur Afficher l'historique dans le tableau de bord. Pour afficher l'historique des pannes d'un produit au cours des cinq dernières années, cliquez sur Voir plus pour ce produit.
Comment afficher les informations d'état régionalisées des produits Google Cloud ?
Le tableau de bord CSH Google affiche l'état de tous les produits Google Cloud organisés par région et par paramètres régionaux internationaux. 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 utiliser les données affichées dans Google Cloud Service Health Dashboard de manière programmatique ?
Oui, vous pouvez utiliser les données affichées dans Google CSH Dashboard comme suit:
- 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 de ceux marqués comme Instables. Exemple: Si vous essayez d'identifier de manière programmatique les incidents affectant un ensemble particulier de produits, utilisez l'ID produit (affected_products>id) et non leur nom à afficher.
ID et noms de produits
À l'origine, le tableau de bord de l'état du service Google Cloud ne proposait pas de mécanisme permettant de localiser l'ID d'un produit donné. Depuis début 2023, Google Cloud Service Health Dashboard met à disposition un catalogue de produits qui fournit ce mappage pour tous les produits. Un ID produit fournit un champ stable à désactiver tout en permettant au nom à afficher d'un produit de changer. Il est préférable de faire référence à l'ID produit lorsque vous identifiez de manière programmatique les incidents affectant un ensemble de produits.
Que se passe-t-il si j'ai des intégrations prédéfinies basées sur tableau de bord d'état du service Google Cloud avant l'introduction des rapports d'état régionalisés et du changement de nom dans le tableau de bord de l'état du service Google Cloud ?
Dans le flux RSS et le fichier JSON, les informations d'état régionales s'ajoutent aux informations déjà publiées avant l'introduction des rapports d'état régionalisés et la modification du nom du tableau de bord d'état du service Google Cloud. Par conséquent, nous nous attendons à ce que vos intégrations existantes continuent de 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
Les informations sur l'état régional sont un nouvel ajout des informations de flux qui étaient fournies avant l'introduction de l'état régionalisé. Toutes les adresses 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 d'incidents dans lequel chaque incident contenait une liste des produits concernés et une liste des mises à jour de l'état pour chacun d'eux, le cas échéant. Ces mises à jour d'état contenaient un champ de chaîne non structurée qui contenait ou non les informations de localisation.
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'enregistrementmost_recent_updatecontiennent ce champ.currently_affected_locations: contient les informations les plus récentes sur les emplacements activement touché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 précédemment affectés lors d'un incident, mais qui ne le sont pas actuellement. À mesure que l'incident progresse, une panne peut être résolue sur certains sites. Ces établissements 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 lieux affectés au cours de 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 de l'état du service Google Cloud fournit des informations actuelles et historiques sur l'état de tout incident majeur affectant les produits et services Google Cloud. Si vous rencontrez un problème non répertorié dans le tableau de bord, il peut ne concerner que vos projets ou vos instances, ou affecter un nombre limité de clients. Les incidents dont la portée est moins étendue peuvent être répertoriés sur Customer Care Portal. Vous pouvez contacter le service client si vous rencontrez des problèmes qui ne figurent 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 est répertorié 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 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 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.