paulasilvatech ASP Personas do SDLC Agêntico v1.0.0
EN PT ES
11 ops · Operation

Engenheiro DevOps

Pipelines e IaC.

Atualizado: 2026-04-24 14 seções Baixar .zip

O DevOps Engineer é a persona que transforma código de aplicação em infraestrutura deployável e observável. Em um SDLC AI-native, o DevOps Engineer opera uma pilha de primitivas validadas, não uma pilha de shell scripts.

Resumo executivo

O DevOps Engineer é dono do caminho do commit até a produção: continuous integration, continuous delivery, infraestrutura como código, promoção de ambiente e release trains. Em um SDLC AI-native, o DevOps Engineer opera dentro da fase de Operation com um conjunto fixo de primitivas: um agente de pipeline, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. As saídas primárias são workflows do GitHub Actions, módulos Bicep, YAML de pipeline do Azure DevOps, configurações de ambiente e artefatos de release rastreáveis de volta à especificação originária.

Papel e responsabilidades

Pense no DevOps Engineer como um superintendente de trilhos em uma rede ferroviária. Trens (releases) precisam rodar no horário, no trilho certo (ambiente), com a carga certa (artefato), e as chaves (gates) só podem abrir quando os sinais estão verdes. O superintendente não dirige cada trem, mas todo trem que se move com segurança faz isso porque trilho, sinais e chaves foram desenhados, testados e mantidos a montante. Em um SDLC AI-native, o superintendente é um humano operando uma frota de chaves automatizadas construídas com Bicep, GitHub Actions e pipelines do Azure DevOps.

Responsabilidades primárias:

  • Desenhar e manter workflows de CI do GitHub Actions e pipelines de release do Azure DevOps
  • Escrever módulos Bicep para toda infraestrutura Azure, com arquivos de parâmetro por ambiente
  • Aplicar regras de promoção de ambiente via GitHub Environments e approval gates do Azure DevOps
  • Operar release trains em cadência previsível, coordenados com o Release Manager
  • Integrar Azure Policy e deny assignments do Azure Resource Manager para prevenir drift
  • Ser dono do ciclo de vida de secrets com Azure Key Vault e federação OIDC do GitHub Actions
  • Operar o agente Pipeline Smith e os prompts /pipeline-scaffold, /iac-review, /env-promote, /release-train

Jobs to be done

  1. Como DevOps Engineer, eu quero fazer scaffold de um novo pipeline de serviço em minutos, para que novos repos herdem o golden path sem copy-paste.
  2. Como DevOps Engineer, eu quero mudanças Bicep revisadas por um agente que entende o grafo de recursos, para que drift seja pego antes do merge.
  3. Como DevOps Engineer, eu quero promoção de ambiente em uma operação de um clique com checklist legível por máquina, para que promoções sejam reproduzíveis.
  4. Como DevOps Engineer, eu quero composição de release train gerada a partir de PRs merged, para que o dia do corte seja uma assinatura, não uma correria.
  5. Como DevOps Engineer, eu quero que todo pipeline emita traces OpenTelemetry para o Azure Monitor, para que builds falhos sejam debugados com dados, não com intuição.
  6. Como DevOps Engineer, eu quero secrets rotacionados automaticamente com referências do Azure Key Vault, para que nenhuma credencial de longa duração viva em um runner.

Dores antes da era AI-native

  1. Pipelines copy-paste. Cada novo serviço começa a partir do YAML do último serviço, divergindo em semanas. Ninguém é dono das invariantes.
  2. Review de Bicep por memória. Revisores não conseguem manter o grafo de assinatura na cabeça. Drift chega em produção como um typo de parâmetro.
  3. Promoção de ambiente como conhecimento tribal. O checklist de promoção vive na cabeça de um engenheiro sênior; promoções travam quando ele está de férias.
  4. Release trains montados manualmente. A release note é escrita raspando Slack e mensagens de commit na noite anterior ao corte.
  5. Secrets em variáveis de CI. Secrets de longa duração são copiados para variáveis do GitHub Actions e variable groups do Azure DevOps. Rotação é anual, se é que acontece.

Fluxo diário AI-native

O DevOps Engineer opera um loop fixo todo dia. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code e Claude Code no terminal, além de um pequeno catálogo de MCPs validados para contexto externo.

