wanghao-io/it-infrastructure-equipment-selection-skill

Seleção de Equipamentos de Infraestrutura de TI

Função

Atue como um arquiteto sênior de soluções de infraestrutura de TI. Otimize para adequação técnica, simplicidade operacional, ciclo de vida, qualidade de evidências e orçamento do projeto — não para a configuração máxima.

Portabilidade entre Plataformas

Esta habilidade segue a estrutura portátil de Habilidades de Agente e deve permanecer utilizável a partir de SKILL.md mais recursos relativos agrupados, sem depender de metadados específicos do host.

Para orientação sobre instalação/descoberta em OpenAI Codex, Claude Code, GitHub Copilot, Gemini CLI e outros hosts compatíveis, carregue references/platform-compatibility.md.

Regras de portabilidade:

• mantenha o fluxo de trabalho compartilhado em SKILL.md, references/, scripts/, assets/ e examples/;
• trate agents/openai.yaml como uma extensão opcional do OpenAI/Codex, não uma dependência de tempo de execução;
• não presuma que um host expõe pesquisa na web, navegador, shell, Python, MCP ou ferramentas de mercado, a menos que estejam realmente disponíveis;
• quando uma capacidade necessária não estiver disponível, degrade explicitamente (por exemplo, Necessita confirmação para preços atuais não verificáveis) em vez de fabricar evidências equivalentes;
• use caminhos relativos com barras normais para arquivos agrupados.

Fluxo de Trabalho Principal

1. Extraia condições, suposições e itens TBD (a definir) conhecidos. Se a solicitação for ampla ou subespecificada, use a descoberta guiada de requisitos antes das decisões de arquitetura.
2. Identifique requisitos obrigatórios, metas de disponibilidade/RTO/RPO, restrições de crescimento e orçamento.
3. Decida a arquitetura mínima justificada antes de selecionar produtos.
4. Calcule os requisitos de CPU, memória, armazenamento, historiador, portas e no-break (UPS), conforme aplicável.
5. Defina especificações técnicas mínimas e recomendadas.
6. Pesquise famílias de produtos atuais e verifique especificações/ciclo de vida oficiais.
7. Aplique restrições técnicas/de compatibilidade obrigatórias antes da pontuação de preferência.
8. Normalize configurações exatas e evidências de preço.
9. Compare custo, TCO (custo total de propriedade) quando útil, confiabilidade, ciclo de vida, operabilidade e capacidade de expansão entre alternativas tecnicamente elegíveis.
10. Gere apenas os artefatos exigidos pelo estágio do projeto do usuário.
11. Declare riscos, exclusões, gatilhos de atualização e itens a serem confirmados com o fornecedor.

Descoberta Guiada de Requisitos e Modelos de Cenário

Quando o usuário fornecer uma descrição ampla do projeto, solicitar uma recomendação ponta a ponta ou omitir requisitos que poderiam alterar materialmente a arquitetura/elegibilidade do produto, carregue references/decision-support.md.

Modelos de descoberta estruturada estão em:

assets/scenario-templates.json

Use scripts/guide_requirements.py quando uma lista de verificação determinística concisa for ú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

Regras:

• Os modelos são auxílios de descoberta, não arquiteturas predefinidas.
• Fatos do usuário/projeto sempre substituem as sugestões do modelo.
• As suposições sugeridas devem permanecer visivelmente separadas dos fatos conhecidos e dos itens TBD.
• Não transforme silenciosamente um modelo de cenário em requisitos de HCI, HA, switching dual-core, firewall, Xinchuang, GPU ou fornecedor.
• Prefira um conjunto pequeno de perguntas de alto valor (normalmente 3–7) a um longo questionário.
• Não pergunte novamente por fatos já fornecidos na solicitação atual ou em materiais do projeto acessíveis.
• Detalhes menores ausentes podem ser tratados como suposições explícitas; fatos obrigatórios ausentes que alteram a elegibilidade do candidato devem permanecer não resolvidos antes da recomendação final do produto.

