Aushandeln realistischer Leistungsziele

Sie haben eine klare Vorstellung von der Benutzerfreundlichkeit, auf die Sie abzielen. Erstellen Sie einen Benchmark, und messen Sie den Fortschritt anhand der von Ihnen festgelegten Geschäftsanforderungen.

Aus Leistungsgründen ist es am besten, Ihren Entwurfsprozess mit klaren Leistungszielen zu starten. Um diese einzurichten, benötigen Sie ein solides Verständnis darüber, was das Unternehmen benötigt, und die Serviceebene, die von der Workload erwartet wird. Arbeiten Sie mit den Geschäftsbeteiligten zusammen, um diese Erwartungen zusammen zu definieren. Anstatt sich nur auf technische Metriken zu konzentrieren, überlegen Sie, welche Art von Auswirkungen auf die Benutzererfahrung akzeptabel ist, insbesondere für die wichtigsten Flüsse.

Hier gibt es ein bisschen eine Schleife. Sie können nicht messen, was Sie nicht definiert haben, und Sie können ohne maßlose Messungen nicht viel definieren. Deshalb ist es wichtig, die Leistung der Arbeitsauslastung nachzuverfolgen, bis jeder zustimmt, was als akzeptabler Schwellenwert gilt.

Leistungs- und Zuverlässigkeitsziele gehen hand in Hand. Beide tragen dazu bei, die Qualität des Diensts im Hinblick auf Leistung, Verfügbarkeit und Resilienz zu gestalten. Ohne eine klare Definition ist es schwierig, Warnungen zu messen, einzurichten oder Tests für die Leistung auszuführen. Nachdem Sie Ihre Ziele definiert und die tatsächlichen Zahlen durch Tests im Laufe der Zeit ermittelt haben, können Sie mit der Automatisierung von Tests beginnen, um die Überprüfung auf diese Ziele beizubehalten.

Halten Sie sich an bewährte Methoden, wenn Sie Ziele auf hoher Ebene definieren, auch wenn sie nur grobe Schätzungen oder Bereiche sind, mit denen Sie beginnen müssen.

Beispielszenario

Contoso Bicycle ist eine Direkt-to-Consumer-Fahrradmarke, die in den USA ansässig ist. Ihr Entwicklungsteam hat mit der Arbeit an einer neuen App begonnen, um den bevorstehenden Mobilen Fahrradreparaturdienst zu unterstützen. Derzeit befindet sich die App in der PoC-Phase (Proof of Concept). Techniker verwenden eine mobile App, um ihre Zeitpläne zu verarbeiten, Arbeitsaufträge zu verwalten und Zahlungen zu übernehmen. Auf der Kundenseite gibt es eine Website, auf der Personen Servicetermine buchen können. Die Web-App, die mobile App und die Back-End-API werden wahrscheinlich in Azure App Service gehostet.

Vorbereiten der Verhandlung von Leistungszielen

Um sich auf die Verhandlungen vorzubereiten, hilft es, die technischen Details wirklich zu verstehen, zu erkunden, was mit der Infrastruktur möglich ist, die Sie haben, und die Ergebnisse von praktischen Tests zu nutzen, die Sie erledigt haben. Verwenden Sie historische Daten, um Ihnen ein klareres Bild von Verwendungsmustern und derEn Engpässe zu geben. Es ist auch smart, externe Perspektiven wie Erkenntnisse aus Marktforschung, Beratung von Experten oder Anleitungen auf Der Grundlage von Branchenstandards zu gewinnen.

Sie können intelligente Entscheidungen treffen, indem Sie sich an Erkenntnissen orientieren, die von der realen Erfahrung stammen.

Leistungsziele konzentrieren sich auf die Benutzererfahrung, und sie sind geprägt von dem, was realistisch ist, was als bewährte Methode in der Branche betrachtet wird und was derzeit auf dem Markt trendig ist.

Herausforderung von Contoso

• Wenn das Team über die App mit Geschäftsbeteiligten gesprochen hat, ist die Leistung noch nicht wirklich aufgekommen.

