SLOs messen

Last reviewed 2024-03-29 UTC

Dieses Dokument im Google Cloud Architecture Framework baut auf den vorangegangenen Diskussionen über Service Level Objectives (SLOs) auf, indem es das „Was“ und „Wie“ der Messung in Bezug auf gängige Dienstarbeitslasten untersucht. Dieses Dokument basiert auf den Konzepten, die unter Komponenten von Service Level Objectives definiert sind.

Entscheiden, was gemessen werden soll

Unabhängig von Ihrer Domain haben viele Dienste die gleichen gängigen Features und können generische SLOs verwenden. In diesem Abschnitt werden allgemeine SLOs für verschiedene Arten von Diensten erörtert und die SLIs, die für jede SLO gelten, ausführlich erläutert.

In jedem der folgenden Unterabschnitte wird ein bestimmter Diensttyp beschrieben und es wird eine kurze Beschreibung dieses Dienstes angegeben. Unter jedem Diensttyp sind dann mögliche SLIs, eine Definition des Indikators und andere Informationen zum SLI aufgeführt.

Anfragengesteuerte Dienste

Dieser Diensttyp empfängt eine Anfrage von einem Client (einem Nutzer oder einem anderen Dienst), führt eine Berechnung durch, sendet möglicherweise Netzwerkanfragen an ein Back-End und gibt dann eine Antwort an den Client zurück.

Verfügbarkeit als SLI

Verfügbarkeit ist der Anteil der gültigen Anfragen, die erfolgreich verarbeitet werden. Die folgende Liste enthält Informationen, die bei der Verwendung der Verfügbarkeit als SLI zu berücksichtigen sind:

  • Als Dienstinhaber entscheiden Sie, was eine gültige Anfrage ist. Gängige Definitionen sind z. B. nicht die Länge null oder entspricht einem Client-Server-Protokoll. Eine Methode zum Beurteilen der Gültigkeit ist die Prüfung von HTTP- oder RPC-Antwortcodes. Beispielsweise sind HTTP 5xx-Codes serverbezogene Fehler, die auf ein SLO angerechnet werden, während 4xx-Codes Clientfehler sind, die nicht gezählt werden.
  • Jeder von Ihrem Dienst zurückgegebene Antwortcode muss überprüft werden, um sicherzustellen, dass die Anwendung diese Codes richtig und konsistent verwendet. Ist der Code ein genauer Indikator für die Erfahrung Ihrer Nutzer mit dem Dienst? Wie reagiert eine E-Commerce-Website beispielsweise, wenn ein Nutzer versucht, einen Artikel zu bestellen, der nicht auf Lager ist? Schlägt die Anfrage fehl und gibt eine Fehlermeldung zurück? Werden auf der Website ähnliche Produkte vorgeschlagen? Fehlercodes müssen an die Nutzererwartungen gebunden sein.
  • Entwickler können Fehler versehentlich missbrauchen. Bei Verwendung des Szenarios out-of-stock aus dem vorherigen Eintrag kann ein Entwickler fälschlicherweise einen Fehler zurückgeben. Das System funktioniert jedoch ordnungsgemäß und ist nicht fehlerhaft. Es muss ein Fehlercode zurückgegeben werden, obwohl der Nutzer den Artikel nicht kaufen konnte. Dienstinhaber sollten zwar über den geringen Bestand informiert werden, die Tatsache, dass ein Kauf nicht abgeschlossen werden kann, ist jedoch aus Kundensicht kein Fehler und wird nicht auf ein SLO angerechnet.
  • Ein Beispiel für einen komplexeren Dienst ist ein Dienst, der asynchrone Anfragen verarbeitet oder Kunden einen lang andauernden Prozess bietet. Sie können die Verfügbarkeit zwar auch auf andere Weise angeben, wir empfehlen jedoch, die Verfügbarkeit als Anteil der gültigen Anfragen darzustellen, die erfolgreich sind. Die Verfügbarkeit kann auch als die Anzahl der Minuten definiert werden, die die Arbeitslast eines Kunden ausgeführt wird (manchmal auch als gute Minuten-Ansatz bezeichnet).
  • Betrachten wir einen Dienst, der virtuelle Maschinen (VMs) anbietet. Sie können die Verfügbarkeit als Anzahl der Minuten nach einer ersten Anfrage messen, in denen die VM für den Nutzer verfügbar ist.

