Best Practices für Workflows

Sie können die hier aufgeführten Best Practices als Referenz verwenden, wenn Sie Ihre Dienste mithilfe von Workflows orchestrieren.

Diese Liste ist nicht vollständig und enthält keine grundlegenden Informationen zur Verwendung von Workflows. In diesem Dokument wird davon ausgegangen, bereits ein allgemeines Verständnis der gesamten Google Cloud-Landschaft haben und von Workflows. Weitere Informationen finden Sie im Google Cloud-Architektur-Framework und in der Workflow-Übersicht.

Das optimale Kommunikationsmuster auswählen

Beim Entwerfen einer Mikrodienstarchitektur für die Bereitstellung mehrerer Dienste aus den folgenden Kommunikationsmustern auswählen:

  • Direkte Service-zu-Dienst-Kommunikation

  • Indirekte ereignisgesteuerte Kommunikation (auch als Choreografie bezeichnet)

  • Automatisierte Konfiguration, Koordination und Verwaltung (auch bekannt als Orchestrierung)

Berücksichtigen Sie die Vor- und Nachteile der einzelnen Optionen und wählen Sie ein optimales Muster für Ihren Anwendungsfall aus. Zum Beispiel Die Dienst-zu-Dienst-Kommunikation ist möglicherweise einfacher zu implementieren als andere. Optionen, aber Ihre Dienste sind eng miteinander verbunden. Im Gegensatz dazu ereignisgesteuerte Architektur Sie Ihre Dienste lose verknüpfen. Monitoring und Fehlerbehebung können jedoch komplizierter machen. Ein zentraler Orchestrator wie Workflows weniger flexibel ist, können Sie die Kommunikation zwischen Diensten koordinieren, ohne die enge Verbindung der direkten Service-zu-Dienst-Kommunikation choreografierter Events.

Sie können auch Kommunikationsmuster kombinieren. Bei der ereignisgesteuerten Orchestrierung werden beispielsweise eng miteinander verbundene Dienste in einer Orchestrierung verwaltet, die durch ein Ereignis ausgelöst wird. In ähnlicher Weise könnten Sie ein System entwerfen, in dem eine Orchestrierung einer Pub/Sub-Nachricht an eine andere orchestrierten System.

Allgemeine Tipps

Wenn Sie sich entschieden haben, Workflows als Dienstorchestrator zu verwenden, sollten Sie die folgenden hilfreichen Tipps beachten.

URLs nicht hartcodieren

Sie können Workflows unterstützen, die in mehreren Umgebungen übertragbar sind einfacher zu verwalten, da hartcodierte URLs vermieden werden. Sie können dies in der auf folgende Arten:

  • Definieren Sie URLs als Laufzeitargumente.

    Dies kann hilfreich sein, wenn Ihr Workflow über eine Clientbibliothek oder die API verwenden. Das funktioniert jedoch nicht, wenn Ihr Workflow durch ein Ereignis von Eventarc ausgelöst wird und das einzige Argument, das übergeben werden kann, die Ereignisnutzlast ist.

    Beispiel

    main:
  params: [args]
  steps:
    - init:
        assign:
          - url1: ${args.urls.url1}
          - url2: ${args.urls.url2}

    Wenn Sie den Workflow ausführen, können Sie die URLs angeben. Hier einige Beispiele:

    gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'

  • Verwenden Sie Umgebungsvariablen und erstellen Sie einen Workflow, der je nach Umgebung, in der er bereitgestellt wird, dynamisch konfiguriert wird. Alternativ können Sie einen Workflow erstellen, der als Vorlage wiederverwendet und gemäß separat verwalteten Umgebungsvariablen konfiguriert werden kann.

  • Mit einem Ersetzungsverfahren einen einzelnen Workflow erstellen der Definitionsdatei, und stellen Sie Varianten mithilfe eines Tools bereit, das Platzhalter in Ihrem Workflow. Sie können beispielsweise Cloud Build verwenden, um einen Workflow bereitzustellen, und in der Cloud Build-Konfigurationsdatei einen Schritt hinzufügen, um Platzhalter-URLs im Workflow zu ersetzen.

    Beispiel

    steps:
‐ id: 'replace-urls'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: bash
  args:
    - -c
    - |
      sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml
      sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml
‐ id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']

    Sie können dann Variablenwerte ersetzen. Beispiel:

    gcloud builds submit --config cloudbuild.yaml \
    --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"

    Weitere Informationen finden Sie unter Senden Sie einen Build über die Befehlszeile und API.

    Alternativ können Sie Terraform verwenden. um Ihre Infrastruktur bereitzustellen und eine Konfigurationsdatei zu definieren, erstellt Workflows für jede Umgebung mithilfe von Eingabevariablen.

    Beispiel

    variable "project_id" {
  type = string
}

