Danke euch – die beiden Klarstellungen haben bei mir den Knoten gelöst. @charmanta dass die Schutzbedarfsanalyse in der Prüfungsordnung steht und Zulassungskriterium ist, war mir schlicht nicht klar. Ich hatte nur in der Handreichung unserer IHK gefunden und daraus den falschen Schluss gezogen. Danke für die Korrektur. Und der Punkt, dass ein "konstruiertes" Evaluationsprojekt kein Problem ist, weil die Fragestellung zählt und nicht die Umsetzung, war genau mein Denkfehler. @cortez dein Beispiel mit "technisch die Lösung, aber Schulungskosten fressen den Vorteil auf" hat es endgültig klar gemacht: Das ist ja ein Ergebnis, kein Scheitern. Ich habe den Antrag entsprechend gedreht. Das Thema lautet jetzt: "Evaluation alternativer Virtualisierungsplattformen als Entscheidungsgrundlage für die künftige Servervirtualisierung, praktisch verifiziert auf einer vom Produktivnetz getrennten Testumgebung mit definiertem Notfallbetrieb." Die Umgebung ist damit nicht mehr das Ziel, sondern das Werkzeug – sie bleibt aber als Ergebnis bestehen, weil wir sie ohnehin brauchen. Was sich konkret geändert hat: - Die Plattformfrage ist jetzt die Problemstellung, nicht ein Auswahlschritt nebenbei. Die Ist-Analyse nennt beides und verknüpft es: Wir können die Frage nicht beantworten, weil uns genau die Umgebung fehlt, in der man das risikofrei täte. - Die Ergebnisoffenheit steht wörtlich im Antrag, inklusive der Möglichkeit, dass sich ein Umstieg wegen Schulungs- und Migrationsaufwand nicht rechnet. Dazu die Abgrenzung, dass die Entscheidung über eine tatsächliche Umstellung bei der Abteilungsleitung liegt und nicht Projektinhalt ist. - Die Wirtschaftlichkeit ist jetzt der Plattformvergleich über einen mittelfristigen Zeitraum – Lizenz- und Supportkosten, Schulungsaufwand, Aufwand für die Übernahme bestehender VMs. Projektkosten laufen als zweite Ebene mit (Vor- und Nachkalkulation). - Phase 1 heißt "Analyse und Bewertung" und hat 12 von 40 Stunden. Neu ist ein Meilenstein: Empfehlung ausarbeiten und dem Projektbetreuer zur Freigabe vorstellen. Phase 3 ist entsprechend auf 11 Stunden geschrumpft, weil nur noch die gewählte Plattform ausgerollt wird. Zur Schutzbedarfsanalyse: Beim Durchdenken ist mir aufgefallen, dass mein eigenes Konzept da einen echten Datenschutzaspekt hat, den ich vorher übersehen hatte. Im Notfallbetrieb spiele ich Produktivsysteme mit personenbezogenen Daten auf Hardware zurück, auf der im Regelbetrieb Azubis mit weitreichenden Rechten arbeiten. Daraus folgen Zugriffsbeschränkung bei der Umschaltung, Verschlüsselung der Datastores – und vor allem ein Verfahren für den Rückweg: Die Produktivdaten müssen sicher gelöscht sein, bevor wieder Testbetrieb läuft. Den Rückweg hatte ich vorher überhaupt nicht bedacht. ===================================================================== PROJEKTANTRAG (Fassung 6, anonymisiert) ===================================================================== 1. THEMA Evaluation alternativer Virtualisierungsplattformen als Entscheidungsgrundlage für die künftige Servervirtualisierung, praktisch verifiziert auf einer vom Produktivnetz getrennten Testumgebung mit definiertem Notfallbetrieb. 1.1 Geplanter Bearbeitungszeitraum 12.10.2026 – 13.11.2026 (40 Stunden) 2. PROJEKTBESCHREIBUNG 2.1 Unternehmensbeschreibung Mein Ausbildungsbetrieb ist Distributor für Druckersupplies und Speichermedien und gehört zu einer europäischen Unternehmensgruppe mit gruppenweit über 1.000 Beschäftigten und mehr als 1,2 Milliarden Euro Jahresumsatz. 2.2 Ausgangssituation (Ist-Analyse) Die IT-Abteilung verfügt über keine vom Produktivbetrieb getrennte Testumgebung. Neue Systeme und Konfigurationen werden auf Bestands-Produktivsystemen erprobt und teilen sich Rechenleistung, Speicher und Netzwerk mit dem Produktivbetrieb; Fehlkonfigurationen wie IP-Adresskonflikte oder falsch zugeordnete VLANs schlagen unmittelbar auf produktive Dienste durch. Insbesondere Auszubildende können Systeme nicht eigenständig aufsetzen, ohne den Produktivbetrieb zu gefährden. Zusätzlich fehlt eine Ausweichkapazität: Fällt die produktive Virtualisierungsumgebung aus, steht kein Cluster bereit, auf dem kritische Systeme kurzfristig weiterlaufen könnten. Zugleich steht die Virtualisierungsbasis mittelfristig zur Disposition: Nach der Übernahme von VMware durch Broadcom haben sich Lizenzmodell und Kosten grundlegend verändert. Ob VMware die richtige Basis bleibt, lässt sich derzeit nicht beantworten – es fehlt eine Umgebung, in der Alternativen ohne Risiko erprobt werden könnten. Gleichzeitig lagern mehrere ungenutzte Server (HP ProLiant DL360), Ethernet- und SAN-Switches sowie Speichersysteme im Bestand, mit denen sich eine solche Umgebung ohne Neuanschaffung aufbauen lässt. 2.3 Projektziel (Soll-Konzept) Das Projekt beantwortet die Frage, ob VMware vSphere mittelfristig die richtige Basis der Servervirtualisierung bleibt oder ob eine Alternative vorzuziehen wäre. Bewertet werden VMware vSphere, Microsoft Hyper-V und Proxmox VE hinsichtlich Lizenz-, Schulungs- und Betriebskosten, Aufwand für die Übernahme vorhandener VMs, Eignung als Notfallziel sowie Unterstützung der Bestandshardware. Das Ergebnis ist ausdrücklich offen und kann ebenso lauten, dass ein Umstieg technisch möglich, wegen Schulungs- und Migrationsaufwand aber mittelfristig unwirtschaftlich ist. Die Entscheidung über eine tatsächliche Umstellung der Produktivumgebung trifft die Abteilungsleitung und ist nicht Gegenstand des Projekts. Bewertungsgrundlage ist eine eigens aufgebaute, vom Produktivnetz getrennte Umgebung, auf der die Kandidaten praktisch erprobt werden. Sie bleibt nach Projektende als Testumgebung bestehen – ausdrücklich auch für Auszubildende, die dort Fehler machen dürfen – und soll im Störfall zusätzlich als Ausweichplattform dienen. Beides zugleich ist ein Zielkonflikt: Eine Umgebung, auf der bewusst experimentiert wird, erfüllt nicht die Anforderungen an ein Notfallsystem. Aufgelöst wird er über zwei definierte Betriebsmodi mit dokumentierter Umschaltprozedur: - Regelbetrieb (Testmodus): freier Zugriff für Auszubildende, Testsysteme belegen die Ressourcen, Umgebung vollständig isoliert. - Notfallbetrieb: Zugriff wird auf die Administratoren reduziert, Testsysteme werden abgeschaltet und geben Ressourcen frei, die Kernsysteme werden über eine kontrolliert hergestellte Netzverbindung aus dem Air-Gap-Backup zurückgespielt. Für die Umschaltung wird eine Zielzeit (Recovery Time Objective, RTO) festgelegt und in Phase 4 praktisch dagegen gemessen. Schutzbedarf und Datenschutz: Zu Projektbeginn wird der Schutzbedarf beider Modi ermittelt. Gewicht hat dabei der Notfallbetrieb: Dort gelangen produktive Systeme mit personenbezogenen Daten auf eine Umgebung, die im Regelbetrieb Auszubildenden offensteht. Daraus folgen Zugriffsbeschränkung bei der Umschaltung, Verschlüsselung der Datastores und ein Verfahren zur sicheren Löschung der Produktivdaten vor Rückkehr in den Testbetrieb. Als Rahmenbedingung gibt der Betrieb vor, ausschließlich vorhandene Hardware wiederzuverwenden. Neben der Plattformbewertung liegen die fachlichen Schwerpunkte bei mir: - Betriebsmodus- und Umschaltkonzept: Ausarbeitung beider Modi, der Umschaltprozedur und des Rollenkonzepts, das beide Modi abbilden muss. - Auslegung der Umgebung: Auswahl der Hardware aus dem Bestand sowie Netz-, Storage- und Redundanzkonzept auf Basis des ermittelten Schutzbedarfs. Wirtschaftlichkeit: Kern ist der Kostenvergleich der drei Plattformen über einen mittelfristigen Zeitraum – Lizenz- und Supportkosten, Schulungsaufwand sowie Aufwand für die Übernahme bestehender VMs. Dazu kommen Kostenvor- und -nachkalkulation des Projekts mit Soll-Ist-Vergleich; gegengerechnet wird die vermiedene Neuanschaffung einer vergleichbaren Umgebung. 2.4 Projektumfeld Das Projekt entsteht in der IT-Abteilung meines Ausbildungsbetriebs; sie ist zugleich interner Auftraggeber und späterer Betreiber. Betrieblicher Ansprechpartner ist mein Projektbetreuer. Anwender sind Auszubildende der Abteilung (eigenständiges Aufsetzen und Testen von Systemen), Betreiber die Administratoren. Aufgebaut wird die Hardware in einer Lagerhalle am Standort. Prozessschnittstellen: Einstieg über Auftrag und Anforderungen der IT-Abteilung samt Freigabe der Bestandshardware; während der Durchführung Abstimmung mit dem Projektbetreuer zu Standort, Stromversorgung und Rollenkonzept; Ausstieg über die Übergabe an die IT-Abteilung inklusive Einweisung und Betriebshandbuch. Abgrenzung: Die Umgebung bleibt netzseitig isoliert; eine dauerhafte Anbindung an das Produktivnetz ist ebenso wenig Projektinhalt wie eine Migration der Produktivumgebung selbst – die Plattformbewertung erfolgt ausschließlich für die neu aufzubauende Umgebung. Eigenleistung: Bewertung, Planung, Konfiguration, Test und Dokumentation führe ich eigenständig durch; Kollegen sind nur an den genannten Freigaben beteiligt. 2.5 Projektphasen mit Zeitplan Phase 1 – Analyse und Bewertung (12,0 h) Ist-Analyse und Anforderungsaufnahme mit der IT-Abteilung 1,0 h Schutzbedarfs- und Datenschutzbetrachtung beider Betriebsmodi 2,0 h Evaluation der Plattformen: Nutzwertanalyse und praktische Erprobung 6,0 h Kostenvergleich der Plattformen und Kostenvorkalkulation 2,0 h Empfehlung ausarbeiten und dem Projektbetreuer vorstellen (Freigabe) 1,0 h Phase 2 – Planung (4,0 h) Betriebsmodus- und Umschaltkonzept inkl. RTO-Zielvorgabe 2,0 h Netz-, Storage- und Rollenkonzept 1,0 h Test- und Abnahmekonzept 1,0 h Phase 3 – Realisierung (11,0 h) Hardware-Aufbau, Verkabelung, Firmware-/iLO-Stand 2,5 h Switch- und Speicherkonfiguration (VLANs, RAID-Verbund, LUNs) 2,5 h Hypervisor der gewählten Plattform auf beiden Hosts einrichten 2,0 h Management-Instanz ausrollen, Cluster und Datastores anlegen 2,0 h Rollenkonzept und Umschaltprozedur umsetzen 2,0 h Phase 4 – Test und Qualitätssicherung (4,0 h) Funktionstests nach Testkonzept 1,0 h Notfallumschaltung und Wiederherstellung gegen RTO-Ziel messen 2,0 h Abnahme mit dem Auftraggeber 1,0 h Phase 5 – Projektabschluss (7,0 h) Projektdokumentation erstellen 5,0 h Kostennachkalkulation und Soll-Ist-Vergleich 1,0 h Übergabe, Einweisung und Reflexion 1,0 h Puffer für unvorhergesehenen Aufwand 2,0 h GESAMT 40,0 h 3. DOKUMENTATION DER PROJEKTARBEIT Die Projektdokumentation erfolgt als prozessorientierter Projektbericht im Portable Document Format (PDF) und beschreibt Ausgangssituation, Zielsetzung, Umsetzung, Tests, Ergebnisse und Nutzen. Als Anlagen sind vorgesehen: Nutzwertanalyse und Kostenvergleich der Plattformen, die Schutzbedarfs- und Datenschutzbetrachtung, Kostenvor- und -nachkalkulation, die Umschaltprozedur für den Notfallbetrieb, das Abnahmeprotokoll sowie die Offenlegung eingesetzter Werkzeuge mit Künstlicher Intelligenz (KI) gemäß Vorgabe der IHK. ===================================================================== Eine Frage bleibt mir noch: Reichen 6 Stunden für die eigentliche Evaluation, wenn ich Kostenvergleich (2 h) und Schutzbedarf (2 h) separat ausweise? @charmanta du hattest 6-8 für die Evaluation genannt – ich bin unsicher, ob du damit den ganzen Block gemeint hast oder die reine Nutzwertanalyse mit praktischer Erprobung. Danke nochmal fürs Dranbleiben, das hat das Projekt spürbar besser gemacht.
Von
Vugas · vor 6 Stunden 6 h