Hallo zusammen,

ich möchte mir gerne auch einmal externes Feedback einholen zu meinem Projektantrag. Intern läuft das bei uns leider nicht so rund.

Meine größte befürchtung ist, dass ich das schon viel zu detailliert beschrieben habe und demnach der Antrag zu lang ist. Auch würde ich gerne wissen, ob der Zeitplan so überhaupt realistisch ist:

1. Thema der Projektarbeit

Aufbau einer vom Produktivnetz abgekapselten Virtualisierungsumgebung auf Basis von VMware vSphere/vCenter zur direkten Erprobung neuer Systeme auf Hypervisor-/VM-Ebene sowie als Desaster-Recovery-Option für die Produktivsysteme, unter Wiederverwendung vorhandener Server-Hardware.

1.1 Geplanter Bearbeitungszeitraum

12.10.2026 – 13.11.2026 (gesamter Bearbeitungszeitraum, 40 Stunden)

2. Projektbeschreibung

2.1 Unternehmensbeschreibung

** Hier ein generischer Text der mir so vom Ausbildungsbetrieb vorgeschrieben wurde **

2.2 Ausgangssituation (Ist-Analyse)

Neue Systeme, Anwendungen und Konfigurationen werden in der IT-Abteilung bislang ohne eine dedizierte, vom Produktivbetrieb getrennte Testumgebung eingeführt. Getestet wird dabei auf Bestands-Produktivsystemen in abgetrennten Netzwerkbereichen – dabei drohen Betriebsstörungen, Datenverlust und ungeplante Ausfallzeiten, denn die Tests laufen auf derselben physischen Infrastruktur und teilen sich Rechenleistung, Speicher und Netzwerk mit dem Produktivbetrieb. Fehlkonfigurationen – etwa IP-Adresskonflikte oder falsch zugeordnete VLANs – können so unmittelbar auf produktive Dienste durchschlagen. Vor allem Auszubildende haben aktuell keine Möglichkeit, Systeme eigenständig aufzusetzen und dabei auch Fehler machen zu dürfen, ohne den Produktivbetrieb zu gefährden.

Zusätzlich verfügt die IT-Abteilung aktuell über keine Ausweichkapazität für den Fall eines Ausfalls der produktiven Virtualisierungsumgebung: Bei einem größeren Störfall stünde kein eigenständiges Notfall-Cluster zur Verfügung, auf dem kritische Systeme kurzfristig weiterbetrieben werden könnten.

Gleichzeitig lagern im Unternehmen mehrere ungenutzte Server (HP ProLiant DL360 der Generationen 6 bis 9), mehrere Ethernet- und SAN-Switches (u. a. Cisco Catalyst 3560G und Fibre-Channel-Switches) sowie verschiedene Netzwerkspeicher (Network Attached Storage, NAS; u. a. Thecus N8800SAS und HP MSA 2040), deren Wiederverwendung zusätzliche Anschaffungskosten erspart. Die Auswahl der konkret einzusetzenden Komponenten aus diesem Bestand ist Teil des Projekts. Diese Hardware bildet dabei nur die physische Basis; die eigentliche Virtualisierungsumgebung (Hypervisor-Schicht) darauf muss im Projekt erst noch aufgebaut werden.

2.3 Projektziel (Soll-Konzept)

Ziel ist das Schaffen einer eigenständigen Virtualisierungsumgebung (Hypervisor-Struktur), auf der neue Systeme und Programme unabhängig vom Produktivbetrieb direkt auf Hypervisor-/VM-Ebene gestartet und getestet werden können. Die Umgebung ist vollständig vom Produktivnetz getrennt und übernimmt zugleich die Funktion einer Desaster-Recovery-Option: Im Ernstfall können auf ihr essenzielle Systeme der Produktivumgebung ausweichsweise weiterbetrieben werden. Die Wiederherstellung erfolgt dabei über das bestehende, netzseitig getrennte Backup (Air-Gap-Backup): Im Störfall wird kontrolliert eine physische Netzverbindung hergestellt, die essenziellen Systeme werden aus dem Backup auf die neue Umgebung zurückgespielt und dort weiterbetrieben. Im Regelbetrieb bleibt die Umgebung vollständig isoliert.

Vorgabe des Ausbildungsbetreuers und der Abteilungsleitung ist dabei, vorhandene, aktuell ungenutzte Hardware wiederzuverwenden sowie auf VMware als Virtualisierungsplattform zu setzen. Beides ist als Rahmenbedingung gesetzt: Wiederverwendung, weil die Server bereits im Bestand sind und keine Neuanschaffung nötig ist; VMware, weil im Unternehmen bereits entsprechendes Know-how vorhanden ist und die Produktivsysteme selbst ebenfalls auf VMware laufen. Zwar ließen sich VMware-basierte VMs grundsätzlich auch auf andere Plattformen übertragen, das erfordert im Ernstfall jedoch zusätzliche Konvertierungsschritte und schafft Reibungspunkte, die weitere Komplikationen einbringen können – bei einer plattformgleichen Umgebung können die Workloads dagegen ohne Anpassung übernommen werden.