Setup da manhã

  1. Abra o repo da plataforma no Visual Studio Code. GitHub Copilot Chat carrega o AGENTS.md e os .github/instructions/*.instructions.md escopados para Bicep, YAML e PowerShell.
  2. No Claude Code, rode o prompt diário de triage para puxar as falhas de pipeline da madrugada do GitHub Actions e Azure DevOps via GitHub MCP e Azure DevOps MCP.
  3. Revise alertas do Azure Monitor para qualquer deployment falho ou recurso com drift sinalizado pelo Azure Policy.
  4. Confirme a janela de release train do dia no Azure Boards.

Execução no meio do dia

Cada ciclo de meio de dia é uma única mudança de pipeline ou IaC, tipicamente 1 a 3 horas de trabalho focado.

  1. Scaffold ou mudança. Invoque /pipeline-scaffold para gerar um novo workflow do GitHub Actions ou pipeline do Azure DevOps a partir do template de serviço. O agente Pipeline Smith emite o YAML mais a fiação do módulo Bicep.
  2. Review de IaC. Invoque /iac-review no diff Bicep. O agente consulta o Azure MCP para computar o grafo efetivo de recursos e sinaliza violações de policy antes do merge.
  3. Auto-review. Rode bicep build, bicep lint e o deployment what-if contra a assinatura de dev. Hooks aplicam isso antes do commit.
  4. Promoção. Quando a mudança estiver verde em dev, invoque /env-promote para abrir a aprovação em GitHub Environments ou Azure DevOps, com o checklist legível por máquina anexado.
  5. Pull request. A descrição do PR é composta a partir das mensagens de commit, do diff what-if e da especificação linkada. GitHub Copilot Code Review escaneia o diff.

Release train no fim da tarde

  1. Invoque /release-train para montar o release candidato a partir dos PRs merged desde o corte anterior. O agente agrupa mudanças por serviço, computa tier de risco e rascunha a release note.
  2. Entregue o rascunho ao Release Manager para assinatura.
  3. Faça push da tag de release. Pipelines do GitHub Actions e Azure DevOps deployam o artefato para staging, depois para produção com o padrão canary.
  4. Monitore o Application Insights pelos primeiros 30 minutos após o deploy. Se os smoke tests falharem, o prompt /rollback-plan do kit do Release Manager é invocado.

Primitivas recomendadas

Agentes

AgenteArquivoPropósito
pipeline-smith.github/agents/pipeline-smith.agent.mdEscrever e revisar pipelines, Bicep e artefatos de promoção de ambiente

O agente Pipeline Smith usa claude-sonnet-4-6 por padrão. Ele carrega ferramentas read, edit, search, grep, glob, bash e uma ligação MCP ao Azure MCP Server para deployments what-if. Extended thinking fica habilitado para raciocínio de grafo Bicep.

Prompts

ComandoArquivoPropósito
/pipeline-scaffold.github/prompts/pipeline-scaffold.prompt.mdGerar um novo workflow do GitHub Actions ou pipeline do Azure DevOps a partir do template de serviço
/iac-review.github/prompts/iac-review.prompt.mdRevisar um diff Bicep com grafo efetivo de recursos e checks de Azure Policy
/env-promote.github/prompts/env-promote.prompt.mdAbrir uma promoção de ambiente com o checklist legível por máquina
/release-train.github/prompts/release-train.prompt.mdMontar o release train a partir de PRs merged e rascunhar a release note

Instruções

Um applyTo escopado reduz o custo em tokens em aproximadamente 68 por cento em comparação com instruções globais.

Escopo (applyTo)ArquivoPropósito
infra/**/*.bicep.github/instructions/bicep.instructions.mdEstrutura de módulo, arquivos de parâmetro, nomenclatura de recursos, tagging
.github/workflows/**/*.yml.github/instructions/actions.instructions.mdReusable workflows, federação OIDC, sem secrets de longa duração
pipelines/**/*.yml.github/instructions/azdo.instructions.mdStages do Azure DevOps, approval gates, variable groups ligados a Key Vault

Skills

Skills são lazy-loaded, então o DevOps Engineer pode instalar muitos e pagar tokens só pelos que forem ativados.

  • policy-diff: chama o Azure MCP para computar deltas de compliance do Azure Policy em cada mudança Bicep
  • oidc-enforcer: recusa workflows que referenciam padrões de secrets.AZURE_CREDENTIALS de longa duração

Hooks

Hooks custam zero tokens de LLM. São a camada mais forte de governança.

  • pre-commit: bicep lint, actionlint, secret scan via GitHub Advanced Security
  • pre-push: bicep build e what-if contra a assinatura de dev
  • pre-merge: exigir compliance verde no Azure Policy no ambiente-alvo

MCPs validados

Todos os MCPs abaixo estão registrados no catálogo de MCPs. Não referencie nenhum MCP que não esteja no catálogo.

MCPStatusUso nesta persona
GitHub MCP ServerOficialLer runs de workflow, gerenciar releases e environments, abrir PRs
Azure MCP ServerOficial (Microsoft)Deployments what-if, compliance de Azure Policy, queries no Azure Monitor
Azure DevOps MCP ServerOficial (Microsoft)Ler pipelines, gerenciar aprovações de release, atualizar work items no Azure Boards
Microsoft Learn Docs MCPOficialBuscar docs de referência de Bicep e GitHub Actions durante a autoria
Playwright MCPOficial (Microsoft)Dirigir smoke tests pós-deploy contra o ambiente canary
Microsoft 365 Agents SDK MCPOficial (Microsoft)Publicar notificações de release no Teams durante o release train

Exemplos reais

Cenário A: fazer scaffold de um novo pipeline de serviço

Entrada: Um novo microsserviço claims-api precisa de um pipeline CI/CD, módulo Bicep e ambientes de dev/staging/prod.

Invocação: /pipeline-scaffold com nome do serviço e tier.

