sewshyi

Hier meine neue Version: Thema der Projektarbeit----------------------- Optimierung der Build-Server-Infrastruktur zur Behebung von CI/CD-Pipeline-Engpässen bei einem mittelständischen Softwareunternehmen Geplanter Bearbeitungszeitraum------------------------------- bla bla Ausgangssituation----------------- Das Unternehmen ist ein Softwareentwicklungsunternehmen mit rund 29 Mitarbeitern, das sich auf die Entwicklung von E-Commerce-Lösungen und webbasierten Anwendungen spezialisiert hat. Es betreibt eine hybride IT-Infrastruktur: Der Großteil der Systeme – darunter Netzwerkkomponenten, Server und die CI/CD-Infrastruktur – ist auf physischen Servern im unternehmenseigenen Serverraum untergebracht; einzelne Dienste laufen ergänzend in der Cloud. Als Auszubildender bin ich in der IT-Abteilung eingesetzt, die Aufgaben aus den Bereichen Systemadministration und DevOps (Development Operations – die Verzahnung von Softwareentwicklung und IT-Betrieb) vereint und für Betrieb sowie Weiterentwicklung dieser Infrastruktur verantwortlich. Die Entwicklungsteams verwalten ihre Softwareentwicklungsprozesse über eine selbst gehostete GitLab-Instanz. GitLab ist eine webbasierte Plattform zur Versionsverwaltung und Projektorganisation. Ein zentraler Bestandteil davon ist die CI/CD-Pipeline (Continuous Integration / Continuous Deployment – automatisiertes Bauen, Testen und Ausliefern von Software), die nach jedem Code-Push automatisch ausgeführt wird. Für die Ausführung dieser Pipelines betreibt die IT-Abteilung derzeit fünf sogenannte GitLab Runner – Prozesse, die auf dedizierten physischen Servern im Serverraum laufen und die einzelnen Pipeline-Aufgaben (sog. Jobs) entgegennehmen und verarbeiten. Vier dieser Runner nutzen den Docker-Executor, bei dem jeder Job in einem isolierten Container (einer abgeschotteten Softwareumgebung) ausgeführt wird. Ein weiterer Runner arbeitet mit dem Shell-Executor, bei dem Jobs direkt auf dem Host-System ausgeführt werden und damit keine Prozessisolation zwischen den Jobs besteht. Die Verwaltung der gesamten Infrastruktur – einschließlich der Runner-Konfiguration – erfolgt über IaC (Infrastructure as Code), konkret über Ansible-Playbooks (automatisierte Konfigurationsskripte). Im Zuge des Unternehmenswachstums und der zunehmenden Anzahl paralleler Entwicklungsprojekte kommt es vermehrt zu Engpässen in der Pipeline-Ausführung: Jobs werden in Warteschlangen eingereiht und verzögern den Entwicklungsworkflow der Teams. Auswertungen des bestehenden Monitoring-Systems – bestehend aus Prometheus (einem System zur Metrikerfassung) und Grafana (einem Werkzeug zur grafischen Darstellung von Metriken) – belegen diesen Engpass messbar: Die durchschnittliche Wartezeit eines Jobs in der Queue beträgt ca. 13–15 Minuten, während die eigentliche Ausführungsdauer lediglich ca. 3 Minuten beträgt. Jobs warten also im Schnitt etwa fünfmal länger auf ihren Start als die Ausführung selbst dauert. In der zuletzt betrachteten Woche wurden insgesamt 2.906 Pipeline-Jobs ausgeführt. Die vorliegenden Metriken belegen den Engpass, lassen jedoch keine eindeutige Aussage über dessen Ursache zu: Es ist bisher ungeklärt, ob die langen Queue-Zeiten auf eine unzureichende Runner-Kapazität, eine suboptimale Konfiguration der bestehenden Runner, ineffiziente Pipeline-Definitionen der Entwicklungsteams oder eine Kombination dieser Faktoren zurückzuführen sind. Ohne diese Ursachenkenntnis wäre jede Maßnahme – etwa die Beschaffung zusätzlicher Hardware – möglicherweise wirkungslos oder unwirtschaftlich. Eine fundierte Analyse ist daher die notwendige Grundlage für jede Entscheidung. Projektziel----------- Ziel des Projekts ist die Erweiterung und Optimierung der CI/CD-Build-Infrastruktur, sodass die bestehenden Pipeline-Engpässe nachhaltig behoben und die Entwicklungsprozesse des Unternehmens dauerhaft entlastet werden. Da bisher keine gesicherte Erkenntnislage über die genaue Ursache der Engpässe besteht, werden die bestehenden Serverkapazitäten, Systemkonfigurationen und Auslastungsprofile zunächst bewertet. Auf dieser Grundlage werden verschiedene Lösungsansätze – darunter physische Kapazitätserweiterungen, Virtualisierungskonzepte, Autoscaling sowie Konfigurationsoptimierungen – anhand eines strukturierten Kriterienkatalogs verglichen. Die geeignetste Lösung wird anschließend in die bestehende Infrastruktur integriert. Die Entscheidung berücksichtigt dabei ausdrücklich: - Wirtschaftlichkeit: Wann rechnet sich welcher Ansatz? Vergleich der Gesamtbetriebskosten (TCO) aller Alternativen - Sicherheit: Schutzbedarfsanalyse, Build-Isolation, Systemhärtung, Secret Management - Netzwerkintegration: Einbindung in die bestehende Infrastruktur (VLAN-Zuordnung, Firewall-Regelwerk) - Wartbarkeit: Überführung der Lösung in das bestehende IaC-System (Ansible), sodass die Infrastruktur reproduzierbar bleibt Alternativen, die aus technischen oder wirtschaftlichen Gründen ausscheiden, werden dokumentiert und mit Begründung ausgeschlossen. Quantitative Projektziele (messbar): - Reduktion der durchschnittlichen Pipeline-Wartezeit von aktuell ca. 13–15 Minuten auf unter 5 Minuten - Verfügbarkeit der Infrastruktur nach Umsetzung von mindestens 99 % Qualitative Projektziele (angestrebter Zustand): - Vollständige Netzwerkintegration der umgesetzten Lösung gemäß Sicherheitskonzept - Systemhärtung und Sicherstellung der Build-Isolation auf allen betroffenen Systemen - Nahtlose Einbindung der Konfiguration in das bestehende IaC-System (Ansible) - Vollständige Dokumentation für Administratoren und Benutzer Zeitplanung----------- 1. Analysephase (10 h) - Vertiefende IST-Analyse der Infrastruktur (Netzwerkstruktur, Kapazitäten, Konfiguration): 3 h - Infrastrukturanalyse: Serverkapazitäten, Systemkonfiguration und Auslastungsverteilung: 3 h - Anforderungserhebung mit Stakeholdern (Abteilungsleiter Entwicklung): 2 h - Recherche und Vorauswahl möglicher Lösungsansätze: 2 h 2. Planungsphase (10 h) - Erstellung eines Kriterienkatalogs für die Lösungsbewertung: 1 h - Evaluation und Vergleich der Lösungsalternativen inkl. Ausschlussbegründungen: 3 h - Wirtschaftlichkeitsbetrachtung (TCO-Analyse): 2 h - Schutzbedarfsanalyse & Sicherheitskonzept: 2 h - Detailplanung der gewählten Lösung (Netzwerk-, Konfigurationsplanung): 2 h 3. Durchführungsphase (12 h) - Vorbereitung und Bereitstellung der Infrastruktur: 1 h - Betriebssysteminstallation & Systemhärtung: 2 h - Netzwerkintegration (VLAN-Konfiguration, Firewall-Regeln): 3 h - Installation & Konfiguration der GitLab-Runner-Software: 2 h - Überführung der Konfiguration in Ansible (IaC): 2 h - Funktionstests & Lasttests: 2 h 4. Abschlussphase (8 h) - Soll-Ist-Vergleich & Qualitätssicherung: 1 h - Benutzerdokumentation: 2 h - Administratordokumentation: 2 h - Projektdokumentation (Abschlussbericht): 3 h Gesamt: 40 h Anlagen------- - Vereinfachtes Netzwerkdiagramm der bestehenden Infrastruktur - Übersicht der aktuellen Server-Ressourcen (anonymisiert) - Logisches Netzwerkdiagramm: Kommunikationswege zwischen GitLab-Instanz, Runner-Servern und Firewall Ist das zu wenig/viel? Präsentationsmittel------------------- Laptop, Beamer, Präsentation (Slides), ggf. Live-Demo der optimierten Pipeline-Ausführung