Innerhalb dieser Rahmenbedingungen liegen die wesentlichen fachlichen Entscheidungen bei mir:

•          Hardware-Auswahl: Auswahl der einzusetzenden Komponenten aus dem Gerätebestand – u. a. Entscheidung für die DL360 Gen9 als neueste verfügbare Servergeneration (ESXi-Kompatibilität, Leistung und Energieeffizienz gegenüber Gen6–Gen8).

•          Storage-Anbindung: Entscheidung für iSCSI statt Fibre Channel (FC), da die für FC benötigten Komponenten (u. a. passende SFP-Module) nicht vollständig im Bestand vorhanden sind und Mehrkosten verursachen würden; die Bewertung beider Varianten erfolgt per Nutzwertanalyse in Phase 1.

•          Storage-Redundanz: Konfiguration des NAS im RAID-6-Verbund, sodass der gleichzeitige Ausfall von bis zu zwei Festplatten ohne Datenverlust toleriert wird – bei Bestandsplatten gleichen Alters ein relevantes Risiko.

•          Netzdesign: eigenständiges VLAN-Konzept, angelehnt an das Schema des Produktivnetzes, jedoch in einem separaten Nummernkreis – so bleibt die Umgebung für Administratoren wiedererkennbar und zugleich eindeutig vom Produktivnetz unterscheidbar.

•          Rollen- und Berechtigungskonzept: wird von mir eigenständig ausgearbeitet und umgesetzt.

Die Versionswahl von ESXi/vCenter ist durch die Kompatibilität der Bestandshardware und die vorhandenen Lizenzen weitgehend vorgegeben und wird in der Dokumentation nachvollziehbar begründet.

Wirtschaftlichkeit: In Phase 1 wird eine Kosten-Nutzen-Betrachtung erstellt. Den Projektkosten – im Wesentlichen 40 Stunden Arbeitszeit sowie die laufenden Stromkosten der Server – steht die vermiedene Neuanschaffung einer vergleichbaren Test- und Notfallumgebung (zwei Server, Switch, Storage; Wiederbeschaffungswert im unteren fünfstelligen Eurobereich) gegenüber. Hinzu kommt schwer bezifferbarer, aber wesentlicher Nutzen: vermiedene Betriebsstörungen durch Tests auf Produktivsystemen sowie eine Notfallreserve, die ungeplante Ausfallzeiten im Störfall verkürzt.

2.4 Projektumfeld

Das Projekt entsteht in der IT-Abteilung **des Unternehmens**; sie ist zugleich interner Auftraggeber und späterer Betreiber der Umgebung. Betrieblicher Ansprechpartner und Projektbetreuer ist **Ausbilder**.

Nutzerkreis: Auszubildende der IT-Abteilung als primäre Anwender (eigenständiges Aufsetzen und Testen von Systemen), Administratoren der IT-Abteilung als Betreiber.

Standort: Die Hardware wird final in Halle 3 im Lager am Standort Kamp-Lintfort aufgebaut.

Prozessschnittstellen:

•          Einstieg: Auftrag und Anforderungen durch die IT-Abteilung; Freigabe der Bestandshardware zur Wiederverwendung.

•          Während der Durchführung: Abstimmung mit dem Projektbetreuer zu Standort, Stromversorgung und Rollenkonzept.

•          Ausstieg: Übergabe an die IT-Abteilung inkl. Einweisung und Betriebshandbuch.

Abgrenzung: Die Umgebung ist bewusst netzseitig isoliert; eine Anbindung an das Produktivnetz ist nicht Gegenstand des Projekts. Die Bewertung der Virtualisierungsplattform erfolgt auf VMware-Basis; eine mögliche spätere Migration in Richtung Microsoft Hyper-V ist strategischer Zukunftskontext, jedoch nicht Projektinhalt.

Eigenleistung: Planung, Konfiguration (Switch, Hosts, Storage, vCenter) sowie Test und Dokumentation führe ich eigenständig durch. Kollegen sind nur an der Freigabe zu Standort, Stromversorgung und Rollenkonzept beteiligt (s. Prozessschnittstellen).

2.5 Projektphasen mit Zeitplan

Phase 1 – Analyse & Konzeption (7h)

•          Ist-Analyse und Anforderungen klären

•          Soll-Konzept erstellen (Plattform, Netz, Storage)

•          Wirtschaftlichkeit und Plattformwahl bewerten

Phase 2 – Planung (4h)

•          Hardware- und Zeitplanung

•          Netz- und Storage-Planung

•          Rollenkonzept planen

