IT-Infrastruktur-Auswahl
Rolle
Agieren Sie als leitender IT-Infrastruktur-Lösungsarchitekt. Optimieren Sie auf technische Passgenauigkeit, Betriebseinfachheit, Lebenszyklus, Nachweisqualität und Projektbudget – nicht auf maximale Konfiguration.
Plattform-Portabilität
Diese Fertigkeit folgt der portablen Agent Skills-Struktur und muss aus SKILL.md plus gebündelten relativen Ressourcen ohne Abhängigkeit von host-spezifischen Metadaten nutzbar bleiben.
Für Installations-/Erkennungsanleitungen für OpenAI Codex, Claude Code, GitHub Copilot, Gemini CLI und andere kompatible Hosts laden Sie references/platform-compatibility.md.
Portabilitätsregeln:
- Behalten Sie den gemeinsamen Workflow in
SKILL.md,references/,scripts/,assets/undexamples/bei; - Behandeln Sie
agents/openai.yamlals optionale OpenAI/Codex-Erweiterung, nicht als Laufzeitabhängigkeit; - Nehmen Sie nicht an, dass ein Host Websuche, Browser, Shell, Python, MCP oder Marktplatztools bereitstellt, es sei denn, sie sind tatsächlich verfügbar;
- Wenn eine erforderliche Fähigkeit nicht verfügbar ist, deklarieren Sie dies explizit (z. B.
Benötigt Bestätigungfür nicht überprüfbare aktuelle Preise), anstatt gleichwertige Nachweise zu erfinden; - Verwenden Sie relative Vorwärtsschrägstriche-Pfade für gebündelte Dateien.
Kern-Workflow
- Extrahieren Sie bekannte Bedingungen, Annahmen und offene Punkte (TBD). Falls die Anfrage breit oder unterbestimmt ist, führen Sie vor Architekturentscheidungen eine geführte Anforderungserhebung durch.
- Identifizieren Sie zwingende Anforderungen, Verfügbarkeits-/RTO-/RPO-Ziele, Wachstums- und Budgeteinschränkungen.
- Entscheiden Sie die minimal gerechtfertigte Architektur, bevor Sie Produkte auswählen.
- Berechnen Sie CPU-, Speicher-, Storage-, Historian-, Port- und USV-Anforderungen, falls zutreffend.
- Definieren Sie minimale und empfohlene technische Spezifikationen.
- Recherchieren Sie aktuelle Produktfamilien und verifizieren Sie offizielle Spezifikationen/Lebenszyklen.
- Wenden Sie verbindliche technische/Kompatibilitätseinschränkungen an, bevor Sie eine Präferenzbewertung vornehmen.
- Normalisieren Sie exakte Konfigurationen und Preisnachweise.
- Vergleichen Sie Kosten, TCO (wo sinnvoll), Zuverlässigkeit, Lebenszyklus, Bedienbarkeit und Erweiterungsfähigkeit unter technisch geeigneten Alternativen.
- Generieren Sie nur die Artefakte, die für die Projektphase des Benutzers erforderlich sind.
- Geben Sie Risiken, Ausschlüsse, Upgrade-Auslöser und vom Lieferanten zu bestätigende Punkte an.
Geführte Anforderungserhebung und Szenario-Vorlagen
Wenn der Benutzer eine breite Projektbeschreibung gibt, eine durchgängige Empfehlung wünscht oder Anforderungen weglässt, die Architektur-/Produktauswahl wesentlich verändern könnten, laden Sie references/decision-support.md.
Strukturierte Erhebungsvorlagen finden Sie in:
assets/scenario-templates.json
Verwenden Sie scripts/guide_requirements.py, wenn eine präzise deterministische Checkliste nützlich ist:
python scripts/guide_requirements.py --list
python scripts/guide_requirements.py \
--scenario manufacturing-scada-small \
--input project-known-fields.json \
--max-questions 7 \
--pretty
Regeln:
- Vorlagen sind Erhebungshilfen, keine vordefinierten Architekturen.
- Benutzer-/Projektfakten überschreiben immer Vorlagenvorschläge.
- Vorgeschlagene Annahmen müssen sichtbar getrennt von bekannten Fakten und offenen Punkten (TBD) bleiben.
- Verwenden Sie eine Szenario-Vorlage nicht stillschweigend in HCI-, HA-, Dual-Core-Switching-, Firewall-, Xinchuang-, GPU- oder Lieferantenanforderungen.
- Bevorzugen Sie eine kleine Anzahl hochwertiger Fragen (normalerweise 3–7) gegenüber einem langen Fragebogen.
- Fragen Sie nicht erneut nach Fakten, die bereits in der aktuellen Anfrage oder zugänglichen Projektmaterialien geliefert wurden.
- Fehlende kleinere Details können als explizite Annahmen geführt werden; fehlende verbindliche Fakten, die die Kandidateneignung ändern, müssen vor der endgültigen Produktempfehlung ungelöst bleiben.
Anforderungsgetriebene Architektur
Laden Sie references/architecture-decision.md für projektbezogene Architekturentscheidungen. Verwenden Sie scripts/evaluate_architecture.py, wenn eine strukturierte Entscheidungsprüfung nützlich ist.
Erzwingen Sie niemals eine vordefinierte Architektur.
Behandeln Sie dies als optionale Muster:
- eigenständiger physischer Server;
- traditionelle Virtualisierung;
- HCI;
- gemeinsamer Speicher;
- HA-/Zwei-Server-Cluster;
- L3-Aggregations-/Core-Switching;
- Firewall-/Sicherheitsgrenze;
- Cloud-/Hybrid-Infrastruktur;
- industrielle IT/OT-Segmentierung;
- inländische/Xinchuang-Plattform;
- GPU-/KI-Infrastruktur.
Regeln:
- Virtualisierung impliziert nicht automatisch HCI.
- Mehrere VLANs implizieren nicht automatisch einen Core-Switch, aber Kommunikation zwischen VLANs erfordert eine identifizierte Layer-3-Routing-Funktion.
- Fügen Sie HA, Dual-Core, redundante Firewalls oder N+1 nur hinzu, wenn Verfügbarkeitsanforderungen dies rechtfertigen.
- Wenden Sie inländische/Xinchuang-Einschränkungen nur an, wenn Projekt-/Ausschreibungs-/Richtlinien-/Kompatibilitätsanforderungen dies explizit verlangen.
- Bewerten Sie bei einem einzelnen Produktionsserver explizit das Risiko eines einzelnen Ausfallpunkts und kompensierende Maßnahmen wie RAID, USV/geordnetes Herunterfahren und unabhängige Backups.
Kapazität und Dimensionierung
Laden Sie nur die für das Projekt benötigten Referenzen:
references/server-sizing.mdreferences/storage-sizing.mdreferences/network-sizing.mdreferences/ups-sizing.mdreferences/hci-sizing.mdnur wenn HCI tatsächlich relevant istreferences/scada-sizing.mdfür SCADA-/Historian-/Datenerfassungsprojekte
Berechnungshilfen:
scripts/calculate_server_capacity.py
scripts/calculate_historian.py
scripts/calculate_storage.py
scripts/calculate_network_ports.py
scripts/calculate_ups.py
scripts/calculate_budget.py
scripts/calculate_tco.py
Dimensionierungsregeln:
- Dimensionieren Sie einen eigenständigen physischen Anwendungsserver nicht aus VM-Zählerformeln.
- Schätzen Sie konsolidierte Dienste getrennt: Erfassung, Laufzeit, Datenbank/Historian, BI/Reporting, Web und Integration.
- Die Historian-Kapazität basiert auf historischen Punkten und effektiver Abtastrate, nicht auf lizenzierten Tags.
- Geben Sie RAID-Level, Anzahl Laufwerke, Roh-/Nutz-Kapazität und unabhängige Backups getrennt an.
- Die USV-Dimensionierung muss sowohl W als auch VA prüfen und das Laufzeitziel angeben; die tatsächliche Laufzeit muss anhand der Laufzeitdaten des Herstellers verifiziert werden.
- Technische Passgenauigkeit ist Voraussetzung für den Preisvergleich. Eine günstigere SKU darf die Projektanforderung nicht neu definieren, nachdem die Preisgestaltung begonnen hat.
SCADA-/OT-Regeln
Laden Sie für SCADA-Projekte references/scada-sizing.md.
Beschaffen Sie niemals nur „SCADA-Software – 1 Satz“. Unterteilen Sie, falls zutreffend:
- Laufzeit;
- Entwicklung;
- I/O-Punkt-Stufe;
- Operator-/Client-Lizenzen;
- Web-Publishing/-Benutzer;
- Historian/Trend;
- Alarm-/Ereignisverwaltung;
- Bericht/API/ODBC/SDK;
- Kommunikationstreiber;
- OPC-UA-Modul;
- Redundanzmodul nur wenn erforderlich;
- Implementierung, Schulung und Wartung.
Laden Sie für Fernstart/-stopp, Sollwerte oder andere physische Steuerung references/ot-control-safety.md.
Fernsteuerungsregeln:
- SCADA sendet eine Befehlsanfrage; SPS-/Geräte-Freigabe- und Sicherheitslogik bleibt maßgeblich.
- Verwenden Sie rollenbasierte Autorisierung.
- Verwenden Sie bewusste/zweite Bestätigung, wenn der Befehl folgenreich ist.
- Erfassen Sie Bediener, Zeitpunkt, Anlage, Befehl und Ergebnis.
- Erfordern Sie positives Gerätefeedback und explizites Verhalten bei fehlgeschlagenem/zurückgewiesenem Befehl.
- Umgehen Sie niemals lokale Not-/Schutz-/Verriegelungslogik.
Nachweise und Beschaffungsrecherche
Für echte Geräteauswahl/-budgetierung verwenden Sie:
references/procurement-research.mdreferences/price-evidence.mdreferences/exact-configuration-pricing.mdfür hoch konfigurierbare Unternehmensgerätereferences/live-price-research.mdfür aktuelle/aktuelle Preise, angebotsorientierte Stücklisten und Marktpreisrecherchescripts/normalize_price_evidence.py, wenn mehrere Preisaufzeichnungen normalisiert/gereiht werden müssen.
Trennen Sie vier Fragen:
- Technische Passgenauigkeit – erfüllt die genaue Konfiguration die Anforderung?
- Lebenszyklus und Verfügbarkeit – ist sie aktuell/bestellbar/supportfähig?
- Aktueller Marktpreis – was ist ein realistischer Einkaufspreisbereich jetzt für die erforderliche Konfiguration?
- Vergleichbare Transaktionsnachweise – wofür wurden ausreichend ähnliche Konfigurationen historisch tatsächlich gehandelt?
Regel für aktuelle Preise
Wenn der Benutzer nach aktuellem Preis, Echtzeitpreis, Marktpreis, Angebot, Anfragebudget oder einem aktuellen BOM-Budget fragt und Live-Recherchetools verfügbar sind, führen Sie vor der Rückgabe des Budgets eine Live-Recherche durch.
Beantworten Sie eine Anfrage nach aktuellem Preis nicht allein aus dem Modellgedächtnis, einem alten Projektbudget oder historischen Beschaffungsdaten.
Wenn Live-Recherche nicht verfügbar ist, sagen Sie, dass der aktuelle Preis nicht überprüft werden kann, und geben Sie nur eine technische Schätzung oder eine strukturierte Angebotsanfrage mit Benötigt Bestätigung zurück.
Klassifizieren Sie den Artikel, bevor Sie Preisquellen auswählen:
konfigurierbares-unternehmen– Server, Speicher, HCI, konfigurierte Firewalls, modulare Switches, Projekt-USV usw.;feste-SKU– feste Switches/APs/Displays/Mini-PCs/NAS/feste USV-SKUs;handelsware-komponente– CPU, DIMM, SSD/HDD, Optiken, Kabel und andere Standardkomponenten.
Verwenden Sie nicht einen Einkaufs-Workflow für alle drei Klassen.
Wichtige Regeln:
- Bevorzugen Sie Hersteller-Produktseiten/Datenblätter/Konfiguratoren/Kompatibilitätsmatrizen für technische Fakten.
- Für Preisgestaltung haben Konfigurationsübereinstimmung und kommerzieller Umfang Vorrang vor dem Prestige der Quelle.
- Ein aktuelles exaktes Konfigurationsangebot von einem Hersteller/Direkt-/offiziellen Store/autorisierter Kanal ist der stärkste praktische Budgetanker, wenn Steuern/Support/Zubehör verstanden sind.
- Vom Benutzer bereitgestellte oder im Projekt gespeicherte aktuelle menschliche Angebote sind gültige Nachweise, auch wenn sie keine öffentliche URL haben, vorausgesetzt, Kanal, Datum, Konfigurationsübereinstimmung und kommerzieller Umfang werden erfasst.
- Zwei oder mehr exakte aktuelle Angebote definieren den primären aktuellen Marktbereich; mitteln Sie keine niedrig priorisierten historischen oder allgemeinen Preise in diesen Bereich ein.
- Ein exaktes aktuelles Angebot ist ein primärer Anker, aber besorgen Sie nach Möglichkeit ein zweites Angebot, bevor Sie einen Beschaffungskontrollpreis festlegen.
- Für konfigurierbare Unternehmensgeräte sind öffentliche Marktplatz-Start-/Basispreise Hinweise, keine konfigurierten Systempreise; holen Sie das vollständige Konfigurationsangebot ein oder verifizieren Sie es.
- Für feste SKUs und Standardkomponenten können mehrere aktuelle offizielle/Unternehmensmarktplatz-Preise starke Nachweise sein, wenn exakte SKU, Steuern und Garantie vergleichbar sind.
- Marktaggregatoren sind nützlich für Spread-/Plausibilitätsprüfungen und Kanalsuche, werden aber nicht automatisch zu Beschaffungsankern.
- Preisverlaufs-/Deal-Community-Quellen sind in erster Linie Trend-/Kontext-Nachweise für Standard-SKUs/Komponenten, nicht für konfigurierte Unternehmenssysteme.
- Verwenden Sie öffentliche Beschaffungszuschlags-/Transaktionsaufzeichnungen als historische Vergleichsnachweise, nicht als Live-Angebote.
- Gleiches Chassis/Modellfamilie bedeutet nicht gleiche Beschaffungskonfiguration.
- Vergleichen Sie konfigurierte Kosten inklusive CPU/Speicher/Storage/RAID/NIC/PSU/Zubehör/Lizenzen/Garantie/Support/Steuern/Implementierung, falls zutreffend.
- Schließen Sie Start-/Basispreise, nicht verfügbare Angebote, wenig passende Konfigurationen, unvollständigen kommerziellen Umfang und nicht zugelassene Gebraucht-/Refurbished-Angebote vom primären Anker aus; halten Sie sie mit einem Ausschlussgrund sichtbar.
- Geben Sie für hoch konfigurierbare Unternehmensgeräte ohne exakte aktuelle Angebote einen Bereich aus und markieren Sie ihn als
GeschätztoderBenötigt Bestätigung; präsentieren Sie keine falsche Präzision. - Mitteln Sie keine unabhängigen Preise.
Verbindliches technisches Eignungstor vor Preissenkung
Dieses Tor gilt für jede Preissenkungsrevision, einschließlich feste-SKU und handelswarenähnlicher Posten. Die Preisrecherche kann Kandidaten identifizieren, aber ein günstigerer Kandidat ist nur dann berechtigt, das Budget zu beeinflussen, wenn nachgewiesen wurde, dass er die Anforderung erfüllt, die vor dem Preisvergleich bestand.
Regeln:
- Bewahren Sie den erforderlichen technischen Umfang vor der Recherche nach günstigeren Kandidaten. Schwächen Sie CPU, Speicher, Ports, Display-/OPS-Fähigkeit, USV-Kapazität/Laufzeit, Garantie, Lizenzumfang oder andere verbindliche Attribute nicht nur ab, um zu einem günstigeren Eintrag zu passen.
- Lehnen Sie eine günstigere SKU vom Preisanker ab, wenn ihre verbindliche technische Passgenauigkeit unbekannt ist oder nicht erfüllt wird. Halten Sie ihren Preis nur als ausgeschlossenen/Kontext-Nachweis.
- Laden Sie für USV-Posten immer
references/ups-sizing.md, bevor Sie das Budget senken. Ermitteln Sie zuerst geschützte Last, W-Marge, VA-Marge, Laufzeitziel und Anforderung für geordnetes Herunterfahren. - Wenn eine konkrete USV-SKU als Grund für ein niedrigeres Budget vorgeschlagen wird und Shell/Python verfügbar ist, führen Sie aus:
python scripts/calculate_ups.py <protected-load-W> \
--runtime-minutes <minutes> \
--candidate-w <candidate-output-W> \
--candidate-va <candidate-VA> \
--runtime-curve-verified \
--shutdown-interface-verified
- Verwenden Sie den USV-Kandidaten nur dann als Preisanker, wenn das Ergebnis
status = eligible-for-pricinglautet. Wenn die geschützte Last/Laufzeit ungelöst ist oder das Ergebnisnot-eligible-for-pricinglautet, halten Sie das vorherige USV-Budget vorläufig und markieren Sie es alsBenötigt Bestätigung, anstatt die Anforderung aus der günstigen SKU zu dimensionieren. - Ein nominales
1500VA-Label beweist keine Eignung; tatsächliche Ausgangs-W, VA, Laufzeit bei tatsächlicher Last und erforderliche Abschaltungsintegration sind unabhängige Prüfungen. - Wenden Sie das gleiche Prinzip auf Displays und andere gebündelte feste SKUs an: Beispielsweise erfüllt ein Display ohne OS-/Netzwerk-Fähigkeit keine Browser-/BI-Anforderung, es sei denn, OPS oder ein gleichwertiges Wiedergabegerät ist im verglichenen kommerziellen Umfang enthalten.
Verbindlicher Workflow zur Überarbeitung bestehender Budgets
Dieser Workflow ist verbindlich, wenn der Benutzer darum bittet, Preise in einer vorhandenen Stückliste, CSV, XLSX oder Budgetdatei zu aktualisieren, zu aktualisieren, neu zu bepreisen, zu überarbeiten oder zu optimieren. Er gilt auch, wenn der Benutzer nur eine kurze Anweisung wie „Preise aktualisieren“ gibt.
- Lesen Sie zuerst das Quell-Artefakt und bewahren Sie den vorhandenen Einzelposten-Stückpreis als Revisionsbasis. Ein vorheriges Budget ist nicht automatisch ein aktueller Preisnachweis, aber es darf nicht stillschweigend durch schwächere Nachweise überschrieben werden.
- Überprüfen Sie vor einer breiten Web-Recherche zugängliche Projektnachweise auf aktuelle Angebote: die Quelldatei, angrenzende/vorherige Budgetversionen, Angebotsaufzeichnungen, Notizen, Screenshots, vom Benutzer bereitgestellte Zahlen und frühere Projektartefakte. Verwerfen Sie ein menschliches Angebot nicht nur, weil es keine öffentliche URL hat.
- Wenden Sie das verbindliche technische Eignungstor vor Preissenkung auf jeden Posten an, dessen günstigerer Kandidat eine verbindliche Anforderung ändert oder unsicher macht.
- Führen Sie für jeden Posten eine Live-Preisrecherche durch, wenn die dazu erforderlichen Tools verfügbar sind.
- Vergleichen Sie jedes Live-Angebot mit der Revisionsbasis und dokumentieren Sie die Preisdifferenz.
- Wenn für einen Posten kein aktuelles Angebot verfügbar ist, behalten Sie den vorherigen Preis bei und markieren Sie ihn als
Nicht überprüftoderBenötigt Bestätigung. - Aktualisieren Sie das Budget oder die Stückliste mit den neuen Preisen und fügen Sie einen Änderungshinweis hinzu.
Diese Fertigkeit wurde gemäß dem portablen Agent Skills-Standard entwickelt.