Latenz als SLI

Latenz (oder Geschwindigkeit) ist der Anteil gültiger Anfragen, die schneller als ein Schwellenwert verarbeitet werden. Die Latenz gibt also die Geschwindigkeit des Dienstes an und kann durch Berechnung der Differenz zwischen der Start- und Stoppzeit für einen bestimmten Anfragetyp gemessen werden. Denken Sie daran, dass dies die Wahrnehmung der Latenz durch den Nutzer ist. Dienstinhaber messen diesen Wert im Allgemeinen zu genau. Tatsächlich können Nutzer nicht zwischen einer Aktualisierung von 100 Millisekunden (ms) und einer Aktualisierung von 300 ms unterscheiden und akzeptieren möglicherweise sogar Antworten zwischen 300 ms und 1.000 ms wie gewohnt. Weitere Informationen finden Sie unter Rail-Modell.

Entwickeln Sie aktivitätsbezogene Messwerte, die sich auf den Nutzer konzentrieren. Im Folgenden finden Sie einige Beispiele für solche Messwerte:

  • Interaktiv: Ein Nutzer wartet nach dem Klicken auf ein Element 1.000 ms auf ein Ergebnis.
  • Schreiben: Eine Änderung an einem zugrunde liegenden verteilten System dauert 1.500 ms. Diese Zeitspanne gilt zwar als langsam, wird aber von Nutzern tendenziell akzeptiert. Wir empfehlen Ihnen, bei den Messwerten explizit zwischen Schreib- und Lesevorgängen zu unterscheiden.
  • Hintergrund: Aktionen, die für den Nutzer nicht sichtbar sind, z. B. eine regelmäßige Aktualisierung von Daten oder andere asynchrone Anfragen, dauern nicht mehr als 5.000 ms.

Die Latenz wird allgemein als Verteilung gemessen und wie unter SLIs auswählen beschrieben. Bei einer Verteilung können Sie verschiedene Perzentile messen. Sie können beispielsweise die Anzahl der Anfragen messen, die langsamer als das frühere 99. Perzentil sind. Ereignisse, die schneller als dieser Schwellenwert sind, werden als gut eingestuft; langsamere Anfragen werden als nicht so gut eingestuft. Dieser Schwellenwert richtet sich nach den Produktanforderungen. Sie können sogar SLOs mit mehreren Latenzen festlegen, z. B. die typische Latenz im Vergleich zur Extremwertlatenz.

Verwenden Sie nicht nur die durchschnittliche Latenz oder Medianlatenz als SLI. Wenn die Medianlatenz zu langsam ist, ist bereits die Hälfte Ihrer Nutzer unzufrieden. Außerdem kann die Latenz Ihres Dienstes mehrere Tage lang zu hoch sein, bevor Sie das Problem entdecken. Definieren Sie daher Ihr SLO für die Extremwertlatenz (95. Perzentil) und für die Medianlatenz (50. Perzentil).

Im ACM-Artikel Metrics That Matter schreibt Benjamin Treynor Sloss Folgendes:

  • „Eine gute praktische Faustregel ... ist: Die Latenz des 99. Perzentils sollte nicht mehr als das Drei- bis Fünffache der Medianlatenz betragen.“
  • „Wir halten die Latenzmesswerte für das 50., 95. und 99. Perzentil eines Dienstes alle für wertvoll und legen daher idealerweise SLOs für jeden der Werte fest.“

Bestimmen Sie Ihre Latenzschwellenwerte basierend auf historischen Perzentilen und messen Sie dann, wie viele Anfragen in jedem Bucket landen. Dieser Ansatz ist ein gutes Modell.

Qualität als SLI

Qualität ist der Anteil gültiger Anfragen, die ohne Beeinträchtigung des Dienstes verarbeitet werden. Beispielsweise ist Qualität ein hilfreicher SLI für komplexe Dienste, die so konzipiert sind, dass sie ordnungsgemäß fehlschlagen. Stellen Sie sich zur Veranschaulichung eine Webseite vor, die ihren Hauptinhalt aus einem Datenspeicher und optionale Assets aus 100 anderen Diensten und Datenspeichern lädt. Wenn eines der optionalen Elemente außer Betrieb oder zu langsam ist, wird die Seite trotzdem ohne die optionalen Elemente gerendert. In diesem Szenario können Sie SLIs für Folgendes verwenden:

  • Indem Sie die Anzahl der Anfragen messen, die eine eingeschränkte Antwort erhalten (eine Antwort, bei der eine Antwort von mindestens einem Back-End-Dienst fehlt), können Sie sich das Verhältnis der fehlerhaften Anfragen anzeigen lassen.
  • Sie können die Anzahl der Antworten verfolgen, denen eine Antwort von einem einzelnen Back-End oder mehreren Back-Ends fehlt.

