“Du kannst nichts kontrollieren, was Du nicht messen kannst”: Langsame Antwortzeiten, träge Verarbeitung von Anfragen und Time-Outs in einem Projekt-Workflow erfordern eine schnelle Optimierung der System-Performance. Um die Leistungsfähigkeit einer Atlassian-Toolchain messbar machen zu können, müssen individuelle Untersuchungen durchgeführt werden. Hintergrund: Jede Umgebung und Systemnutzung ist einzigartig. catworkx setzt beim Controlling von Performance-Werten auf die Paarung von Open-Source-Software und eigenen, internen Werkzeugen, wie z. B. catworkx SPIN (Stress-App). Verhaltensinformationen eines bestimmten Systems lassen sich dadurch über einen festgelegten Zeitrahmen genau abbilden, bei gleichzeitiger Maximierung des Stress-Levels der Atlassian-Instanz.
“Performance Engineering” ist in der IT der Sammelbegriff für die Entwicklung von Lösungen nicht-funktioneller Anforderungen, wie Durchfluss, Verzögerungen oder Speicherbedarf. Das heißt, die entwickelten Lösungen müssen dem Anstieg der Benutzeranforderungen standhalten und gleichzeitig die Geschwindigkeitserwartungen der Benutzer erfüllen. Warum ist das wichtig? Weil Benutzer keine Geduld haben. Es bleiben lediglich drei oder weniger Sekunden Zeit, die Aufmerksamkeit des Benutzers zu halten. Wenn diese Hürde nicht genommen wird, besteht die Gefahr, dass der Benutzer nicht mehr “da” ist. Gemeint ist, es entsteht eine hohe Ablehnung gegen die Lösung, der Prozess wird vermieden und der Kunde ist unzufrieden.
Heutzutage müssen Geschäftsabläufe zuverlässig, schnell und mit einem Minimum an Unterbrechungen funktionieren. So können die Geschäftserwartungen erfüllt werden und man bleibt handlungsfähig. Das Messen der Leistungsfähigkeit ist der Schlüssel für die Identifikation von Verbesserungspotenzialen. Nur so kann ein Geschäftswachstum ermöglicht werden. Dieser Zusammenhang ist die Grundlage für den Satz: “Du kannst nichts kontrollieren, was Du nicht messen kannst” (Tom DeMarco).
Von der Idee zur Realisierung:
Diese Erkenntnis war der Auslöser für catworkx, in die Messung der Leistungsfähigkeit der Atlassian-Werkzeugkette zu investieren. Da zentrale Prozesse und Geschäftsfunktionen in mittleren und großen Unternehmen die Notwendigkeit von Workflow-Management, Dokumentation, Zusammenarbeit und Umsetzung der Compliance-Richtlinien erhöhen, müssen alle Teile der Toolchain unter die Lupe genommen werden.
Im folgenden Beispiel hat sich das catworkx-Team um ein Jira-System gekümmert und dafür eine Werkzeugpalette zusammengestellt, mit der Geschäftskunden die wesentlichen Informationen übersichtlich visualisieren können. So können Geschäftsführer und IT-Personal Engpässe oder Stolperfallen, die den Dienst behindern, verstehen und identifizieren. catworkx hat seine Fähigkeiten bei der Performance-Verbesserung und Erhöhung der Systemstabilität der Atlassian-Toolchain schon viele Male anwenden können. Dieses Wissen und das nachfolgende Set-up sind die Grundlage dafür, wie wir unseren heutigen Kunden helfen, ihre Probleme von gestern loszuwerden und sich auf die Geschäftsanforderungen von morgen vorzubereiten.
Werkzeugkette und Benutzung:
Wohlwissend, dass jede Umgebung und jede Systemnutzung einzigartig ist und eine individuelle Untersuchung erfordert, muss die Ausgangslage für jedes einzelne System hinterfragt werden. Nach der Evaluation mehrerer Werkzeuge für unser Anliegen, ist catworkx auf ein Tool-Set aus Gatling (Open-Source-Testing-Framework), InfluxDB (Open-Source-TSDB-Datenbank zum Speichern großer Datenmengen aus Zeitmessreihen) und Grafana (Open-Source-Metrik-Dashboard) gestoßen, das unseren Ansprüchen in Skalierbarkeit und Praktikabilität entgegen kommt.
Diese externen Werkzeuge werden mit eigenen, internen Werkzeugen, wie z. B. catworkx SPIN (Stress-App), gebündelt, um Verhaltensinformationen eines bestimmten Systems – bei Maximierung des Stress-Levels der Atlassian-Instanz – über eine festgelegte Zeitdauer zu sammeln.
In Anlehnung an den Deming-Kreis, als prozessualer Ansatz für unsere Bedürfnisse, beginnen wir das Nutzungsprofil des zu messenden Systems zu planen. Hierdurch bekommen wir einen Eindruck, welchen Einfluss die Anzahl, der auf dem System installierten Apps hat, als auch von der Komplexität der Workflows und die Anzahl der Custom-Fields innerhalb der Jira-Instanz. Zusätzlich fragen wir von den Firmenkunden Daten über Benutzerprofile und über die Verwendung von komplexen JQL-Abfragen im Alltagsbetrieb an.
Als zweiten Schritt implementieren wir unsere Werkzeugkette. Hauptanforderung ist, reale Use-Case-Informationen im Gatling zur Verfügung zu haben, um die tatsächliche Systemauslastung zu messen.
In der Überprüfungsphase unseres Prozesses lassen sich anhand der Messungen unsere Annahmen aus Schritt 1 verifizieren.
Die Messungen werden dokumentiert und mehrere Verbesserungsmöglichkeiten identifiziert. Schrittweise passen wir einzelne Einstellungen an, um Wissen darüber zu erlangen, welchen Einfluss sie auf die Gesamtsystemauslastung und die Problempunkte des Kunden haben.
Kundenbeispiel:
Im folgenden Beispiel geht es um ein Kundensystem (Jira), das durch langsame Antwortzeiten, träge Verarbeitung von Anfragen und Time-Outs aufgefallen ist. Nach dem ersten Zyklus haben wir herausgefunden, dass jede einzelne Änderung am Set-up des Werkzeuges oder seiner Konfiguration gegengetestet werden muss, um ihren Nutzen zu untersuchen. Das Ändern von mehr als einer Bedingung zu einem Zeitpunkt hat sich nicht als das richtige Vorgehen herausgestellt, da Überschneidungen und Seiteneffekte die Messungen negativ beeinflussen können.
1. Assessment:
Die ersten Analyse zeigte ein System, das seit langer Zeit in Benutzung ist und das noch nie einer Performance-Optimierung in der ein oder anderen Form unterzogen wurde. Das Ergebnis präsentierte ein langsames System, mit langen Antwortzeiten und einer Benutzererfahrung am unteren Ende.
2. Assessment:
Nachdem wir gesehen haben, dass die Antwortzeiten des Systems sich verbesserten, sind wir zur dritten Testrunde übergegangen, der Datenbank-Optimierung.
3. Assessment:
Wir fanden heraus, dass die angewendeten Datenbank-Parameter und die verwendeten JDBC-Treiber auf dem Kundensystem verbesserungswürdig sind. Als nächstes machten wir den offensichtlichen Schritt: Wir gaben dem System schrittweise mehr Speicher.
4. Visualisierung der Ergebnisse mit Grafana-Dashboard:
Das angepasste Grafana-Dashboard ermöglichte uns, eine Messung auf einzelne, besondere Entitäten und Werte herunterzubrechen und so ein Maximum an Transparenz und Visualisierung zu erhalten. Besonders die Interferenz der verschiedenen System- und Softwarebereiche konnte einfach über dieses Dashboard aufgedeckt werden.
Fazit:
Mit diesen Schritten konnte die gesamte Systemperformance und Flüssigkeit auf ein akzeptables Maß angehoben werden, sodass der Kunde sein System mit den optimierten Parametern weiter benutzen konnte. Die Maßnahmen haben in einzelnen Teilaspekten einen Effekt von 30 bis 60 Prozent erzielt. Durch die kontinuierliche Überwachung konnte sichergestellt werden, dass überlagernde Seiteneffekte aus der Betrachtung entfernt wurden. Das Ergebnis war ein zufriedener Kunde, der kein neues (größeres) System kaufen musste, um mit seinen Geschäftsanforderungen Schritt halten zu können.