Google PCA: Betrieb, Observability und Plattformautomatisierung — Lernleitfaden

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

Teil des Google Professional Cloud Architect — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Betrieb, Beobachtbarkeit und Plattformautomatisierung in Google Cloud stellen sicher, dass Dienste diagnostizierbar und wartbar sind und kontinuierlich verbessert werden, während gleichzeitig Sicherheit und Kosten kontrolliert werden. Ein schlüssiges Design umfasst Logging, Messwerte, Tracing, Auditierbarkeit, Runbooks, Incident Response, Kontingent- und Kapazitätssteuerung sowie Automatisierung. Das Ziel sind verwertbare, rauscharme Signale, die an Dienstgüteziele (Service-Level Objectives) gekoppelt sind, in Verbindung mit einer deterministischen Automatisierung, die manuelle, repetitive Arbeit (Toil) und Konfigurationsdrift reduziert.

Logging und Auditierbarkeit

Cloud Logging zentralisiert Logs von Google Cloud-Diensten, GKE und VMs. Bevorzugen Sie strukturierte Logs (JSON) mit konsistenten Schlüsseln für request_id, user_id, service, version, latency_ms und severity; strukturierte Daten ermöglichen präzise Abfragen, logbasierte Messwerte und die Auswertung von Richtlinien. Installieren Sie auf VMs und GKE-Knoten den Ops Agent (bevorzugt) oder den älteren Logging-Agent, um System- und Anwendungslogs zu erfassen; stellen Sie sicher, dass Parser JSON für Ihre Frameworks ausgeben.

• Log-Buckets und Aufbewahrung: Verwenden Sie regional angesiedelte Log-Buckets für Datenresidenz und CMEK. Standard-Buckets umfassen _Default und _Required; letzterer speichert Audit-Logs zu Admin Activity, System Event und Policy Denied mit fester Langzeitaufbewahrung. Erstellen Sie dedizierte Buckets pro Datenklasse (z. B. App, Sicherheit, Analyse) mit angepasster Aufbewahrungsdauer und CMEK. Eine längere Aufbewahrung verbessert forensische Analysen, erhöht aber die Kosten; exportieren Sie Daten für die Langzeitarchivierung, wenn eine Aufbewahrung in Logging nicht erforderlich ist.

• Log-Senken und Exporte: Leiten Sie Logs mit dem Log Router über Senken an BigQuery (Analyse), Pub/Sub (SIEM oder Pipelines) und Cloud Storage (Archivierung) weiter. Verwenden Sie partitionierte BigQuery-Tabellen, um Volumen und Kosten zu verwalten. Gewähren Sie dem Dienstkonto der Senke immer Schreibzugriff auf das Ziel nach dem Prinzip der geringsten Rechte, um stille Fehler zu vermeiden. Vermeiden Sie Routing-Schleifen, indem Sie exportierte Logs nicht erneut in Logging aufnehmen.

• Abfragen und logbasierte Messwerte: Verwenden Sie den Logs Explorer mit Filtern für logName, resource.type, severity, Labels und jsonPayload-Felder. Leiten Sie logbasierte Messwerte (Zähler oder Verteilung) für Fehlerraten-SLIs und Latenz-Histogramme ab, um die Alarmierung zu unterstützen. Kontrollieren Sie die Kardinalität durch Normalisierung von Feldern mit hoher Varianz.

• Cloud-Audit-Logs: Logs zu Admin Activity (Schreibvorgänge auf der Steuerungsebene), Data Access (Lese-/Schreibvorgänge von Nutzerdaten), System Event und Policy Denied bieten administrative Beobachtbarkeit. Data-Access-Logs sind voluminös und standardmäßig für viele Dienste deaktiviert; aktivieren Sie sie nur bei Bedarf und leiten Sie sie in einen Bucket mit angemessener Aufbewahrungsdauer und CMEK. Policy-Denied-Logs helfen, Berechtigungs- und Organisationsrichtlinienverstöße frühzeitig zu erkennen. Stellen Sie eine aufgabenspezifische Trennung sicher: Sicherheitsteams sind in der Regel Eigentümer der Audit-Logs und haben Zugriff darauf, während andere Teams nur eingeschränkte Ansichten erhalten.

• Fehlermodi und Abwägungen:

  • Zu breit gefasste Senken lassen die Kosten in BigQuery explodieren; filtern Sie präzise und lassen Sie Partitionen ablaufen.
  • JSON-Felder mit hoher Kardinalität (z. B. vollständige URLs) verschlechtern die Abfrageleistung; bereinigen Sie diese und extrahieren Sie normalisierte Labels.
  • Eine unzureichende Aufbewahrungsdauer beeinträchtigt Untersuchungen; Exporte nach GCS oder BigQuery mildern dies ab.
  • Fehlende Agenten oder Parser-Fehlkonfigurationen verursachen stillen Log-Verlust; richten Sie Alarme für den Agent-Heartbeat und Aufnahmefehler ein.

