IT-Architekt

Für eine Eigenentwicklung auf Basis von Microsoft Azure Kuberentes Cluster unterstütze ich unseren Kunden im Betrieb, damit der reibungslose Betrieb des Services sichergestellt ist. Dieses dient zur Visualisierung der Produktionsstrecke und wird auf Monitoren in den Büros verschiedener Abteilungsleiter projiziert. Das Setup bestand aus einem AKS Cluster, das einen OpenSearch Service (über OpenSearch Operator bereitgestellt) zur Sammlung von Maschinendaten bereitstellt. Diese werden von HyveMQ OnPrem an das private AKS gesendet, dort im Eventhub eingesammelt und an das OpenSearch Cluster weitergeleitet. Das Dashboarding übernimmt Grafana, welches direkt an OpenSearch angebunden ist. Die Konfiguration und den Rollout von Changes übernimmt FluxCD in Kombination mit einem privaten Github Repository,
sowie Github Actions und Terraform für das Deployment über die Github Actions. Der State von Terraform ist auf einem Volume in AKS abgelegt. Alle Zugänge und Passwörter wurden verschlüsselt im Git Repo abgelegt. Ich habe die Produktionsumgebung um eine Entwicklungsumgebung erweitert, um bspw. Updates vorab in einer sicheren Umgebung testen zu können, bevor in der Produktion ausgerollt wird. Dazu wird das OnPrem Setup ebenfalls clusterfähig umgebaut, damit die aktuelle VM auch für Patchzyklen offline gehen kann, ohne den Service und die Darstellung zu unterbrechen. Finden Auslastungssspitzen statt, werden diese in Prometheus bzw. im Alertmanager erkannt und über einen Teams-Channel benachrichtigt.

Die IT-Infrastruktur nutzt insgesamt knapp 1000 RedHat 7, 8 und 9 Installationen, die analysiert und optimiert werden sollen. Der Kunde wünscht, vorhandene technische Prozesse zu hinterfragen und diese samt technischer Implementierung zu optimieren. Zum einen ist eine Zuarbeit im alltäglichen Betrieb notwendig, des Weiteren gehört die Weiterentwicklung von Script und implementierten Lösungen zum Aufgabengebiet dazu. Beispielsweise die Erweiterung vorhandener Bash, Perl und Python Scripte um das Fehlerhandling zu optimieren, als auch neue Scripte zu schreiben, um verschiedene Anwendungsfälle wie die automatisierte Erweiterung von NetApp LUNs zentral anstoßen zu können. Ein weiteres Aufgabengebiet ist das Schreiben von Puppet Modulen um die Infrastruktur weiter zu automatisieren und Prozesse wie die Verteilung von SUDO Regeln oder die Anbindung an das zentrale Monitoring (mit Hilfe einer PuppetDB) zu vereinfachen. Auch das Provisioning mit Satellite 6 soll gemeinsam mit Puppet eine einfache Installation bis zum produktiven Server soll weiter optimiert und enger verzahnt werden. Dazu zählen auch die Einführung von Satellite Jobs, um Puppetläufe sowohl über APIs anzusteuern oder manuell für mehrere Ziele ausführen zu können. Durch die interne Umstrukturierung soll das verlorene Wissen durch die Einführung von neuen Standards abgefangen werden. Dazu gehört die Ablöse des produktiven Monitoring Thruk für eine neue und modernere Lösung. Zu Beginn wurde eine Bestandsanalyse der 1100 überwachten Server durchgeführt und die 11500 Services geprüft, da ausschließlich Eigenimplementierungen vorhanden sind. Anschließend wurden diese Bewertet und eine Kombination eines IT-Observability Stacks bestehend aus Prometheus, Grafana, Loki, Promtail, NGINX, Thanos, verschiedene Exporter (z. B. Node Exporter), AlertManager und Telegraf aufgebaut und vorgestellt. Aktuell befinde ich mich in der Implementierung der Vorphase zur Ablöse von Thruk mit dem vorgestellten Stack. Zum einen soll Vorhandenes (mit minimalen Änderungen) beibehalten und mit neueren Features erweitert werden. Dazu werden mit den verschiedenen Abteilungen Dashboards und Alert-Regeln gebaut werden, die sowohl im täglichen Operating unterstützen, als auch als Schnittstelle mit dem internen Kollaborationstool Webex dienen.

Ich habe ein Verkehrsunternehmen im Münchner Umland beim Upgrade des Betriebssystems unter Satellite 6.9 unterstützt. Dies beinhaltet den Austausch des Betriebssystems, den Umzug der gesamten Software und Sicherstellung, dass Satellite nach dem Umzug wie konfiguriert funktioniert. Dazu gehört ein Backup-Restore Plan samt anschließender Durchführung, die Installation und Konfiguration von RHEL8 nach Kundenstandard und Sicherstellung der Einstellungen nach dem Restore. Zudem war es notwendig, die Python Scripte und Funktionen auf Kompatibilität zu prüfen, da anschließend ein Infrastrukturupdate geplant und durchgeführt wurde. Die Clients sollen, wenn möglich nicht angefasst werden, was bedeutet, dass Zertifikate mit einer internen CA bestehen bleiben und ggfs. über einen AltDNSName ausgetsattet werden soll.