Die meisten Unternehmen sind dabei, ihre IT-Abläufe umzugestalten – von vor Ort in die Cloud, von physisch zu virtuell. Und mit dem Ausbruch von COVID-19 beschleunigen nahezu alle Unternehmen ihren Modernisierungsprozess.
Dies ist der Fall bei CSG, einem 35 Jahre alten Anbieter von Kundenbindungsdiensten für die Telekommunikations- und Kabelbranche. Das Unternehmen stattet die größten Kabelanbieter Nordamerikas mit digitalen Lösungen aus, um Kundenbeziehungen, Abrechnung und Betrieb effizienter zu verwalten.
Vor einigen Jahren hatte CSG mit den Einschränkungen des Alterungsprozesses zu kämpfen, die durch das mangelnde Engagement neuer Anwendungsbesitzer noch verstärkt wurden. So wie CSG seinen Kunden bei der Modernisierung hilft, war es auch an der Zeit, die eigenen Betriebsabläufe weiterzuentwickeln.
Erica Morrison, Vizepräsidentin für Softwareentwicklung bei CSG, wurde damit beauftragt, dem Operational Engineering-Team von CSG beim Aufbau einer DevOps-Organisation und -Kultur zu helfen – obwohl sie zuvor nur im Softwarebereich gearbeitet hatte.
„Für einen Entwickler ist es ein Schock, plötzlich in die Betriebswelt geworfen zu werden und die Herausforderungen, mit denen er konfrontiert wird, direkt vor Augen zu haben“, sagt sie. „Ich weiß die Arbeit unserer gesamten Einsatzteams jetzt definitiv mehr zu schätzen.“
Durch die Einführung bewährter Entwicklungsmethoden in einem Team, das früher nur aus Betriebsabläufen bestand, war CSG in der Lage, eine Reihe von Herausforderungen zu bewältigen: die Nutzung von Funktionen von F5, die bisher nicht verwendet wurden, das Hinzufügen neuer Tools und die Einführung einer Unternehmenslizenzvereinbarung, die die erforderliche Flexibilität bot.
Erin Garrigan war damals der Scrum Master des Teams. Als heutige Vorgesetzte berichtet sie von mehreren Initiativen, die zusammen das ergaben, was CSG im Jahr 2016 als Fünfjahres- oder sogar Zehnjahresplan vor Augen hatte.
„Aus technischer Sicht hatten wir zu viele manuelle Prozesse im Zusammenhang mit Änderungen und nicht genügend Einblick darin, wer was tat“, sagt sie. „Viele verschiedene Teams hatten Zugriff auf unsere Geräte und wir hatten nicht die robusten Kontrollen, die wir dafür benötigten.“
Dies waren nicht die einzigen Probleme. Die gesamte Infrastruktur war instabil und da es an einer allgemeinen Zustandsüberwachung und Warnfunktion mangelte, war sich das Team oft nicht bewusst, wenn die Geräte in einem schlechten Zustand waren, bis es von Kunden von den Problemen erfuhr. Ein weiteres wichtiges Anliegen war die Modernisierung der Hardware.
Das erste und größte Projekt des Teams bestand darin, mithilfe von F5 iApps alles in den Quellcode zu bringen. Da die Prozesse bei CSG bisher manuell waren, führten sie zunächst einen nächtlichen Export der Gerätekonfigurationen ein, wodurch das Team Einblick in die Konfigurationen erhielt. Schließlich gingen sie zu einem neuen Paradigma über, bei dem der Quellcode nun steuert, was auf den Geräten ist.
„Innerhalb eines Jahres haben wir aus manuellen Änderungen und dem Infrastruktur-als-Code-Konzept über 100 iApps erstellt“, sagt Garrigan. „Der enorme Aufwand, jede manuelle Einrichtung in iApps zu kodifizieren, war beträchtlich, aber wir haben einige Tools entwickelt und das Problem mit der Zeit in den Griff bekommen.“
Da die Infrastruktur nun als Code definiert ist, kann das Team die Funktionen seiner Apps herausarbeiten. Operational Engineering unterstützt Dutzende Anwendungsteams in einer dynamischen Serverumgebung, die täglich mehrere Änderungsanforderungen erhält. Durch die Implementierung eines Self-Service-Prozesses konnten interne Verbraucher aus den Anwendungsteams von CSG mithilfe eines Sandbox-BIG-IP-Geräts Änderungen konfigurieren, prüfen und zur Validierung und Codeüberprüfung durch eine Pipeline leiten. Sie haben außerdem ein weiteres Tool erstellt, mit dem diese Benutzer die Änderungen selbst in die Produktion übertragen können.
„Zu diesem Zeitpunkt boten wir tatsächlich Lastausgleich und Anwendungsbereitstellung als Service an“, sagt Phil Todd, Leiter der Softwareentwicklung bei CSG. „Wir verwenden Jenkins, um die meisten unserer Self-Service-Automatisierungsfunktionen sowie unsere Berichtsfunktionen zu steuern. Und wir haben einen Teil unseres eigenen C#-Codes geschrieben, um diese Funktionalität im Hintergrund zu implementieren.“
Ein weiteres wichtiges Bedürfnis bei der großen und vielfältigen Palette von Anwendungen von CSG war es, diese Änderungen transparent zu machen. In ihrer bislang manuellen Welt konnten sich die Anwendungsteams durch überlappende Änderungen gegenseitig in die Quere kommen. Das Auffinden von fehlerhaftem Code war ein komplexeres Rätsel als nötig.
„Die Umgebung wäre einfach komisch“, sagt Garrigan. „Wir wissen nicht, warum es schief ist, nur, dass jemand etwas getan haben muss.“
Die manuellen Prozesse führten außerdem dazu, dass das Team nach der Identifizierung eines Problems häufig den Einzelnen ausfindig machen musste, der die Änderung vorgenommen hatte, um das Problem vollständig zu verstehen.
Zur Lösung des Problems implementierte das Team F5 BIG-IQ und begann mit der Einführung von Änderungen rund um den Änderungsprozess selbst, indem es automatisierte Berichte zur Systemintegrität und den allgemeinen Auswirkungen der Änderungen einführte. Sie haben außerdem ein Grafana-Dashboard erstellt, um mehr als tausend Endpunkte zu überwachen und so die Validierung von Änderungen zu unterstützen. Mit der Konfiguration als Code und der Automatisierung rund um die Bereitstellungen konnte CSG einen echten Einblick in alle vorgenommenen Änderungen gewinnen.
Laut Todd hat dies zu einem der größten Unterschiede zwischen der heutigen Umgebung von CSG und den manuellen Prozessen in der Vergangenheit geführt: Wenn durch eine Änderung etwas kaputt geht, beträgt die durchschnittliche Reparaturzeit jetzt nur noch Minuten. Früher konnte es Stunden dauern, bis das Team das Problem untersucht und gelöst hatte.
„Wenn Sie sich bei Kibana anmelden, werden alle Änderungen protokolliert – welche Version bereitgestellt wurde und welche die vorherige Version war“, sagt er. „Ohne uns also zu fragen, warum es nicht funktioniert, stellen wir die vorherige Version des Codes einfach per Knopfdruck in Jenkins bereit.“
Der nächste Entwicklungsschritt bestand darin, Skalierbarkeit, Flexibilität und Stabilität der Infrastruktur zu berücksichtigen. Obwohl sie Dutzende von physischen Hardwaregeräten, darunter auch F5 VIPRIONS, betrieben, liefen die meisten Anwendungen über nur zwei: eines für den externen Datenverkehr aus dem Internet und ein anderes für den internen Datenverkehr.
Dadurch kam es zu großen Gruppengrößen, die im Falle eines Ausfalls ein größeres Risiko für die Organisation darstellten. „Wenn eines dieser Geräte ausfiel, hatte das im Prinzip Auswirkungen auf jedes Produkt und jeden Kunden“, sagt Todd.
Gleichzeitig begann man, die Anwendungen von CSG in die private und die öffentlichen Clouds des Unternehmens zu verlagern, doch die Möglichkeiten des Systems, sich in diese Umgebungen zu erweitern, waren begrenzt – und eine Migration zu AWS war nicht möglich.
Auch bei der Lösung dieser Probleme war die Virtualisierung von entscheidender Bedeutung. Durch die Bereitstellung von Infrastruktur als Code in iApps wurde die Flexibilität erreicht, die Gesamtgröße der Fehlergruppen zu verringern und dadurch eine anwendungsspezifischere Lastverteilung zu erreichen. Darüber hinaus wurde dadurch die Tür für eine Weiterentwicklung hin zur öffentlichen Cloud geöffnet, falls dies erforderlich sein sollte.
„Wir hatten vor Kurzem einen Ausfall und ein Produkt war davon betroffen“, sagt Morrison. „Vor etwas mehr als einem Jahr wären alle Produkte davon betroffen gewesen. Durch die Aufteilung mehrerer Instanzen in kleinere Gruppen haben wir bei Bedarf auch die Möglichkeit, ein Failover durchzuführen, wobei der Explosionsradius sehr gering ist. Die Investition in Stabilität hat also bereits einige gute Nachrichten für unsere internen und externen Kunden gebracht.“
Durch die Umstellung von F5 BIG-IP Virtual Editions auf eine neue Enterprise-Lizenzvereinbarung (ELA) von F5 konnte CSG weitere betriebliche Flexibilität und Kosteneinsparungen erzielen. Früher arbeitete die Gruppe hauptsächlich innerhalb eines Rechenzentrums am Firmensitz in Omaha. Ihre Lösung zur Notfallwiederherstellung bestand lediglich darin, die Dienste in einem Rechenzentrum eines Drittanbieters bereitzustellen, falls die Ereignisse dies erforderlich machten.
Als das Team vor ein paar Jahren ein zweites Rechenzentrum aufbaute, wollte es die Hochverfügbarkeit dieser Rechenzentren testen, aber die bisherige Lizenzvereinbarung und die physische Hardware schränkten seine Möglichkeiten ein. Mit der festen Hardware stand das Unternehmen vor Herausforderungen hinsichtlich Skalierbarkeit, Verfügbarkeit und der Möglichkeit zur Expansion in die öffentliche Cloud.
„Der Wechsel zu einem F5-Unternehmenslizenzvertrag und der virtuellen Lösung gab uns die Freiheit, das zu etablieren, was wir wollen, wann wir wollen, und dieses zweite Rechenzentrum hinzuzufügen“, sagt Todd. „Und es hat uns die Freiheit gegeben, die Bedürfnisse unserer internen Kunden zu erkunden und sehr gut darauf einzugehen.“
Heute verfügt das Team über mehr Flexibilität, um sich weiterzuentwickeln und eine hohe Verfügbarkeit verschiedener Dienste zu erreichen.
Nach der Modernisierung seiner Umgebung hat das Operations Engineering-Team von CSG nun Raum für die Planung der Zukunft. Das Team möchte die Sicherheitsfunktionen von F5 weiter ausbauen, Referenzarchitekturen für die Verwendung von BIG-IP und Amazon Web Services (AWS) zusammenstellen und mit NGINX neue Funktionen einführen. Und mit einem ELA konnte das Unternehmen das vorhandene Budget auf neue Architekturen und Funktionssätze umstellen.
Morrison arbeitet außerdem mit den Produktbesitzern von CSG an einem neuen Fahrplan, um auf dem bisher Erreichten aufzubauen. Dazu gehören die Verbesserung der Systemüberwachung und -warnung, das Hinzufügen neuer Monitore und die Entwicklung eines Kompetenzzentrumsmodells für die Anwendungsbereitstellung.
Aus einer Gesamtbetrachtung heraus, sagt sie, sei es ein schöner Ort. Zu diesem Zeitpunkt hat das Team fast alle Projekte seiner ursprünglichen Fünfjahresvision verwirklicht. Mit den Partnerschaften, Self-Service-Funktionen und Konfigurationen, die sie aufgebaut haben, müssen sie nur noch mehr Verantwortung für die Apps an die App-Teams selbst übertragen.
„Zum ersten Mal sagen wir: Was machen wir als nächstes?“, sagt sie. „Wir haben so große Fortschritte gemacht, dass wir uns nicht mehr selbst aus der Patsche helfen. Jetzt kommt es darauf an, proaktiv zu handeln und auf dem soliden Fundament aufzubauen, das wir geschaffen haben.“