Google PCA: Opérations, observabilité et automatisation de la plateforme — Guide d'étude

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Architect — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Les opérations, l’observabilité et l’automatisation de la plateforme sur Google Cloud garantissent que les services sont diagnostiquables, maintenables et améliorés en continu, tout en maîtrisant la sécurité et les coûts. Une conception cohérente englobe la journalisation, les métriques, le traçage, l’auditabilité, les runbooks, la réponse aux incidents, la gouvernance des quotas et de la capacité, ainsi que l’automatisation. L’objectif est d’obtenir des signaux exploitables et à faible bruit, liés aux objectifs de niveau de service, associés à une automatisation déterministe qui réduit les tâches répétitives et la dérive de configuration.

Journalisation et auditabilité

Cloud Logging centralise les journaux des services Google Cloud, de GKE et des VM. Privilégiez les journaux structurés (JSON) avec des clés cohérentes pour request_id, user_id, service, version, latency_ms et severity ; les données structurées permettent des requêtes précises, des métriques basées sur les journaux et l’évaluation des politiques. Sur les VM et les nœuds GKE, installez l’Ops Agent (recommandé) ou l’agent de journalisation hérité pour collecter les journaux système et applicatifs ; assurez-vous que les analyseurs (parsers) émettent du JSON pour vos frameworks.

• Buckets de journaux et rétention : Utilisez des buckets de journaux situés dans des régions spécifiques pour la résidence des données et les CMEK. Les buckets par défaut incluent _Default et _Required ; ce dernier stocke les journaux d’audit Admin Activity, System Event et Policy Denied avec une rétention fixe à long terme. Créez des buckets dédiés par classe de données (par ex., application, sécurité, analytique) avec une rétention et des CMEK adaptées. Une rétention plus longue améliore les analyses post-mortem (forensics) mais augmente les coûts ; exportez pour un archivage à long terme lorsque la rétention dans Logging n’est pas nécessaire.

• Récepteurs de journaux et exportations : Acheminez avec le Log Router en utilisant des récepteurs (sinks) vers BigQuery (analytique), Pub/Sub (SIEM ou pipelines) et Cloud Storage (archivage). Utilisez des tables partitionnées dans BigQuery pour gérer le volume et les coûts. Accordez toujours au compte de service du récepteur un accès en écriture avec le moindre privilège à la destination pour éviter les échecs silencieux. Évitez les boucles de routage en ne ré-ingérant pas les journaux exportés dans Logging.

• Requêtes et métriques basées sur les journaux : Utilisez l’Explorateur de journaux (Logs Explorer) avec des filtres sur les champs logName, resource.type, severity, labels et jsonPayload. Dérivez des métriques basées sur les journaux (compteur ou distribution) pour les SLI de taux d’erreur et les histogrammes de latence, afin de prendre en charge les alertes. Contrôlez la cardinalité en normalisant les champs à forte variance.

• Cloud Audit Logs : Les journaux Admin Activity (écritures sur le plan de contrôle), Data Access (lectures/écritures de données utilisateur), System Event et Policy Denied fournissent une observabilité administrative. Les journaux Data Access ont un volume élevé et sont désactivés par défaut pour de nombreux services ; activez-les uniquement là où c’est nécessaire et acheminez-les vers un bucket avec une rétention et des CMEK appropriées. Les journaux Policy Denied aident à détecter précocement les violations d’autorisations et de politiques d’organisation. Assurez une ségrégation des responsabilités : les équipes de sécurité possèdent et accèdent généralement aux journaux d’audit, avec des vues restreintes pour les autres équipes.

• Modes de défaillance et compromis :

  • Des récepteurs trop larges font exploser les coûts dans BigQuery ; filtrez avec précision et faites expirer les partitions.
  • Les champs JSON à haute cardinalité (par ex., des URL complètes) dégradent les performances des requêtes ; nettoyez et extrayez des libellés normalisés.
  • Une rétention insuffisante complique les investigations ; les exportations vers GCS ou BigQuery atténuent ce risque.
  • Un agent manquant ou des erreurs de configuration de l’analyseur (parser) provoquent une perte de journaux silencieuse ; alertez sur le signal de présence (heartbeat) de l’agent et les erreurs d’ingestion.

Exemple : créer un bucket de journaux régional avec une rétention personnalisée et exporter un récepteur d’audit filtré.

• gcloud logging buckets create app-logs –location=us-central1 –retention-days=30
• gcloud logging sinks create bq-audit-sink bigquery.googleapis.com/projects/PROJECT/datasets/audit –log-filter=“logName:cloudaudit.googleapis.com AND protoPayload.serviceName:*” –use-partitioned-tables

Surveillance, traçage et diagnostic des applications

Cloud Monitoring collecte les métriques système et applicatives, prend en charge les tableaux de bord, les alertes, les vérifications de disponibilité (uptime checks), les canaux de notification et les objectifs de niveau de service.