Beispiel: Erstellen eines regionalen Log-Buckets mit benutzerdefinierter Aufbewahrung und Export einer gefilterten Audit-Senke.

undefined

undefined

Monitoring, Tracing und Anwendungsdiagnose

Cloud Monitoring sammelt System- und Anwendungsmesswerte und unterstützt Dashboards, Alarmierung, Verfügbarkeitsprüfungen, Benachrichtigungskanäle und Dienstgüteziele (SLOs).

• Messwerte und Dashboards: Nutzen Sie die integrierten Messwerte für Google-Dienste und erstellen Sie benutzerdefinierte Messwerte über die Cloud Monitoring API oder OpenTelemetry. Legen Sie den Schwerpunkt auf die vier goldenen Signale: Latenz, Traffic, Fehler, Sättigung. Wenden Sie Labels mit Bedacht an; vermeiden Sie unbegrenzte Label-Werte. Verwenden Sie Metrics Scope, um Ansichten über mehrere Projekte hinweg zu aggregieren. Nutzen Sie bei Bedarf MQL für ausdrucksstarke Abfragen.

• Alarmierung und Benachrichtigungskanäle: Implementieren Sie Multi-Window- und Multi-Burn-Rate-Alarme für SLOs, um eine schnelle Erkennung und Rauschreduzierung auszugleichen. Definieren Sie Benachrichtigungskanäle (E-Mail, SMS, Pub/Sub, Webhooks, Incident-Tools von Drittanbietern) und fügen Sie Runbook-Links und Kontext in die Alarmdokumentation ein. Verwenden Sie Ratenbegrenzungen für Benachrichtigungen und das automatische Schließen von Incidents, um Benachrichtigungsstürme zu verhindern.

• Verfügbarkeitsprüfungen: Überprüfen Sie kritische Endpunkte aus mehreren Regionen mit TLS-Verifizierung, DNS und Inhaltsabgleich. Verknüpfen Sie Verfügbarkeitsprüfungen mit Alarmen und Dienst-SLOs. Bedenken Sie, dass Verfügbarkeitsprüfungen keine internen Abhängigkeiten validieren; ergänzen Sie sie durch synthetische Transaktionen und interne Zustandsprüfungen.

• SLOs und SLIs: Definieren Sie SLIs für Verfügbarkeit, Latenz und Korrektheit. Konfigurieren Sie SLOs im Cloud Monitoring Service Monitoring und verfolgen Sie Fehlerbudgets. Alarmieren Sie bei der Ausschöpfung des Budgets, nicht bei reinen Fehlern, um sich an den Auswirkungen für den Kunden zu orientieren. Nutzen Sie Release Gates oder progressive Bereitstellung, um das verbleibende Fehlerbudget zu berücksichtigen.

• Cloud Trace, Error Reporting, Profiler: Verwenden Sie verteiltes Tracing über Dienste hinweg mit OpenTelemetry, um Spans mit Metadaten zu Anfragen und Abhängigkeiten zu versehen. Passen Sie das Sampling dynamisch pro Dienst und pro Pfad an, um die Abdeckung kritischer Abläufe sicherzustellen und gleichzeitig die Kosten zu kontrollieren. Error Reporting aggregiert automatisch Ausnahmen aus Logs, dedupliziert sie nach Stack-Trace und löst Benachrichtigungen aus. Profiler liefert kontinuierliche CPU-, Heap- und Wall-Time-Profile in der Produktion mit geringem Overhead; nutzen Sie es, um leistungskritische Pfade zu eliminieren und Kosten zu senken.

• Fehlermodi und Abwägungen:

  • Eine übermäßige Kardinalität von Messwerten erhöht die Kosten und verlangsamt Abfragen; aggregieren Sie vor dem Senden.
  • Ein niedriges Trace-Sampling verbirgt Tail-Latency-Probleme; führen Sie für langsame Pfade ein Sampling mit einer höheren Rate durch.
  • Falsch ausgerichtete SLOs (z. B. zu streng) führen zu Alarmmüdigkeit; iterieren Sie mit echten Verkehrsdaten.
  • Verfügbarkeitsprüfungen können erfolgreich sein, während interne Abhängigkeiten ausfallen; verwenden Sie abhängigkeitsbewusste SLOs.