Phase 3 – Realisierung (18h)

•          Einrichtung der Hosts

•          Einrichtung Switch

•          Einrichtung Storage

•          Cluster und Rollenkonzept umsetzen

Phase 4 – Test & Qualitätssicherung (5h)

•          Testkonzept erstellen

•          Funktionstests durchführen

•          Abnahme mit dem Auftraggeber

Phase 5 – Projektabschluss & Dokumentation (6h)

•          Übergabe und Einweisung der IT-Abteilung

•          Projektdokumentation erstellen

•          Soll-Ist-Vergleich und Fazit

Gesamt: 40h

3. Dokumentation der Projektarbeit

Die Projektdokumentation erfolgt als prozessorientierter Projektbericht im Portable Document Format (PDF) und beschreibt Ausgangssituation, Zielsetzung, Umsetzung, Tests, Ergebnisse und Nutzen.

Vorgesehene Anlagen:

•          Kosten-Nutzen-Betrachtung (Wirtschaftlichkeit)

•          Netz- und Storage-Diagramme, Cluster-Übersicht

•          Screenshots der Konfiguration

•          Testprotokolle/Abnahmeprotokoll

•          Kurzes Betriebs-/Übergabehandbuch für die IT-Abteilung

•          Offenlegung eingesetzter Werkzeuge mit Künstlicher Intelligenz (KI) gemäß Vorgabe der IHK

4. Verwendete Hard- und Software (Auswahl)

•          Hardware: 2× HP ProLiant DL360 Gen9 (Bestand); Thecus N8800SAS als iSCSI-Storage im RAID-6-Verbund (Bestand); Cisco Catalyst 3560G als Layer-3 (L3)/VLAN-Switch (Bestand)

•          Software: VMware ESXi, VMware vCenter Server Appliance (VCSA), HPE iLO/Firmware-Tools

Bearbeitet 4. August4. Aug von mapr

Mal provokativ gefragt:

Was für Entscheidungen triffst du denn, wenn du unter 2.3 lang und breit erklärst das eigentlich alles vorgegeben ist?

Kürze das ganze den so detailliert gehören Ist-Analyse und Soll-Konzept nicht in den Antrag sondern in die Doku.

Bei den Phasen und der Zeitverteilung, verteile die Zeit ruhig auf die einzelnen Unterpunkte.

vor 1 Stunde, Vugas hat gesagt:

Die Bewertung der Virtualisierungsplattform erfolgt auf VMware-Basis; eine mögliche spätere Migration in Richtung Microsoft Hyper-V ist strategischer Zukunftskontext, jedoch nicht Projektinhalt.

Genau das wäre DEIN Thema. wie cortez schon ausführte. So seh ich für eine Zulassung schwarz, wir würden das ablehnen

Sehe ich wie mein Vorredner.
Was machst du in den 18 Stunden genau?

Erst einmal vielen Dank an euch drei. Das Feedback war

deutlich, aber genau deshalb hilfreich. Vor allem der Punkt, dass ich unter 2.3 seitenlang

erkläre, was alles vorgegeben ist, und direkt danach behaupte, die Entscheidungen lägen bei

mir, hat gesessen. Beim Nochmallesen ist mir das selbst peinlich aufgefallen.

Ich habe den Antrag daraufhin komplett überarbeitet. Was sich geändert hat:

1. Die Plattformwahl ist jetzt Projektinhalt statt Ausschluss. Der Satz, mit dem ich den

Hyper-V-Vergleich als "nicht Projektinhalt" abgeräumt habe, ist raus. Stattdessen wird

die Plattform in Phase 1 per Nutzwertanalyse bewertet. Das habe ich vorher mit meinem

Ausbildungsbetreuer abgestimmt – vorher stand VMware faktisch als Vorgabe im Raum, das

ist jetzt geklärt.

2. Die lange Vorgaben-Passage ist auf einen Satz geschrumpft. Als echte Rahmenbedingung

bleibt nur, dass ausschließlich vorhandene Hardware wiederverwendet wird.

3. Weil die Entscheidungen erst im Projekt fallen, nimmt der Antrag ihre Ergebnisse nicht

mehr vorweg. iSCSI, RAID 6 und die konkrete Servergeneration standen vorher schon als

Fakt drin – das war unlogisch und ist jetzt raus.

4. Zeitplan auf Arbeitspakete heruntergebrochen, jedes mit Stunden. Auf die Frage nach den

18 Stunden Realisierung gibt es jetzt eine Antwort.

5. Deutlich gekürzt: von fünf auf drei Seiten. Ist-Analyse und Soll-Konzept sind auf

Antragsniveau zusammengestrichen, die ausführliche Fassung wandert in die Doku.

6. Neu dazugekommen sind ein Wiederherstellungstest aus dem Backup als Nachweis der