• Métriques et tableaux de bord : Utilisez les métriques intégrées pour les services Google et créez des métriques personnalisées via l’API Cloud Monitoring ou OpenTelemetry. Mettez l’accent sur les quatre signaux d’or : latence, trafic, erreurs, saturation. Appliquez les libellés (labels) judicieusement ; évitez les valeurs de libellés non bornées. Utilisez le périmètre de métriques (Metrics Scope) pour agréger les vues multi-projets. Utilisez MQL pour des requêtes expressives lorsque c’est nécessaire.

• Alertes et canaux de notification : Implémentez des alertes multi-fenêtres et à plusieurs taux de consommation (multi-burn-rate) pour les SLO afin d’équilibrer la détection rapide et la réduction du bruit. Définissez des canaux de notification (e-mail, SMS, Pub/Sub, webhooks, outils d’incident tiers) et incluez des liens vers les runbooks et du contexte dans la documentation des alertes. Utilisez la limitation du débit de notifications et la clôture automatique des incidents pour éviter les tempêtes d’alertes.

• Vérifications de disponibilité : Sondez les points de terminaison critiques depuis plusieurs régions avec vérification TLS, DNS et correspondance de contenu. Liez les vérifications de disponibilité aux alertes et aux SLO de service. N’oubliez pas que les vérifications de disponibilité ne valident pas les dépendances internes ; complétez-les avec des transactions synthétiques et des vérifications de santé internes.

• SLO et SLI : Définissez des SLI pour la disponibilité, la latence et l’exactitude (correctness). Configurez les SLO dans Cloud Monitoring Service Monitoring et suivez les budgets d’erreur. Alertez sur la consommation du budget, pas sur les erreurs brutes, pour vous aligner sur l’impact client. Utilisez des portes de déploiement (release gates) ou une livraison progressive pour respecter le budget d’erreur restant.

• Cloud Trace, Error Reporting, Profiler : Utilisez le traçage distribué à travers les services avec OpenTelemetry pour annoter les spans avec les métadonnées de requête et de dépendance. Ajustez l’échantillonnage (sampling) de manière dynamique par service et par chemin pour assurer la couverture des flux critiques tout en maîtrisant les coûts. Error Reporting agrège automatiquement les exceptions à partir des journaux, les déduplique par trace de la pile (stack trace) et déclenche des notifications. Profiler fournit des profils continus du CPU, du tas (heap) et du temps d’exécution (wall-time) en production avec une faible surcharge ; utilisez-le pour éliminer les chemins critiques (hot paths) et réduire les coûts.

• Modes de défaillance et compromis :

  • Une cardinalité excessive des métriques augmente les coûts et ralentit les requêtes ; agrégez avant d’émettre.
  • Un faible échantillonnage de traces masque les problèmes de latence de queue ; échantillonnez à un taux plus élevé pour les chemins lents.
  • Des SLO mal alignés (par ex., trop stricts) génèrent une fatigue liée aux alertes ; itérez avec des données de trafic réelles.
  • Les vérifications de disponibilité peuvent réussir alors que des dépendances internes échouent ; utilisez des SLO qui tiennent compte des dépendances.

Opérations de la plateforme, runbooks et gestion des incidents

La rigueur opérationnelle réduit le temps moyen de détection, de mitigation et d’apprentissage.

• Runbooks et escalade : Chaque alerte doit renvoyer à un runbook déterministe avec des prérequis, des étapes de diagnostic, de restauration (rollback) et des modèles de communication. Définissez des rotations d’astreinte et des politiques d’escalade claires. Stockez les runbooks dans un système de contrôle de version et testez-les.

• Gestion des incidents et post-mortems : Utilisez des niveaux de sévérité, des rôles (chef d’incident, communications, ops, SME) et des canaux standardisés. Privilégiez le chat ops et les pages de statut pour la diffusion d’informations. Rédigez des post-mortems sans blâme qui documentent la chronologie, les facteurs contributifs, les lacunes de détection, l’impact client et des actions de suivi concrètes associées à des responsables et des dates.

• Gestion des quotas et signaux de capacité : Surveillez les métriques de Service Usage et de quota serviceruntime avec des alertes sur le ratio d’utilisation. Demandez des augmentations de quota de manière proactive et alignez les limites d’autoscaling sur les quotas. Utilisez des signaux de capacité tels que le CPU, la mémoire, les descripteurs de fichiers, les pools de connexions et la profondeur des files d’attente. Pour GKE, ajustez HPA/VPA et le cluster autoscaler ; pour les GCE MIGs, configurez des délais de récupération (cool-downs) et l’autoscaling prédictif le cas échéant.