Plattformbetrieb, Runbooks und Incident Management

Betriebsdisziplin reduziert die durchschnittliche Zeit zur Erkennung, Behebung und zum Lernen.

• Runbooks und Eskalation: Jeder Alarm muss auf ein deterministisches Runbook mit Vorbedingungen, Diagnoseschritten, Rollback-Anweisungen und Kommunikationsvorlagen verweisen. Definieren Sie klare Bereitschaftsdienste (On-Call-Rotationen) und Eskalationsrichtlinien. Speichern Sie Runbooks in der Versionskontrolle und testen Sie sie.

• Incident Management und Post-Mortems: Verwenden Sie standardisierte Schweregrade, Rollen (Incident Commander, Kommunikation, Ops, SME) und Kanäle. Bevorzugen Sie ChatOps und Statusseiten für die breite Kommunikation (Broadcast). Verfassen Sie schuldfreie (blameless) Post-Mortems, die den Zeitverlauf, die beitragenden Faktoren, Erkennungslücken, die Auswirkungen auf den Kunden und konkrete Folgemaßnahmen mit Verantwortlichen und Terminen erfassen.

• Quota-Management und Kapazitätssignale: Überwachen Sie Service Usage- und Serviceruntime-Quota-Metriken mit Alarmen für die Auslastungsquote (Usage Ratio). Beantragen Sie Quota-Erhöhungen proaktiv und gleichen Sie die Autoscaling-Limits mit den Quotas ab. Nutzen Sie Kapazitätssignale wie CPU, Arbeitsspeicher, File Descriptors, Connection Pools und Warteschlangentiefe (Queue Depth). Passen Sie für GKE HPA/VPA und den Cluster Autoscaler an; legen Sie für GCE MIGs gegebenenfalls Cool-downs und Predictive Autoscaling fest.

• Service-Zustand und Fehlerbehebung: Kombinieren Sie Logs Explorer Live Tail, logbasierte Metriken, Dashboards und Trace, um die MTTD zu reduzieren. Aktivieren Sie VPC Flow Logs und Firewall Rules Logging für die Netzwerk-Triage; verwenden Sie die serielle VM-Konsole bei Boot-Fehlern. Halten Sie Packet Capture und Kernel Tracing als „Break-Glass“-Prozeduren in Runbooks bereit.

• Fehlermodi:

  • Quota-Erschöpfung äußert sich wie ein Ausfall; richten Sie Alarme bei 80 Prozent Auslastung ein und wenden Sie Rate-Limiting auf Upstream-Systeme an.
  • Autoscaling ohne Vorwärmen (Prewarming) verursacht Kaltstarts (Cold Starts); verwenden Sie eine Mindestanzahl an Replikaten für kritische Pfade.
  • Fehlende synthetische Prüfungen (Synthetic Checks) verschleiern für den Kunden sichtbare Ausfälle; implementieren Sie Canary-Transaktionen.

Automatisierung, Ressourceninventar, Richtlinien und Drift

Automatisieren Sie wiederholbare Aufgaben mit dem Prinzip der geringsten Rechte (Least Privilege) und Idempotenz.

• Tools: Verwenden Sie Cloud Shell für sichere, ephemere administrative Aufgaben mit persistentem $HOME; legen Sie Hilfs-Binärdateien in ~/bin ab, um die PATH-Persistenz zu gewährleisten. Automatisieren Sie mit gcloud, REST APIs und Client-Bibliotheken. Verwenden Sie Service Accounts und Workload Identity, um langlebige Schlüssel zu vermeiden.

• Scheduler und Orchestratoren: Verwenden Sie Cloud Scheduler, um HTTP- und Pub/Sub-Jobs nach Cron-Zeitplänen auszulösen. Nutzen Sie Workflows, um die Automatisierung über mehrere Dienste hinweg mit Wiederholungsversuchen (Retries), Backoff, Kompensation und Timeouts zu orchestrieren. Stellen Sie Idempotenz sicher und fügen Sie Korrelations-IDs zu den Logs hinzu.

• Beispiele für Routineautomatisierung:

  • Täglicher Export von Assets nach GCS und BigQuery für Inventar- und Drift-Berichte.
  • Automatisierte Berechnung der SLO-Burn-Rate mit Veröffentlichung auf einem Dashboard.
  • Periodische Auswertung von Richtlinien im Abgleich mit Organisationsrichtlinien und IAM-Anomalien.