variable "url1" {
  type = string
}

variable "url2" {
  type = string
}

locals {
  env = ["staging", "prod"]
}

# Define and deploy staging and production workflows
resource "google_workflows_workflow" "multi-env-workflows" {
  for_each = toset(local.env)

  name            = "multi-env-${each.key}"
  project         = var.project_id
  region          = "us-central1"
  source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" })
}

    Wenn im Stammmodul Ihrer Konfiguration Variablen deklariert sind, können sie zugewiesene Werte in vielerlei Hinsicht nutzen. Beispiel:

    terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"

  • Secret Manager-Connector verwenden um URLs sicher in Secret Manager zu speichern und abzurufen.

Verschachtelte Schritte verwenden

Jeder Workflow muss mindestens einen Schritt enthalten. Standardmäßig werden Schritte in Workflows so behandelt, als wären sie geordnet und führt sie nacheinander aus, bis alle Schritte ausgeführt wurden. Logischerweise sollten einige Schritte gruppiert werden. Mit einem steps-Block können Sie eine Reihe von Schritten verschachteln. Das ist praktisch, da Sie so auf den richtigen atomaren Schritt verweisen können, um eine Reihe von Schritten zu verarbeiten.

Beispiel

main:
    params: [input]
    steps:
    - callWikipedia:
        steps:
        - checkSearchTermInInput:
            switch:
                - condition: ${"searchTerm" in input}
                  assign:
                    - searchTerm: ${input.searchTerm}
                  next: readWikipedia
        - getCurrentDate:
            call: http.get
            args:
                url: https://timeapi.io/api/Time/current/zone?timeZone=Europe/Amsterdam
            result: currentDate
        - setFromCallResult:
            assign:
                - searchTerm: ${currentDate.body.dayOfWeek}
        - readWikipedia:
            call: http.get
            args:
                url: https://en.wikipedia.org/w/api.php
                query:
                    action: opensearch
                    search: ${searchTerm}
            result: wikiResult
    - returnOutput:
            return: ${wikiResult.body[1]}

Ausdrücke umbrechen

Alle expressions müssen mit beginnen $ und in geschweiften Klammern eingeschlossen:

${EXPRESSION}

Um Probleme beim YAML-Parsing zu vermeiden, können Sie Ausdrücke in Anführungszeichen setzen. Beispielsweise können Ausdrücke mit Doppelpunkten zu unerwartetem Verhalten führen, wenn der Doppelpunkt als Definition einer Zuordnung interpretiert wird. Sie können dieses Problem beheben, indem Sie den YAML-Ausdruck in einfache Anführungszeichen setzen:

'${"Name: " + myVar}'

Sie können auch Ausdrücke verwenden, die mehrere Zeilen umfassen. Beispielsweise müssen Sie eine SQL-Abfrage in Anführungszeichen setzen, wenn Sie den BigQuery-Connector für Workflows verwenden.

Beispiel

- runQuery:
    call: googleapis.bigquery.v2.jobs.query
    args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        body:
            useLegacySql: false
            useQueryCache: false
            timeoutMs: 30000
            # Find top 100 titles with most views on Wikipedia
            query: ${
                "SELECT TITLE, SUM(views)
                FROM `bigquery-samples.wikipedia_pageviews." + table + "`
                WHERE LENGTH(TITLE) > 10
                GROUP BY TITLE
                ORDER BY SUM(VIEWS) DESC
                LIMIT 100"
                }
    result: queryResult

Die vollständige Workflowdefinition finden Sie unter Mehrere BigQuery-Jobs parallel ausführen.

Deklarative Aufrufe verwenden

Verwenden Sie Workflows, um Services direkt aus dem Workflow heraus aufzurufen und und einfache Aufgaben wie einen HTTP-Aufruf ausführen. Arbeitsabläufe kann Dienste aufrufen, Antworten parsen Eingaben für andere verbundene Dienste erstellen Durch das Aufrufen eines Dienstes vermeiden Sie die Komplikationen zusätzlicher Aufrufe, zusätzliche Abhängigkeiten und Dienste, die Dienste aufrufen. Ersetzen Sie sie ggf. Dienste ohne Geschäftslogik mit deklarativen API-Aufrufen und Workflows abstrahieren, um Komplexität zu überwinden