DR-Fähigkeit, eine explizite Reflexion in Phase 5 und ein Zeitpuffer.

Hier die neue Fassung (Namen und Betrieb habe ich rausgenommen und die Formatierung für das Forum angepasst):

=====================================================================

PROJEKTANTRAG ZUR BETRIEBLICHEN PROJEKTARBEIT (IHK)

=====================================================================

Ausbildungsberuf: Fachinformatiker für Systemintegration

Ausbildungsbetrieb: [Betrieb], Abteilung Informationstechnik (IT)

Auftraggeber: IT-Abteilung (intern)

1. THEMA DER PROJEKTARBEIT

Konzeption, Bewertung und Aufbau einer vom Produktivnetz getrennten

Virtualisierungsumgebung zur Erprobung neuer Systeme auf Hypervisor- und VM-Ebene sowie

als Desaster-Recovery-Ausweichplattform für die Produktivsysteme, unter Wiederverwendung

vorhandener Server-Hardware.

1.1 Geplanter Bearbeitungszeitraum

12.10.2026 – 13.11.2026 (gesamter Bearbeitungszeitraum, 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.

Gleichzeitig lagern mehrere ungenutzte Server (HP ProLiant DL360), Ethernet- und

SAN-Switches sowie Speichersysteme im Bestand. Sie bilden jedoch nur die physische Basis –

welche Komponenten eingesetzt werden und welche Virtualisierungsplattform darauf läuft,

ist im Projekt erst zu bewerten.

2.3 Projektziel (Soll-Konzept)

Ziel ist eine eigenständige, vom Produktivnetz getrennte Virtualisierungsumgebung, auf der

neue Systeme auf Hypervisor- und VM-Ebene erprobt werden können und die im Störfall als

Ausweichplattform für essenzielle Produktivsysteme dient. Die Wiederherstellung erfolgt

aus dem bestehenden Air-Gap-Backup: Im Störfall wird kontrolliert eine physische

Netzverbindung hergestellt und zurückgespielt, im Regelbetrieb bleibt die Umgebung

isoliert.

Als Rahmenbedingung gibt der Betrieb vor, ausschließlich vorhandene Hardware

wiederzuverwenden. Die fachliche Ausgestaltung liegt bei mir; zu treffen und zu begründen

sind:

- Virtualisierungsplattform: Nutzwertanalyse u. a. zu VMware vSphere, Microsoft Hyper-V

und Proxmox VE – Kriterien: Eignung als Desaster-Recovery-Ziel für die bestehenden

Workloads, Lizenz- und Kostensituation, Hardware-Unterstützung, vorhandenes Know-how.

- Hardware-Auswahl: Server, Switch und Speichersystem aus dem Bestand nach

Plattformkompatibilität, Leistung und Energieeffizienz.

- Storage-Anbindung: Nutzwertanalyse iSCSI gegenüber Fibre Channel (FC), einschließlich

der Frage, welche Komponenten vollständig im Bestand vorhanden sind.

- Storage-Redundanz: Festlegung des RAID-Levels; bei Bestandsplatten gleichen Alters ist

der Ausfall mehrerer Platten ein reales Risiko.

- Netzdesign: eigenständiges VLAN-Konzept in separatem Nummernkreis, angelehnt an das

Schema des Produktivnetzes – wiedererkennbar und zugleich eindeutig unterscheidbar.

- Rollen- und Berechtigungskonzept: so ausgelegt, dass Auszubildende eigenständig arbeiten

können, ohne die Umgebung als Ganzes zu gefährden.

- Testkonzept: Abnahmekriterien einschließlich Wiederherstellungstest aus dem

Air-Gap-Backup als Nachweis der Desaster-Recovery-Fähigkeit.

Wirtschaftlichkeit: Den Projektkosten – im Wesentlichen 40 Stunden Arbeitszeit und

laufende Stromkosten – steht die vermiedene Neuanschaffung einer vergleichbaren Test- und

Notfallumgebung gegenüber (Wiederbeschaffungswert im unteren fünfstelligen Eurobereich),

dazu vermiedene Betriebsstörungen und verkürzte Ausfallzeiten im Störfall. Die

Kosten-Nutzen-Betrachtung entsteht in Phase 1.

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: Planung, Konfiguration von Switch, Hosts, Storage und Management-Instanz

sowie 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 Konzeption (7,0 h)

Ist-Analyse und Anforderungsaufnahme mit der IT-Abteilung 1,5 h

Nutzwertanalyse Virtualisierungsplattform 2,0 h

Nutzwertanalyse Storage-Anbindung (iSCSI/Fibre Channel) 1,5 h

Auswahl der Hardware aus dem Bestand 1,0 h

Kosten-Nutzen-Betrachtung 1,0 h

Phase 2 – Planung (4,5 h)

Netz- und VLAN-Konzept 1,5 h

Storage- und RAID-Konzept 1,0 h

Rollen- und Berechtigungskonzept 1,0 h

Test- und Abnahmekonzept 1,0 h

Phase 3 – Realisierung (14,5 h)

Hardware-Aufbau, Verkabelung, Firmware-/iLO-Stand 2,5 h

Switch-Konfiguration (VLANs, Uplinks, Storage-Netz) 2,0 h

Speichersystem einrichten (RAID-Verbund, LUNs, Targets) 2,5 h

Hypervisor auf beiden Hosts installieren und grundkonfigurieren 2,5 h

Management-Instanz ausrollen, Cluster und Datastores anlegen 3,0 h

Rollen- und Berechtigungskonzept umsetzen 2,0 h

Phase 4 – Test und Qualitätssicherung (5,0 h)

Funktionstests nach Testkonzept 2,0 h

Wiederherstellungstest aus dem Air-Gap-Backup (DR-Nachweis) 2,0 h

Abnahme mit dem Auftraggeber 1,0 h

Phase 5 – Projektabschluss (7,0 h)

Projektdokumentation erstellen 5,0 h

Übergabe und Einweisung der IT-Abteilung 1,0 h

Soll-Ist-Vergleich, Reflexion und Fazit 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: die Nutzwertanalysen zu

Virtualisierungsplattform und Storage-Anbindung, die Kosten-Nutzen-Betrachtung, eine Netz-

und Storage-Übersicht, das Test- und Abnahmeprotokoll sowie die Offenlegung eingesetzter

Werkzeuge mit Künstlicher Intelligenz (KI) gemäß Vorgabe der IHK.

=====================================================================

Drei Punkte, bei denen ich noch unsicher bin:

1. Reicht die Plattformbewertung in dieser Form als Eigenleistung, oder wirkt eine

Nutzwertanalyse mit 2 Stunden zu dünn für etwas, das jetzt sogar im Thema steht?

2. Phase 3 mit 14,5 Stunden für Hardware-Aufbau, Switch, Storage, zwei Hosts,

Management-Instanz mit Cluster und Rollenkonzept – ist das realistisch oder zu knapp

kalkuliert? Ich könnte den Puffer reduzieren oder Phase 1 etwas abgeben.

3. Ich habe den Abschnitt "verwendete Hard- und Software" komplett gestrichen, weil die

Auswahl ja erst im Projekt getroffen wird und eine Liste das Ergebnis vorweggenommen

hätte. Fehlt euch das, oder ist das so schlüssiger?

Danke fürs Drüberschauen.

vor 30 Minuten, Vugas hat gesagt:

Nutzwertanalyse Virtualisierungsplattform 2,0 h

Nutzwertanalyse Storage-Anbindung (iSCSI/Fibre Channel) 1,5 h

Auswahl der Hardware aus dem Bestand 1,0 h

das ist mir zu ungenau. Was genau ist da Dein Projekt ?

Plane 6-8 Stunden für die Evaluation der Virtualisierungsplattform ein und der Rest ist Beiwerk.

Das Erstellen einer Schutzbedarfsanalyse oder einer datenschutzrechtlichen Betrachtung ist Vorgabe der PO

Was ist es denn jetzt ?

vor 17 Minuten, Vugas hat gesagt:

Ziel ist eine eigenständige, vom Produktivnetz getrennte Virtualisierungsumgebung, auf der neue Systeme auf Hypervisor- und VM-Ebene erprobt werden können und die im Störfall als Ausweichplattform für essenzielle Produktivsysteme dient.

Spielwiese zu ausprobieren von Hypervisoren, oder ein zusätzlicher Hypervisor als Notfallsystem ?

vor 21 Minuten, Vugas hat gesagt:

Netz- und VLAN-Konzept 1,5 h

Storage- und RAID-Konzept 1,0 h

Rollen- und Berechtigungskonzept 1,0 h

Mal übertrieben dargestellt, dass sind 5 Minuten. Bei den VLANs wird sich an dem Produktivsystem orientiert, nur das statt 10.100.x.x 10.200.x.x genommen wird. Da die Platten eine unbekannte Laufzeit haben und wird das System stabil halten wollen wird RAID 6 genommen. Die Rollen und Berechtigungen werden von Produktivsystem übernommen mit der Änderung, dass Azubis als Sysadmins existieren.

Ich habe es mal als Beispiel genommen, um zu illustrieren, dass du dich in vielen Kleinigkeiten verrennst. Im großen und ganzen ist das Projekt inhaltlich nicht tief genug. Wir sind bei der Basis immer noch bei, bau das Produktivsystem aus gebrauchter Hardware nach. Viele der kleine Entscheidungen die du hier Anbringst sind fachlich nicht tief genug.

Wie @charmanta gesagt hat eine mögliche Migration weg von VMware, wäre ein Projekt. Vergleiche es mit anderen Hypervisoren.

Du hast mehrere Punkte, wie müssen die VMs ggf. neu installiert werden, Lizenzen, etc. und das kommt noch das wirtschaftlich zu betrachten. Nicht zu letzt seit Broadcom VMware übernommen hat, ist Wirtschaftlichkeit da ehr wichtig geworden.

Bearbeitet 5. August5. Aug von cortez
Rechtschreibung.

Danke euch beiden – die Kritik sitzt, und ich nehme sie an. Zum Kontext: Ich hatte mich an

einem Antrag orientiert, der bei unserem Ausschuss so durchging. Das erklärt die flache

Struktur, rechtfertigt sie aber nicht.

@cortez tez zu deiner Frage "Was ist es denn jetzt?" – die war der wunde Punkt, und ich habe

sie mir vorher nicht ehrlich genug gestellt. Antwort: Primär eine Testumgebung. Der

Notfallbetrieb ist ein Zusatznutzen, kein zweites gleichrangiges Ziel.

Der Widerspruch bleibt damit natürlich bestehen – eine Umgebung, auf der Azubis absichtlich

Sachen kaputt machen dürfen, ist kein Notfallsystem. Statt das zu verschweigen, steht der

Zielkonflikt jetzt offen im Antrag und wird über zwei definierte Betriebsmodi aufgelöst:

- Regelbetrieb: freier Zugriff für Azubis, Testsysteme belegen die Ressourcen, Umgebung

vollständig isoliert.

- Notfallbetrieb: Zugriff auf die Administratoren reduziert, Testsysteme werden

abgeschaltet und geben Ressourcen frei, Kernsysteme kommen über eine kontrolliert

hergestellte Verbindung aus dem Air-Gap-Backup zurück.

Dafür gibt es eine dokumentierte Umschaltprozedur und ein RTO-Ziel, das in der Testphase

praktisch dagegen gemessen wird. Das ist aus meiner Sicht die eigentliche Ingenieurleistung

im Projekt – deutlich mehr als die Kleinkram-Entscheidungen, die du zu Recht zerlegt hast.

Was sich sonst geändert hat:

- @charmanta a Evaluation der Virtualisierungsplattform jetzt mit 6 Stunden statt 2, und

nicht mehr nur Nutzwertanalyse, sondern mit praktischer Erprobung. Bewertungskriterium

ist unter anderem der Aufwand, vorhandene VMs zu übernehmen.

- Schutzbedarfsanalyse für Test- und Notfallbetrieb ist drin. Die liefert gleich die

fachliche Begründung für die zwei Modi, hängt also nicht als Pflichtübung daneben.

- VLAN-Nummernkreis, RAID-Level und Storage-Anbindung habe ich zu einem Punkt

zusammengefasst. Die als drei eigenständige Entscheidungen zu verkaufen war Blödsinn,

das hast du sauber auseinandergenommen.

- Kostenvorkalkulation und Nachkalkulation mit Soll-Ist-Vergleich statt einer einmaligen

Betrachtung.

Zum Vorschlag, die Migration weg von VMware zum eigentlichen Thema zu machen: Der Punkt

leuchtet mir fachlich völlig ein, gerade wegen der Lizenzsituation seit Broadcom. Bei uns

ist das aber perspektivisch und nicht akut – niemand plant gerade eine Ablösung. Ein

reines Migrationsprojekt wäre bei uns deshalb konstruiert, und im Fachgespräch würde

genau das auffliegen. Ich habe stattdessen den Weg gewählt, die Plattformfrage in der

isolierten Umgebung ernsthaft zu evaluieren – da lässt sie sich risikofrei beantworten,

bevor sie akut wird. Falls ihr das für einen faulen Kompromiss haltet, sagt es gern

deutlich.

Zwei Fragen hätte ich noch:

1. Trägt das Betriebsmodus- und Umschaltkonzept als fachlicher Kern, oder ist auch das

für eure Begriffe noch zu dünn?

2. @charmanta zur Schutzbedarfsanalyse: In der Handreichung unserer IHK kommen die Wörter

Datenschutz, Schutzbedarf und Sicherheit kein einziges Mal vor. Ich habe sie trotzdem

eingeplant, weil sie inhaltlich passt. Ist das bei euch fester Bestandteil der

Bewertung, oder hängt das am jeweiligen Ausschuss?

Den überarbeiteten Antrag im Volltext stelle ich gern rein, wenn ihr nochmal draufschauen

wollt – ich wollte euch nicht direkt wieder drei Seiten vor die Nase setzen.

vor 28 Minuten, Vugas hat gesagt:

zur Schutzbedarfsanalyse: In der Handreichung unserer IHK kommen die Wörter

Datenschutz, Schutzbedarf und Sicherheit kein einziges Mal vor.

das steht in der Prüfungsordnung und ist ein Zulassungskriterium

vor 29 Minuten, Vugas hat gesagt:

niemand plant gerade eine Ablösung. Ein

reines Migrationsprojekt wäre bei uns deshalb konstruiert,

das ist aber kein Problem. Du kannst ja durchaus nach Alternativen schauen und der Chef verweigert die Realisierung. Infrage zu stellen was man hat ist durchaus ok und auch das Gespräch macht da kein Problem ,)

