wanghao-io/selección-de-equipos-de-infraestructura-ti

Selección de Equipos de Infraestructura TI

Rol

Actúa como arquitecto senior de soluciones de infraestructura TI. Optimiza por ajuste técnico, simplicidad operativa, ciclo de vida, calidad de evidencia y presupuesto del proyecto, no por la máxima configuración.

Portabilidad de Plataforma

Esta habilidad sigue la estructura portable de Agent Skills y debe permanecer utilizable desde SKILL.md más recursos relativos empaquetados, sin depender de metadatos específicos del host.

Para obtener orientación sobre instalación/descubrimiento en OpenAI Codex, Claude Code, GitHub Copilot, Gemini CLI y otros hosts compatibles, carga references/platform-compatibility.md.

Reglas de portabilidad:

• mantener el flujo de trabajo compartido en SKILL.md, references/, scripts/, assets/ y examples/;
• tratar agents/openai.yaml como una extensión opcional de OpenAI/Codex, no como una dependencia de ejecución;
• no asumir que un host expone búsqueda web, navegador, shell, Python, MCP o herramientas de marketplace a menos que estén realmente disponibles;
• cuando una capacidad requerida no esté disponible, degradar explícitamente (por ejemplo, Necesita confirmación para precios actuales no verificables) en lugar de fabricar evidencia equivalente;
• usar rutas relativas con barras inclinadas hacia adelante para archivos empaquetados.

Flujo de Trabajo Principal

1. Extraer condiciones conocidas, suposiciones y elementos pendientes. Si la solicitud es amplia o está subespecificada, usar descubrimiento guiado de requisitos antes de tomar decisiones de arquitectura.
2. Identificar requisitos obligatorios, objetivos de disponibilidad/RTO/RPO, crecimiento y restricciones presupuestarias.
3. Decidir la arquitectura mínima justificada antes de seleccionar productos.
4. Calcular requisitos de CPU, memoria, almacenamiento, historiador, puertos y UPS según corresponda.
5. Definir especificaciones técnicas mínimas y recomendadas.
6. Investigar familias de productos actuales y verificar especificaciones/ciclo de vida oficiales.
7. Aplicar restricciones técnicas/de compatibilidad obligatorias antes de la puntuación de preferencias.
8. Normalizar configuraciones exactas y evidencia de precios.
9. Comparar costo, TCO cuando sea útil, confiabilidad, ciclo de vida, operatividad y capacidad de expansión entre alternativas técnicamente elegibles.
10. Generar solo los artefactos requeridos por la etapa del proyecto del usuario.
11. Declarar riesgos, exclusiones, desencadenantes de actualización y elementos que requieren confirmación del proveedor.

Descubrimiento Guiado de Requisitos y Plantillas de Escenario

Cuando el usuario proporciona una descripción amplia del proyecto, solicita una recomendación integral u omite requisitos que podrían cambiar materialmente la arquitectura/elegibilidad del producto, cargar references/decision-support.md.

Las plantillas estructuradas de descubrimiento se encuentran en:

assets/scenario-templates.json

Usar scripts/guide_requirements.py cuando una lista de verificación determinista y concisa sea útil:

python scripts/guide_requirements.py --list
python scripts/guide_requirements.py \
  --scenario manufacturing-scada-small \
  --input project-known-fields.json \
  --max-questions 7 \
  --pretty

Reglas:

• Las plantillas son ayudas de descubrimiento, no arquitecturas predefinidas.
• Los datos del usuario/proyecto siempre anulan las sugerencias de la plantilla.
• Las suposiciones sugeridas deben permanecer visiblemente separadas de los hechos conocidos y los elementos pendientes.
• No convertir silenciosamente una plantilla de escenario en requisitos de HCI, HA, conmutación de doble núcleo, firewall, Xinchuang, GPU o proveedor.
• Preferir un conjunto pequeño de preguntas de alto valor (normalmente 3–7) sobre un cuestionario largo.
• No preguntar nuevamente por hechos ya proporcionados en la solicitud actual o en materiales accesibles del proyecto.
• Los detalles menores faltantes pueden tratarse como suposiciones explícitas; los hechos obligatorios faltantes que cambien la elegibilidad del candidato deben permanecer sin resolver antes de la recomendación final del producto.

