Wenn Sie während der Vorschauphase Zugriff auf Fault Injection Testing anfordern möchten, wenden Sie sich an Ihren Google Cloud-Account Manager.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Test planen

Auf dieser Seite wird beschrieben, wie Sie Tests in Fault Injection Testing planen und externe Planungsdienste verwenden, um Ihre Resilienztests zu automatisieren.

Durch das Planen von Tests können Sie Ihre Testprozesse automatisieren und Tests in Zeiträumen ausführen, in denen die Auswirkungen auf Ihre Nutzer minimiert werden, z. B.:

Außerhalb der Stoßzeiten oder in geplanten Wartungsfenstern.
Regelmäßig geplante Game Days oder Chaos Engineering-Übungen.
Automatisierte Testpipelines (CI/CD) zur Überprüfung der Resilienz vor der Bereitstellung.

Durch das Planen von Tests können Sie die Fehlertoleranz Ihrer Systeme kontinuierlich validieren, ohne dass für jede Ausführung ein manueller Eingriff erforderlich ist.

Funktionsweise geplanter Tests

Fault Injection Testing enthält keinen integrierten Planungsdienst. Stattdessen planen Sie Tests, indem Sie Fault Injection Testing in einen externen Planungsdienst wie Cloud Scheduler einbinden.

Wenn Sie einen Test planen möchten, konfigurieren Sie den externen Planer so, dass er zu einem bestimmten Zeitpunkt die Fault Injection Testing API aufruft oder einen gcloud-Befehl ausführt. Zur Unterstützung dieser Integration bietet Fault Injection Testing den Parameter startOnCreateEnabled. Wenn dieser Parameter auf true gesetzt ist, wird der Test automatisch gestartet, sobald er erstellt wurde.

Ziele für geplante Tests auswählen

Die Zielressourcen für einen geplanten Test werden in der Testvorlage und nicht in der Planungskonfiguration selbst definiert. So verarbeitet Fault Injection Testing Ziele:

Wenn Sie eine Testvorlage erstellen, definieren Sie den Fehlertyp und die Auswahlkriterien für Ihre Zielressourcen. Beispiele für Ressourcen sind bestimmte VM-Instanzen, Ressourcen mit übereinstimmenden Tags oder Ressourcen in einer bestimmten Zone.
Wenn Sie Ihren externen Planer konfigurieren, verweist die API-Nutzlast auf Ihre Testvorlage.
Zum geplanten Zeitpunkt löst der externe Planer die Erstellung des Tests aus. Fault Injection Testing wertet dann die Regeln für die Zielauswahl in der Vorlage aus, um zu ermitteln, welche Ressourcen betroffen sind.

Wenn Ihre Vorlage VMs basierend auf einem Tag auswählt, wirkt sich der geplante Test auf alle VMs aus, die dieses Tag zum Zeitpunkt der Testausführung haben.

Geplanten Test einrichten

Prüfen Sie, ob Sie die Rolle roles/faulttesting.operator oder roles/faulttesting.admin haben.

Zeitplan mit der Google Cloud console und Cloud Scheduler konfigurieren

Sie können zwar keine Zeitpläne direkt in der Fault Injection Testing Console erstellen, aber die Console bietet die Parameter, die Sie zum Einrichten eines Jobs in Cloud Scheduler benötigen.

Rufen Sie in der Google Cloud console die Seite Testvorlagen auf.
Wählen Sie eine Vorlage aus, um die Details aufzurufen.
Notieren Sie sich auf der Detailseite Folgendes:
- Die JSON-Nutzlast, die "startOnCreateEnabled": true enthält.
- Die REST API-Endpunkt-URL zum Erstellen eines Tests.
Sie verwenden diese in Cloud Scheduler.
Rufen Sie in der Google Cloud console die Cloud Scheduler Seite auf und klicken Sie auf Job erstellen.
Definieren Sie den Zeitplan und die Zeitzone für Ihren Job.
Wählen Sie unter Zieltyp die Option HTTP aus.
Legen Sie die URL auf die REST API-Endpunkt-URL von der Detailseite Testvorlagen fest.
Legen Sie die HTTP-Methode auf POST fest.

Geben Sie im Feld Textkörper die JSON-Nutzlast ein:

{
  "experimentTemplate": "projects/PROJECT_ID/locations/REGION/experimentTemplates/TEMPLATE_ID",
  "startOnCreateEnabled": true,
  "description": "DESCRIPTION"
}

Konfigurieren Sie die Authentifizierung für den Job. Siehe Best Practices für Empfehlungen zu Dienstkonten
Klicken Sie auf Erstellen.

Zeitplan mit der Google Cloud CLI konfigurieren

Wenn Sie Skripts oder Tools verwenden, die Shell-Befehle ausführen, können Sie Tests planen, indem Sie Cloud Scheduler oder Ihren eigenen Planer so konfigurieren, dass der Befehl gcloud alpha fault-testing experiments create mit dem Flag --start-on-create-enabled ausgeführt wird.

Führen Sie den folgenden Befehl aus, um eine Testinstanz zu erstellen und sofort zu starten:

gcloud alpha fault-testing experiments create EXPERIMENT_ID \
    --experiment-template=TEMPLATE_ID \
    --location=REGION \
    --start-on-create-enabled \
    [--description="DESCRIPTION"] \
    [--project=PROJECT_ID]

EXPERIMENT_ID: Eine eindeutige ID für die Testausführung. Da dieser Befehl automatisiert ist, sollte Ihr Skript für jede Ausführung eine eindeutige ID generieren. Sie können beispielsweise einen Zeitstempel anhängen: scheduled-exp-$(date +%s).
TEMPLATE_ID: Die ID Ihrer vorkonfigurierten Testvorlage.
REGION: Die Google Cloud Region, in der der Test ausgeführt wird.
--start-on-create-enabled: Mit diesem Flag wird Fault Injection Testing angewiesen, den Test sofort nach der Erstellung zu starten.
DESCRIPTION: (Optional) Eine Beschreibung der Testausführung.
PROJECT_ID: (Optional) Ihre Google Cloud Projekt-ID.

Testausführungen verwalten

Bei jeder geplanten Ausführung wird eine neue, separate Testinstanz erstellt. Sie können diese Instanzen mit den folgenden Befehlen verwalten:

Alle Testausführungen auflisten:

gcloud alpha fault-testing experiments list --location=REGION

Details zu einer bestimmten Ausführung ansehen:

gcloud alpha fault-testing experiments describe EXPERIMENT_ID --location=REGION

Einen laufenden Test vorzeitig beenden:

gcloud alpha fault-testing experiments stop EXPERIMENT_ID --location=REGION

Best Practices

Beachten Sie beim Planen von Tests die folgenden Best Practices:

Dediziertes Dienstkonto verwenden Wenn Sie Ihren Planer (z. B. Cloud Scheduler) konfigurieren, verknüpfen Sie ihn mit einem dedizierten Dienstkonto. Erteilen Sie diesem Dienstkonto nur die Mindestberechtigungen, die zum Verwalten von Tests erforderlich sind, z. B. roles/faulttesting.operator oder roles/faulttesting.admin für Ihr Projekt.
Eindeutige Test-IDs generieren Wenn Sie Tests mit Skripts auslösen, muss Ihr Skript für jede Ausführung eine eindeutige Test-ID generieren, um Konflikte mit Ressourcennamen zu vermeiden.
Beschreibende Namen oder Beschreibungen verwenden Bei jeder geplanten Ausführung wird eine neue Testinstanz erstellt. Vorherige Tests werden nicht neu gestartet oder überschrieben. Verwenden Sie beschreibende Namen oder Beschreibungen, um Ausführungen dem Zeitplan zuzuordnen.
Fehler bei der Zeitplanung beobachten Externe Trigger können aufgrund von Netzwerkproblemen, abgelaufenen Anmeldedaten oder API-Kontingenten fehlschlagen. Richten Sie Monitoring und Benachrichtigungen für Ihre Planerjobs ein, um benachrichtigt zu werden, wenn ein Job nicht ausgeführt wird oder eine Fehlermeldung empfangen wird.
Mit Ausschlussfenstern koordinieren Prüfen Sie, ob sich Ihre geplanten Tests nicht mit aktiven Ausschluss fenstern überschneiden. Wenn ein geplanter Test während eines Ausschlussfensters ausgelöst wird, blockiert Fault Injection Testing die Ausführung und der Test kann nicht gestartet werden.