• Ressourceninventar und Richtlinienauswertung: Cloud Asset Inventory bietet Point-in-Time-Snapshots und Echtzeit-Änderungsfeeds von Ressourcen, IAM-Bindungen und Organisationsrichtlinien. Exportieren Sie nach BigQuery für historische Analysen und Drift-Erkennung; abonnieren Sie Pub/Sub für die Triage von Richtlinienverstößen in nahezu Echtzeit. Verwenden Sie Policy Analyzer und Recommender, um zu weitreichende IAM-Berechtigungen und ungenutzte Berechtigungen zu erkennen. Setzen Sie Einschränkungen mit Organization Policy durch und validieren Sie Konfigurationen vor dem Deployment mit Policy-as-Code.

• Konfigurationsdrift: Verhindern Sie Drift durch deklaratives IaC und kontinuierliche Validierung. Bei Erkennung können Ressourcen entweder automatisch abgeglichen oder unter Quarantäne gestellt werden. Taggen Sie Ressourcen mit ihrer Herkunft (z. B. deployment_id), um zwischen verwalteten und Ad-hoc-Ressourcen zu unterscheiden.

• Architektur für Beobachtbarkeit (Observability) in Bezug auf Sicherheit, Zuverlässigkeit und Kosten:

  • Sicherheit: Leiten Sie Audit-Logs in CMEK-geschützte Buckets mit eingeschränktem Zugriff weiter; exportieren Sie sie in ein dediziertes Sicherheitsprojekt. Integrieren Sie SIEM über Pub/Sub.
  • Zuverlässigkeit: Steuern Sie Dashboards und Alarme über SLIs und Traces; üben Sie die Automatisierung von Vorfällen mit Workflows.
  • Kosten: Kontrollieren Sie die Kardinalität von Metriken, passen Sie die Aufbewahrungsdauer von Logs pro Bucket an, partitionieren Sie BigQuery-Exporte und verwenden Sie Profiler, um Hot Paths zu optimieren.

Beispiel: einen täglichen Asset-Export planen und einen Workflow ausführen.

• gcloud asset export –content-type=resource –output-path=gs://ORG-SEC-BUCKET/daily/resources-$(date +%F).json
• gcloud scheduler jobs create http run-asset-scan –schedule=“0 3 * * *” –uri=“WORKFLOW_EXECUTIONS_API_ENDPOINT” –http-method=POST –oauth-service-account-email=scheduler-sa@PROJECT.iam.gserviceaccount.com

Praktisches Problemszenario

Contoso Commerce startet eine auf GKE basierende Checkout-Plattform, die über mehrere Regionen verteilt ist. Anforderungen: nachvollziehbare Administration, SLO-gesteuerte Alarme mit minimalem Rauschen, durchgängiges Request-Tracing, automatisiertes nächtliches Compliance-Inventar und strenge Kostenkontrollen.

Vorgehensweise:

1. Grundlagen für Logging und Auditing schaffen

• Erstellen Sie regionale Log-Buckets mit CMEK für Anwendungs-, Sicherheits- und Analyse-Logs; legen Sie 30 Tage für Anwendungs-Logs und 400+ Tage für Sicherheits-Logs fest, wie erforderlich. Leiten Sie Admin Activity, System Event und Policy Denied Logs in den Sicherheits-Bucket um; aktivieren Sie Data Access Logs nur für Zahlungsdienste.
• Begründung: Die Trennung nach Sensitivität reduziert den „Blast Radius“ (Schadensausmaß) und die Kosten; CMEK erfüllt Compliance-Anforderungen; die Beschränkung von Data Access Logs vermeidet Volumen-Spitzen.

2. Strukturiertes Anwendungs-Logging und Sammlung implementieren

• Installieren Sie den Ops Agent auf GKE-Knoten und Sidecar/DaemonSet-Collectors, um Anwendungs-Logs als strukturiertes JSON mit Korrelations-IDs (trace_id, span_id) und von PII bereinigten Benutzer-/Sitzungs-Labels zu versenden.
• Begründung: Strukturierte Logs ermöglichen präzise Abfragen, log-basierte Metriken und die Verknüpfung mit Traces; Korrelations-IDs unterstützen die verteilte Diagnose.

3. Verteiltes Tracing, Fehleraggregation und Profiling einsetzen

• Instrumentieren Sie Microservices mit OpenTelemetry SDKs, die nach Cloud Trace exportieren; setzen Sie ein höheres Sampling für Checkout- und Zahlungspfade. Aktivieren Sie Error Reporting für alle Laufzeitumgebungen und Profiler für CPU-/speicherkritische Dienste.
• Begründung: Traces lokalisieren Latenz pro Service-Hop; Error Reporting gruppiert Stack-Traces, um die Triage zu beschleunigen; Profiler reduziert Rechenkosten und Tail-Latenz.