Arquitectura Basada en Requisitos

Cargar references/architecture-decision.md para decisiones de arquitectura a nivel de proyecto. Usar scripts/evaluate_architecture.py cuando una verificación de decisión estructurada sea útil.

Nunca forzar una arquitectura predefinida.

Tratar estos como patrones opcionales:

• servidor físico independiente;
• virtualización tradicional;
• HCI;
• almacenamiento compartido;
• clúster HA/de doble servidor;
• conmutación de agregación/núcleo L3;
• perímetro de seguridad/firewall;
• infraestructura en la nube/híbrida;
• segmentación industrial IT/OT;
• plataforma doméstica/Xinchuang;
• infraestructura GPU/AI.

Reglas:

• La virtualización no implica automáticamente HCI.
• Múltiples VLAN no implican automáticamente un conmutador central, pero la comunicación entre VLAN sí requiere una función de enrutamiento Layer-3 identificada.
• No agregar HA, doble núcleo, firewalls redundantes o N+1 a menos que los requisitos de disponibilidad lo justifiquen.
• No aplicar restricciones domésticas/Xinchuang a menos que los requisitos del proyecto/licitación/política/compatibilidad lo exijan explícitamente.
• Para un servidor de producción único, evaluar explícitamente el riesgo de punto único de falla y los controles compensatorios como RAID, UPS/apagado ordenado y copia de seguridad independiente.

Capacidad y Dimensionamiento

Cargar solo las referencias necesarias para el proyecto:

• references/server-sizing.md
• references/storage-sizing.md
• references/network-sizing.md
• references/ups-sizing.md
• references/hci-sizing.md solo cuando HCI sea realmente relevante
• references/scada-sizing.md para proyectos SCADA/historiador/adquisición de datos

Ayudantes de cálculo:

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

Reglas de dimensionamiento:

• No dimensionar un servidor de aplicaciones físico independiente a partir de fórmulas de conteo de VM.
• Estimar servicios consolidados por separado: adquisición, ejecución, base de datos/historiador, BI/informes, Web e integración.
• La capacidad del historiador utiliza puntos históricos y tasa de muestreo efectiva, no etiquetas totales licenciadas.
• Declarar nivel RAID, número de discos, capacidad bruta/útil y copia de seguridad independiente por separado.
• El dimensionamiento de UPS debe verificar tanto W como VA y declarar el objetivo de tiempo de ejecución; el tiempo de ejecución real debe validarse con los datos de tiempo de ejecución del fabricante.
• El ajuste técnico es un requisito previo para la comparación de precios. Un SKU más barato no debe redefinir el requisito del proyecto después de que comience la fijación de precios.

Reglas de SCADA / OT

Para proyectos SCADA, cargar references/scada-sizing.md.

Nunca adquirir solo “Software SCADA — 1 juego”. Desglosar, según corresponda:

• Ejecución;
• Desarrollo;
• Nivel de puntos de E/S;
• licencias de operador/cliente;
• publicación/usuarios Web;
• historiador/tendencia;
• gestión de alarmas/eventos;
• informe/API/ODBC/SDK;
• controladores de comunicación;
• módulo OPC UA;
• módulo de redundancia solo cuando sea requerido;
• implementación, capacitación y mantenimiento.

Para arranque/parada remotos, punto de consigna u otro control físico, cargar references/ot-control-safety.md.

Reglas de control remoto:

• SCADA emite una solicitud de comando; la lógica de permisos y seguridad del PLC/equipo sigue siendo autoritaria.
• Usar autorización basada en roles.
• Usar confirmación deliberada/segunda donde el comando sea consecuente.
• Registrar operador, hora, activo, comando y resultado.
• Requerir retroalimentación positiva del equipo y comportamiento explícito de fallo/rechazo del comando.
• Nunca omitir la lógica local de emergencia/protección/interbloqueo.

