Den Workload verstehen

Um das Framework anwenden zu können, sollten Sie zunächst die Arbeitslast verstehen, die Sie analysieren möchten. Ein Systemarchitekturdiagramm bietet einen Ausgangspunkt für die Dokumentation der wichtigsten Details des Systems. Der Versuch, eine gesamte Arbeitslast zu analysieren, kann jedoch komplex sein, da viele Systeme aus zahlreichen Komponenten und Interaktionen bestehen. Stattdessen empfehlen wir, dass Sie sich auf User Stories konzentrieren, bei denen es sich um informelle, allgemeine Erklärungen von Softwarefunktionen handelt, die aus der Sicht des Endbenutzers verfasst wurden. Sie sollen verdeutlichen, wie eine Softwarefunktion dem Kunden einen Mehrwert bietet. Anschließend können Sie diese Anwenderberichte mit Architektur- und Datenflussdiagrammen modellieren, um die Bewertung der technischen Komponenten zu erleichtern, die die beschriebene Geschäftsfunktionalität bereitstellen. Eine In-App-Kauflösung für Handyspiele könnte beispielsweise zwei User Stories enthalten: „In-App-Credits kaufen“ und „In-App-Rückerstattungen erhalten“, wie in der folgenden Abbildung dargestellt. (Diese Beispielarchitektur verdeutlicht, wie Sie ein System in User Storys zerlegen können. Sie ist nicht dazu gedacht, eine äußerst robuste Anwendung darzustellen.)

Jede User Story besteht aus vier gemeinsamen Komponenten: Code und Konfiguration, Infrastruktur, Datenspeicher und externe Abhängigkeiten. Ihre Diagramme sollten all diese Komponenten enthalten und die Interaktionen zwischen den Komponenten widerspiegeln. Wenn beispielsweise Ihr Amazon API Gateway Gateway-Endpunkt überlastet ist, sollten Sie sich überlegen, wie sich diese Last auf andere Komponenten im System überträgt, z. B. auf Ihre AWS Lambda Funktionen oder Amazon DynamoDB-Tabellen. Wenn Sie diese Interaktionen verfolgen, können Sie besser verstehen, wie sich der Fehlermodus auf die User Story auswirken kann. Sie können diesen Fluss visuell mit einem Datenflussdiagramm oder mithilfe einfacher Flusspfeile in einem Architekturdiagramm erfassen, wie in der vorherigen Abbildung. Erwägen Sie, für jede Komponente Details zu erfassen, z. B. die Art der übertragenen Informationen, die empfangenen Informationen, ob die Kommunikation synchron oder asynchron ist und welche Fehlergrenzen überschritten werden. In diesem Beispiel werden die DynamoDB-Tabellen in beiden User Storys gemeinsam genutzt, wie Sie anhand der Pfeile sehen können, die angeben, dass die Lambda-Komponente in der In-App-Rückerstattungsstory auf die DynamoDB-Tabellen in der In-App-Kaufstory zugreift. Das bedeutet, dass ein Fehler, der durch die Benutzerstory zum In-App-Kauf verursacht wird, aufgrund eines gemeinsamen Schicksals zur User Story mit In-App-Rückerstattungen führen kann.

Darüber hinaus ist es wichtig, die Basiskonfiguration für jede Komponente zu verstehen. Die Basiskonfiguration identifiziert Einschränkungen wie die durchschnittliche und maximale Anzahl von Transaktionen pro Sekunde, die maximale Größe einer Nutzlast, ein Client-Timeout und standardmäßige oder aktuelle Dienstkontingente für die Ressource. Wenn Sie einen neuen Entwurf modellieren, empfehlen wir Ihnen, die funktionalen Anforderungen für den Entwurf zu dokumentieren und die Grenzen zu berücksichtigen. Dies hilft Ihnen zu verstehen, wie sich Fehlermodi in der Komponente manifestieren können.

Schließlich sollten Sie User Stories auf der Grundlage des geschäftlichen Nutzens, den sie bieten, priorisieren. Diese Priorisierung hilft Ihnen, sich zunächst auf die wichtigsten Funktionen Ihres Workloads zu konzentrieren. Anschließend können Sie Ihre Analyse auf die Workload-Komponenten konzentrieren, die Teil des kritischen Pfads für diese Funktionalität sind, und so schneller den Nutzen aus der Nutzung des Frameworks ziehen. Während Sie den Prozess durchlaufen, können Sie weitere User Stories mit unterschiedlichen Prioritäten untersuchen.