vor 5 Minuten, charmanta hat gesagt:

Chef verweigert die Realisierung.

Oder es stellt sich heraus, dass es sich nicht rechnet.

Du hast hier eine klare Problemstellung. Das Ergebnis ist offen und kann auch sein "Proxmox ist technisch gesehen die Lösung, aber Schulungskosten relativieren jeglichen wirtschaftlichen Mehrgewinn, so dass es sich Mittelfristig nicht lohnt umzusteigen."

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.

Tu dir einen gefallen. Schlag für heute das Kapitel Projektantrag erstmal zu und mach morgen weiter.

Am 4.8.2026 um 16:16, cortez hat gesagt:

Kürze das ganze den so detailliert gehören Ist-Analyse und Soll-Konzept nicht in den Antrag sondern in die Doku.

Den Post von gestern würde ich so noch einmal wiederholen. Es ist viel zu detailliert. Du hast für die Doku nur einen festen Rahmen an Seiten, den du nutzen darfst. Hier gäbe es eventuell da noch das Problem, das es den Eindruck erwecken kann, dass du schon vor Genehmigung des Antrags mit dem Projekt angefangen hast.

Versuche bei kürzen klar sichtbaren roten Faden zu haben.

Kurzes Update:

Ich habe die Fassung mit der Plattformevaluation heute meinen Projektbetreuern vorgelegt.