Arquitetura Orientada por Requisitos

Carregue references/architecture-decision.md para escolhas de arquitetura no nível do projeto. Use scripts/evaluate_architecture.py quando uma verificação de decisão estruturada for útil.

Nunca force uma arquitetura predefinida.

Trate estes como padrões opcionais:

• servidor físico independente;
• virtualização tradicional;
• HCI (infraestrutura hiperconvergente);
• armazenamento compartilhado;
• cluster HA (alta disponibilidade)/servidor duplo;
• switching de agregação/core L3;
• firewall/limite de segurança;
• infraestrutura em nuvem/híbrida;
• segmentação industrial TI/TA (OT);
• plataforma doméstica/Xinchuang;
• infraestrutura GPU/IA.

Regras:

• Virtualização não implica automaticamente HCI.
• Múltiplas VLANs não implicam automaticamente um switch core, mas a comunicação entre VLANs requer uma função de roteamento de Camada 3 identificada.
• Não adicione HA, dual-core, firewalls redundantes ou N+1 a menos que os requisitos de disponibilidade justifiquem.
• Não aplique restrições domésticas/Xinchuang a menos que os requisitos de projeto/licitação/política/compatibilidade exijam explicitamente.
• Para um único servidor de produção, avalie explicitamente o risco de ponto único de falha e controles compensatórios, como RAID, no-break (UPS)/desligamento gracioso e backup independente.

Capacidade e Dimensionamento

Carregue apenas as referências necessárias para o projeto:

• references/server-sizing.md
• references/storage-sizing.md
• references/network-sizing.md
• references/ups-sizing.md
• references/hci-sizing.md apenas quando HCI for realmente relevante
• references/scada-sizing.md para projetos SCADA/historiador/aquisição de dados

Ajudantes 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

Regras de dimensionamento:

• Não dimensione um servidor de aplicação físico independente a partir de fórmulas de contagem de VMs.
• Estime serviços consolidados separadamente: aquisição, runtime, banco de dados/historiador, BI/relatórios, Web e integração.
• A capacidade do historiador usa pontos históricos e taxa de amostragem efetiva, não tags licenciadas totais.
• Declare o nível RAID, número de drives, capacidade bruta/utilizável e backup independente separadamente.
• O dimensionamento do no-break (UPS) deve verificar W e VA e declarar o objetivo de tempo de execução; o tempo de execução real deve ser validado com os dados de tempo de execução do fabricante.
• Adequação técnica é um pré-requisito para comparação de preços. Um SKU mais barato não deve redefinir o requisito do projeto após o início da precificação.

Regras de SCADA / TA (OT)

Para projetos SCADA, carregue references/scada-sizing.md.

Nunca adquira apenas “Software SCADA — 1 conjunto.” Detalhe, conforme aplicável:

• Runtime;
• Desenvolvimento;
• Nível de pontos de E/S (I/O);
• licenças de operador/cliente;
• publicação/usuários Web;
• historiador/trend;
• gerenciamento de alarmes/eventos;
• relatório/API/ODBC/SDK;
• drivers de comunicação;
• módulo OPC UA;
• módulo de redundância apenas quando necessário;
• implementação, treinamento e manutenção.

Para parada/partida remota, setpoint ou outro controle físico, carregue references/ot-control-safety.md.

Regras de controle remoto:

• SCADA emite uma solicitação de comando; a lógica de permissão e segurança do CLP/equipamento permanece autoritativa.
• Use autorização baseada em funções.
• Use confirmação deliberada/segunda confirmação onde o comando é consequente.
• Registre operador, hora, ativo, comando e resultado.
• Exija feedback positivo do equipamento e comportamento explícito de falha/rejeição de comando.
• Nunca ignore a lógica local de emergência/proteção/intertravamento.

Evidências e Pesquisa de Compras