Datenverarbeitungsdienste

Diese Dienste nehmen Daten aus einer Eingabe auf, verarbeiten diese Daten und generieren eine Ausgabe. Die Leistung des Dienstes bei Zwischenschritten ist nicht so wichtig wie das Endergebnis. Die besten SLIs sind Aktualität, Abdeckung, Richtigkeit und Durchsatz. Latenz und Verfügbarkeit sind weniger nützlich.

Aktualität als SLI

Aktualität ist der Anteil der gültigen Daten, die vor einem Schwellenwert aktualisiert wurden. Folgende Liste enthält einige Beispiele für die Verwendung der Aktualität als SLI:

  • In einem Batchsystem wird die Aktualität als die Zeit gemessen, die während eines erfolgreich abgeschlossenen Verarbeitungslaufs für eine bestimmte Ausgabe verstrichen ist.
  • Bei der Echtzeitverarbeitung oder in komplexeren Systemen erfasst die Aktualität das Alter des zuletzt in einer Pipeline verarbeiteten Datensatzes.
  • In einem Onlinespiel, das Kartenkacheln in Echtzeit generiert, bemerken Nutzer möglicherweise nicht, wie schnell Kartenkacheln erstellt werden, aber sie bemerken vielleicht, wenn Kartendaten fehlen oder nicht aktuell sind. In diesem Fall erfasst die Aktualität fehlende oder veraltete Daten.
  • Bei einem Dienst, der Datensätze aus einem Tracking-System ausliest, um die Meldung „X Artikel auf Lager“ für eine E-Commerce-Website zu generieren, könnte ein Aktualitäts-SLI als der Prozentsatz der Anfragen definiert werden, die kürzlich (innerhalb der letzten Minute) aktualisierte Bestandsinformationen verwenden.
  • Sie können auch einen Messwert für die Bereitstellung nicht aktueller Daten verwenden, um den SLI für Qualität zu informieren.

Abdeckung als SLI

Die Abdeckung ist der Anteil der gültigen Daten, die erfolgreich verarbeitet wurden.

So definieren Sie die Abdeckung:

  1. Legen Sie fest, ob eine Eingabe als gültig akzeptiert oder übersprungen werden soll. Wenn ein Eingabedatensatz beispielsweise beschädigt ist oder die Länge null hat und nicht verarbeitet werden kann, können Sie diesen Datensatz als Messwert als ungültig betrachten.
  2. Zählen Sie die Anzahl der gültigen Datensätze. Diese Zählung kann mit einer einfachen *count()-*-Methode erfolgen. Sie stellt die Gesamtzahl der Datensätze dar.
  3. Zählen Sie abschließend die Anzahl der erfolgreich verarbeiteten Datensätze und vergleichen Sie diese Anzahl mit der Gesamtzahl der gültigen Datensätze. Dieser Wert ist Ihr SLI für die Abdeckung.

Richtigkeit als SLI

Die Richtigkeit ist der Anteil gültiger Daten, die eine korrekte Ausgabe erzeugt haben. Beachten Sie bei der Verwendung von Richtigkeit als SLI die folgenden Punkte:

  • In manchen Fällen werden die Methoden zum Bestimmen der Richtigkeit einer Ausgabe verwendet, um die Ausgabeverarbeitung zu prüfen. Beispielsweise sollte ein System, das ein Bild rotiert oder einfärbt, niemals ein Null-Byte-Bild oder ein Bild mit einer Länge oder Breite von null erzeugen. Es ist wichtig, diese Validierungslogik von der Verarbeitungslogik selbst zu trennen.
  • Eine Methode zum Messen eines Richtigkeits-SLI ist die Verwendung als funktionierend bekannte Testeingabedaten. Diese Art von Daten sind Daten, die eine bekannte korrekte Ausgabe erzeugen. Denken Sie daran, dass Eingabedaten repräsentativ für Nutzerdaten sein müssen.
  • In anderen Fällen ist es möglich, eine mathematische oder logische Prüfung der Ausgabe durchzuführen, wie im vorherigen Beispiel, bei dem ein Bild gedreht wurde.
  • Betrachten wir schließlich ein Abrechnungssystem, das die Transaktionsgültigkeit bestimmt, indem die Differenz zwischen dem Kontostand vor und nach einer Transaktion geprüft wird. Wenn dieser Wert mit dem Wert der Transaktion selbst übereinstimmt, handelt es sich um eine gültige Transaktion.