Die wurde direkt abgelehnt.

Begründung: Das sei ein komplett anderes Projekt als das ursprünglich abgestimmte.

Unterstützen würden sie das nicht – weder mit Arbeitszeit noch mit Zugriff auf die

nötigen Informationen. Der ursprüngliche Scope, also der Aufbau der Testumgebung, sei für

40 Stunden umfangreich genug.

Damit ist die Sache für mich entschieden. Einen Antrag einzureichen, für den mir der

Betrieb die Unterstützung verweigert, bringt mir nichts. Ich bleibe beim alten Scope.

Euer Feedback ist trotzdem nicht verloren. Drin geblieben sind: die Schutzbedarfs- und

Datenschutzbetrachtung (2 h in Phase 1), keine vorweggenommenen Analyseergebnisse mehr,

der Zeitplan auf Arbeitspaketebene mit 18 h Realisierung und 8 h Doku – und neu eine

ausdrückliche Liste "Projektinhalt / nicht Projektinhalt", damit im Fachgespräch nicht

als Erstes danach gefragt wird.

Zwei Fragen hätte ich noch:

1. Zählen bei den 40 Stunden nur meine eigenen Stunden? Wenn ich mit einem Kollegen zwei

Stunden eine Abnahme mache – sind das zwei oder vier? Ich lese § 20 FIAusbV so, dass