4. SLIs/SLOs definieren und Alarme sowie Dashboards konfigurieren

• Definieren Sie SLIs: p90- und p99-Latenz des Checkouts, Verfügbarkeit der Checkout-API und Erfolgsrate von Zahlungen. Legen Sie SLOs fest (z. B. 99,9 % Verfügbarkeit, p99-Latenz unter 800 ms). Konfigurieren Sie Burn-Rate-Alarme (2 % über 1 Stunde und 1 % über 6 Stunden) mit Links zu Runbooks und einem PagerDuty-Kanal; erstellen Sie Dashboards, die Golden Signals und Trends des Fehlerbudgets anzeigen.
• Begründung: Fehlerbudget-Alarme sind an die Auswirkungen auf den Kunden gekoppelt und reduzieren das Rauschen; Dashboards bieten ein operatives Lagebild.

5. Externe und interne Health Checks hinzufügen

• Konfigurieren Sie Uptime-Prüfungen für Checkout-Endpunkte aus mehreren Regionen mit Inhaltsvalidierung; fügen Sie synthetische Transaktionsprüfungen für den Warenkorb-bis-Zahlung-Ablauf hinzu. Integrieren Sie GCLB- und GKE-Readiness-Probes.
• Begründung: Uptime-Prüfungen verifizieren die für den Kunden sichtbare Verfügbarkeit; synthetische Abläufe erkennen Ausfälle von Abhängigkeiten.

6. Inventarisierung, Richtlinienüberwachung und Drift-Erkennung automatisieren

• Erstellen Sie ein Sicherheitsprojekt, um Cloud Asset Inventory-Exporte nach GCS und BigQuery zu empfangen; aktivieren Sie Echtzeit-Pub/Sub-Feeds für Änderungen an IAM und Organisationsrichtlinien. Führen Sie nächtlich Workflows aus, um Soll-Zustands-Manifeste mit den aktuellen Assets zu vergleichen; erstellen Sie Tickets oder gleichen Sie risikoarmen Drift automatisch ab.
• Begründung: Ein zentralisiertes Inventar unterstützt Audits; kontinuierliche Richtlinienauswertung verhindert eine Ausweitung von Berechtigungen (Privilege Creep); Automatisierung dämmt Drift ein.

7. Kontingente und Kapazität steuern

• Überwachen Sie Compute-, Load-Balancer- und API-Kontingente mit Alarmen bei 70 % und 85 % Auslastung. Beantragen Sie proaktiv höhere Kontingente für die Ziellast; stimmen Sie die Limits des GKE Cluster Autoscalers und des HPA auf die Kontingente ab. Aktivieren Sie Predictive Autoscaling für MIG-basierte Dienste, bei denen der Start langsam ist.
• Begründung: Kontingentobergrenzen können sich als Ausfälle tarnen; proaktive Anpassungen und abgestimmtes Autoscaling verhindern Drosselung unter Spitzenlast.

8. Kosten bei der Beobachtbarkeit optimieren

• Begrenzen Sie die Aufbewahrungsdauer von Logs pro Bucket, schließen Sie ausführliche Debug-Logs in der Produktion über Log Router-Filter aus und exportieren Sie nur notwendige Felder nach BigQuery mit Partitionsablauf. Beschränken Sie die Kardinalität von Metrik-Labels; nutzen Sie die Ergebnisse von Profiler, um die Größe von Hot Services zu reduzieren.
• Begründung: Beobachtbarkeit sollte kosteneffizient sein; gezielte Aufbewahrung und Exporte verhindern ausufernde Kosten.

9. Runbooks und Vorfallübungen vorbereiten

• Verfassen Sie versionierte Runbooks für jede Alarmrichtlinie, einschließlich Diagnoseabfragen, Trace-Filtern, Rollback-Befehlen und Kommunikationsplänen. Führen Sie Game Days durch, um Eskalationswege und Automatisierung zu validieren.
• Begründung: Deterministische, geübte Reaktionen reduzieren die MTTR und verbessern die Zuverlässigkeit.

10. Validieren und iterieren

• Überprüfen Sie kontinuierlich das Alarmrauschen, passen Sie Schwellenwerte an und verfeinern Sie SLOs basierend auf dem realen Traffic. Verfolgen Sie die Abarbeitung von Maßnahmen aus Post-Mortems mit Verantwortlichen und Fristen bis zum Abschluss.
• Begründung: Beobachtbarkeit und Betrieb verbessern sich durch gemessenes Feedback, was den manuellen Aufwand (Toil) reduziert und die Servicequalität im Laufe der Zeit erhöht.

← Migration · Alle Domänen · DevOps →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →