Hauke Bruno

Ziele des Kunden: Nach einem Merger von vier Firmen sollten diverse kleinere Atlassian Data Center und Cloud Instanzen in eine große Instanz je Tool konsolidiert werden

Auswirkung des Projekts: Senkung der Lizenzkosten um ~50% sowie einheitliches und kollaboratives Arbeiten aller Mitarbeitenden in einem einzigen Toolstack.

Zusammenfassung: Für jede kleinere Jira und Confluence Instanz wurde initial eine Inventarisierung durchgeführt. Es wurden Project- und Space-Verantwortliche benannt und auf dem Papier eine Vorausgewahl getroffen welche Inhalte migriert werden müssen und welche archiviert.

Neben den eigentlichen Inhalten wurde analysiert welche Workflows, Screens, Issue Types usw. im Zuge der Migration konsolidiert werden konnten. So sollte "duplicate code" vermieden werden.

Es wurden Skripte in SkriptRunner erstellt um unter Anderem durch die Migration kaputt gegangene Hardlinks oder auch User Referenzen zu reparieren.

Die Migrationen waren primär Data Center zu Data Center, je Tool wurde eine Migration von Cloud zu Data Center durchgeführt.

Um den Impact auf die Mitarbeitenden so gering wie möglich zu halten, wurden die meisten Inhalte kleinteilig (auf Project- oder Space-Ebene) in enger Abstimmung mit den Stakeholdern migriert.

Ziele des Kunden: Der bislang in Confluence gepflege Servicekatalog sollte in Jira mit Assets als Datenbasis implementiert werden.

Auswirkung des Projekts: Die Datenintegrität und - qualität wurde gesteigert. Service Daten konnten maschinell eingelesen werden, was anderen Projekten und vor allem technischen Deployments zu Gute kam. Ein Lifecycle Management sowie ein ans Unternehmen angepasster Approval Prozess konnten sauber im UI abgebildet werden.

Zusammenfassung: Initial wurden alle Services und deren Bausteine zur Erbringung in eine neue Datenstruktur innerhalb Jira Assets übertragen.

In einem dedizierten Jira Project wurde dann das "UI" für das Management der Services angelegt. Services sollten nicht im wenig intuitiven Assets Backend sondern in einem Ticket bearbeitet werden.

Es wurden ScriptRunner Behaviours entwickelt, die Daten aus Assets direkt in Screens nachladen und auch wieder speichern konnten.

Ein eigens angepasster Approval Prozess wurde entwickelt und implementiert. So konnte eine Auswahl an Einzelpersonen aber auch kompletten Teams (mit der Möglichkeit, dass eine beliebige Anzahl an Personen des Teams approven können) getroffen werden, um einen Service z.B. im Lifecycle Prozess zu approven oder nicht.

Um die Approvals grafisch sichtbar zu machen, wurde mit ScriptRunner ein Custom Panel in die Ticketansicht gebaut auf dem zu erkennen war, wer bereits approved hat und wieviele sowie welche Approvals noch fehlen (in der Optik eines Ampelsystems).

Ein REST Endpoint wurde erstellt um Services programmatisch verfügbar zu machen. Dies wurde u.A. im HTTP Provider von Terraform benutzt, um Deployments für Monitoring und Billing zu taggen.

Ziele des Kunden: Zur Verbesserung der Serviceerbringung und der Transparenz sowohl nach Innen aber auch nach Aussen sollte ein bestehender, rudimentärer Incident Management Prozess neu entwickelt und in Jira und JSM integriert werden. Es sollte ein hoher Grad an Automation erreicht werden um weitere Tools zu integrieren.

Auswirkung des Projekts: Das Handling von Incidents in Jira wurde stark verbessert, das Auslösen von OpsGenie Alarmen und das setzen von StatusPage Incidents musste nicht mehr von Hand stattfinden. Durch diverse Automatisierungen wurden jedliche zum Prozess gehörende Dokumente angelegt und in Teilen vorausgefüllt sowie Teams über für sie relevante Schritte im Prozess notifiziert.

Zusammenfassung: Das eigentliche Incident Handling wurde aus dem generischen Helpdesk Projekt entkoppelt und in ein eigenes JSM Projekt ausgelagert.

So war eine 1-zu-n Beziehung zwischen Incident und Support Cases möglich. Es wurde Automatisierungen entwickelt, die relevante Status' eines Incident Tickets in die zugehörigen Support Tickets geschrieben haben. Damit ist das manuelle Informieren gegenüber vor allem auch mehreren Kunden entfallen.

Prozessrelevante Logiken wie z.B. das Notifizieren von dedizierten Incident Managern oder auch der Geschäftsleitung ab einer bestimmten Kritikalität wurden vollständig automatisiert.

Per ScriptRunner sind eigene Skripte entstanden, die bspw. den Workflow des Tickets bei Bedarf via API Integration in StatusPage abgebildet haben. Im Ticket Flow gab es die Möglichkeit Textbausteine (wählbar durch jeden Mitarbeitenden) oder Freitext (wählbar durch eingeschränkten Personenkreis) für StatusPage Updates auszuwählen.

Es wurden diverse eigene Bibliotheken entwickelt um z.B. StatusPage, OpsGenie aber auch VMware und OpenStack anzubinden. Diese Bibliotheken wurden generisch aufgebaut, um sie auch ausserhalb der Incident Prozess Implementierung nutzen zu können.

Bei bestimmten Schritten im Ticket Flow wurden automatisiert Confluence Seiten erstellt und mit Inhalt vorbefüllt (z.B. Post Mortem Analysis und Incident Report).