Durchsatz als SLI

Der Durchsatz ist der Anteil der Zeit, in der die Datenverarbeitungsrate über dem Schwellenwert lag. Hier sind einige Punkte, die bei der Verwendung des Durchsatzes als SLI zu berücksichtigen sind:

  • Der Durchsatz in einem Datenverarbeitungssystem ist häufig repräsentativer für die Zufriedenheit der Nutzer als eine einzelne Latenzmessung für einen bestimmten Vorgang. Wenn die Größe jeder Eingabe stark variiert, ist es möglicherweise nicht sinnvoll, die Ausführungszeit der einzelnen Elemente zu vergleichen (wenn alle Jobs mit einer akzeptablen Geschwindigkeit ausgeführt werden).
  • Byte pro Sekunde ist eine gängige Methode, um den Arbeitsaufwand für das Verarbeiten von Daten unabhängig von der Größe des Datasets zu messen. Aber jeder Messwert, der in Bezug auf die Verarbeitungskosten ungefähr linear skaliert wird, ist geeignet.
  • Es kann sich lohnen, Datenverarbeitungssysteme anhand der erwarteten Durchsatzraten zu partitionieren. Sie können auch ein Dienstqualitätssystem implementieren, das dafür sorgt, dass Eingaben mit hoher Priorität verarbeitet und Eingaben mit niedriger Priorität in die Warteschlange gestellt werden. In jedem Fall können Sie durch das Messen des Durchsatzes auf die in diesem Abschnitt beschriebene Weise feststellen, ob Ihr System gemäß dem SLO funktioniert.

Dienste mit geplanter Ausführung

Für Dienste, die in regelmäßigen Abständen eine Aktion ausführen müssen, z. B. Kubernetes-Cronjobs, können Sie die Verzerrung und die Ausführungsdauer messen. Im Folgenden finden Sie ein Beispiel für einen geplanten Kubernetes-Cronjob:

  apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
  name: hello
  spec:

  schedule: "0 * * * *"

Verzerrung als SLI

Abweichung: Der Anteil der Ausführungen, die innerhalb eines akzeptablen Zeitfensters vor oder nach der erwarteten Startzeit beginnen Beachten Sie bei der Verwendung von Abweichungen Folgendes:

  • Die Verzerrung misst die Zeitdifferenz zwischen dem planmäßigen Start eines Jobs und der tatsächlichen Startzeit. Betrachten Sie das vorherige Beispiel für einen Kubernetes-Cronjob. Wenn er so eingestellt ist, dass er bei Minute Null jeder Stunde beginnt, aber um drei Minuten nach der vollen Stunde startet, beträgt die Abweichung drei Minuten. Wenn ein Job zu früh ausgeführt wird, kommt es zu einer negativen Verzerrung.
  • Sie können messen, wie sich die Verzerrung im Laufe der Zeit entwickelt, indem sie entsprechende akzeptable Bereiche festlegen, die eine gute Verzerrung definieren. Vergleichen Sie zum Ermitteln des SLI die Anzahl der Ausführungen, die innerhalb eines guten Bereichs lagen.

Ausführungsdauer als SLI

Ausführungsdauer ist der Anteil der Ausführungen, die innerhalb des zulässigen Dauerfensters abgeschlossen werden. Im Folgenden werden wichtige Konzepte zur Verwendung der Ausführungsdauer erläutert:

  • Ausführungsdauer ist die Zeit, die zum Fertigstellen eines Jobs benötigt wird. Ein häufiger Fehlermodus bei einer bestimmten Ausführung ist, wenn die tatsächliche Dauer die geplante Dauer überschreitet.
  • Ein interessanter Fall ist die Anwendung dieses SLI auf einen nie endenden Job. Da diese Jobs nicht abgeschlossen werden, erfassen Sie die für einen bestimmten Job aufgewendete Zeit, anstatt auf den Abschluss eines Jobs zu warten. Dieser Ansatz bietet eine genaue Verteilung dafür, wie lange es dauert, bis die Arbeit fertiggestellt wurde, selbst in Worst-Case-Szenarien.
  • Wie bei der Verzerrung können Sie die Verteilung der Ausführungsdauer verfolgen und akzeptable Ober- und Untergrenzen für gute Ereignisse definieren.

