Atlassian-Beratung für einen britischen Anbieter von Softwareentwicklung

Lösung

Wir haben das Projekt in drei Phasen aufgeteilt:

1. Überprüfung der aktuellen Workflows
2. Feinabstimmung der Arbeitsabläufe gemäß den Atlassian-Richtlinien
3. Mitarbeiterschulung

Neben der Demonstration fortgeschrittener Atlassian-Funktionen und dem Austausch von Tipps zur Nutzung der Plattform haben wir auch den Aufbau von Unternehmenswissen durch Confluence-Fragen initiiert.

Im Laufe des Projekts hat das Team von Itransition:

• Sammeln der Anforderungen beim Kunden.
• Einrichten der Standalone-Versionen von Jira, Confluence und Service Desk in der AWS-Umgebung des Kunden, um Workflow-Automatisierung, benutzerdefinierte Berichte und SSO-Authentifizierung zu ermöglichen und gleichzeitig die Systemausfallzeiten zu minimieren.
• Die bestehende Jira-Lösung wurde überprüft, um ungenutzte Komponenten zu identifizieren und zu entfernen.
• Migrierte die bestehenden Projekte und Issues sowie die Confluence-Spaces von der Atlassian Cloud zu eigenständigen Instanzen.
• Implementierung einer Jira- und Confluence-Failover-Lösung.
• Organisierte Atlassian-Schulungen vor Ort für die Mitarbeiter des Kunden.

Prüfung

Um klare Anforderungen zu formulieren, führten die Atlassian-Experten von Itransition vor Ort Interviews mit den für verschiedene Betriebsbereiche zuständigen Mitarbeitern (Top-Manager, Business-Analysten, Entwickler, QA- und DevOps-Ingenieure). Das gesammelte Feedback half uns, die folgenden Probleme zu identifizieren:

• Einige Workflows waren falsch konfiguriert und überkompliziert. Zum Beispiel gab es über 50 Workflow-Status, aus denen man wählen konnte.
• Jira wurde nicht ausreichend genutzt, weil die Mitarbeiter die Technologie nicht vollständig verstanden. Infolgedessen waren sie nur mit den grundlegenden Funktionen wie Suche, Dashboards, Zeiterfassung usw. vertraut.
• Der Arbeitsrückstand war durch zu viele ungelöste Anfragen aufgebläht (einige von ihnen wurden vor 3 Jahren erstellt). Einige Formulare waren mit unnötigen Feldern überfrachtet, die zudem nicht richtig beschrieben waren.
• Eine ganze Reihe von automatischen Benachrichtigungen waren nutzlos und bedurften der Optimierung.
• Einige Prozesse waren nicht automatisiert (z.B. das Verschieben oder Wiedereröffnen von Tickets).
• Es gab kein Single Sign-On (SSO), keine Integration mit Active Directory und keine CI/CD-Integration.
• Die Mitarbeiter wussten nicht, wie sie mit Jira-Berichten und /de/portfolio arbeiten können.

Migration und Prozessoptimierung

Anhand der Auditergebnisse erstellte das Team von Itransition einen Fahrplan für Verbesserungen. Darunter war die Migration der Schlüssel zur Optimierung der Jira-basierten Arbeitsabläufe.

Wir richteten Amazon EC2- und Amazon RDS-Umgebungen ein, um eigenständige Atlassian-Lösungen zu installieren und sie von der Atlassian Cloud auf den Atlassian Server zu migrieren. Anschließend migrierten wir Jira- und Confluence-Daten (bestehende Projekte, Bereiche und Probleme) in die eigenständigen Instanzen. Außerdem haben wir Jira in das Active Directory des Kunden integriert, um die Benutzerauthentifizierung zu erleichtern.

Die Migration ermöglichte dem Kunden eine bessere Kontrolle über die Atlassian-Bereitstellung und gleichzeitig mehr Flexibilität bei den Anpassungen. Nach der Migration ging unser Team zur Workflow-Optimierung über.

Während die Atlassian-Richtlinien die Verwendung von Workflows mit maximal fünf Schritten empfehlen, enthielten einige der Workflows des Kunden bis zu 20 Schritte, die aufgrund ihrer schieren Menge für die Teams nur schwer zu verfolgen und zu verwalten waren. Die Benutzer konnten den Status von Workflows kaum erfassen und den Lebenszyklus von Aufgaben insgesamt verfolgen.