Vielen Dank für das Feedback, @charmanta , @Morrigan und @ickevondepinguin ! Das hilft mir wirklich weiter. Der Hinweis auf den FIDV-Schwerpunkt war berechtigt , der alte Antrag hat zu viel Gewicht auf die Metrik-Auswertung gelegt, was eher nach Datenanalyse klingt. Ich habe den Antrag daraufhin grundlegend überarbeitet. Wie kann ich jetzt fortfahren damit ich nochmal Feedback bekomme? Neuer Post? oder Hier einfach als Antwort und makieren mit edited oder sowas?

Geplanter Bearbeitungszeitraum bla bla --- AusgangssituationDas Ausbildungsunternehmen ist ein Softwareentwicklungsunternehmen mit rund 29 Mitarbeitern, das sich auf die Entwicklung von E-Commerce-Lösungen und webbasierten Anwendungen spezialisiert hat. Das Unternehmen gliedert sich in mehrere Entwicklungsteams sowie eine IT-Abteilung, die für den Betrieb und die Weiterentwicklung der internen Infrastruktur zuständig ist. Der Auszubildende ist in dieser IT-Abteilung eingesetzt, die Aufgaben aus den Bereichen Systemadministration und DevOps (Development Operations – die Verzahnung von Softwareentwicklung und IT-Betrieb) vereint. Die Entwicklungsteams verwalten ihre Softwareentwicklungsprozesse über eine selbst gehostete GitLab-Instanz. GitLab ist eine webbasierte Plattform zur Versionsverwaltung und Projektorganisation. Ein zentraler Bestandteil davon ist die CI/CD-Pipeline (Continuous Integration / Continuous Deployment – automatisiertes Bauen, Testen und Ausliefern von Software), die nach jedem Code-Push automatisch ausgeführt wird. Für die Ausführung dieser Pipelines betreibt die IT-Abteilung derzeit fünf sogenannte GitLab Runner – Prozesse, die auf dedizierten physischen Servern im unternehmenseigenen Serverraum laufen und die einzelnen Pipeline-Aufgabe (sog. Jobs) entgegennehmen und verarbeiten. Vier dieser Runner nutzen den Docker-Executor, bei dem jeder Job in einem isolierten Container (einer abgeschotteten Softwareumgebung) ausgeführt wird. Ein weiterer Runner arbeitet mit dem Shell-Executor, bei dem Jobs direkt auf dem Host-System ausgeführt werden. Die Verwaltung der gesamten Infrastruktur – einschließlich der Runner-Konfiguration – erfolgt über IaC (Infrastructure as Code), konkret über Ansible-Playbooks (automatisierte Konfigurationsskripte).. Im Zuge des Unternehmenswachstums und der zunehmenden Anzahl paralleler Entwicklungsprojekte kommt es vermehrt zu Engpässen in der Pipeline-Ausführung: Jobs werden in Warteschlangen eingereiht und verzögern den Entwicklungsworkflow der Teams. Auswertungen des bestehenden Monitoring-Systems – bestehend aus Prometheus (einem System zur Metrikerfassung) und Grafana (einem Werkzeug zur grafischen Darstellung von Metriken) – zeigen, dass die durchschnittliche Wartezeit eines Jobs in der Queue bei ca. 13–15 Minuten liegt. Die durchschnittliche Ausführungsdauer eines Jobs beträgt dabei lediglich ca. 3 Minuten – Jobs warten also im Schnitt etwa fünfmal länger auf ihren Start als die eigentliche Ausführung dauert. In der zuletzt betrachteten Woche wurden insgesamt 2.906 Pipeline-Jobs ausgeführt. Dies führt zu verlängerten Feedbackzeiten für Entwickler sowie einem messbaren Rückgang der Entwicklungsgeschwindigkeit. Es ist bisher ungeklärt, ob die Engpässe auf eine unzureichende Anzahl von Runnern, eine suboptimale Konfiguration der bestehenden Infrastruktur oder strukturelle Ursachen (z. B. ineffiziente Pipelines) zurückzuführen sind. Eine fundierte Analyse der Ist-Situation sowie eine Bewertung möglicher Lösungsansätze sind daher erforderlich. --- ProjektzielZiel des Projekts ist die systematische Analyse der bestehenden GitLab-Runner-Infrastruktur sowie die Identifikation und Behebung der Pipeline-Engpässe. Dabei wird zunächst geprüft, ob Optimierungspotenzial in der bestehenden Konfiguration besteht, bevor eine Erweiterung der Infrastruktur in Betracht gezogen wird. Verschiedene Lösungsansätze – darunter physische Erweiterungen, virtualisierungsbasierte Konzepte sowie containerbasierte und autoskalierbare Architekturen – werden anhand eines strukturierten Kriterienkatalogs evaluiert. Die Bewertung berücksichtigt technische Anforderungen (Skalierbarkeit, Build-Isolation, Netzwerkintegration), Sicherheitsaspekte (Host-Härtung, Secret Management) sowie wirtschaftliche Faktoren (Beschaffungs- und Betriebskosten,TCO-Vergleich). Erfolgskriterien: - Reduktion der durchschnittlichen Pipeline-Wartezeit - Steigerung der parallelen Pipeline-Kapazität - Einhaltung der Sicherheitsanforderungen gemäß Schutzbedarfsanalyse - Wirtschaftliche Vertretbarkeit der gewählten Lösung --- Zeitplanung (gesamt 40 Stunden) 1. Analysephase (10 h) - Erhebung der Ist-Situation (Metriken, Logs, Konfiguration): 3 h - Identifikation der Engpass-Ursachen (Rootcause-Analyse): 3 h - Anforderungserhebung mit Stakeholdern: 2 h - Recherche möglicher Lösungsansätze: 2 h 2. Planungsphase (10 h) - Erstellung eines Kriterienkatalogs: 2 h - Evaluation der Lösungsalternativen: 3 h - Wirtschaftlichkeitsbetrachtung (TCO-Analyse): 2 h - Schutzbedarfsanalyse & Sicherheitskonzept: 2 h - Entscheidungsdokumentation & Detailplanung: 1 h 3. Durchführungsphase (13 h) - Vorbereitung der Infrastruktur: 3 h - Installation & Konfiguration des/der neuen Runner(s): 3 h - Netzwerkintegration (VLAN, Firewall-Regeln): 3 h - Integration in GitLab & Anbindung an bestehende Infrastruktur: 2 h - Funktionstests & Lasttest: 2 h 4. Abschlussphase (7 h) - Soll-Ist-Vergleich & Qualitätssicherung: 1 h - Projektdokumentation: 6 h --- Anlagenbla bla --- Präsentationsmittel Laptop, Beamer, Präsentation (Slides), ggf. Live-Demo der optimierten Pipeline-Ausführung, KI?