Sie sollten jedoch Dienste erstellen, um Aufgaben auszuführen, die für Workflows zu komplex sind. Dazu gehören beispielsweise die Implementierung wiederverwendbarer Geschäftslogik, komplexer Berechnungen oder Transformationen, die von Workflow-Ausdrücken und der Standardbibliothek nicht unterstützt werden. Komplizierte Fälle lassen sich in der Regel einfacher in Code implementieren, YAML oder JSON und die Workflow-Syntax.

Nur das speichern, was du brauchst

Halten Sie den Speicherverbrauch unter Kontrolle, damit Sie Ressourcenlimits oder ein Fehler, der z. B. ResourceLimitError, MemoryLimitExceededError oder ResultSizeLimitExceededError

Wählen Sie sorgfältig aus, was Sie speichern. Variablen festlegen, indem Sie nach und und speichern Sie nur das, was Sie brauchen. Gibt ein Dienst eine zu große Nutzlast zurück, verwenden Sie eine separate Funktion, um den Aufruf für Sie zu starten und nur das zurückzugeben, was erforderlich ist.

Sie können Speicherplatz freigeben, indem Sie Variablen löschen. Zum Beispiel möchten Sie vielleicht der für die nachfolgenden Schritte benötigt wird. Oder Sie haben Anrufe mit Ergebnisse, die Ihnen nicht wichtig sind, und können diese Ergebnisse ganz weglassen.

Sie können eine Variable löschen, indem Sie null zuweisen. In YAML können Sie einer Variablen auch einen leeren Wert oder ~ zuweisen. So wird Speicherplatz ermittelt, der sicher wiederverwendet werden kann.

Beispiel

  - step:
      assign:
        - bigVar:

Untergeordnete und externe Workflows verwenden

Mit untergeordneten Workflows können Sie eine Logik oder eine Reihe von Schritten definieren, die Sie mehrmals aufrufen möchten. So wird die Workflowdefinition vereinfacht. Untergeordnete Workflows ähneln einer Funktion oder Routine in einer Programmiersprache. Sie können Parameter akzeptieren und Werte zurückgeben, und so komplexere Workflows mit einer größeren Palette von Anwendungen erstellen können.

Untergeordnete Workflows sind lokal für Ihre Workflowdefinition und können nicht in anderen Workflows wiederverwendet werden. Sie können jedoch Anruf-Workflows aus anderen Workflows. Die Workflows-Connectors können Ihnen dabei helfen. Weitere Informationen finden Sie in den Connector-Übersichten für die Workflow Executions API und der Workflows API.

Workflows-Connectors verwenden

Workflows bietet eine Reihe von Connectors, um auf andere Google Cloud-Produkte in einem Workflow zuzugreifen. Connectors vereinfachen den Aufruf von Diensten, da sie die Formatierung von Anfragen für Sie verarbeiten und Methoden und Argumente bereitstellen. Sie müssen also die Details einer Google Cloud API nicht kennen. Connectors haben auch ein integriertes Verhalten für die Verarbeitung Wiederholungen und lang andauernden Vorgängen Iteration und das Warten auf den Abschluss von Aufrufen; Connectors erledigen das für Sie.

Wenn Sie eine Google Cloud API aufrufen müssen, prüfen Sie zuerst, Workflows-Connector dafür ist vorhanden. Wenn Sie keine für ein Google Cloud-Produkt haben, können Sie anfordern.

Informationen zur Verwendung eines Connectors und eine detaillierte Referenz zu den verfügbaren Connectors finden Sie in der Referenz zu Connectors.

Workflowschritte parallel ausführen

Workflows können Schritte sequenziell ausführen, Sie können aber auch unabhängige Schritte parallel ausführen. In einigen Fällen kann dies die Ausführung des Workflows erheblich beschleunigen. Weitere Informationen finden Sie unter Workflowschritte parallel ausführen.

Wiederholungsversuche und das Saga-Muster anwenden

Gestalten Sie Workflows, die stabil sind und sowohl vorübergehende als auch dauerhafte Daten verarbeiten können. Störungen. Fehler für Workflows können beispielsweise durch fehlgeschlagene HTTP-Anfragen, Funktionen, Connectors oder durch Ihren eigenen Workflowcode verursacht werden. Fügen Sie eine Fehlerbehandlung und Wiederholungen hinzu, damit ein Fehler bei einem Schritt nicht zum Absturz des gesamten Workflows führt.

