Projetos selecionados

Validar primeiro: uma residência multi-site de Hyper-V e SCVMM

Para o cliente final — a administração de um estado dos EUA — de uma empresa global de serviços de TI · entregue ao abrigo de um contrato de residência da Dell

Os engenheiros do cliente já tinham feito o trabalho pesado: hosts implementados, clusters de failover formados, a malha de rede construída entre dois sites. O que pediram não foi uma reconstrução — foi certeza. Tinha sido bem construído? Aguentaria em operação? E como deveria ser a camada de gestão?

Estruturámos a residência em torno dessa pergunta. As primeiras três semanas foram validação pura: configuração dos hosts, comportamento dos clusters, caminhos de armazenamento e de rede — testados metodicamente, com os resultados documentados à medida que avançávamos. Sem suposições herdadas, sem dar crédito ao «deve estar bem».

Sobre essa fundação validada, desenhámos o estado-alvo do SCVMM e construímo-lo em ambos os sites, seguindo-se sessões de capacitação para que a equipa do cliente pudesse operar o que agora era seu.

O momento que justifica esta história chegou a meio do projeto: a equipa de engenharia do cliente reviu o nosso desenho de estado-alvo e contestou uma das suas decisões centrais — onde deveria ficar a fronteira de responsabilidade entre o Network ATC e o SCVMM para a configuração de rede. Tinham razão em insistir. Revimos o desenho, e a versão 1.1 transporta essa revisão: uma divisão mais limpa de quem gere o quê, acordada linha a linha com as pessoas que operam a plataforma.

Algumas consultoras chamariam a isto fricção de âmbito. Para nós, é o projeto a funcionar exatamente como foi desenhado — fazemos engenharia com o cliente, não à revelia dele. Um desenho que sobrevive aos próprios engenheiros do cliente vale mais do que um que nunca foi posto em causa.

O que ficou quando saímos: relatórios de validação, o desenho de estado-alvo revisto, documentação de construção e uma equipa capacitada para operar a plataforma. Cada hora da residência deixou um artefacto.

Uma metodologia de migração de aplicações, industrializada

Projeto ativo de migração de aplicações com a Dell · entrega B2B2B

As migrações de aplicações raramente falham nas ferramentas. Falham nos intervalos — entre o discovery e o planeamento, entre o runbook na cabeça de alguém e o que é executado às duas da manhã, entre «conseguimos reverter» e um plano de rollback real e testado.

No nosso projeto com a Dell, pegámos na metodologia de migração em três fases da Dell e industrializámo-la: não um framework em slides, mas uma fábrica de migração governada.

Como funciona a fábrica:

• Gates de fase. Cada fase termina num gate com critérios de entrada e de saída definidos. Nada avança por inércia.
• Runbooks gerados — e planos de rollback gerados. Para cada grupo de migração, a fábrica produz o caminho de ida e o de volta, num formato consistente e passível de revisão. O plano de rollback não é um acrescento posterior; é gerado em conjunto com o runbook, todas as vezes.
• Go/no-go humano. Os agentes de IA preparam a evidência — síntese do discovery, mapeamento de dependências, verificações de validação, documentação. Cada decisão de gate é tomada por uma pessoa. Nenhum passo de migração é executado apenas porque um agente o diz.
• Rastreabilidade total. Cada decisão e cada ação fica registada e é atribuível: o que foi feito, quando, por quem e com que aprovação.

Somos deliberadamente cautelosos com o que esta página afirma. Esta é uma história de metodologia e capacidade: a fábrica está produtizada num projeto ativo com a Dell e é entregue em modelo B2B2B aos clientes da Dell. Publicaremos resultados quando as migrações dos clientes estiverem concluídas — não antes.

Se o seu backlog de migração parece uma longa fila de projetos heroicos e irrepetíveis, o modelo de fábrica é a alternativa: consistência industrial nos artefactos e julgamento humano em cada gate.

Delivery agêntico, supervisionado por engenheiros

O nosso modelo de entrega · como decorre cada projeto da Gus IT

A primeira pergunta que um comprador sério faz sobre delivery conduzido por IA é a certa: é seguro deixar agentes de IA aproximarem-se de infraestrutura de produção?

A nossa resposta é uma divisão de trabalho rigorosa, aplicada em todos os projetos.

O que os nossos agentes de IA fazem: a engenharia repetitiva que consome tempo sénior e convida ao erro humano. Executam discovery sobre ambientes inteiros, sintetizam configurações em documentação, geram runbooks e planos de rollback, executam verificações de validação e mantêm o registo documental atualizado — de forma consistente, a qualquer hora, sem fadiga.

O que nunca fazem: aprovar um desenho. Tocar num sistema de produção sem supervisão. Tomar uma decisão de go/no-go.

Cada projeto tem um engenheiro sénior com nome, que responde pela aprovação do desenho e por cada ação que altera o estado dos sistemas. A nossa automatização é construída para dry-run: pode ser ensaiada sem tocar em sistemas reais, e cada fase transporta um plano de rollback antes de transportar uma alteração. Cada ação — humana ou de agente — fica registada e é atribuível: sabe-se sempre quem decidiu e quem agiu.

Porque é que isto lhe interessa: obtém a consistência de uma fábrica nos artefactos — documentação verdadeiramente completa, runbooks verdadeiramente atualizados — sem entregar o julgamento a uma máquina. O engenheiro não corrige os trabalhos de casa da IA depois do facto; o engenheiro é o gate por onde o trabalho tem de passar.

Isto não é um conceito de laboratório. É assim que entregamos hoje o nosso trabalho contratado, incluindo projetos ao abrigo de contratos de parceiros e de canal.

Se está a ponderar se a IA pertence à sua cadeia de delivery — ou como governá-la quando lá estiver —, traga as suas perguntas mais difíceis para a conversa de avaliação. Este modelo foi construído para ser interrogado.