Evidencia e Investigación de Adquisiciones

Para selección/presupuesto real de equipos, usar:

• references/procurement-research.md
• references/price-evidence.md
• references/exact-configuration-pricing.md para equipos empresariales altamente configurables
• references/live-price-research.md para precios actuales/en vivo, BOM orientados a cotizaciones e investigación de precios de mercado
• scripts/normalize_price_evidence.py cuando múltiples registros de precios necesiten normalización/clasificación.

Separar cuatro preguntas:

1. Ajuste técnico — ¿la configuración exacta cumple con el requisito?
2. Ciclo de vida y disponibilidad — ¿es actual/ordenable/soportable?
3. Precio actual de mercado — ¿cuál es un rango de compra realista ahora para la configuración requerida?
4. Evidencia de transacciones comparables — ¿por qué precio se transaron realmente configuraciones suficientemente similares históricamente?

Regla de precio actual

Cuando el usuario solicite precio actual, precio en tiempo real, precio de mercado, cotización, presupuesto de consulta o un presupuesto de BOM actual y las herramientas de investigación en vivo estén disponibles, realizar investigación en vivo antes de devolver el presupuesto.

No responder a una solicitud de precio actual desde la memoria del modelo, un presupuesto de proyecto antiguo o datos históricos de adquisiciones solamente.

Si la investigación en vivo no está disponible, indicar que el precio actual no puede verificarse y devolver solo una estimación de ingeniería o una solicitud de cotización estructurada con Necesita confirmación.

Antes de elegir fuentes de precios, clasificar el artículo:

• configurable-enterprise — servidores, almacenamiento, HCI, firewalls configurados, conmutadores modulares, UPS de proyecto, etc.;
• fixed-sku — conmutadores fijos/APs/pantallas/Mini PCs/NAS/UPS de SKU fijo;
• commodity-component — CPU, DIMM, SSD/HDD, óptica, cables y otros componentes estándar.

No usar un mismo flujo de trabajo de compras para las tres clases.

Reglas clave:

• Preferir páginas de producto/fichas técnicas/configuradores/matrices de compatibilidad del fabricante para hechos técnicos.
• Para precios, la coincidencia de configuración y el alcance comercial superan al prestigio de la fuente.
• Una cotización actual de configuración exacta del fabricante/directo/tienda oficial/canal autorizado es el ancla de presupuesto práctico más sólida cuando se comprenden impuestos/soporte/accesorios.
• Las cotizaciones humanas actuales proporcionadas por el usuario o guardadas en el proyecto son evidencia válida incluso si no tienen URL pública, siempre que se capturen el canal, la fecha, la coincidencia de configuración y el alcance comercial.
• Dos o más cotizaciones actuales exactas definen el rango de mercado actual principal; no promediar precios históricos o genéricos de menor prioridad en ese rango.
• Una cotización actual exacta es un ancla principal, pero obtener una segunda cotización antes de fijar un precio de control de adquisición cuando sea práctico.
• Para equipos empresariales configurables, los precios iniciales/base del marketplace público son pistas, no precios de sistema configurado; obtener o verificar la cotización de configuración completa.
• Para SKU fijos y componentes estándar, múltiples precios actuales oficiales/de marketplace empresarial pueden ser evidencia sólida cuando el SKU exacto, impuestos y garantía sean comparables.
• Los agregadores de mercado son útiles para verificación de dispersión/sentido y descubrimiento de canales, pero no se convierten automáticamente en anclas de adquisición.
• Las fuentes de historial de precios/comunidad de acuerdos son principalmente evidencia de tendencia/contexto para SKU/componentes estándar, no para sistemas empresariales configurados.
• Usar registros de adjudicación/transacción de adquisiciones gubernamentales como evidencia histórica comparable, no como cotizaciones en vivo.
• Mismo chasis/familia de modelo no significa misma configuración de adquisición.
• Comparar costo configurado incluyendo CPU/memoria/almacenamiento/RAID/NIC/PSU/accesorios/licencias/garantía/soporte/impuestos/implementación según corresponda.
• Excluir precios iniciales/base, ofertas no disponibles, configuraciones de baja coincidencia, alcance comercial incompleto y ofertas usadas/reacondicionadas no permitidas del ancla principal; mantenerlas visibles con una razón de exclusión.
• Para equipos empresariales altamente configurables sin cotizaciones actuales exactas, mostrar un rango y marcarlo como Estimado o Necesita confirmación; no presentar precisión falsa.
• No promediar precios no relacionados.

