Für die Bereitstellung eines ITSM Projekts auf Basis von Atlassian Data Center sollte eine hochverfügbare Systemlandschaft entworfen, entwickelt und aufgebaut werden.
Verbesserung des Lifecycle Managements, stark reduzierte Downtimes bei Wartungsarbeiten sowie Steigerung der Performance und Verfübarkeit. Reproduzierbarkeit von Deployments und damit schnelleres Aufbauen neuer Umgebungen.
Ein Live-System bestehend aus einzelnen Services war bereits vorhanden. Es wurde ein Konzept entwickelt um zum einen parallel neue, hochverfügbare Umgebungen (Prod, Test, Dev) automatisiert deployen zu können und ein Migratiosszenario geschaffen um so unterbrechungsfrei wie möglich die Einzelservices in die neuen Cluster Systeme zu migrieren.
Es wurden eigene Ansible Rollen entwickelt, die gleichzeitig unkompliziert deployed werden konnten aber auch den speziellen Anforderungen des Kunden entsprachen.
Rollen für Cluster Systeme konnten sowohl ein Bootstrapping als auch Config Changes im Live-Betrieb vornehmen und waren dennoch idempotent.
Mit Hilfe von Plattform Repositories und den versionierten, entwickelten Ansible Rollen konnten reproduzierbare Umgebungen in Code definert werden. Changes waren damit gut nachvollziehbar und auditierbar.
Nach einem Merger von vier Firmen sollten diverse kleinere Atlassian Data Center und Cloud Instanzen in eine große Instanz je Tool konsolidiert werden
Senkung der Lizenzkosten um ~50% sowie einheitliches und kollaboratives Arbeiten aller Mitarbeitenden in einem einzigen Toolstack.
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.
Im Rahmen eines Pilotprojekts für agile Arbeitsmethoden sollten zwei Teams von der grünen Wiese hin zu einem Scrum Prozess unter Zuhilfenahme von Jira Cloud geführt werden. Weiterhin sollte während der Transformation eine auf Excel basierte "Ticketliste" mit mehreren zehntausend Zeilen in ein Jira Project überführt werden, um einen Showcase für Jira im Unternehmen darzustellen.
Awareness für agile Arbeitsmethoden wurde geschaffen, was zu mehr Transparenz in den Teams aber auch im Upper Management geführt hat wodurch Fehlervektoren in der Projektplanung minimiert und die allgemeine Effizienz der Planung gesteigert werden konnte.
Nach der Benennung zweier Teams aus der Produktentwicklung für das Pilotprojekt "Scrum einführen" wurde anhand von Keyuser Gesprächen eine Anforderungsliste an Jira erstellt und etwaig zu benutzende Plugins eruiert.
Jira Cloud wurde für den Grossteil des Unternehmens geplant und aufgesetzt.
Ein Gruppen- bzw. Berechtigungskonzept wurde direkt mit entwickelt und implementiert.
Parallel zum Scrum Enablement wurden die Projektteams sowie weitere Stakeholder individuell in Jira geschult.
Screens, Workflows, Issue Types usw. wurden an die jeweiligen Team Anforderungen angepasst bzw. erstellt. Mittels Jira Automation wurden einfache Regeln erstellt, die den Teams bei der täglichen Arbeit helfen sollten.
Als Side-Quest wurde ein PoC erstellt um eine historisch gewachsene Excel-Liste in Jira abzubilden, damit die Mitarbeitenden kollaborativ daran arbeiten können und jedes Listen Element ein eigenständiges Objekt wird (statt die komplette Excel Liste als Entität zu verwenden und damit Kolleginnen zu "blocken").
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.
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.
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).
Der bislang in Confluence gepflege Servicekatalog sollte in Jira mit Assets als Datenbasis implementiert werden.
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.
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.
Die bislang in AWS aufgebauten Kundenplattformen sollten stabilisiert sowie das Deployment standartisiert werden. Komplexität sollte aus dem grundlegenden Setup genommen werden. Es sollte ein zentrales Log Management implementiert werden.
Durch eine aufgebrochene Komplexität und Migration aus AWS heraus, konnten gleichzeitig Stabilität gewährt als auch monatliche Kosten reduziert werden. Debugging fuer das Ops-Team wurde durch zentrale, aggregierte Logs vereinfacht. Ebenso konnte ein Großteil von neuen Deployments vollautomatisiert passieren, was weniger benötigte Zeit und weniger Fehleranfälligkeit zur Folge hatte.
Nach einer Bestandsanalyse der bestehenden Kunden Setups wurde ein neue zur Workload passende Infrastruktur- und Deployment-Strategie entwickelt.
Die Entscheidung wurde gemäß des KISS Prinzips getroffen und neue Plattformen sollten vollumfänglich vom Team selbst in klassischen VMs bei einem europäischen Hoster betrieben werden.
Terraform Meta-Module wurde entwickelt um das IaaS Deployment stark zu vereinfachen, einen Standard zu schaffen und die Deployment Zeit zu verringern.
Für alle benötigten Services wurden Ansible Rollen geschrieben und diese dann in Meta-Rollen gebündelt; ebenfalls um einen Standard zu schaffen und ein initiales Deployment stark zu vereinfachen.
Um die Terraform und Ansible Meta Rollen wurden Plattform Templates gebaut. Ein Kunden Repository konnte so mit wenig User Input statt vormals dem Schreiben langer Vars Files angelegt werden.
Um dynamisch auf Kundenanforderungen zu reagieren, wurde Consul als "Config Store" eingesetzt und in viele Ansible Rollen integriert. Ansible Defaults konnten per Lookup direkt aus Consul befüllt werden, weiterhin hatten viele Config Templates einen generischen Fallback dessen Inhalt ebenfalls aus Consul bezogen werden konnte.
Die Online Buchungsplattform stand in der Peak Season unter Volllast, was zu Ausfällen führte die der bisherige Hoster nicht lösen konnte. Die Plattform sollte in einem sehr kurzen Zeitfenster ad hoc zu einem neuen Hoster umgezogen werden. Primäres Ziel war die Peak Season über online zu bleiben um das Geschäft nicht weiter zu gefährden und danach die komplette Plattform neu zu designen und zu bauen.
Der Geschäftsbetrieb in der Peak Season konnte aufrecht erhalten werden. Die Plattform konnte in den Folgemonaten weiterentwickelt und technologisch auf den neusten Stand gebracht werden. Dies resultierte in höherer Stabiltät, Verfügbarkeit und Performance. Folgende Peak Seasons waren kein betriebliches Risiko mehr.
Die gesamte Plattform wurde im laufenden Betrieb mit kurzen Downtimes von einem Hoster zum Anderen migriert. Da ein Teil der Configs nicht oder nicht schnell genug verfügbar war, musste ein Reverse Engineering der App- und Datenbankserver stattfinden.
Nach dem "Überstehen" der Peak Season wurde in intensiven Workshops mit dem Kunden ein neues Architekturbild entworfen um die Plattform stabiler und ausfallsicherer zu machen sowie schneller bereit stellen zu können. Ebenso sollte sowohl Scale up als auch Scale out ohne große Vorlaufzeit möglich sein.
Die Appserver wurden stateless entwickelt und hinter einen großen Pacemaker/Corosync HAProxy Cluster gebaut. Der Application Code wurde aus einem hochverfügbaren DRBD Cluster bezogen, während die Datenbanken in einen Multi Primary Cluster (MariaDB + Galera) ausgelagert wurden.
Bis auf den Application Code wurden alle Bestandteile der Plattform mit Ansible und Terraform automatisiert. Es wurden drei feste Stages aufgebaut und betrieben. Durch den Automatisierungs Code konnte der Kunde jederzeit kleine Entwicklungsumgebungen beauftragen, die per Knopfdruck in kurzer Zeit zur Verfügung gestellt werden konnten.
Es wurde eine an DevOps angelehnte Arbeitsmethodik zwischen Kunde (bzw. Softwarehersteller) und Hoster entwickelt, woraus viele neue Features der Plattform entstanden sind.
In Peak Seasons konnte bzw. wurde die Plattform in die Breite gezogen, in eher ruhigen Zeiten wurde sie verkleinert um die Kosten so effizient wie möglich zu halten.
Ein schnell wachsendes Startup brauchte ein dediziertes Team um Linux Services für Kunden entwickeln, bereitstellen und betreiben zu können.
Neukunden konnten gewonnen werden und Bestandskunden konnten weitere Services erbracht werden. Das Produktportfolio des Unternehmen konnte vergrössert und weitere Talente für die Firma gewonnen werden.
Das initiale Team wurde durch drei Mitarbeitende aufgestellt, die bereits für das Unternehmen tätig waren.
In Eigeninitiative und teilweise mit Hilfe von Recruitment Partnern wurden insgesamt vier neue Talente für das Team gesucht und gefunden.
Das Team wurde hin zu einer Scrum entsprechenden Arbeitsmethodik transformiert.
Drei Senior und vier Junior Engineers bildeten das finale Team. Periodischer Wissenaustausch wurde gefördert, so dass sich jedes Team Mitglied weiterentwickeln konnte.
Als einer der ersten Provider für einen innovativen Cloud Ressourcen Marktplatz sollte das Unternehmen technisch in diesen Marktplatz integriert werden.
Das Unternehmen war einer der ersten Provider für den Marktplatz und konnte gekaufte Resource Contracts zuverlässig aus deutschen Rechenzentren bereitstellen. Ein weiterer Sales Channel konnte so eröffnet und ausgebaut werden, was positiv zum Umsatz und der Reputation beigetragen hat. OpenStack Know-How im Unternehmen konnte auf- und ausgebaut werden.
Initial wurde eine OpenStack Plattform mit einer zentralen, hochverfügbaren Control Plane und zwei Availability Zones für Compute in zwei deutschen Rechenzentren entworfen und aufgebaut.
Gemeinsam mit dem Marktplatz Betreiber wurde die Middleware zwischen OpenStack und Marktplatz integriert, ausgiebig getestet und auch weiterentwickelt.
Es wurden klassische Cattle Workloads erwartet, weswegen die Hardware und der Grad an Hochverfügbarkeit bewusst effizient ausgelegt wurden. Der Fokus lag auf schnellem Kommissionieren und Dekommissionieren von Cloud Instanzen.
Parallel zur Marktplatz Integration wurde ein PoC durchgeführt um HPC Workloads auf speziellen Hypervisoren die mit Infiniband angebunden waren auszuführen.