• Das Entwicklungsteam ist neu bei Azure, daher sind sie nicht zu vertraut mit der Funktionsweise und Skalierung auf der Plattform.

• Ohne klare Richtung von Projektbeteiligten oder praktischen Erfahrungen mit dem, was Azure tun kann, ist das Team etwas nervös, dass sie die Infrastruktur für Tests bereitstellen und dann später neu erstellen müssen.

• Sie sind auch besorgt darüber, dass niemand, wenn alle aufeinander treffen, bereit sein wird, eine echte Unterhaltung darüber zu führen, wie realistische Leistungsziele aussehen sollen.

Umsetzung und Ergebnisse

• Die Analytiker und Entwickler von Contoso Bicycle sprachen über ihre Bedenken und haben einen Plan erhalten. Die Geschäftsanalysten würden die Leistungserwartungen untersuchen, indem sie eine wettbewerbsfähige Forschung und informelle Umfrage durchführen, während das Entwicklungsteam untersuchen würde, was Azure tun und die verschiedenen Preisniveaus untersuchen kann.

• Wenn die Teams wieder mit den Geschäftsbeteiligten zusammenkamen, haben sie alle gesammelten Daten mitgebracht und als Ausgangspunkt für eine echte Unterhaltung über Leistungsziele verwendet. Nachdem sie sich mit der Art der Leistung vertraut gemacht haben, die sie erwarten konnten und wie die Kosten aussehen könnten, war jeder davon überzeugt, dass App Service für die Arbeitsauslastung geeignet war.

Effektives Aushandeln von Leistungszielen

Arbeiten Sie mit den Geschäftsbesitzern zusammen, um ein klares Bild davon zu erhalten, was den Benutzern versprochen wird, insbesondere wenn es um Qualität und behördliche Anforderungen geht, die gelten könnten. Halten Sie Ihre Ansicht vorerst breit. Dies ist nicht die Zeit, um in die Details zu gelangen. Seien Sie vorab darüber informiert, was auf der Grundlage der getätigten Investitionen als akzeptable Performance zählt. Stellen Sie sicher, dass Sie das größere Geschäftsbild verstehen und wo Wachstum erwartet wird.

Mit diesem Ansatz können Sie die Annahmen klar steuern, die möglicherweise nicht mit dem, was das Unternehmen tatsächlich benötigt, in Einklang stehen. Es bringt auch mehr Klarheit und Energie für das Workload-Team.

Wenn Sie den Geschäftskontext verstehen, einschließlich funktionaler und nichtfunktionaler Anforderungen, finden Sie möglicherweise Möglichkeiten, das Design in anderen Bereichen des Azure Well-Architected Frameworks zu optimieren. Diese Art von Erkenntnissen hilft Ihnen, intelligentere Kompromisse zu schaffen.

Wenn Sie diese Parameter frühzeitig definieren, können Sie die Kosten und den Aufwand sparen, die Lösung später neu zu gestalten. Außerdem wird sichergestellt, dass Ihre Leistungsziele nicht nur heute sind. Sie sind so eingerichtet, dass sie unterstützen, wo die Arbeitsauslastung in Zukunft geleitet wird, damit Ihre aktuelle Arbeit mit langfristigen Zielen übereinstimmt.

Herausforderung von Contoso

• Das Architekturteam hat einen allgemeinen Sinn für das, was akzeptabel sein könnte, aber sie haben noch keine Besonderheiten. Sie fühlen sich ziemlich zuversichtlich, dass ihre Wahl der Anwendungsplattform ihnen helfen wird, Überarbeitungen zu vermeiden, aber sie würden viel besser fühlen, wenn sie konkretere Details haben, um weiter zu gehen.

• Bisher waren Leistungsunterhaltungen ziemlich vage, z. B. "Die Website muss schnell sein." Diese Erkenntnis ist nicht super hilfreich, wenn es darum geht, Designentscheidungen zu treffen.

• Ohne mehr Klarheit machen sich die Architekten sorgen dafür, dass sie die Lösung möglicherweise überlasten, nur um sicher zu sein, oder es treten Verzögerungen auf, die die Produktionsfreigabe zurückdrängen könnten.

