Anforderungsprofil: Server & Compute
Herstellerneutrales technisches Anforderungs- und Beschaffungspaket zum Entscheidungspaket „Server & Compute“.
Am Ende steht eine abgenommene Server-/Compute-Auslegung mit gemessener Last, dokumentierten Fehlerdomänen, Wartungs-/Lifecycle-Plan, Lizenzbasis und Recovery-Nachweis.
Thema: server · Stand 2026-09-21Welle 3 · Compute, Recovery & Observability
Server, Virtualisierung, Backup/Restore und Monitoring als gemeinsame Betriebsplattform dimensionieren und abnehmen.
Vor jeder Punktebewertung nachweisen
Diese Kriterien sind als technische Mindestnachweise formuliert. Nicht erfüllte Muss-Kriterien sollten nicht durch Komfort- oder Preisvorteile kompensiert werden.
| ID | Kriterium | Geforderter Nachweis |
|---|---|---|
| M01 | CPU-, RAM-, Storage- und I/O-Annahmen mit Messwerten der bestehenden Workloads oder einem repräsentativen Pilot validieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M02 | NIC-, Netzteil-, Storage-/RAID- und Switch-Fehlerdomänen gemeinsam auf Single Points of Failure prüfen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M03 | Garantie, Vor-Ort-Service, Firmware-/Treiberpfad und geplante Nutzungsdauer der konkreten Hardware festlegen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M04 | Virtualisierungsrechte, Core-Lizenzierung und VM-Mobilität für alle möglichen Zielhosts separat lizenzseitig verifizieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M05 | Backup, Monitoring, Ersatzteilstrategie und Disaster-Recovery-Verfahren vor Beschaffung dokumentieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
Mehrwert nur mit realem Betriebsnutzen bewerten
| ID | Kriterium | Bewertungshinweis |
|---|---|---|
| K01 | Remote-Management und Hardware-Telemetrie lassen sich sicher in Monitoring und Automatisierung integrieren. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K02 | Firmware-/Treiber-Baselines können zentral, versioniert und mit kontrolliertem Rollback betrieben werden. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K03 | Flexible Ausbaupfade für RAM, Storage, Accelerator oder Netzwerk reduzieren vorzeitige Plattformwechsel. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K04 | Standardisierte Komponenten und dokumentierte Austauschpfade vereinfachen Ersatzteilhaltung und Lifecycle. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
Fragen für Angebot, Workshop und technische Klärung
Sind CPU, RAM, Storage, IOPS und Netzbedarf aus realen Messwerten plus definierter Reserve abgeleitet?
Sind NIC, PSU, Storage, RAID, Switch-Pfade und Hostausfall ohne unerkannte Single Points of Failure geplant?
Sind Support, Firmware, Ersatzteile und Plattformlebenszyklus über die Nutzungsdauer abgesichert?
Passen Edition, Core-Lizenzierung, Virtualisierungsrechte und Mobilität zum tatsächlichen Betriebsmodell?
Sind Monitoring, Backup, Recovery und Wartung mit realen Störungen und Workloads getestet?
Kann die Plattform erweitert oder migriert werden, ohne Kapazitäts- und Vertragsannahmen neu erfinden zu müssen?
Gates als objektive Abnahmekriterien verwenden
Sizing basiert auf gemessenen Spitzen und definierten Reserven für Ausfall sowie Wachstum.
Ein einzelner geplanter oder relevanter ungeplanter Komponentenfehler überschreitet nicht die definierte Servicegrenze.
Hardware-, Support- und Lizenzmodell passen zur geplanten VM-Dichte und Mobilität ohne versteckte Unterlizenzierung.
Die Zielworkloads bleiben im definierten Performance- und Verfügbarkeitskorridor; Wartung ist reproduzierbar.
Der Betrieb kann Kapazitätsengpässe, Firmwareänderungen und Hardwareausfälle ohne ad-hoc Sonderwissen bearbeiten.
Vor Produktivsetzung klären
- Hardwarezustand, Kapazität, I/O, Firmware und Supportstatus zentral überwachen.
- Firmware-/Treiberänderungen mit Wartungsfenster, Abnahme und Rückfall betreiben.
- Ersatzteil-/Supportpfad und Hardware-Lifecycle mit eindeutigen Ownern pflegen.
- Backup, Recovery und Kapazitätsreserve regelmäßig gegen reale Workloads prüfen.
Vor Vertragsbindung nachweisen
- Workloads, Konfigurationen und Betriebsdokumentation ohne proprietäre Managementabhängigkeit auf Folgehardware überführen können.
- Support-/Firmware- und Hardwarebindungen sowie proprietäre Optionen vor Vertragsende transparent inventarisieren.
- Kapazitäts- und Recovery-Daten so dokumentieren, dass eine Folgebeschaffung ohne Neuvermessung möglich bleibt.
Gewichtete Bewertung erst nach den Muss-Kriterien
Die Gewichte ergeben zusammen 100 %. Die Skala bewertet nachgewiesene Eignung – nicht Herstellergröße oder Markenpräferenz.
| Kategorie | Gewicht | Skala | Dokumentation |
|---|---|---|---|
| Capacity & Performance | 25 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Availability & Physical Design | 25 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Lifecycle & Operations | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Licensing & Integration | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Commercial & Exit | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
Für Pilot, Entscheidung und Vertrag dokumentieren
- Workload-Inventar
- Messwert-Baseline
- Compute-Design
- Fehlerdomänenmatrix
- Support-/Lifecycle-Matrix
- Lizenzmodell
- Pilotmessungen
- Failover-Protokoll
- Betriebs-Runbook
- Erweiterungs-/Exit-Plan