Wenn Jira-Administratoren darüber nachdenken, Jira zu skalieren, liegt der Fokus oft zunächst auf der Anzahl der Vorgänge, die eine einzelne Jira-Instanz handhaben kann. Allerdings sind bei der Jira-Skalierung zahlreiche weitere Faktoren mit ausschlaggebend.
Auf dieser Seite stellen wir dar, wie Jira unter verschiedenen Konfigurationen performt und wie große Unternehmen Jira anpassen können. Dabei gibt es zwei grundsätzliche Ansätze, um Jira zu skalieren, die auch miteinander kombiniert werden können:
- Skalierung einer einzelnen Instanz
- Nutzung mehrerer und miteinander verbundener Instanzen
Skalierung einer einzelnen Jira-Instanz
Zahlreiche Faktoren von der Anzahl der Vorgänge und Projekte bis hin zur Backend-Konfiguration tangieren die Performance eines Jira-Systems. Abseits von Vorgängen und Projekten haben die folgenden Aspekte Auswirkungen auf die Jira-Performance:
- Daten
- Die Anzahl der Vorgänge in Jira
- Die Anzahl der Anhänge in der Jira-Instanz
- Nutzung
- Die Anzahl der Nutzer, die gleichzeitig mit Jira arbeiten
- Die Anzahl der gleichzeitig durchgeführten Operationen
- Das Volumen an E-Mail-Benachrichtigungen
- Konfiguration
- Die Anzahl der Plugins (Einige haben ihre eigenen Speicheranforderungen.)
- Die Anzahl der Workflow-Schritte wie z.B. Transitions
- Die Anzahl der geplanten Services
- Die Anzahl der konfigurierten Projektelemente wie Custom Fields, Vorgangstypen usw.
- Hardware / Betriebssystem
- Der Server, auf dem Jira läuft
- Die Datenbank und die Konnektivität zu ihr
- Das Betriebssystem inklusive lokaler Datenspeicher, Speicherzuordnung und Speicherbereinigung
Instanzen bestehender Kunden
Atlassian führt regelmäßig Kundenbefragungen durch, um ein akkurates Bild von den Einsatzumgebungen und den Herausforderungen bei der Skalierung von Jira in großen Unternehmen zu generieren. Dies sind einige Beispiele für große Produktivinstanzen.
Neben Vorgängen wirken sich noch andere Aspekte auf die Performance von Jira aus, die alle berücksichtigt werden müssen:
Vorgänge | Custom Fields | Nutzer | Berechtigungs-Schemata | Projekte | Vorgangstypen | Auflösungen | Prioritäten | Workflows |
|---|---|---|---|---|---|---|---|---|
840.000 | 600 | 6.500 | 10 | 290 | 160 | 10 | 5 | 10 |
800.000 | 310 | 1.000 | 14 | 395 | 690 | 10 | 5 | 10 |
705.000 | 600 | 13.000 | 35 | 425 | 50 | 10 | 5 | 35 |
530.000 | 540 | 8.000 | 45 | 610 | 70 | 15 | 5 | 85 |
455.000 | 235 | 2.700 | 165 | 250 | 20 | 35 | 5 | 35 |
390.000 | 755 | 5.600 | 100 | 475 | 95 | 20 | 20 | 360 |
360.000 | 700 | 12.000 | 200 | 800 | 250 | 20 | 10 | 150 |
330.000 | 615 | 35.000 | 25 | 1090 | 54 | 8 | 5 | 100 |
225.000 | 2715 | 93.000 | 65 | 3 | 115 | 61 | 5 | 65 |
205.000 | 300 | 6.000 | 25 | 190 | 45 | 10 | 5 | 35 |
Projekt-Konfigurationen
Aufgrund der Flexibilität von Jira sind zahlreiche ganz unterschiedliche Konfigurationen möglich und auch praxisbewährt. Allerdings haben einige Ansätze der Projektkonfiguration größere Performance-Auswirkungen als andere. Diese Tabelle zeigt die Ergebnisse einfacher Performance-Tests des Jira-Durchlaufs, wenn die Werte diverser Konfigurationen verdoppelt werden.
Durchlauf entspricht in diesem Zusammenhang der Operationen pro Sekunde. Operationen sind hier Aktionen, die normale User während der täglichen Arbeit mit dem System durchführen: Vorgänge erstellen, editieren und suchen, Auswertungen, Dashboards und Projekte einsehen usw.
Die Konfigurationen, die Jira am stärksten beeinflussen:
- Vorgänge
- Custom Fields
Darüber hinaus wirken sich zwei weitere Faktoren besonders auf die Jira-Performance aus:
- Berechtigungen
- Gleichzeitige Nutzer
Projekte | Workflows | Nutzer | Vorgangstypen | Auflösungen | Custom Fields | Vorgänge | Resultat des Durchlaufs |
|---|---|---|---|---|---|---|---|
250.000 | 30 | 5.000 | 55 | 10 | 300 | 200.000 | 30 (Mittel) |
500.000 | 30 | 5.000 | 55 | 10 | 300 | 200.000 | 30 |
250.000 | 60 | 5.000 | 55 | 10 | 300 | 200.000 | 30 |
250.000 | 30 | 10.000 | 55 | 10 | 300 | 200.000 | 30 |
250.000 | 30 | 5.000 | 110 | 10 | 300 | 200.000 | 30 |
250.000 | 30 | 5.000 | 55 | 20 | 300 | 200.000 | 29 |
250.000 | 30 | 5.000 | 55 | 10 | 600 | 200.000 | 22 |
250.000 | 30 | 5.000 | 55 | 10 | 300 | 400.000 | 20 |
Die Quintessenz der Tests: Halten Sie die Jira-Konfiguration schlank. Mit der Zeit erreichen manche Jira-Instanzen einen Zustand, als wäre Jira seit Jahren in Betrieb. Es ist dringend zu empfehlen, Schemes wiederzuverwenden statt ständig neu zu erstellen und alles zu löschen, was nicht mehr benötigt wird.
Archivierung von Vorgängen
Obwohl die Anzahl der Vorgänge nur eine von mehreren Dimensionen ist, die sich auf die Jira-Performance auswirken, hat dieser Aspekte mit Abstand die größten Auswirkungen. In der Übersicht oben ist ersichtlich, wie eine Verdopplung der Vorgänge die Performance beeinflusst. Daher ist die Implementierung einer Archivierungsstrategie sinnvoll. Hier bieten sich zwei Ansätze an.
Backup und löschen (einzelne Jira-Instanz)
Diese Methode ist die einfachere und schnellere. Erstellen Sie einfach ein Backup der gesamten Jira-Instanz, datieren Sie sie und speichern Sie sie in einer sicheren Umgebung. Stellen Sie in einer Testinstanz sicher, dass sich das Backup wiederherstellen lässt. Ist das der Fall, können Sie in der Produktivinstanz die Projekte oder Vorgänge löschen, die nicht mehr genutzt werden. Die Löschen-Strategie kann auch auf die anderen Dimensionen wie Custum Fields, Schemes usw. ausgeweitet werden.
Der Nachteil dieses Ansatzes: Wenn Nutzer einen archivierten Vorgang einsehen müssen, muss zunächst das entsprechende Backup gefunden und in einer anderen Jira-Instanz wiederhergestellt werden. Der Ansatz empfiehlt sich also eher, wenn in Ihrem Unternehmen auf archivierte Objekte nicht regelmäßig und häufig zurückgegriffen werden muss.
Migrieren und löschen (zwei Jira-Instanzen)
Diese Methode ist deutlich komplizierter. Zunächst muss ein komplettes Backup gezogen und in einer separaten Jira-Instanz wieder verfügbar gemacht sowie getestet werden. Anschließend behalten Sie die Vorgänge, die Sie in dieser Instanz archivieren wollen, und löschen alles andere.
Für künftige Archivierungen müssen Sie in der Produktivinstanz einen Filter für alle Vorgänge erstellen, die archiviert werden sollen. Sammeln Sie diese Vorgänge in einem separaten Projekt und erstellen Sie ein komplettes Backup Ihrer Jira-Instanz. Mithilfe der Project-Restore-Funktion können Sie dieses Projekt in die Archivierungsinstanz importieren und dort die Vorgänge dann in ihre entsprechenden Projekte verschieben.
Obwohl diese Methode mehr Zeit und Ressourcen erfordert, besteht der Vorteil darin, dass das Archivierungssystem eine Live-Instanz ist, die Nutzer jederzeit aufrufen können, um archivierte Objekte einzusehen.
Es ist wichtig, darüber nachzudenken, welche Vorgänge in der Produktivinstanz ständig verfügbar sein müssen: Müssen z.B. wirklich 800.000 Vorgänge vorgehalten werden, wenn man die Auswirkungen auf die Performance kennt?
Jira-Skalierung über mehrere Instanzen
Obwohl viele Hundert oder Tausende Vorgänge in einer einzelnen Jira-Instanz kein Problem sind, entscheiden sich viele Kunden dafür, mit mehreren Jira-Instanzen zu arbeiten. Dies ist auch der empfehlenswerte Ansatz, um Jira für große Unternehmen zu skalieren.
Aus den folgenden Gründen entschließen sich Kunden für den Einsatz mehrerer Instanzen.
Öffentliche vs. Private Jira-Instanzen
In vielen Fällen betreiben Kunden sowohl eine öffentliche als auch eine gesicherte Jira-Instanz. Letztere läuft in der Regel hinter der Firewall und ist nur für die internen Mitarbeiter zugänglich. Die öffentliche Instanz wird bspw. als Helpdesk für Kunden oder als öffentlicher Issue Tracker genutzt.
Räumliche Verteilung
Viele Jira-Kunden haben eine internationale Ausrichtung und eine räumlich verteilte Nutzerschaft an verschiedenen Standorten. In einigen Fällen verbieten landesspezifische Gesetze die Datenspeicherung in anderen oder mehreren Ländern. Daher nutzen Kunden mehrere Jira-Instanzen an den verschiedenen Standorten.
Unterschiedliche Konfigurationen oder Einstellungen
Einige Kunden arbeiten mit mehreren Instanzen, auf denen unterschiedliche Plugins auf den einzelnen Systemen laufen oder die unterschiedlich gebrandet oder konfiguriert (globale Einstellungen wie z.B. unterschiedliche Prioritäten, Auflösungen, Administratoren-Sets, Zeiterfassung oder nicht).
Organisatorische Aspekte
In vielen Fällen wird Jira an unterschiedlichen Standorten mit separaten Instanzen gestartet, in denen Abteilungen oder Mitarbeiter an Zweigstellen erfolgreich arbeiten. In anderen Fällen bietet die IT einen Jira-Service mit individuellen Anpassungen für jeden Unternehmensbereich an.
Skalierung
Die Skalierung mit mehreren Jira-Instanzen ist die Methode, die Atlassian Kunden empfiehlt. Einige Features richten sich speziell an Kunden, die mit einer einzelnen Instanz an Performance-Grenzen stoßen:
- Application Links ermöglichen die sichere Verbindung zwischen zwei oder mehr Jira-Instanzen.
- Gadgets können auf einem Dashboard Informationen aus anderen Jira-Instanzen integrieren, die via Application Links angebnden sind.
- Remote Issue Links zwischen Vorgängen in verschiedenen Jira-Instanzen ermöglichen es, Vorgänge in separaten Instanzen miteinander zu verknüpfen (siehe Bild unten).
- Remote Issue Copy ist (in Entwicklung befindliches) ein Plugin, mit dem Vorgänge von einer Instanz in eine andere kopiert werden können.
- Aktivitätsströme zeigen Ereignisse in allen via Application Links integrierten Jira-Instanzen an.
- Für ein zentralisiertes Nutzermanagement über alle Instanzen hinweg ist Crowd oder die Jira-Nutzung als Crowd-Server eine etablierte Lösung.
Wann mehrere Instanzen nutzen?
Wie oben erwähnt, sollte man über eine Skalierung mithilfe mehrerer Instanzen nachdenken, wenn ein einzelnes Set an globalen Einstellungen (Prioritäten, Time-Tracking usw.) zu Herausforderungen führt.
Auch wenn eine kritische Masse im Hinblick auf eine der oben beschriebenen Dimensionen erreicht ist, sollte man ein Splitting evaluieren. Haben Sie in Ihrer Instanz z.B. 300 Custom Fields, die alle benötigt werden, könnte es sinnvoll sein, dieses Jira-System in mehrere Instanzen besser handhabbarer Größe aufzusplitten.