Umsetzung und Ergebnisse

• Die Geschäftspartner und das technische Team kamen zusammen, um einige allgemeine, aber realistische Leistungsziele zu vereinbaren, zusammen mit einigen harten Grenzen, die unbedingt vermieden werden müssen. Mit dieser Klarheit können die Architekten im Rahmen ihrer frühen Entwurfsarbeit mit POCs vorankommen. Dies gibt ihnen die Möglichkeit, ihre Wahl der Anwendungsplattform zu überprüfen und einige frühe Erkenntnisse über Leistung und Preise zu teilen.

• Eine große Schlussfolgerung aus der Besprechung war, dass Contoso Bicycle plant, nur in den südwestlichen USA im ersten Jahr zu arbeiten, mit Den Plänen, im jahr 2 landesweit zu expandieren. Diese Art von Detail ist super hilfreich und wird definitiv in das Design eingegliedert werden.

Entwerfen mit Flow-zentriertem Fokus

Ordnen Sie die verschiedenen Flüsse in Ihrer Workload zu und ermitteln Sie, welche am wichtigsten sind. Markieren Sie diese Flüsse in Ihrem Architekturdiagramm. Definieren Sie für jeden Fluss einen Leistungsbereich von dem, was Sie idealerweise möchten, was völlig inakzeptabel wäre. Sehen Sie sich an, wo jeder Fluss beginnt und endet. Überlegen Sie, wie kritisch dieser Weg ist, wie oft er verwendet wird und wie komplex es aus architektonischer Sicht ist.

Wenn Sie Arbeitsauslastungsflüsse priorisieren, stellen Sie sicher, dass Ihre Zeit und Ressourcen zu den Bereichen gehen, die sich wirklich auf die Benutzererfahrung und geschäftsergebnisse auswirken.

Wenn Sie das System in seine Teile unterteilen und verstehen, wie sie voneinander abhängen, können Sie sehen, was jede Komponente tut und wie sich dies auf die Leistung auswirkt. Es gibt Ihnen auch einen Kopf nach oben, wo Probleme auftreten können.

Diese Art von Analyse hilft Ihnen beim Festlegen einer guten Leistungsbasis und bietet Ihnen einen klaren Ausgangspunkt für verbesserungen.

Herausforderung von Contoso

• Bisher hat das technische Team mit den Projektbeteiligten zusammengearbeitet, um einige hochrangige Leistungsziele zu vereinbaren, aber sie haben sich noch nicht auf bestimmte Abläufe konzentriert. Damit das Designteam In Flüsse wie den Service locator und zahlungsflüsse eingreift, müssen sie wissen, was für jeden erwartet wird.

• Ohne diese Details besteht das Risiko, dass das Design das Zeichen nicht verpassen könnte, entweder durch nicht genügend Ressourcen für die Flüsse, die wirklich wichtig sind, oder durch die Überlastung für Flüsse, die nicht so kritisch sind.

Umsetzung und Ergebnisse

• Nachdem der Benutzer mit dem Geschäftsteam übergeht, hat das Architekturteam nun klare, detaillierte Ziele, die für jedes team geschrieben wurden. Sie haben die Arbeitsauslastung auf eine Weise aufgeschlüsselt, die die volle Bandbreite der Leistungserwartungen für jeden Fluss widerspiegelt, von einem angestrebten Bereich bis zu einem inakzeptablen Bereich.

• Die Architekten zielen darauf ab, diese ziele in ihrem Design so zu entwickeln, dass das System später Platz hat, um neue Features zu wachsen und zu unterstützen. Gleichzeitig achten sie auf Kosten und andere nicht funktionsfähige Anforderungen, daher machen sie einige Kompromisse, wo es sinnvoll ist.

• Wenn diese Ziele gesperrt sind, ist das Design jetzt abgeschlossen. Es liegt an dem Implementierungsteam, diese Grenzen einzuhalten und zu sprechen, wenn sie etwas erreichen, das die Ziele mit dem aktuellen Design schwer erreichen kann.