Messwerte für andere Systemtypen

Viele andere Arbeitslasten haben eigene Messwerte, um SLIs und SLOs zu generieren. Betrachten Sie hierzu folgende Beispiele:

  • Speichersysteme: Langlebigkeit, Durchsatz, Zeit bis zum ersten Byte, Blob-Verfügbarkeit.
  • Medien/Video: Client-Wiedergabekontinuität, Startzeit für die Wiedergabe, Vollständigkeit von Transcode-Diagrammausführungen.
  • Gaming: Zeit zum Zuordnen aktiver Spieler und Zeit für die Erstellung einer Karte.

Entscheiden, wie die Messung erfolgen soll

Im vorherigen Abschnitt geht es um die Messungen. Nachdem Sie entschieden haben, was gemessen werden soll, können Sie entscheiden, wie gemessen werden soll. Sie können SLI-Messwerte auf verschiedene Arten erfassen. In den folgenden Abschnitten werden verschiedene Messmethoden erläutert, die Methode kurz beschrieben, ihre Vor- und Nachteile aufgeführt und die geeigneten Implementierungstools für die Methode ermittelt.

Serverseitiges Logging

Bei der serverseitigen Logging-Methode werden serverseitige Logs von Anfragen oder verarbeiteten Daten verarbeitet.

Serverseitiges Logging Details
Vorteile
  • Vorhandene Logs noch einmal verarbeiten, um für historische SLI-Datensätze ein Backfill durchzuführen.
  • Verwenden Sie dienstübergreifende Sitzungs-IDs, um komplexe Kaufprozesse über mehrere Dienste hinweg zu rekonstruieren.
Nachteile
  • Anfragen, die nicht beim Server eingehen, werden nicht aufgezeichnet.
  • Anfragen, die einen Serverabsturz verursachen, werden möglicherweise nicht aufgezeichnet.
  • Die Dauer der Verarbeitung von Logs kann zu veralteten SLIs führen, deren Daten dann für eine operative Antwort möglicherweise ungeeignet sind.
  • Das Schreiben von Code in Verarbeitungslogs kann eine fehleranfällige und zeitaufwendige Aufgabe sein.
Implementierungsmethode und -tools

Anwendungsserver-Messwerte

Die Methode Anwendungsserver-Messwerte umfasst das Exportieren von SLI-Messwerten aus dem Code, der Nutzeranfragen oder deren Daten verarbeitet.

Anwendungsserver-Messwerte Details
Vorteile
  • Das Hinzufügen neuer Messwerte zum Code ist normalerweise schnell und kostengünstig
Nachteile
  • Anfragen, die die Anwendungsserver nicht erreichen, werden nicht aufgezeichnet.
  • Multidienstanfragen sind möglicherweise schwer zu verfolgen
Implementierungsmethode und -tools

Frontend-Infrastrukturmesswerte

Die Methode Fronted Infrastruktur-Messwerte verwendet Messwerte aus der Load-Balancing-Infrastruktur (z. B. ein globaler Layer-7-Load-Balancer in Google Cloud).

Messwerte für die Frontend-Infrastruktur Details
Vorteile
  • Messwerte und Verlaufsdaten sind oft bereits vorhanden, was die für den Einstieg erforderlichen Entwicklungsbemühungen verringert.
  • Die Messwerte werden an dem Punkt erhoben, der sich am nächsten am Kunden, aber noch innerhalb der Bereitstellungsinfrastruktur befindet.
Nachteile
  • Nicht für Datenverarbeitungs-SLIs geeignet
  • Kann Nutzerverhalten mit mehreren Anfragen nur näherungsweise ermitteln
Implementierungsmethode und -tools

Synthetische Clients oder Daten

Bei der Methode mit synthetischen Clients oder Daten werden Clients verwendet, die in regelmäßigen Abständen vorgefertigte Anfragen senden und die Antworten validieren.