Einige Geschäftstransaktionen umfassen mehrere Dienste. Daher benötigen Sie einen Mechanismus, um Transaktionen zu implementieren, die mehrere Dienste umfassen. Das Design der Saga ist eine Möglichkeit, Datenkonsistenz in Mikrodiensten in verteilten Transaktionsszenarien zu verwalten. Eine Saga ist eine Abfolge von Transaktionen, bei der für jede Transaktion und die die nächste Transaktion auslöst. Wenn eine Transaktion fehlschlägt, führt die Saga Ausgleichstransaktionen aus, die die vorherigen Fehler in der Sequenz rückgängig machen. Sehen Sie sich die Anleitung zu Wiederholungen und dem Saga-Muster in Workflows auf GitHub an.

Rückrufe zum Warten verwenden

Workflow zum Zulassen von Callbacks mit denen darauf gewartet wird, dass ein anderer Dienst eine Anfrage an den Callback-Endpunkt; setzt diese Anfrage die Ausführung des Workflows fort.

Mit Callbacks können Sie Ihrem Workflow signalisieren, dass ein bestimmtes Ereignis aufgetreten ist, und auf dieses Ereignis ohne Abfrage warten. Sie können beispielsweise einen Workflow erstellen, der Sie benachrichtigt, wenn ein Produkt wieder verfügbar ist. auf Lager oder wenn ein Artikel versendet wurde; oder dass wartet darauf, dass menschliche Interaktionen z. B. um einen Auftrag oder eine Übersetzung zu überprüfen. Sie können auch mithilfe von Rückrufen und Eventarc-Triggern auf Ereignisse warten.

Langlaufende Jobs orchestrieren

Wenn Sie langlaufende Batchverarbeitungen ausführen müssen, können Sie Batch oder Cloud Run-Jobs verwenden. Mit Workflows können Sie die Dienste verwalten. So können Sie sowie die effiziente Bereitstellung und Orchestrierung des gesamten Prozesses.

Batch ist ein vollständig verwalteter Dienst, mit dem Sie Batcharbeitslasten auf Compute Engine-VM-Instanzen planen, in die Warteschlange stellen und ausführen können. Sie können den Workflows-Connector für Batch verwenden, um einen Batchjob zu planen und auszuführen. Weitere Informationen erhalten Sie Anleitung.

Cloud Run-Jobs werden verwendet, um Code auszuführen, der eine Arbeit ausführt (einen Job) und nach Abschluss der Arbeit beendet wird. Mit Workflows können Sie Cloud Run-Jobs als Teil eines Workflows ausführen, um eine komplexere Datenverarbeitung durchzuführen oder ein System vorhandener Jobs zu orchestrieren. Sehen Sie sich die Anleitung an, in der gezeigt wird, wie Sie mit Workflows einen Cloud Run-Job ausführen.

Lang andauernde Aufgaben containerisieren

Sie können die Ausführung eines Containers mit langer Laufzeit automatisieren, Workflows und Compute Engine. Sie können beispielsweise eine langlaufende Aufgabe containerisieren, damit sie überall ausgeführt werden kann, und den Container dann für die maximale Dauer einer Workflowausführung (ein Jahr) auf einer Compute Engine-VM ausführen.

Mit Workflows können Sie die Erstellung der VM, der das Ausführen des Containers auf der VM und das Löschen der VM. So können Sie einen Server verwenden und einen Container ausführen, aber abstrahiert die Komplexität von und kann hilfreich sein, wenn Sie bei der Nutzung z. B. Cloud Run-Funktionen oder Cloud Run. Sehen Sie sich die Anleitung Langlaufende Container mit Workflows und Compute Engine auf GitHub an.

Befehlszeilentools über Workflows ausführen

Cloud Build ist ein Dienst, der Ihre Builds in Google Cloud als eine Reihe von Build-Schritten ausführt, wobei jeder Build-Schritt in einem Docker-Container ausgeführt wird. Build-Schritte werden genauso wie Befehle in einem Skript aufgerufen.

Die Google Cloud CLI enthält die Befehlszeilentools gcloud, bq und kubectl. Es gibt jedoch keine direkte Möglichkeit, gcloud CLI-Befehle aus Workflows auszuführen. Cloud Build stellt Container-Images bereit, die die gcloud CLI enthalten. Sie können gcloud-Befehle in diesen Containern über einen Cloud Build-Schritt ausführen. Diesen Schritt können Sie in Workflows mit dem Cloud Build-Connector erstellen.

Beispiel

gcloud in einem Workflow ausführen:

# This example shows how to execute gcloud commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: gcloud
      args:
          args: "workflows list"
      result: result
  - return_result:
      return: ${result}