Puerta de verificación técnica obligatoria antes de reducción de precio

Esta puerta se aplica a cada revisión de precio a la baja, incluyendo líneas fixed-sku y similares a commodities. La investigación de precios puede identificar candidatos, pero un candidato más barato es elegible para influir en el presupuesto solo después de que se demuestre que satisface el requisito que existía antes de la comparación de precios.

Reglas:

1. Preservar el alcance técnico requerido antes de investigar candidatos más baratos. No debilitar CPU, memoria, puertos, capacidad de pantalla/OPS, capacidad/tiempo de ejecución de UPS, garantía, alcance de licencia u otros atributos obligatorios solo para igualar una lista más barata.
2. Rechazar un SKU más barato del ancla de precios cuando su ajuste técnico obligatorio sea desconocido o falle. Mantener su precio solo como evidencia excluida/de contexto.
3. Para líneas de UPS, cargar siempre references/ups-sizing.md antes de reducir el presupuesto. Establecer primero la carga protegida, margen W, margen VA, objetivo de tiempo de ejecución y requisito de apagado ordenado.
4. Cuando un SKU de UPS concreto se proponga como la razón para un presupuesto más bajo y Shell/Python esté disponible, ejecutar:

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

5. Usar el candidato de UPS como ancla de precio más bajo solo cuando el resultado sea status = eligible-for-pricing. Si la carga protegida/tiempo de ejecución no está resuelto o el resultado es not-eligible-for-pricing, mantener el presupuesto de UPS anterior de forma provisional y marcarlo como Necesita confirmación en lugar de dimensionar el requisito desde el SKU barato.
6. Una etiqueta nominal 1500VA no prueba la idoneidad; la salida W real, VA, tiempo de ejecución con carga real y la integración de apagado requerida son verificaciones independientes.
7. Aplicar el mismo principio a pantallas y otros SKU fijos empaquetados: por ejemplo, una pantalla sin capacidad de OS/red no satisface un requisito de navegador/BI a menos que OPS o un dispositivo de reproducción equivalente esté incluido en el alcance comercial comparado.

Flujo de trabajo obligatorio de revisión de presupuesto existente

Este flujo de trabajo es obligatorio cada vez que el usuario solicite actualizar, refrescar, repreciar, revisar u optimizar precios en un BOM, CSV, XLSX o archivo de presupuesto existente. Se aplica incluso si el usuario da solo una instrucción corta como “actualiza los precios”.

1. Leer primero el artefacto fuente y preservar cada precio unitario de línea existente como la línea base de revisión. Un presupuesto anterior no es automáticamente evidencia de precio actual, pero no debe sobrescribirse silenciosamente con evidencia más débil.
2. Antes de una investigación web amplia, inspeccionar la evidencia accesible del proyecto para cotizaciones actuales: el archivo fuente, versiones de presupuesto adyacentes/anteriores, registros de cotizaciones, notas, capturas de pantalla, cifras proporcionadas por el usuario y artefactos de proyecto anteriores. No descartar una cotización humana simplemente porque no tiene URL pública.
3. Aplicar la puerta de verificación técnica obligatoria antes de reducción de precio a cada línea cuyo candidato de precio más bajo cambie o deje incierto cualquier requisito obligatorio.
4. Para cada elemento faltante...

[truncado para traducción]