Google Cloud Professional Cloud Architect
Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der PCA-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Eine globale Anwendung erfordert niedrige Latenz und hohe Verfügbarkeit für Nutzer weltweit.
Verwenden Sie einen Globalen HTTP(S) Load Balancer mit Multi-Region-Backends (MIGs/GKE), Cloud CDN für statische Inhalte und Cloud Armor für DDoS-Schutz.
Warum: Der Globale Load Balancer bietet eine einzige Anycast-IP, die Nutzer zum nächstgelegenen funktionierenden Backend leitet. CDN speichert Inhalte am Edge, wodurch die Origin-Last und die Latenz reduziert werden.
Erfassen und verarbeiten Sie hochdurchsatzstarke Echtzeitdaten von IoT-Geräten für die sofortige Analyse.
Verwenden Sie Pub/Sub für die skalierbare Nachrichtenerfassung, eine Dataflow-Streaming-Pipeline für die Echtzeitverarbeitung und Anomalieerkennung und schreiben Sie Ergebnisse zur Analyse in BigQuery.
Warum: Dies ist das kanonische Serverless-Muster für Echtzeitdaten. Pub/Sub entkoppelt die Erfassung, Dataflow verarbeitet komplexe Daten mit Autoscaling, und BigQuery unterstützt Streaming-Einfügungen für Echtzeit-Analysen.
Ein Gaming-Backend muss den Spielerstatus und Bestenlisten mit Lese-Latenzzeiten im Sub-Millisekundenbereich und hohem Durchsatz speichern.
Verwenden Sie Cloud Bigtable für den Spielstatus/Bestenlisten und Memorystore (Redis) für Session-Caching.
Warum: Bigtable bietet Latenzzeiten im einstelligen Millisekundenbereich für Lese-/Schreibvorgänge mit hohem Durchsatz, ideal für Zeitreihen- oder große Analyse-Datasets. Memorystore bietet Mikrosekunden-Latenz für den Session-Status.
Eine global verteilte Anwendung erfordert eine Datenbank mit starker Transaktionskonsistenz und horizontaler Skalierbarkeit.
Verwenden Sie Cloud Spanner mit einer Multi-Region-Konfiguration.
Warum: Spanner ist der einzige Dienst, der globale, stark konsistente Transaktionen mit SQL-Semantik und horizontaler Skalierbarkeit bietet. Cloud SQL erfordert für diese Skalierung manuelles Sharding.
Migration einer anspruchsvollen lokalen Oracle- oder PostgreSQL-Datenbank, die hohe Verfügbarkeit, Leistung und minimale Refaktorierung erfordert.
Verwenden Sie AlloyDB für PostgreSQL.
Warum: AlloyDB ist eine vollständig verwaltete, PostgreSQL-kompatible Datenbank mit überragender Leistung, 99,99 % Verfügbarkeit und Oracle-Kompatibilitätsfunktionen, was sie ideal für Unternehmensmigrationen macht.
Verbindung eines lokalen Rechenzentrums mit GCP mit konsistenten Anforderungen an niedrige Latenz (<10ms) und hohe Bandbreite (10+ Gbit/s).
Verwenden Sie Dedicated Interconnect mit redundanten Verbindungen.
Warum: Dedicated Interconnect bietet eine private, hochbandbreitige, latenzarme physische Verbindung. Cloud VPN läuft über das öffentliche Internet und kann Latenz- oder Bandbreiten-SLAs auf diesem Niveau nicht garantieren.
Entwurf eines Netzwerks für mehrere Teams/Projekte, das eine zentralisierte Netzwerkverwaltung, aber dezentralisierte Projektverantwortung erfordert.
Implementieren Sie ein Hub-and-Spoke-Modell mithilfe einer Shared VPC. Das zentrale Netzwerkteam verwaltet das Hostprojekt, und Anwendungsteams verwenden Dienstprojekte.
Warum: Shared VPC ermöglicht eine zentralisierte Kontrolle über Netzwerkressourcen (Subnetze, Firewalls) bei gleichzeitiger Delegierung der Ressourcenverwaltung in Dienstprojekten. Dies ist skalierbarer und sicherer als VPC-Peering.
Konsistente Verwaltung von Kubernetes-Clustern über Google Cloud, AWS, Azure und On-Premises-Umgebungen hinweg.
Verwenden Sie Anthos, um eine einheitliche Steuerungsebene für Multi-Cloud- und Hybrid-Cluster-Management, Policy-Durchsetzung und Observability bereitzustellen.
Warum: Anthos erweitert GKE auf andere Umgebungen und ermöglicht konsistente Operationen und GitOps-basiertes Konfigurationsmanagement (Config Management) über Ihre gesamte Flotte hinweg.
Ein Data-Science-Team muss komplexe ML-Modelle mit GPU-Beschleunigung trainieren, ohne die Infrastruktur verwalten zu müssen.
Verwenden Sie Vertex AI Training mit benutzerdefinierten Containern und Vertex AI Experiments zur Verfolgung von Modelliterationen.
Warum: Vertex AI bietet einen vollständig verwalteten Trainingsdienst, der die Infrastrukturbereitstellung, Skalierung und GPU-Verwaltung übernimmt. Er integriert sich mit Experimenten, um die Modellleistung zu verfolgen und zu vergleichen.
Bereitstellung eines großen ML-Modells mit niedriger Latenz und hoher Verfügbarkeit, das autoskalieren kann.
Verwenden Sie Vertex AI Prediction mit einem benutzerdefinierten Container, der auf einem verwalteten Endpunkt mit aktiviertem Autoscaling bereitgestellt wird.
Warum: Vertex AI Prediction ist für die Modellbereitstellung mit niedriger Latenz optimiert. Es übernimmt Autoscaling, Traffic Splitting (für A/B-Tests) und Infrastrukturmanagement, wodurch die Komplexität für Entwickler abstrahiert wird.
Eine Cloud Function oder ein Cloud Run-Dienst muss sich sicher mit einer Cloud SQL-Instanz mit privater IP verbinden.
Konfigurieren Sie einen Serverless VPC Access Connector, um die Serverless-Umgebung mit Ihrer VPC zu verbinden.
Warum: Der Connector erstellt einen Tunnel in Ihre VPC, wodurch Serverless-Dienste über ihre privaten IP-Adressen auf interne Ressourcen zugreifen können, ohne sie dem Internet preiszugeben.
Migration einer zustandsbehafteten Anwendung, die lokalen Session-Speicher verwendet, auf eine zustandslose, autoskalierende Plattform wie Cloud Run oder GKE.
Externalisieren Sie den Session-Status in einen verwalteten In-Memory-Speicher wie Memorystore (Redis).
Warum: Zustandslose Rechenressourcen erfordern, dass Session-Daten extern gespeichert werden, damit jede Instanz jede Benutzeranfrage bearbeiten kann. Memorystore bietet dafür eine gemeinsame, latenzarme Lösung.
Erstellen Sie eine verwaltete Continuous-Delivery-Pipeline, um Releases über mehrere Umgebungen (Staging, Prod) mit Genehmigungen zu promoten.
Verwenden Sie Cloud Deploy, um eine Bereitstellungspipeline zu definieren, die Bereitstellungen in Zielumgebungen (GKE, Cloud Run) mit integrierten Genehmigungs-Gates orchestriert.
Warum: Cloud Deploy ist ein vollständig verwalteter Dienst für CD, der Release-Management, Nachvollziehbarkeit und automatisierte Rollback-Funktionen bietet, ohne den Betriebsaufwand selbst gehosteter Tools wie Spinnaker.
Stellen Sie eine containerisierte Anwendung auf einem produktionsbereiten Kubernetes-Cluster mit minimalem Betriebs- und Verwaltungsaufwand bereit.
Verwenden Sie einen GKE Autopilot-Cluster.
Warum: Autopilot verwaltet die Control Plane und die Knoten des Clusters, einschließlich Bereitstellung, Skalierung und Sicherheitshärtung. Sie zahlen nur für die von Ihnen angeforderten Pod-Ressourcen, was sowohl den Betrieb als auch das Kostenmanagement vereinfacht.
Inkrementelle Migration einer großen, monolithischen Anwendung zu einer Microservices-Architektur mit minimalem Risiko und Ausfallzeiten.
Wenden Sie das Strangler Fig-Muster an. Platzieren Sie einen Proxy vor dem Monolithen und leiten Sie den Traffic für bestimmte Funktionalitäten schrittweise auf neue Microservices um, sobald diese erstellt und validiert wurden.
Warum: Dieses Muster vermeidet eine risikoreiche "Big Bang"-Neuschreibung, indem es einen schrittweisen, kontrollierten Übergang ermöglicht. Der Monolith wird langsam "erdrosselt", während neue Dienste seine Funktionalität übernehmen.
Migration einer großen Anzahl von lokalen VMs zu Google Cloud mit minimalen Ausfallzeiten.
Verwenden Sie Migrate to Virtual Machines (ehemals Migrate for Compute Engine), um eine kontinuierliche, blockweise Replikation von On-Premises nach GCP durchzuführen, gefolgt von einer schnellen Umstellung.
Warum: Dieses Tool ist für Lift-and-Shift-Migrationen konzipiert und minimiert Ausfallzeiten auf Minuten, indem Quell- und Ziel-VMs bis zur endgültigen Umstellung synchron gehalten werden.
Ein Team übernimmt SRE-Prinzipien und muss seine anfänglichen SLOs festlegen.
Definieren Sie zuerst benutzerzentrierte Service Level Indicators (SLIs) (z.B. Verfügbarkeit, Latenz). Analysieren Sie historische Leistungsdaten, um realistische anfängliche Service Level Objectives (SLOs) festzulegen.
Warum: SLOs müssen auf der Benutzererfahrung (SLIs) basieren und erreichbar sein. Die Festlegung auf der Grundlage historischer Daten stellt sicher, dass das anfängliche Fehlerbudget realistisch ist und nicht sofort verletzt wird.
Automatisieren Sie die Erstellung neuer GCP-Projekte mit einer standardisierten Konfiguration (APIs, IAM, Netzwerk, Sicherheit).
Verwenden Sie ein "Project Factory"-Muster mit einem Terraform-Modul, das von Cloud Build ausgelöst wird. Verwenden Sie den Service Catalog, um eine Self-Service-Schnittstelle bereitzustellen.
Warum: Dies stellt sicher, dass alle neuen Projekte den Organisationsstandards und Sicherheitsgrundlagen entsprechen, reduziert den manuellen Aufwand und die Konfigurationsabweichungen. Es ermöglicht Governance in großem Maßstab.
Verhinderung manueller Änderungen (Konfigurationsabweichungen) an der von Terraform verwalteten Infrastruktur.
Verwenden Sie eine CI/CD-Pipeline (z.B. Cloud Build) für alle Anwendungen, Terraform State Locking (über GCS-Backend), Organisationsrichtlinien zur Beschränkung von Konsolenaktionen und regelmäßige Drift-Erkennung.
Warum: Ein mehrschichtiger Ansatz ist erforderlich. Die Pipeline erzwingt einen einzigen Pfad für Änderungen, das Locking verhindert gleichzeitige Anwendungen, und Organisationsrichtlinien bieten eine präventive Leitplanke.
Verwaltung von Infrastrukturcode (Terraform) für mehrere Umgebungen (Dev, Staging, Prod) mit gemeinsam genutzten Modulen, aber unterschiedlichen Konfigurationen.
Verwenden Sie einen einzigen Satz wiederverwendbarer Terraform-Module und stellen Sie umgebungsspezifische Konfigurationen über separate `.tfvars`-Dateien oder Workspaces bereit.
Warum: Dies folgt dem Don't Repeat Yourself (DRY)-Prinzip. Module gewährleisten Konsistenz, während Variablen-Dateien die Flexibilität bieten, jede Umgebung anzupassen.
Implementierung eines GitOps-Workflows zur automatischen Bereitstellung von Kubernetes-Manifesten aus einem Git-Repository in GKE-Clustern.
Verwenden Sie Anthos Config Management (oder das eigenständige Config Sync), um den Cluster-Status kontinuierlich mit der Konfiguration in einem Git-Repository abzugleichen.
Warum: Config Sync bietet eine vollständig verwaltete GitOps-Lösung, die Konfigurationsabweichungen erkennt und korrigiert und sicherstellt, dass das Git-Repository die einzige Quelle der Wahrheit für den Cluster-Status ist.
Implementierung einer Blue/Green-Bereitstellung für eine Webanwendung mit null Ausfallzeit und sofortiger Rollback-Möglichkeit.
Verwenden Sie zwei identische Managed Instance Groups (oder GKE Deployments) hinter einem HTTP(S) Load Balancer. Führen Sie die Umstellung durch, indem Sie den Traffic im Backend-Dienst des Load Balancers umleiten.
Warum: Traffic Splitting auf Load-Balancer-Ebene erfolgt sofort und ermöglicht ein einfaches Rollback durch einfaches Zurückschalten des Traffics auf das ursprüngliche Backend. Dies ist langsameren DNS-basierten Methoden überlegen.
Sicheres Speichern, Verwalten und Überprüfen des Zugriffs auf Secrets wie API-Schlüssel und Datenbankpasswörter für Anwendungen.
Verwenden Sie Secret Manager mit IAM für die Zugriffssteuerung und Workload Identity für die schlüssellose Authentifizierung von GKE/Cloud Run.
Warum: Secret Manager ist ein zentraler, verwalteter Dienst mit Versionierung, Rotationsrichtlinien und Audit-Logging. Die Verwendung von Workload Identity vermeidet die Verwaltung und Verteilung von Dienstkontoschlüsseln.
Verhindern Sie, dass sensible Daten in Diensten wie BigQuery und Cloud Storage von unbefugten Projekten oder Standorten aus abgerufen oder kopiert werden.
Verwenden Sie VPC Service Controls, um einen Dienstperimeter um sensible Projekte zu erstellen und den Datenfluss einzuschränken.
Warum: VPC Service Controls fungieren als Firewall für von Google verwaltete Dienste und verhindern Datenexfiltration auf API-Ebene. Dies ist eine kritische Defense-in-Depth-Schicht jenseits von IAM und Netzwerk-Firewalls.
Verschlüsseln Sie ruhende Daten in Google Cloud-Diensten und behalten Sie dabei die volle Kontrolle über die Verschlüsselungsschlüssel.
Verwenden Sie Customer-Managed Encryption Keys (CMEK) mit Schlüsseln, die in Cloud KMS gespeichert und verwaltet werden.
Warum: CMEK ermöglicht es Ihnen, Ihre eigenen Schlüssel über Cloud KMS zu verwenden, um Daten in anderen GCP-Diensten zu schützen. Sie steuern die Schlüsselrotation und können den Zugriff durch Deaktivierung des Schlüssels widerrufen, was eine kryptografische Löschung ermöglicht.
Entwurf einer Architektur zur Handhabung von Protected Health Information (PHI) in Übereinstimmung mit HIPAA.
Verwenden Sie CMEK zur Verschlüsselungssteuerung, VPC Service Controls zur Verhinderung von Exfiltration, Assured Workloads für Compliance-Grenzen, Cloud Audit Logs und Access Transparency für die Überwachung.
Warum: HIPAA erfordert eine Kombination technischer Kontrollen. CMEK bietet Schlüsselkontrolle, VPC-SC verhindert Datenlecks, und umfangreiches Logging (Audit Logs, Access Transparency) bietet die notwendige Überprüfbarkeit.
Ein GKE-Pod muss sich sicher mit einer Cloud SQL-Datenbank verbinden, ohne Passwörter zu verwenden oder Dienstkontoschlüssel zu verwalten.
Verwenden Sie Workload Identity, um ein Kubernetes Service Account an ein Google Service Account zu binden. Stellen Sie die Verbindung mit dem Cloud SQL Auth Proxy Sidecar und der IAM-Datenbankauthentifizierung her.
Warum: Dieses "passwortlose" Muster ist das sicherste. Workload Identity bietet schlüssellose Authentifizierung, der Auth Proxy verschlüsselt den Traffic, und IAM DB Auth verwendet IAM für den Datenbankzugriff anstelle statischer Anmeldeinformationen.
Erzwingen Sie eine Richtlinie, dass alle Cloud-Ressourcen nur in bestimmten geografischen Regionen (z.B. EU) erstellt werden dürfen.
Konfigurieren Sie eine Organisationsrichtlinien-Einschränkung (`gcp.resourceLocations`) auf Organisations- oder Ordnerebene, die die zulässigen Regionen festlegt.
Warum: Dies ist eine präventive Kontrolle, die die Erstellung nicht konformer Ressourcen auf API-Ebene blockiert. Es ist die maßgebliche Methode zur Durchsetzung von Datenresidenzrichtlinien in der gesamten Organisation.
Stellen Sie sicher, dass nur vertrauenswürdige, gescannte und autorisierte Container-Images in Produktions-GKE-Clustern bereitgestellt werden.
Verwenden Sie Artifact Registry für das Schwachstellen-Scanning und Binary Authorization, um Bereitstellungsrichtlinien durchzusetzen, die gültige Attestierungen (Signaturen) erfordern.
Warum: Dies schafft eine sichere Software-Lieferkette. Artifact Registry scannt nach Schwachstellen, und Binary Authorization fungiert als Richtliniendurchsetzungspunkt, der kryptografisch überprüft, ob ein Image alle erforderlichen Prüfungen bestanden hat.
Bieten Sie sicheren, kontextsensitiven Zugriff auf interne Webanwendungen für Remote-Mitarbeiter ohne Verwendung eines herkömmlichen VPN.
Verwenden Sie BeyondCorp Enterprise mit Identity-Aware Proxy (IAP), Access Context Manager für Richtlinien und Endpoint Verification für die Gerätehaltung.
Warum: Dies implementiert ein Zero-Trust-Modell, bei dem der Zugriff basierend auf Benutzeridentität und Gerätevertrauen gewährt wird, nicht auf dem Netzwerkstandort. IAP fungiert als authentifizierender Proxy für jede Anfrage.
Eine regulierte Workload erfordert, dass Verschlüsselungsschlüssel in einem FIPS 140-2 Level 3 zertifizierten Hardware Security Module (HSM) gespeichert und verarbeitet werden.
Verwenden Sie Cloud KMS mit dem Schutzlevel `HSM` für Schlüssel.
Warum: Cloud HSM ist ein vollständig verwalteter Dienst, der FIPS 140-2 Level 3 zertifizierte HSMs bereitstellt. Schlüssel, die mit diesem Schutzlevel generiert werden, verlassen die HSM-Grenze niemals im Klartext.
Automatisches Erkennen und De-Identifizieren sensibler Daten (wie PII) in Cloud Storage oder BigQuery.
Verwenden Sie Cloud Data Loss Prevention (DLP), um nach sensiblen Daten zu scannen und De-Identifizierungs-Techniken wie Maskierung, Tokenisierung oder Redaktion anzuwenden.
Warum: DLP bietet vorgefertigte und benutzerdefinierte Detektoren für eine Vielzahl sensibler Datentypen, die einen automatisierten und skalierbaren Datenschutz ohne benutzerdefinierte Skripterstellung ermöglichen.
Mitarbeitern von mehreren Identitätsanbietern (z.B. Okta, Azure AD) den Zugriff auf Google Cloud-Ressourcen ermöglichen, ohne Google-Konten zu erstellen.
Verwenden Sie Workforce Identity Federation, um externe Identitätsanbieter mit Google Cloud IAM zu verbinden.
Warum: Dies ermöglicht es Ihnen, Ihre bestehenden Identitätssysteme als Quelle der Wahrheit zu nutzen und die Notwendigkeit zu vermeiden, Benutzer zu synchronisieren oder separate Google-Identitäten für Ihre Belegschaft zu verwalten.
Verarbeiten Sie hochsensible Daten, bei denen die Daten auch während der Nutzung (im Speicher) verschlüsselt bleiben müssen.
Verwenden Sie Confidential VMs.
Warum: Confidential Computing verschlüsselt Daten während der Verarbeitung unter Verwendung spezieller Hardwarefunktionen (AMD SEV). Dies schützt vor Memory Scraping-Angriffen und bietet eine zusätzliche Sicherheitsebene für sensible Workloads.
Optimieren Sie die Kosten und Leistung von BigQuery für ein großes Data Warehouse.
Implementieren Sie Partitionierung nach Datum und Clustering auf häufig gefilterten Spalten. Verwenden Sie BI Engine für Dashboards und materialisierte Views für gängige, teure Aggregationen.
Warum: Partitionierung und Clustering sind grundlegend, um die pro Abfrage gescannte Datenmenge zu reduzieren, was direkt Kosten senkt und die Geschwindigkeit verbessert. BI Engine und MVs reduzieren redundante Berechnungen.
Führen Sie große, fehlertolerante Batch-Verarbeitungsaufträge mit den geringstmöglichen Rechenkosten aus.
Verwenden Sie Spot VMs in einer Managed Instance Group. Stellen Sie sicher, dass die Anwendung fehlertolerant ist und Präemptions handhaben kann.
Warum: Spot VMs bieten Einsparungen von bis zu 91 % gegenüber On-Demand-Instanzen. Sie sind ideal für zustandslose, fehlertolerante Workloads, die gestoppt und neu gestartet werden können, wie viele Batch-Verarbeitungsaufgaben.
Implementieren Sie FinOps-Praktiken, um verschiedenen Teams oder Abteilungen Kostenübersicht und Verantwortlichkeit zu ermöglichen.
Verwenden Sie eine Ressourcenhierarchie (Ordner pro Team), wenden Sie Labels für die Kostenverteilung an und exportieren Sie detaillierte Abrechnungsdaten nach BigQuery zur Analyse und Visualisierung in Looker Studio.
Warum: Diese Kombination bietet eine strukturierte Möglichkeit, Ressourcen zu organisieren, Kosten über Labels granular zu verfolgen und benutzerdefinierte, teamspezifische Dashboards für Showback/Chargeback zu erstellen.
Optimieren Sie die GKE-Clusterkosten und -Leistung für Anwendungen mit variabler Last.
Verwenden Sie Horizontal Pod Autoscaler (HPA), um Pods basierend auf Metriken zu skalieren, und Cluster Autoscaler, um Knoten bei Bedarf hinzuzufügen/zu entfernen.
Warum: Dieser zweistufige Autoscaling-Ansatz stellt sicher, dass sowohl die Anwendung (Pods) als auch die Infrastruktur (Knoten) synchron mit der Nachfrage skalieren, wodurch eine Überbereitstellung verhindert und die Leistung gewährleistet wird.
Ein ML-Trainingsjob zeigt eine geringe GPU-Auslastung (<30 %), was auf einen Engpass hindeutet.
Diagnostizieren und optimieren Sie die Dateneingabe-Pipeline. Verwenden Sie `tf.data` mit Prefetching und parallelen Lesevorgängen oder Cloud Storage FUSE, um die I/O-Leistung zu verbessern.
Warum: Eine geringe GPU-Auslastung ist fast immer ein Daten-I/O-Engpass. Die GPU ist im Leerlauf, während sie auf den nächsten Datenbatch wartet. Die Optimierung des Datenladens ist der erste Schritt zur Verbesserung der Trainingseffizienz.
Reduzieren Sie hohe Netzwerkausgangskosten für die Bereitstellung von Daten an das Internet oder über Regionen hinweg.
Verwenden Sie Cloud CDN, um statische Inhalte zu cachen. Für den regionenübergreifenden Datenverkehr verwenden Sie den Standard Network Service Tier für nicht-latenzempfindliche Workloads.
Warum: CDN liefert Daten vom Edge, was günstiger ist als der Ausgang vom Origin. Der Standard Tier leitet den Traffic über das öffentliche Internet statt über Googles Premium-Netzwerk und bietet so niedrigere Kosten für die Massendatenübertragung.
Reduzieren Sie Kosten für Entwicklungs- und Test-VMs, die nur während der Geschäftszeiten benötigt werden.
Verwenden Sie Cloud Scheduler, um Cloud Functions auszulösen, die Instanzen automatisch nach einem vordefinierten Zeitplan starten und stoppen.
Warum: Dieses "Instanzplanungs"-Muster automatisiert den Prozess des Herunterfahrens von Ressourcen, wenn sie nicht verwendet werden, wodurch die Kosten für Nicht-Produktionsumgebungen erheblich gesenkt werden.
Eine kritische Anwendung erfordert eine relationale Datenbank mit automatischem Failover im Falle eines zonalen Ausfalls.
Konfigurieren Sie die Cloud SQL-Instanz mit der High Availability (HA)-Option.
Warum: Die HA-Konfiguration erstellt eine Standby-Instanz in einer anderen Zone mit synchroner Replikation. Im Falle eines Ausfalls der primären Instanz oder Zone erfolgt das Failover automatisch und dauert typischerweise weniger als 60 Sekunden.
Automatische Erkennung und Wiederherstellung von nicht reagierenden oder fehlgeschlagenen Compute Engine-Instanzen.
Stellen Sie Instanzen in einer Managed Instance Group (MIG) bereit und konfigurieren Sie die Selbstheilung mit einem anwendungsbasierten Health Check.
Warum: Die MIG-Selbstheilung prüft aktiv die Anwendung auf jeder Instanz. Wenn die Anwendung ihren Health Check nicht besteht, erstellt die MIG die Instanz automatisch neu und gewährleistet so die Service-Zuverlässigkeit.
Entwerfen Sie einen Disaster-Recovery-Plan mit einem RTO von < 1 Stunde und einem RPO von < 15 Minuten.
Implementieren Sie einen Warm Standby in einer sekundären Region. Verwenden Sie Cloud SQL Cross-Region-Replikate, multi-regionalen Cloud Storage und vorkonfigurierte Instanzvorlagen für die Berechnung.
Warum: Dieser Ansatz gleicht Kosten und Wiederherstellungszeit aus. Daten werden nahezu synchron repliziert, um den RPO zu erfüllen, und eine minimale Infrastruktur läuft (warm), um eine schnelle Skalierung zur Erfüllung des RTO zu ermöglichen.
Implementieren Sie umfassende Observability für eine Microservices-Anwendung, um eine schnelle Fehlerbehebung zu ermöglichen.
Verwenden Sie strukturiertes Logging mit Korrelations-IDs, Cloud Trace für verteiltes Tracing, Cloud Monitoring für Metriken und Cloud Error Reporting für die automatische Fehlergruppierung.
Warum: Eine Kombination aus Logs, Traces und Metriken (die "drei Säulen der Observability") ist unerlässlich. Korrelations-IDs und verteiltes Tracing sind entscheidend, um eine einzelne Anfrage über mehrere Dienste hinweg zu verfolgen.
Verhindern Sie, dass ein Fehler in einem Microservice einen Kaskadenfehler in der gesamten Anwendung verursacht.
Implementieren Sie Resilienz-Muster wie Circuit Breaker, Retries mit exponentiellem Backoff und aggressive Timeouts an jedem Service-zu-Service-Kommunikationspunkt.
Warum: Diese Muster isolieren Fehler. Ein Circuit Breaker stoppt Aufrufe an einen fehlerhaften Dienst und verhindert, dass der aufrufende Dienst seine Ressourcen erschöpft und seinerseits ausfällt.
Implementieren Sie SRE-Best Practices, um das Risiko von Produktionsausfällen durch neue Bereitstellungen zu reduzieren.
Verwenden Sie Canary-Bereitstellungen, um Änderungen schrittweise einzuführen, Feature Flags, um die Bereitstellung von der Freigabe zu entkoppeln, und automatisierte Rollback-Trigger basierend auf der SLO-Überwachung.
Warum: Diese Praktiken begrenzen den "Explosionsradius" einer fehlerhaften Bereitstellung. Canaries setzen die neue Version zuerst einer kleinen Untergruppe von Benutzern aus, und der automatisierte Rollback minimiert die mittlere Wiederherstellungszeit (MTTR).
Verwenden Sie SRE-Fehlerbudgets, um die Feature-Geschwindigkeit mit der Zuverlässigkeit in Einklang zu bringen.
Definieren Sie eine Fehlerbudget-Richtlinie: Wenn das Budget fast aufgebraucht ist, frieren Sie neue Feature-Bereitstellungen ein und priorisieren Sie Arbeiten, die die Zuverlässigkeit verbessern.
Warum: Das Fehlerbudget ist ein datengesteuerter Mechanismus für Abwägungsentscheidungen. Es gibt Teams die Erlaubnis, Risiken einzugehen, wenn das Budget intakt ist, und erzwingt einen Fokus auf Stabilität, wenn dies nicht der Fall ist.
Eine global verteilte Anwendung, die Cloud Spanner verwendet, weist in bestimmten Regionen hohe Schreiblatenzen auf.
Analysieren Sie die Schreibmuster der Anwendung und konfigurieren Sie die Leader-Region der Spanner-Instanz so, dass sie geografisch nahe an den meisten Schreibvorgängen liegt.
Warum: In Spanner werden alle Schreibvorgänge über die Leader-Region geleitet, um Konsistenz zu gewährleisten. Die Platzierung der Leader-Region nahe der primären Quelle der Schreibvorgänge minimiert die Netzwerklatenz für diese Transaktionen.