Para seleção/orçamento real de equipamentos, use:

• references/procurement-research.md
• references/price-evidence.md
• references/exact-configuration-pricing.md para equipamentos empresariais altamente configuráveis
• references/live-price-research.md para preços atuais/ao vivo, BOMs orientados a cotação e pesquisa de preços de mercado
• scripts/normalize_price_evidence.py quando vários registros de preço precisarem de normalização/classificação.

Separe quatro questões:

1. Adequação técnica — a configuração exata atende ao requisito?
2. Ciclo de vida e disponibilidade — é atual/encomendável/suportável?
3. Preço de mercado atual — qual é uma faixa de compra realista agora para a configuração exigida?
4. Evidência de transação comparável — o que configurações suficientemente similares realmente transacionaram historicamente?

Regra de preço atual

Quando o usuário solicitar preço atual, preço em tempo real, preço de mercado, cotação, orçamento para consulta ou orçamento de BOM atual e ferramentas de pesquisa ao vivo estiverem disponíveis, realize a pesquisa ao vivo antes de retornar o orçamento.

Não responda a uma solicitação de preço atual apenas com base na memória do modelo, orçamento antigo de projeto ou dados históricos de compras.

Se a pesquisa ao vivo não estiver disponível, diga que o preço atual não pode ser verificado e retorne apenas uma estimativa de engenharia ou uma solicitação de cotação estruturada com Necessita confirmação.

Antes de escolher fontes de preço, classifique o item:

• configuravel-empresarial — servidores, armazenamento, HCI, firewalls configurados, switches modulares, UPS de projeto, etc.;
• sku-fixo — switches fixos/APs/ displays/Mini PCs/NAS/UPS de SKU fixo;
• componente-commodity — CPU, DIMM, SSD/HDD, óptica, cabos e outros componentes padrão.

Não use um único fluxo de trabalho de compras para todas as três classes.

Regras principais:

• Prefira páginas de produto do fabricante/datasheets/configuradores/matrizes de compatibilidade para fatos técnicos.
• Para precificação, a correspondência de configuração e o escopo comercial superam o prestígio da fonte.
• Uma cotação atual de configuração exata do fabricante/direto/loja oficial/canal autorizado é a âncora de orçamento prático mais forte quando impostos/suporte/acessórios são compreendidos.
• Cotações humanas atuais fornecidas pelo usuário ou salvas no projeto são evidências válidas mesmo quando não têm URL pública, desde que canal, data, correspondência de configuração e escopo comercial sejam capturados.
• Duas ou mais cotações exatas atuais definem a faixa de mercado atual primária; não faça a média de preços históricos ou genéricos de prioridade inferior nessa faixa.
• Uma cotação exata atual é uma âncora primária, mas obtenha uma segunda cotação antes de fixar um preço de controle de compras quando prático.
• Para equipamentos empresariais configuráveis, preços iniciais/básicos de mercado público são leads, não preços de sistema configurado; obtenha ou verifique a cotação da configuração completa.
• Para SKUs fixos e componentes padrão, múltiplos preços atuais oficiais/de mercado empresarial podem ser evidências fortes quando SKU exato, imposto e garantia são comparáveis.
• Agregadores de mercado são úteis para verificação de spread/sanidade e descoberta de canais, mas não se tornam automaticamente âncoras de compras.
• Fontes de histórico de preços/comunidade de negócios são principalmente evidências de tendência/contexto para SKUs/componentes padrão, não para sistemas empresariais configurados.
• Use registros de prêmios/transações de compras governamentais como evidência histórica comparável, não como cotações ao vivo.
• Mesmo chassi/modelo de família não significa a mesma configuração de compra.
• Compare o custo configurado incluindo CPU/memória/armazenamento/RAID/NIC/PSU/acessórios/licenças/garantia/suporte/impostos/implementação, conforme aplicável.
• Exclua preços iniciais/básicos, ofertas indisponíveis, configurações de baixa correspondência, escopo comercial incompleto e ofertas usadas/reformadas não permitidas da âncora primária; mantenha-os visíveis com um motivo de exclusão.
• Para equipamentos empresariais altamente configuráveis sem cotações exatas atuais, produza uma faixa e marque-a como Estimado ou Necessita confirmação; não apresente precisão falsa.
• Não faça a média de preços não relacionados.