Synthetische Clients oder Daten Details
Vorteile
  • Erstellt Messwerte für alle Schritte eines Nutzerverhaltens mit mehreren Anfragen
  • Das Senden von Anfragen von außerhalb Ihrer Infrastruktur führt zum Erfassen eines größeren Teils des gesamten Anfragepfads im SLI
Nachteile
  • Die Approximation der Nutzererfahrung mit synthetischen Anfragen kann irreführend sein (sowohl falsch positive als auch falsch negative Ergebnisse).
  • Es ist schwierig, alle seltenen Fälle abzudecken und dieser Versuch kann in Integrationstests übergehen.
  • Ziele mit hoher Zuverlässigkeit erfordern häufige Prüfungen für genaue Messwerte.
  • Der Prüfungs-Traffic kann den echten Traffic in den Hintergrund rücken.
Implementierungsmethode und -tools

Client-Instrumentierung

Die Methode Client-Instrumentierung umfasst das Hinzufügen von Beobachtbarkeitsfeatures zum Client, mit dem der Nutzer interagiert, und das Logging von Ereignissen in Ihrer Bereitstellungsinfrastruktur, die SLIs verfolgt.

Client-Instrumentierung Details
Vorteile
  • Liefert die genauesten Messwerte für die Nutzererfahrung
  • Kann die Zuverlässigkeit von Drittanbietern wie CDN oder Zahlungsdienstleistern messen.
Nachteile
  • Die Aufnahme von Clientlogs und die Verarbeitungslatenz machen diese SLIs zum Auslösen einer operativen Antwort ungeeignet.
  • SLI-Messwerte enthalten eine Reihe von sehr variablen Faktoren, die sich möglicherweise nicht direkt kontrollieren lassen.
  • Das Integrieren von Instrumentierung in den Client kann viel Entwicklungsarbeit erfordern.
Implementierungsmethode und -tools

Messmethode auswählen

Nachdem Sie entschieden haben, was und wie Ihr SLO gemessen werden soll, besteht der nächste Schritt darin, eine Messmethode zu wählen, die der Erfahrung Ihrer Kunden mit Ihrem Dienst am ehesten entspricht und Ihnen den geringsten Aufwand abverlangt. Um dieses Ideal zu erreichen, müssen Sie möglicherweise die Methoden in den vorherigen Tabellen kombinieren. Im Folgenden finden Sie Vorschläge, die Sie im Laufe der Zeit implementieren können. Die Schritte sind in der Reihenfolge des zunehmenden Aufwands aufgeführt:

  • Exporte von Anwendungsservern und Infrastrukturmesswerte verwenden. In der Regel können Sie sofort auf diese Messwerte zugreifen und sie bieten schnell einen Mehrwert. Einige APM-Tools enthalten eingebundene SLO-Tools.
  • Clientinstrumentierung verwenden. Da in Legacy-Systeme normalerweise keine Clientinstrumentierung für Endnutzer eingebunden ist, kann das Einrichten der Instrumentierung eine erhebliche Investition erfordern. Wenn Sie jedoch eine APM-Suite oder ein Frontend-Framework verwenden, das eine Clientinstrumentierung bietet, können Sie schnell einen Einblick in die Zufriedenheit Ihrer Kunden gewinnen.
  • Verwenden Sie die Logverarbeitung. Wenn Sie keine Serverexporte oder Clientinstrumentierung (vorherige Aufzählungspunkte) implementieren können, aber Logs vorhanden sind, ist die Logverarbeitung möglicherweise der beste Ansatz. Eine weitere Methode besteht darin, Exporte und Logverarbeitung zu kombinieren. Verwenden Sie Exporte als sofortige Quelle für einige SLIs (z. B. sofortige Verfügbarkeit) und die Logverarbeitung für langfristige Signale (z. B. Slow-Burn-Benachrichtigungen, die unter SLOs und Benachrichtigung erläutert werden).
  • Implementieren Sie synthetische Tests. Nachdem Sie sich ein grundlegendes Verständnis davon verschafft haben, wie die Kunden Ihren Dienst nutzen, testen Sie ihn. Sie können beispielsweise fehlerfreie Daten in Testkonten übertragen und sie abfragen. Dieser Ansatz kann hilfreich sein, um Fehlermodi hervorzuheben, die nicht ohne Weiteres beobachtet werden, z. B. bei Diensten mit geringem Traffic.

Nächste Schritte