Erreichen und Aufrechterhalten der Leistung
 Schützen Sie sich vor Leistungsbeeinträchtigungen, während das System verwendet wird und sich weiterentwickelt. |
|---|
Die Entwicklung ist kein einmaliger Aufwand. Sie ist ein fortlaufender Prozess. Erwarten Sie Änderungen an der Leistung, wenn sich Features ändern. Es gibt Abweichungen in Benutzermustern und -profilen, sogar Änderungen von Optimierungen in anderen Azure Well-Architected-Säulen. Jede Änderung kann Workloadressourcen belasten.
Schützen Sie das System vor Änderungen, damit es nicht hinter die Leistungsziele zurückfällt. Integrieren Sie Tests und Überwachung in den Entwicklungsprozess. Testen Sie die Leistung des Systems in der Produktion mit realer Last und simulieren Sie diese Last mit automatisierten Tests vor der Produktionseinführung. In beiden Fällen sollten Sie Überwachungspraktiken für Überprüfungszwecke eingerichtet haben.
Führen Sie während des gesamten Entwicklungslebenszyklus verschiedene Arten von Tests in verschiedenen Stages durch. Testen Sie in den anfänglichen Stages den Proof of Concept, um sicherzustellen, dass die Leistungsergebnisse nicht völlig unerwartet sind. Führen Sie im Laufe der Entwicklung manuelle Tests mit geringem Aufwand durch, um Benchmarks einzurichten. Beginnen Sie in der Buildstage mit der Entwicklung automatisierter Routineleistungstests, welche die Wartezeit, Stressebenen, Lastkapazität und andere in den Testplänen definierte Merkmale bewerten.
Die Überwachung muss ein integraler Bestandteil dieser Bemühungen sein, anstatt eine isolierte Übung zu sein. Sie können sehen, wie das System und seine Ressourcen im Laufe der Zeit funktionieren. Sie können sie dann optimieren, um ihren Wert zu maximieren und sicherzustellen, dass sie weiterhin die Leistungsstandards erfüllen.
Beachten Sie, dass Leistungsziele im Laufe der Zeit als Reaktion auf Änderungen variieren. Aktualisieren Sie das Leistungsmodell basierend auf getesteten und überwachten Metriken. Geben Sie deutlich an, ob die Leistung der Flows erhöht, verringert oder nicht beeinflusst wird.
Seien Sie immer bereit, die Erwartungen mit den Projektbeteiligten neu zu verhandeln und zurückzusetzen.
Beispielszenario
Contoso Event Solutions bietet ein Produkt an, mit dem das Personal am Eingang zu einem Ereignis die Tickets mit einem mobilen Gerät scannen und den Berechtigten schnell den Zutritt zu einem Veranstaltungsort mit Eintrittskarten ermöglichen kann. Das System ist sowohl mit einem vollständig Offlinemodus als auch als Cloud-verbundene Version für Veranstaltungsorte verfügbar, die sich Sorgen machen über die Ticketduplizierung. Der Offlinemodus ist sehr leistungsfähig, aber der Onlinemodus verfehlte seine Leistungsziele. Das Entwicklungsteam hat kürzlich einige Entwicklungszyklen investiert, um daran zu arbeiten, und jetzt ist die Leistung viel verbessert und erfüllt die Ziele. Projektbeteiligte im Unternehmen möchten ihre Kundenbasis erweitern, um bald größere Veranstaltungsorte zu unterstützen.
Testen der Leistung in der Entwicklung
Formalisieren Sie Leistungstests als Qualitätstore, welche die Freigabe und die endgültige Bereitstellung in der Produktion genehmigen oder verweigern können.
Diese Prüfpunkte stellen sicher, dass jede Stage der Bereitstellung die erforderlichen Leistungsstandards erfüllt, bevor Sie mit der nächsten fortfahren. Die Prüfpunkte helfen dabei, eine unbeabsichtigte Leistungsregression zu verhindern. Wenn die Leistung beispielsweise deutlich unter den Erwartungen liegt, könnten Sie einen Release blockieren, bis Verbesserungen vorgenommen werden.
Herausforderung von Contoso
- Das Team hat erhebliche Zeit und Mühe investiert, um eine akzeptable Leistung für die Onlineversion der Anwendung zu erreichen, aber sie verfügen über kein System, um eine Regression zu verhindern.
- Das nächste Feature, das sie hinzufügen möchten, ist die Möglichkeit für einen Veranstaltungsort, ein Bild des Teilnehmers zusammen mit dem Scan zur zusätzlichen Überprüfung anzuzeigen. Es besteht ein Risiko, dass die zusätzliche Fotosuche und das Herunterladen den Vorgang verlangsamen.
- Ohne einen formalen Prozess besteht das Risiko, dass die Leistung sowohl der Online- wie auch Offlineversion von der zusätzlichen Funktionalität negativ beeinflusst werden kann und sie die Zielvorgaben nicht erreichen.
Umsetzung und Ergebnisse
- Das Team integriert automatisierte Leistungstests in die Buildpipeline. Durch die Implementierung strenger leistungsbasierter „Go/No-Go“-Kriterien in der Buildpipeline ist das Team zuversichtlicher, dass das neue Feature nicht mit einer Leistungsregression freigegeben werden wird.
- Es war klug vom Team, diese Tests durchzuführen, da sie einen Fehler in der neuesten Version des Builds erkannten. Der Fehler führte dazu, dass die App versuchte, sich mit dem Internet zu verbinden, um ein Bild herunterzuladen, während der Scanner auf den Offlinemodus eingestellt war, was zu einer Zeitüberschreitung bei jedem Ticketscan führte. Durch die Erkennung dieses Fehlers mit den automatisierten Tests konnte das Team den Fehler beheben, bevor die neue Version veröffentlicht wurde.
Optimieren durch Einblick
Richten Sie einen wiederholbaren Prozess für die Überwachung realer Transaktionen in der Produktion und Abweichungen gegenüber Ihren Leistungszielen ein. Verwenden Sie außerdem synthetische Transaktionen in der Produktion, und richten Sie Überwachungswarnungen für Leistungsregressionen ein.
Sie möchten Einblicke in die tatsächliche Leistung Ihres Systems unter realen Lasten erhalten, die nicht durch Tests simuliert werden konnten. Anschließend können Sie Probleme und Verbesserungsbereiche proaktiv identifizieren, z. B. potenzielle Engpässe, nicht ausgelastete Ressourcen und andere Bedenken.
Herausforderung von Contoso
- Während eines Ereignisses, bei dem sie die Onlineticketüberprüfung verwenden, wird das Back-End-System stark belastet.
- Es gibt ein System zur Anwendungsleistungsüberwachung (Application Performance Monitoring, APM), aber es wurde nicht verwendet, um die Integrität von Produktionstransaktionen zu überwachen.
Umsetzung und Ergebnisse
- Das Team hat beschlossen, aktualisierte Prozesse zur besseren Erfassung von Integritätsmetriken einzuführen:
- Sie konfigurieren Warnungen auf der Grundlage von Leistungsperzentilen und für Leistungsausreißer. Keine Warnungen deutet darauf hin, dass das System für die meisten Ticketscans in akzeptablen Bereichen funktioniert.
- Nach Abschluss eines Offlineereignisses werden die Telemetriedaten für Ticketscans als Batch hochgeladen, und diese Metriken durchlaufen auch einen Prozess, um nach Abweichungen von der akzeptablen Leistung zu suchen.
- Das Team implementiert auch synthetische Transaktionstests, um die Leistungsüberwachung zu verbessern. Da fast alle Ereignisse an Wochenenden und am Abend stattfinden, verwendet das Team synthetische Transaktionstests während der Woche, um eine konsistenteren Leistungsbaseline zu generieren.
Intelligentes Behandeln von Workloadänderungen
Kümmern Sie sich um den Leistungsabfall, wenn der Verbrauch sich erhöht, die Features sich ändern und Daten sich im Laufe der Zeit ansammeln, um die Leistung aufrechtzuerhalten. Setzen Sie Erwartungen zurück und schaffen Sie neue Ziele, wenn die Feinabstimmung nur kurzfristigen Nutzen bringt.
Durch die Übernahme dieses Ansatzes können Sie den Leistungszustand beibehalten, bevor eine Beeinträchtigung zu Problemen führt, welche die Benutzererfahrung über das akzeptable Maß hinaus beeinträchtigen.
Durch das Ändern von Zielen wird das Leistungsmodell zurückgesetzt, und Sie verschwenden keine Zeit bei der Optimierung des Systems, das seine Kapazität bereits erreicht hat.
Herausforderung von Contoso
- Das Vertriebsteam hat aggressiv neue Veranstaltungsorte in das System integriert. Das Geschäft ist gut.
- Das Workloadüberwachungssystem hat festgestellt, dass das Leistungsbudget mit der Zeit immer mehr aufgefressen wird, auch ohne die Einführung neuer Funktionen.
- Ohne eine Änderung kann diese Entwicklung zu einem inakzeptablen Rückgang der Leistung führen, so dass bei einem Zwischenfall das Risiko eines Workloadausfalls besteht.
Umsetzung und Ergebnisse
- Das Team erkennt, dass der Datensuchmechanismus für Onlineereignisse bei der Integration von mehr Kunden für viele Abfragen einen sehr großen Scan der Daten durchführt.
- Einige Abfrageoptimierungen haben dazu beigetragen, dass der erhöhte Verbrauch keinen zusätzlichen Schaden verursachte. In den kommenden Monaten plant das Team, verschiedene Ereignisse in verschiedene Datenpartitionen aufzuteilen, um den Bedarf an Abfragescans zu verringern. Dies wird die fortgesetzte Aufskalierung der Workload unterstützen.
- Sie erkennen auch, dass sie das Wachstum des System weiter optimieren können, indem Ticketingdaten von alten Ereignissen entfernt werden. Die Suche nach alten Ereignissen ist nicht etwas, was das Ticketprüfungssystem tun sollte, so dass die Daten in einen Speicher verschoben werden können, der für Berichte und historische Nachforschungen dediziert ist.