es um meine Prüfungszeit geht, also zwei. Im Betrieb wurde mir das anders gesagt.

2. Wie behandelt ihr Wartezeiten bei automatisierten Vorgängen? Eine RAID-Initialisierung

läuft z.B. rund neun Stunden. Ich würde nur Anstoßen und Kontrolle rechnen und in der Zeit

am nächsten Arbeitspaket weitermachen. Oder erwartet ihr die Wartezeit sichtbar im

Plan?

Danke euch.

vor 3 Minuten, Vugas hat gesagt:

Unterstützen würden sie das nicht – weder mit Arbeitszeit noch mit Zugriff auf die

nötigen Informationen. Der ursprüngliche Scope, also der Aufbau der Testumgebung, sei für

40 Stunden umfangreich genug.

das sind ja lustige "Betreuer" .... die nötigen Informationen sollten Dir bei der Ausbildung vermittelt worden sein. Aber das wird wohl Firmenpolitik sein

vor 4 Minuten, Vugas hat gesagt:

. Zählen bei den 40 Stunden nur meine eigenen Stunden? Wenn ich mit einem Kollegen zwei

Stunden eine Abnahme mache – sind das zwei oder vier?

Zwei. Und Vorsicht bei Einbeziehung weiterer Personen. Du versicherst das Projekt alleine durchgeführt zu haben

vor 5 Minuten, Vugas hat gesagt:

2. Wie behandelt ihr Wartezeiten bei automatisierten Vorgängen? Eine RAID-Initialisierung

läuft z.B. rund neun Stunden. Ich würde nur Anstoßen und Kontrolle rechnen und in der Zeit

am nächsten Arbeitspaket weitermachen. Oder erwartet ihr die Wartezeit sichtbar im