Um die bestehenden Prozesse zu optimieren, entfernte das Team von Itransition alle ungenutzten Felder, Status, Projektschemata und Workflow-Schritte. Dank der Bereinigung gelang es uns, die Anzahl der Schritte in den Arbeitsabläufen des Kunden auf sechs zu reduzieren. Wir erstellten eine Reihe von vereinfachten Workflow-Vorlagen und migrierten alle komplizierten Workflows auf diese Vorlagen.

Außerdem haben wir falsch konfigurierte Projektverknüpfungen behoben, die die Integration zwischen den Atlassian-Anwendungen behinderten.

Das Team von Transition automatisierte auch das Verschieben und Wiedereröffnen von Jira-Problemen und richtete ein einheitliches Help Center für alle Service-Desk-Benutzer ein.

Im Rahmen der Atlassian-Beratung führten die Spezialisten von Itransition das ITIL-Framework ein und richteten so die IT-Prozesse an den Geschäftsanforderungen des Kunden aus. Wir richteten den Jira Service Desk in Übereinstimmung mit dem Framework ein und unterstützten die Mitarbeiter beim Erlernen der ITIL-Prinzipien.

Ausbildung

Unsere Atlassian-Beratungsleistungen umfassten Anwenderschulungen, damit die Mitarbeiter des Kunden Jira, Service Desk und Confluence effizienter nutzen können. Wir führten vor Ort Schulungen durch, die Aspekte wie Projekt- und Produktmanagement (Scrum/Kanban), CI/CD und Versionsmanagement abdeckten.

Um die Schulungen zu personalisieren, teilten unsere Atlassian-Experten die Benutzer in mehrere Gruppen ein und bereiteten für jede Gruppe ein individuelles Training vor:

• Jira/Confluence-Benutzer. Wir demonstrierten wesentliche Jira- und Confluence-Funktionen, die für jeden Jira- oder Confluence-Benutzer nützlich sind.
• Jira-Manager. In einer agil ausgerichteten Schulung haben wir die Arbeit mit Scrum/Kanban-Projekten beschrieben und einige nützliche Tipps für Manager zur Vereinfachung des Entwicklungsprozesses und zum Sammeln von Metriken über die Projektqualität und -ergebnisse gegeben.
• Jira/Service Desk-Administratoren. Wir zeigten, wie man Jira und Service Desk einrichtet und gaben Empfehlungen für die Feinabstimmung der eingesetzten Lösungen.

Insgesamt haben wir 15 Gruppenschulungen sowie mehrere Einzelschulungen durchgeführt. Außerdem hielten wir mehrere spezielle Schulungen für QA-Ingenieure und Administratoren ab.

Dank der Schulungen lernten die Mitarbeiter, wie sie das Beste aus den Atlassian-Produkten herausholen und sie richtig verwalten können. Die Entwickler konnten nun Jira als ihr wesentliches Werkzeug für die tägliche Verfolgung aller entwicklungsbezogenen Prozesse nutzen. Durch den Einsatz von Confluence als Wissensdatenbank und Dokumentenspeicher erhielten die Mitarbeiter außerdem die Möglichkeit, alle Prozesse zu dokumentieren und Best Practices zu sammeln.

Integration

Um die Benutzerfreundlichkeit zu verbessern und die täglichen Arbeitsabläufe zu beschleunigen, integrierte das Team von Itransition die Atlassian-Lösungen in mehrere Anwendungen von Drittanbietern:

• TestRail, ein Testfall- und Testmanagement-Tool, das Teams bei der Verwaltung und Verfolgung ihrer Softwaretests unterstützt.
• Slack, eine App für die Zusammenarbeit, mit der Teams Jira-Probleme erstellen, aktualisieren, zuweisen und kommentieren sowie Jira-Benachrichtigungen in konfigurierten Kanälen empfangen können, die alle Teammitglieder vereinen.
• Zabbix und Splunk zum Verfolgen und Analysieren von Ereignissen innerhalb des Atlassian-Stacks.
• Twilio, um das Service-Desk-Team des Unternehmens, den Service-Desk-Manager oder den CEO (je nach Risikostufe) per Telefonanruf oder SMS zu benachrichtigen, wenn eine bestimmte Serviceanfrage Aufmerksamkeit erfordert.

Umsetzung der Failover-Lösung

Der Kunde, der Dienstleistungen für die Produktentwicklung anbietet, wollte eine unterbrechungsfreie Entwicklung ohne Ausfallzeiten sicherstellen. Um die Fehlertoleranz des Atlassian-Stacks in der AWS-Umgebung zu gewährleisten und Ausfallzeiten zu vermeiden, haben wir daher eine Failover-Lösung implementiert. Die Fehlertoleranz des Systems wird durch die folgenden drei Faktoren erreicht:

• Ein fehlertolerantes EFS-Dateisystem
• Eine fehlertolerante Amazon RDS-Datenbank
• Ein duplizierter Server in einem 'gestoppten' Zustand

Die Lösungsarchitektur umfasst die folgenden Komponenten:

Load Balancer. Ein einziger Zugangspunkt zu Jira und Confluence, sowie ein einziger Punkt der HTTPS-Traffic-Verschlüsselung. Er überwacht EC2-Server und leitet den Datenverkehr auf eine aktive Instanz um.

Amazon EC2 bietet skalierbare Rechnerkapazitäten in der AWS-Cloud. In EC2 werden zwei Anwendungsserver (primär und sekundär) in verschiedenen Rechenzentren einer Region bereitgestellt. Die lokale EBS-Datei wird als AMI-Image gespeichert und kann bei Bedarf in einer beliebigen Region bereitgestellt werden. EC2 speichert nur die zustandslosen Komponenten des Systems und der Anwendungen, einschließlich aller Systemdateien und konfigurierten Anwendungen, mit Ausnahme von zustandsabhängigen Daten, die sich im Laufe der Zeit ändern (wie Anhänge, Plugins, Indizes, Protokolle und zwischengespeicherte Daten).

Amazon RDS. Eine Cloud-Datenbank, die in der gleichen Region wie EC2-Server mit aktivierter Option Multi-AZ (Verfügbarkeitszonen) bereitgestellt wird. Das bedeutet, dass die Datenbank über mehrere Rechenzentren in dieser Region repliziert wird, was ihre Verfügbarkeit und Fehlertoleranz erhöht. Unser Team konfigurierte regelmäßige, inkrementelle und vollständige Datenbank-Backups.

Amazon EFS. Ein Dateisystem, das über mehrere Rechenzentren in einer Region repliziert wird, was die Fehlertoleranz erhöht. Es ist auf jeder EC2-Instanz gemountet und speichert zustandsabhängige (sich ändernde) Dateien von Jira und Confluence. Der Zugriff auf das Dateisystem ist auch dann gewährleistet, wenn ein oder zwei Rechenzentren nicht verfügbar sind.

CloudWatch überwacht den Status der Anwendungsserver und ergreift Maßnahmen, wenn der Hauptserver nicht mehr verfügbar ist. Es stoppt den Hauptserver, um den gleichzeitigen Start von zwei Anwendungsservern zu verhindern, und startet dann den Sekundärserver, während der Load Balancer automatisch auf eine gesunde Instanz umschaltet.

Wie es funktioniert

Die EC2-Server sind mit der gleichen Multi-AZ-RDS-Datenbank verbunden. Die primäre Instanz wird durch eine identische sekundäre Instanz gesichert. Alle zustandsbezogenen Dateien werden alle 1-2 Stunden oder täglich zwischen den Instanzen kopiert. Es besteht keine Notwendigkeit, zustandslose Daten zu kopieren, da dieselbe Datenbank bereits verwendet wird. Wenn die Hauptinstanz ausfällt, werden die Anwendungen auf der sekundären Instanz gestartet, die in der Regel etwa eine Minute braucht, um geladen zu werden. Der DNS-Webdienst Amazon Route53 leitet den Domainnamen an die sekundäre Instanz weiter.

Das Team von Transition hat mehrere mögliche Failover-Szenarien in Betracht gezogen:

1. Nicht verfügbare RDS- oder EFS-Rechenzentren

   Dieses Szenario wird durch das fehlertolerante Design der Dienste selbst abgedeckt, sodass keine Maßnahmen erforderlich sind. Die Lösung benachrichtigt die Support-Techniker des Kunden automatisch.

2. Datenzentrum mit nicht verfügbarem Anwendungsserver

   Wenn der primäre Anwendungsserver nicht mehr verfügbar ist, wird der sekundäre Anwendungsserver automatisch aktiviert. Er nutzt die gleichen EFS/EBS-Dateisysteme, wobei alle Daten erhalten bleiben. Die Support-Techniker erhalten sofort eine entsprechende Benachrichtigung.

3. Regionaler Ausfall

   Wenn alle regionalen Server nicht verfügbar sind, erfolgt die Wiederherstellung über Backup-Systeme. Aktuelle Backup-Versionen der Datenbank und des EFS-Dateisystems werden in einer anderen Region wiederhergestellt. EC2 wird aus dem gesicherten AMI-Image in derselben Region wiederhergestellt. Das System startet mit minimalem Datenverlust durch regelmäßige Datenbanksicherungen. Die durchschnittliche Wiederherstellungszeit in einer anderen Region beträgt etwa 3-8 Stunden.