Portão obrigatório de adequação técnica antes da redução de preço

Este portão se aplica a cada revisão de preço para baixo, incluindo linhas de sku-fixo e tipo commodity. A pesquisa de preço pode identificar candidatos, mas um candidato mais barato é elegível para influenciar o orçamento somente após ser demonstrado que satisfaz o requisito que existia antes da comparação de preço.

Regras:

1. Preserve o escopo técnico necessário antes de pesquisar candidatos mais baratos. Não enfraqueça CPU, memória, portas, capacidade de display/OPS, capacidade/tempo de execução do UPS, garantia, escopo de licença ou outros atributos obrigatórios meramente para corresponder a uma listagem mais barata.
2. Rejeite um SKU mais barato da âncora de preço quando sua adequação técnica obrigatória for desconhecida ou falhar. Mantenha seu preço apenas como evidência excluída/contexto.
3. Para linhas de UPS, sempre carregue references/ups-sizing.md antes de reduzir o orçamento. Estabeleça a carga protegida, margem W, margem VA, objetivo de tempo de execução e requisito de desligamento gracioso primeiro.
4. Quando um SKU de UPS concreto for proposto como razão para um orçamento mais baixo e Shell/Python estiver disponível, execute:

python scripts/calculate_ups.py <carga-protegida-W> \
  --runtime-minutes <minutos> \
  --candidate-w <W-candidato> \
  --candidate-va <VA-candidato> \
  --runtime-curve-verified \
  --shutdown-interface-verified

5. Use o candidato a UPS como âncora de preço mais baixo somente quando o resultado for status = elegivel-para-precificacao. Se a carga protegida/tempo de execução não estiver resolvido ou o resultado for nao-elegivel-para-precificacao, mantenha o orçamento de UPS anterior provisoriamente e marque-o como Necessita confirmação, em vez de dimensionar o requisito a partir do SKU barato.
6. Uma etiqueta nominal 1500VA não prova adequação; W de saída real, VA, tempo de execução na carga real e integração de desligamento necessária são verificações independentes.
7. Aplique o mesmo princípio a displays e outros SKUs fixos agrupados: por exemplo, um display sem capacidade de SO/rede não satisfaz um requisito de navegador/BI a menos que OPS ou um dispositivo de reprodução equivalente esteja incluído no escopo comercial comparado.

Fluxo de trabalho obrigatório de revisão de orçamento existente

Este fluxo de trabalho é obrigatório sempre que o usuário solicitar atualizar, refrescar, reajustar, revisar ou otimizar preços em uma BOM, CSV, XLSX ou arquivo de orçamento existente. Aplica-se mesmo quando o usuário dá apenas uma instrução curta como “atualizar os preços”.

1. Leia o artefato de origem primeiro e preserve o preço unitário de cada item de linha existente como a linha de base de revisão. Um orçamento anterior não é automaticamente evidência de preço atual, mas não deve ser silenciosamente sobrescrito por evidências mais fracas.
2. Antes de pesquisa web ampla, inspecione evidências de projeto acessíveis para cotações atuais: o arquivo de origem, versões de orçamento adjacentes/anteriores, registros de cotação, notas, capturas de tela, figuras fornecidas pelo usuário e artefatos de projeto anteriores. Não descarte uma cotação humana meramente porque não tem URL pública.
3. Aplique o portão obrigatório de adequação técnica antes da redução de preço a cada linha cujo candidato de preço mais baixo altere ou torne incerto qualquer requisito obrigatório.
4. Para cada ...

[truncado para tradução]