gcloud:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/google.com/cloudsdktool/cloud-sdk
            entrypoint: /bin/bash
            args: ${["-c", "gcloud " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Run kubectl in a workflow:

# This example shows how to execute kubectl commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: kubectl
      args:
          args: "--help"
      result: result
  - return_result:
      return: ${result}

kubectl:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/cloud-builders/kubectl
            entrypoint: /bin/bash
            args: ${["-c", "kubectl " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Workflow mit Terraform erstellen

Terraform ist ein IaC-Tool (Infrastruktur als Code), mit dem Sie die Cloud-Infrastruktur mithilfe von Code vorhersehbar erstellen, ändern und verbessern können.

Sie können einen Workflow mithilfe von Terraform definieren und bereitstellen. google_workflows_workflow . Weitere Informationen finden Sie unter Workflow mit Terraform erstellen

Um Sie bei der Verwaltung und Pflege großer Workflows zu unterstützen, können Sie Ihren Workflow erstellen. in einer separaten YAML-Datei erstellen und diese Datei mithilfe der templatefile-Funktion die eine Datei in einem bestimmten Pfad liest und ihren Inhalt als Vorlage rendert.

Beispiel

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow YAML file
    source_contents = templatefile("${path.module}/workflow.yaml",{})
  }

Wenn Sie einen Haupt-Workflow haben, der mehrere untergeordnete Workflows aufruft, können Sie den Haupt-Workflow und die untergeordneten Workflows in separaten Dateien definieren und sie mit der Funktion templatefile importieren.

Beispiel

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow and subworkflow YAML files
    source_contents = join("", [
      templatefile(
        "${path.module}/workflow.yaml",{}
      ),

      templatefile(
        "${path.module}/subworkflow.yaml",{}
      )])
  }

Wenn Sie beim Debuggen eines Workflows auf Zeilennummern verweisen, werden alle über die Terraform-Konfigurationsdatei importierten YAML-Dateien zusammengeführt und als einzelner Workflow bereitgestellt.

Workflow aus einem Git-Repository bereitstellen

Cloud Build verwendet Trigger erstellen, um die CI/CD-Automatisierung zu aktivieren Sie können Konfigurieren Sie Trigger, um eingehende Ereignisse zu erfassen, z. B. wenn ein neuer Commit ausgeführt wird. an ein Repository gesendet oder eine Pull-Anfrage initiiert wird. automatisch einen Build ausführen, wenn neue Ereignisse eingehen.

Mit einem Cloud Build-Trigger können Sie einen Build automatisch starten und einen Workflow aus einem Git-Repository bereitstellen. Sie können den Trigger so konfigurieren, dass er Ihren Workflow bei allen Änderungen am Quell-Repository oder nur bei Änderungen, die bestimmte Kriterien erfüllen, bereitstellt.

Dieser Ansatz kann Ihnen bei der Verwaltung Ihres Bereitstellungszyklus helfen. Zum Beispiel haben Sie kann Änderungen an einem Workflow in einer Staging-Umgebung bereitstellen, Tests für und diese Änderungen schrittweise in den der Produktionsumgebung. Weitere Informationen finden Sie unter Workflow aus einem Git-Repository mit Cloud Build bereitstellen

Nutzung optimieren

Die Kosten für die Ausführung eines Workflows sind minimal. Bei hohen Volumennutzung zu erhöhen, wenden Sie die folgenden Richtlinien an, um die Nutzung zu optimieren und die Kosten zu senken:

  • Verwenden Sie anstelle von benutzerdefinierten Domains *.appspot.com, *.cloud.goog, *.cloudfunctions.net oder *.run.app für alle Aufrufe von Google Cloud-Diensten, damit Ihnen nur interne und keine externen Schritte in Rechnung gestellt werden.

  • Wenden Sie eine benutzerdefinierte Wiederholungsrichtlinie an, die Ihre Anforderungen an Latenz und Zuverlässigkeit mit den Kosten in Einklang bringt. Häufigere Wiederholungen verringern die Latenz und erhöhen die Zuverlässigkeit, können aber auch die Kosten erhöhen.

  • Wenn Sie Connectors verwenden, die auf Vorgänge mit langer Ausführungszeit warten, legen Sie eine benutzerdefinierte Abfragerichtlinie zur Kostenoptimierung der Latenz. Wenn Sie beispielsweise davon ausgehen, dass ein Vorgang länger als eine Stunde dauert, können Sie eine Richtlinie festlegen, die bei einem sofortigen Fehler zuerst nach einer Minute und dann alle 15 Minuten eine Abfrage durchführt.

  • Aufgaben in einem Schritt kombinieren

  • Vermeiden Sie die übermäßige Verwendung von sys.log Schritten. Sie können stattdessen Anrufprotokolle verwenden.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die allgemeinen Tipps und Best Practices in diesem Dokument.

Allgemeine Tipps
Best Practices

Nächste Schritte