Montag um 11:512 Tage 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?
Montag um 12:452 Tage Boah das ist schwierg. Auch wenn formal alles drin ist seh ich das als FIDV Thema und würde das ablehnen. Dazu kommt dass das nicht jeder Prüfer fachlich beurteilen kann ( vermute ich )was sagen denn zb @skylake @ickevondepinguin dazu?
Montag um 16:111 Tag Wow das ist mal ein richtig praxisnahes Projekt!!!Genau so eine Infrastruktur gibt es in vielen mittelständigen Betrieben und genau das sind die Projekte an denen Azubis ebenfalls arbeiten sollten, um einmal hinter die Kulissen zu schauen.vor 3 Stunden, charmanta hat gesagt:Boah das ist schwierg. Auch wenn formal alles drin ist seh ich das als FIDV Thema und würde das ablehnen. Dazu kommt dass das nicht jeder Prüfer fachlich beurteilen kann ( vermute ich )Wenn solche Projekte nicht zugelassen werden, dann spiegelt genau das doch das Kernproblem der Ausbildung wider. Azubis müssen auch einmal praxisnahe Projekte angehen dürfen und nicht nur immer den 0815 easy Kram, den dann auch Prüfer verstehen. So lösen wir nie das Fachkräfteproblem...
Montag um 16:371 Tag vor 23 Minuten, Morrigan hat gesagt:Wenn solche Projekte nicht zugelassen werden, dann spiegelt genau das doch das Kernproblem der Ausbildung wider. Azubis müssen auch einmal praxisnahe Projekte angehen dürfen und nicht nur immer den 0815 easy Kram, den dann auch Prüfer verstehenIch habe nur EINE von drei Meinungen und bei uns könnte das benotet werden. Aber in meinem Post steht dass dieses Thema nicht so sehr in den Fachbereich des FISI passt und DAS ist das Problem. Ein Thema für ein Projekt muss dem Lehrberuf entsprechen und für mich ( das ist meine private Meinung ) ist das FIDV ... 0815 Easy haben aktuell ( wir hatten grade heute Zulassungsgespräche ) eher nur noch 1/3 der eingereichten Projekte. Da ist durchaus hippes Zeug drin
Gestern um 07:111 Tag vor 18 Stunden, charmanta hat gesagt:was sagen denn zb @skylake @ickevondepinguin dazu?Bin da geteilter Meinung.vor 19 Stunden, sewshyi hat gesagt:Die Bewertung berücksichtigt technische Anforderungen (Skalierbarkeit, Build-Isolation, Netzwerkintegration), Sicherheitsaspekte (Host-Härtung, Secret Management) sowie wirtschaftliche Faktoren (Beschaffungs- und Betriebskosten,TCO-Vergleich)Ich finde, hier steckt durchaus recht viel FiSi drin, in diesem Satz. Ich stimme aber @charmanta zu: Vom Gesamtumfang und dem IST-/SOLL-Bild sehe ich insgesamt auch eher den FIDV. Frage die ich mir aber hier immer stelle ist: Wer hat das denn vor dem FIDV bearbeitet? Ggf. bekommst du es ja hin, dass es mehr nach FiSi als nach FiDV klingt. Wobei ich sagen muss, dass das IST eben sehr den FiDV entspricht. Das SOLL und dann die Tätigkeiten in der Zeitplanung eher dem FiSi entsprechen können.Bei uns würde das Thema auch bei einem FiSi "durch kommen" und wäre eines der spannenderen Projekte. Kann da aber nur für meinen PA sprechen natürlich.
vor 4 Stunden4 h Autor 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? Bearbeitet vor 4 Stunden4 h von sewshyi
vor 4 Stunden4 h Einfach hier als Antwort nun rein, so wie deinen Dank ;) war schneller Bearbeitet vor 4 Stunden4 h von ickevondepinguin
vor 3 Stunden3 h Autor Hier meine neue Version:Thema der Projektarbeit-----------------------Optimierung der Build-Server-Infrastruktur zur Behebung von CI/CD-Pipeline-Engpässen bei einem mittelständischen SoftwareunternehmenGeplanter Bearbeitungszeitraum-------------------------------bla blaAusgangssituation-----------------Das Unternehmen ist ein Softwareentwicklungsunternehmen mit rund 29 Mitarbeitern,das sich auf die Entwicklung von E-Commerce-Lösungen und webbasierten Anwendungenspezialisiert hat. Es betreibt eine hybride IT-Infrastruktur: Der Großteil derSysteme – darunter Netzwerkkomponenten, Server und die CI/CD-Infrastruktur – ist aufphysischen Servern im unternehmenseigenen Serverraum untergebracht; einzelne Dienstelaufen ergänzend in der Cloud. Als Auszubildender bin ich in der IT-Abteilungeingesetzt, 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 selbstgehostete GitLab-Instanz. GitLab ist eine webbasierte Plattform zurVersionsverwaltung und Projektorganisation. Ein zentraler Bestandteil davon ist dieCI/CD-Pipeline (Continuous Integration / Continuous Deployment – automatisiertesBauen, Testen und Ausliefern von Software), die nach jedem Code-Push automatischausgeführt wird.Für die Ausführung dieser Pipelines betreibt die IT-Abteilung derzeit fünfsogenannte GitLab Runner – Prozesse, die auf dedizierten physischen Servern imServerraum laufen und die einzelnen Pipeline-Aufgaben (sog. Jobs) entgegennehmenund verarbeiten. Vier dieser Runner nutzen den Docker-Executor, bei dem jeder Jobin einem isolierten Container (einer abgeschotteten Softwareumgebung) ausgeführtwird. Ein weiterer Runner arbeitet mit dem Shell-Executor, bei dem Jobs direkt aufdem Host-System ausgeführt werden und damit keine Prozessisolation zwischen denJobs besteht. Die Verwaltung der gesamten Infrastruktur – einschließlich derRunner-Konfiguration – erfolgt über IaC (Infrastructure as Code), konkret überAnsible-Playbooks (automatisierte Konfigurationsskripte).Im Zuge des Unternehmenswachstums und der zunehmenden Anzahl parallelerEntwicklungsprojekte kommt es vermehrt zu Engpässen in der Pipeline-Ausführung:Jobs werden in Warteschlangen eingereiht und verzögern den Entwicklungsworkflow derTeams. Auswertungen des bestehenden Monitoring-Systems – bestehend aus Prometheus(einem System zur Metrikerfassung) und Grafana (einem Werkzeug zur grafischenDarstellung von Metriken) – belegen diesen Engpass messbar: Die durchschnittlicheWartezeit eines Jobs in der Queue beträgt ca. 13–15 Minuten, während die eigentlicheAusführungsdauer lediglich ca. 3 Minuten beträgt. Jobs warten also im Schnitt etwafünfmal länger auf ihren Start als die Ausführung selbst dauert. In der zuletztbetrachteten 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 eineunzureichende Runner-Kapazität, eine suboptimale Konfiguration der bestehenden Runner,ineffiziente Pipeline-Definitionen der Entwicklungsteams oder eine Kombination dieserFaktoren zurückzuführen sind. Ohne diese Ursachenkenntnis wäre jede Maßnahme – etwadie Beschaffung zusätzlicher Hardware – möglicherweise wirkungslos oderunwirtschaftlich. Eine fundierte Analyse ist daher die notwendige Grundlage für jedeEntscheidung.Projektziel-----------Ziel des Projekts ist die Erweiterung und Optimierung der CI/CD-Build-Infrastruktur,sodass die bestehenden Pipeline-Engpässe nachhaltig behoben und dieEntwicklungsprozesse des Unternehmens dauerhaft entlastet werden.Da bisher keine gesicherte Erkenntnislage über die genaue Ursache der Engpässebesteht, werden die bestehenden Serverkapazitäten, Systemkonfigurationen undAuslastungsprofile zunächst bewertet. Auf dieser Grundlage werden verschiedeneLösungsansätze – darunter physische Kapazitätserweiterungen, Virtualisierungskonzepte,Autoscaling sowie Konfigurationsoptimierungen – anhand eines strukturiertenKriterienkatalogs verglichen. Die geeignetste Lösung wird anschließend in diebestehende Infrastruktur integriert.Die Entscheidung berücksichtigt dabei ausdrücklich:- Wirtschaftlichkeit: Wann rechnet sich welcher Ansatz? Vergleich derGesamtbetriebskosten (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 bleibtAlternativen, die aus technischen oder wirtschaftlichen Gründen ausscheiden, werdendokumentiert und mit Begründung ausgeschlossen.Quantitative Projektziele (messbar):- Reduktion der durchschnittlichen Pipeline-Wartezeit von aktuell ca. 13–15 Minutenauf 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 BenutzerZeitplanung-----------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 h2. 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 h3. 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 h4. Abschlussphase (8 h)- Soll-Ist-Vergleich & Qualitätssicherung: 1 h- Benutzerdokumentation: 2 h- Administratordokumentation: 2 h- Projektdokumentation (Abschlussbericht): 3 hGesamt: 40 hAnlagen-------- Vereinfachtes Netzwerkdiagramm der bestehenden Infrastruktur- Übersicht der aktuellen Server-Ressourcen (anonymisiert)- Logisches Netzwerkdiagramm: Kommunikationswege zwischenGitLab-Instanz, Runner-Servern und FirewallIst das zu wenig/viel?Präsentationsmittel-------------------Laptop, Beamer, Präsentation (Slides), ggf. Live-Demo deroptimierten Pipeline-Ausführung Bearbeitet vor 3 Stunden3 h von sewshyi
Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.