• Santé du service et dépannage : Combinez le live tail de Logs Explorer, les métriques basées sur les logs, les tableaux de bord et Trace pour réduire le MTTD. Activez VPC Flow Logs et Firewall Rules Logging pour le diagnostic réseau ; utilisez la console série des VM pour les échecs de démarrage. Conservez la capture de paquets et le traçage du noyau (kernel tracing) comme procédures de dernier recours (break-glass) dans les runbooks.

• Modes de défaillance :

  • L’épuisement des quotas ressemble à des pannes ; alertez à 80 % d’utilisation et limitez le débit en amont (rate-limit).
  • L’autoscaling sans pré-chauffage (prewarming) provoque des démarrages à froid (cold starts) ; utilisez un nombre minimum de réplicas pour les chemins critiques.
  • L’absence de tests synthétiques masque les défaillances visibles par le client ; mettez en œuvre des transactions canary.

Automatisation, inventaire des ressources, politiques et dérive

Automatisez les tâches répétables avec le principe de moindre privilège et l’idempotence.

• Outillage : Utilisez Cloud Shell pour une administration sécurisée et éphémère avec un $HOME persistant ; placez les binaires utilitaires dans ~/bin pour la persistance du PATH. Automatisez avec gcloud, les API REST et les bibliothèques clientes. Utilisez des comptes de service et Workload Identity pour éliminer les clés à longue durée de vie.

• Planificateurs et orchestrateurs : Utilisez Cloud Scheduler pour déclencher des tâches HTTP et Pub/Sub selon des planifications cron. Utilisez Workflows pour orchestrer l’automatisation multi-services avec des nouvelles tentatives, un backoff (retrait exponentiel), une compensation et des délais d’attente. Assurez l’idempotence et ajoutez des ID de corrélation aux journaux.

• Exemples d’automatisation de routine :

  • Exportation quotidienne des éléments (assets) vers GCS et BigQuery pour l’inventaire et les rapports de dérive.
  • Calcul automatisé du taux de consommation du budget d’erreur SLO (burn-rate) et publication sur un tableau de bord.
  • Évaluation périodique des politiques par rapport aux politiques d’organisation et aux anomalies IAM.

• Inventaire des ressources et évaluation des politiques : Cloud Asset Inventory fournit des flux de changements de ressources, de liaisons IAM et de politiques d’organisation à un instant T et en temps réel. Exportez vers BigQuery pour l’analyse historique et la détection de dérive ; abonnez-vous à Pub/Sub pour le triage quasi en temps réel des violations de politique. Utilisez Policy Analyzer et Recommender pour détecter les permissions IAM trop larges et inutilisées. Appliquez des contraintes avec Organization Policy et validez les configurations avant le déploiement avec le policy-as-code.

• Dérive de configuration : Prévenez la dérive avec l’IaC déclaratif et la validation continue. Lors de la détection, réconciliez automatiquement ou mettez en quarantaine les ressources. Taguez les ressources avec leur provenance (ex: deployment_id) pour distinguer les ressources gérées des ressources ad hoc.

• Architecture d’observabilité pour la sécurité, la fiabilité et les coûts :

  • Sécurité : Routez les journaux d’audit vers des buckets protégés par CMEK avec accès restreint ; exportez vers un projet de sécurité dédié. Intégrez un SIEM via Pub/Sub.
  • Fiabilité : Alimentez les tableaux de bord et les alertes à partir des SLI et des traces ; répétez l’automatisation des incidents avec des workflows.
  • Coût : Contrôlez la cardinalité des métriques, ajustez la rétention des journaux par bucket, partitionnez les exportations BigQuery et utilisez Profiler pour optimiser les chemins critiques (hot paths).

Exemple : planifier une exportation quotidienne des éléments et exécuter un workflow.

undefined

undefined

Scénario de problème pratique

Contoso Commerce lance une plateforme de paiement multi-région basée sur GKE. Exigences : administration auditable, alertes basées sur les SLO avec un minimum de bruit, traçage de bout en bout des requêtes, inventaire de conformité nocturne automatisé et contrôles de coûts stricts.

Approche :

1. Établir les fondations pour la journalisation et l’audit

• Créer des buckets de journaux régionaux avec CMEK pour les journaux applicatifs, de sécurité et d’analyse ; définir une rétention de 30 jours pour les journaux applicatifs, 400+ jours pour ceux de sécurité, selon les besoins. Router les journaux Admin Activity, System Event et Policy Denied vers le bucket de sécurité ; activer les journaux d’accès aux données (Data Access) uniquement pour les services de paiement.
• Justification : La ségrégation par sensibilité réduit le rayon d’impact (blast radius) et les coûts ; CMEK satisfait les exigences de conformité ; limiter les journaux Data Access évite les pics de volume.

2. Mettre en œuvre la journalisation et la collecte d’applications structurées