Saída esperada:

  1. Um reusable workflow do GitHub Actions .github/workflows/claims-api.yml que chama o workflow compartilhado build-test-deploy da organização com federação OIDC para o Azure.
  2. Um módulo Bicep infra/claims-api/main.bicep com arquivos de parâmetro para dev, staging e prod.
  3. Três GitHub Environments configurados com reviewers obrigatórios e secrets com backing de Key Vault.
  4. Um PR intitulado feat(claims-api): scaffold CI/CD and infra linkado ao ticket de intake do serviço.

Cenário B: revisar uma mudança Bicep antes do merge

Entrada: Um PR muda o tier do plano do App Service de P1v3 para P2v3 em três ambientes.

Invocação: /iac-review.

Saída esperada:

  1. Um diff what-if obtido via Azure MCP, resumido por ambiente.
  2. Uma estimativa de delta de custo computada a partir do endpoint Azure Retail Pricing.
  3. Um relatório de compliance do Azure Policy confirmando que o novo SKU é permitido pela policy Allowed SKUs for App Service.
  4. Um comentário de review postado no PR com os três artefatos acima, mais uma recomendação de aprovação.

Anti-padrões

  1. Copy-paste de YAML inline. Cada repo de serviço mantendo seu próprio workflow diverge em um trimestre. Mitigação: reusable workflows referenciados por tag, de propriedade do time de plataforma.
  2. Secrets em variáveis. AZURE_CREDENTIALS de longa duração em variáveis do GitHub Actions ou variable groups do Azure DevOps. Mitigação: federação OIDC com Entra ID; referências a Key Vault para secrets em runtime.
  3. Bicep sem arquivos de parâmetro. Mudar um parâmetro inline para deployar em outro ambiente. Mitigação: um arquivo de parâmetro por ambiente, commitado, revisado pelo agente.
  4. Release notes manuais. Raspar commits na noite anterior ao corte. Mitigação: /release-train compõe a partir de PRs merged com tiers de risco.
  5. Pular o what-if. Deployar Bicep sem preview what-if. Mitigação: hook pre-push falha o push se o what-if não foi rodado.

KPIs e métricas de impacto

A persona DevOps Engineer é avaliada com uma mistura de métricas DORA, SPACE e Agentic DevOps.

MétricaLinha base (manual)Meta (agentic)Medição
Tempo de scaffold de pipeline1 dia< 15 minTempo do ticket de intake até PR verde
Tempo de review de IaC2 dias< 2 horasTempo da abertura do PR até o primeiro comentário de /iac-review
Change failure rate18 por cento< 5 por centoPorcentagem de deploys com rollback em 24 horas
Frequência de deploymentSemanalMúltiplos por diaGitHub Deployments API
Mean time to restore3 horas< 30 minDuração de incidente do Azure Monitor
Incidentes de drift de policy6 por trimestre0Recursos não-compliant do Azure Policy
Idade máxima de secret365 dias< 30 diasAuditoria de rotação do Key Vault
Eficiência de tokensN/A< 500k tokens por release trainRelatório de uso do Copilot

Maturidade em quatro níveis

NívelNomeMarcadores
L1ManualYAML escrito à mão por repo, templates ARM, secrets em variáveis, sem aplicação de policy
L2AssistidoAutocomplete do GitHub Copilot em YAML, Bicep adotado parcialmente, OIDC para alguns ambientes
L3AumentadoUm agente Pipeline Smith, quatro slash prompts, instruções escopadas, Azure MCP para what-if, reusable workflows
L4AutônomoKit completo de primitivas, hooks aplicados, só MCPs validados, release train auto-rascunhado, Azure Policy verde por padrão

Integração com outras personas

Hand-offs:

  • Do Software Architect: topologia-alvo, requisitos não-funcionais, IMPLEMENTATION_PLAN.md
  • Do Developer: PR merged com testes passando, artefato de deployment
  • Para Release Manager: rascunho de release train, tiers de risco, plano de rollback
  • Para SRE: artefato deployado, dashboards, configuração de SLO
  • Para InfoSec Officer: relatório de compliance de policy, auditoria de rotação de secret, mapa de federação OIDC

Glossário

  • Agente: um papel de LLM configurado com ferramentas, instruções e uma forma de saída definida. Vive em .github/agents/<nome>.agent.md.
  • Prompt: um slash command reutilizável que invoca um agente com uma tarefa específica. Vive em .github/prompts/<nome>.prompt.md.
  • Instruções: guia escopado aplicado por pattern match em caminhos de arquivo via applyTo.
  • Skill: uma capacidade lazy-loaded que ativa em match de keyword. Custa tokens só quando acionada.
  • Hook: uma regra de custo zero em tokens aplicada em um evento específico do ciclo de vida.
  • MCP: Model Context Protocol server que expõe sistemas externos ao agente.
  • Bicep: a linguagem específica de domínio para Azure Resource Manager que compila para ARM JSON.
  • Federação OIDC: troca de token de curta duração entre GitHub Actions ou Azure DevOps e Entra ID, substituindo secrets de longa duração.
  • What-if: uma preview do Azure Resource Manager que mostra o efeito de um deployment sem aplicá-lo.

Referências