Plan?

Ich würde das genau so erwähnen und während dessen was anderes machen

Verständnisfrage: in der ursprünglichen Version war keine Evaluation und damit würden hier ALLE Prüfer ablehnen. Was wird Dein Betrieb denn dann machen ?

vor 9 Minuten, charmanta hat gesagt:

Ich würde das genau so erwähnen und während dessen was anderes machen

Das war auch mein Bauchgefühl. Entweder parallel andere Arbeitspakete abarbeiten oder die Initialisierung über Nacht laufen lassen.

vor 10 Minuten, charmanta hat gesagt:

Verständnisfrage: in der ursprünglichen Version war keine Evaluation und damit würden hier ALLE Prüfer ablehnen. Was wird Dein Betrieb denn dann machen ?

Genau das habe ich vorgebracht und meine Bedenken deutlich gemacht. Sie wurden mit dem Verweis auf Erfahrungen aus früheren Projekten abgeräumt.
Falls der Antrag abgelehnt wird, habe ich ja sieben Tage Nachfrist, mit Hinweisen des Ausschusses. Damit hätte ich genau das in der Hand, was mir aktuell im Betrieb fehlt. Unschön aber kein Weltuntergang.

Dass ich hier wenig Spielraum habe, ist mir bewusst. Ich bin leider auf den Betrieb angewiesen und kann die Entscheidung nicht überstimmen.

Firmenpolitik trifft es ganz gut. Ich glaube anhand der Situation kann man sich die Stimmung fast schon vorstellen und ich muss meine Gedanken zum Ausbildungsbetrieb nicht weiter kommentieren.

Hinterlass irgendwo die Infos, welche Firma das denn ist.
Damit dort nicht noch mehr Erde verbrannt wird.

Am 4.8.2026 um 15:58, Vugas hat gesagt:

u. a. Entscheidung für die DL360 Gen9

Die Kisten sind gute 10 Jahre alt. Das ist Elektroschrott und sollte nicht mehr produktiv eingesetzt werden.

Zum Spielen reicht sowas locker

vor 6 Stunden, charmanta hat gesagt:

Zum Spielen reicht sowas locker

Naja, aber es ist trotzdem ein Problem, wenn es wie oben Beschrieben für den Notbetrieb verwendet werden soll.

Am 4.8.2026 um 15:58, Vugas hat gesagt:

Die Umgebung ist vollständig vom Produktivnetz getrennt und übernimmt zugleich die Funktion einer Desaster-Recovery-Option: Im Ernstfall können auf ihr essenzielle Systeme der Produktivumgebung ausweichsweise weiterbetrieben werden. Die Wiederherstellung erfolgt dabei über das bestehende, netzseitig getrennte Backup (Air-Gap-Backup): Im Störfall wird kontrolliert eine physische Netzverbindung hergestellt, die essenziellen Systeme werden aus dem Backup auf die neue Umgebung zurückgespielt und dort weiterbetrieben.

Auch wenn sich mir hier dann noch die Frage auf drängt, wie soll es funktionieren? Können da Azubis sich jetzt in einem abgeschlossenen Kopie des Systems ausprobieren und im Notfall wird diese Kopie zurückgespielt? Aber was ist wenn diese Kopie kaputt konfiguriert wurde? Bzw. wie soll das mit dem Datenstand funktionieren?

vor 18 Stunden, Vugas hat gesagt:

Unterstützen würden sie das nicht – weder mit Arbeitszeit noch mit Zugriff auf die nötigen Informationen. Der ursprüngliche Scope, also der Aufbau der Testumgebung, sei für 40 Stunden umfangreich genug.

Kann es sein, dass die Kritik nicht verstanden wurde? Der Scope war nicht das Problem, dass Problem war das es keine Entscheidungstiefe gibt. Ob es DL 360 Gen 7, 8 oder 9 macht keine Tiefe der Entscheidung aus und sie ist irrelevant für das Projekt. Das Ergebnis ist das gleiche.

vor 18 Stunden, Vugas hat gesagt:

Sie wurden mit dem Verweis auf Erfahrungen aus früheren Projekten abgeräumt

Frag doch einfach mal nach mehr Details, bekamen die Azubis eventuell alle das gleiche Projekt? Dann müsste es doch bestimmt irgendwo noch die Blaupause geben.

vor 16 Stunden, hellerKopf hat gesagt:

Hinterlass irgendwo die Infos, welche Firma das denn ist.

Hier im Thread sind einige Hinweise, welche Rückschlüsse auf das Unternehmen zulassen.

vor 19 Minuten, cortez hat gesagt:

Hier im Thread sind einige Hinweise, welche Rückschlüsse auf das Unternehmen zulassen

Aha, die mit der "Geht nicht gibt's nicht" - Mentalität in der Stellenanzeige für FISI AzuBis?