• Déployer l’Ops Agent sur les nœuds GKE et des collecteurs en sidecar/daemonset pour envoyer les journaux applicatifs en JSON structuré avec des ID de corrélation (trace_id, span_id) et des étiquettes utilisateur/session nettoyées des informations personnelles identifiables (PII).
• Justification : Les journaux structurés permettent des requêtes précises, des métriques basées sur les journaux et la jointure avec les traces ; les ID de corrélation soutiennent les diagnostics distribués.

3. Déployer le traçage distribué, l’agrégation d’erreurs et le profilage

• Instrumenter les microservices avec les SDK OpenTelemetry exportant vers Cloud Trace ; définir un échantillonnage plus élevé pour les parcours de validation de panier et de paiement. Activer Error Reporting pour tous les runtimes et Profiler pour les services critiques en termes de CPU/mémoire.
• Justification : Les traces localisent la latence par saut de service ; Error Reporting regroupe les traces de pile (stack traces) pour accélérer le triage ; Profiler réduit les coûts de calcul et la latence de queue (tail latency).

4. Définir les SLI/SLO et configurer les alertes et les tableaux de bord

• Définir les SLI : latence p90 et p99 de la validation de panier, disponibilité de l’API de paiement et taux de réussite des paiements. Définir les SLO (ex: disponibilité de 99,9 %, latence p99 inférieure à 800 ms). Configurer des alertes de consommation du budget d’erreur (burn-rate) (2 % sur 1 heure et 1 % sur 6 heures) avec des liens vers des runbooks et un canal PagerDuty ; construire des tableaux de bord affichant les signaux de référence (golden signals) et les tendances du budget d’erreur.
• Justification : Les alertes basées sur le budget d’erreur sont liées à l’impact client et réduisent le bruit ; les tableaux de bord fournissent une conscience situationnelle opérationnelle.

5. Ajouter des vérifications de santé externes et internes

• Configurer des vérifications de disponibilité (uptime checks) multi-régions pour les points de terminaison de paiement avec validation de contenu ; ajouter des vérifications de transactions synthétiques pour le flux du panier au paiement. Intégrer les sondes de préparation (readiness probes) de GCLB et GKE.
• Justification : Les vérifications de disponibilité valident la disponibilité côté client ; les flux synthétiques détectent les ruptures de dépendances.

6. Automatiser l’inventaire, la surveillance des politiques et la détection de dérive

• Créer un projet de sécurité pour recevoir les exportations de Cloud Asset Inventory vers GCS et BigQuery ; activer les flux Pub/Sub en temps réel pour les changements IAM et de politiques d’organisation. Exécuter des Workflows chaque nuit pour comparer les manifestes d’état désiré avec les éléments actuels ; ouvrir des tickets ou réconcilier automatiquement la dérive à faible risque.
• Justification : Un inventaire centralisé soutient les audits ; l’évaluation continue des politiques prévient l’escalade des privilèges ; l’automatisation maîtrise la dérive.

7. Gouverner les quotas et la capacité

• Surveiller les quotas de calcul, de load balancer et d’API avec des alertes à 70 % et 85 % d’utilisation. Demander à l’avance des quotas plus élevés pour la charge cible ; aligner les limites de l’autoscaler de cluster GKE et du HPA avec les quotas. Activer l’autoscaling prédictif pour les services basés sur des MIG où le démarrage est lent.
• Justification : Les plafonds de quota peuvent se faire passer pour des pannes ; des ajustements proactifs et un autoscaling aligné empêchent le throttling (limitation) en période de pointe.

8. Optimiser les coûts de l’observabilité

• Plafonner la rétention des journaux par bucket, exclure les journaux de débogage verbeux en production via les filtres de Log Router, et exporter uniquement les champs nécessaires vers BigQuery avec une expiration de partition. Limiter la cardinalité des étiquettes de métriques ; utiliser les résultats de Profiler pour réduire la taille des services très sollicités.
• Justification : L’observabilité doit être rentable ; une rétention et des exportations ciblées préviennent les dépenses incontrôlées.

9. Préparer les runbooks et la pratique des incidents

• Rédiger des runbooks versionnés pour chaque politique d’alerte, incluant des requêtes de diagnostic, des filtres de trace, des commandes de rollback et des communications. Organiser des “game days” pour valider l’escalade et l’automatisation.
• Justification : Des réponses déterministes et entraînées réduisent le MTTR (temps moyen de résolution) et améliorent la fiabilité.

10. Valider et itérer

• Examiner continuellement le bruit des alertes, ajuster les seuils et affiner les SLO en fonction du trafic réel. Suivre les actions de postmortem jusqu’à leur achèvement avec des responsables et des échéances.
• Justification : L’observabilité et les opérations s’améliorent grâce à un feedback mesuré, réduisant le labeur (toil) et augmentant la qualité du service au fil du temps.

← Migration · Tous les domaines · DevOps →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →