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

Ingeniero DevOps

Pipelines e IaC.

Actualizado: 2026-04-24 14 secciones Descargar .zip

El DevOps Engineer es la persona que convierte el código de aplicación en infraestructura desplegable y observable. En un SDLC AI-native, el DevOps Engineer opera un stack de primitivas validadas, no un stack de scripts de shell.

Resumen ejecutivo

El DevOps Engineer es dueño del camino del commit a producción: integración continua, entrega continua, infraestructura como código, promoción de entornos y trenes de release. En un SDLC AI-native, el DevOps Engineer opera dentro de la fase de Operation con un conjunto fijo de primitivas: un agente de pipeline, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son workflows de GitHub Actions, módulos Bicep, YAML de pipelines de Azure DevOps, configuraciones de entorno y artefactos de release trazables hasta la especificación de origen.

Rol y responsabilidades

Piense en el DevOps Engineer como un superintendente de vías en una red ferroviaria. Los trenes (releases) deben correr a tiempo, en la vía correcta (entorno), con la carga correcta (artefacto), y los cambios (gates) deben abrirse solo cuando las señales están en verde. El superintendente no conduce cada tren, pero cada tren que se mueve con seguridad lo hace porque la vía, las señales y los cambios fueron diseñados, probados y mantenidos aguas arriba. En un SDLC AI-native, el superintendente es un humano operando una flota de cambios automatizados construidos con Bicep, GitHub Actions y pipelines de Azure DevOps.

Responsabilidades principales:

  • Diseñar y mantener workflows CI de GitHub Actions y pipelines de release de Azure DevOps
  • Autorar módulos Bicep para toda la infraestructura Azure, con archivos de parámetros por entorno
  • Aplicar reglas de promoción de entornos vía GitHub Environments y gates de aprobación de Azure DevOps
  • Operar trenes de release con cadencia predecible, coordinados con el Release Manager
  • Integrar Azure Policy y deny assignments de Azure Resource Manager para prevenir drift
  • Ser dueño del ciclo de vida de los secretos con Azure Key Vault y federación OIDC de GitHub Actions
  • Operar el agente Pipeline Smith y los prompts /pipeline-scaffold, /iac-review, /env-promote, /release-train

Jobs to be done

  1. Como DevOps Engineer, quiero levantar un nuevo pipeline de servicio en minutos, para que los nuevos repos hereden el golden path sin copiar y pegar.
  2. Como DevOps Engineer, quiero que los cambios de Bicep sean revisados por un agente que entiende el grafo de recursos, para que el drift se detecte antes del merge.
  3. Como DevOps Engineer, quiero que la promoción de entornos sea una operación de un clic con un checklist legible por máquina, para que las promociones sean reproducibles.
  4. Como DevOps Engineer, quiero que la composición del tren de release se genere a partir de PRs mergeados, para que el día de cut sea una firma, no una corrida.
  5. Como DevOps Engineer, quiero que cada pipeline emita trazas OpenTelemetry hacia Azure Monitor, para que las builds fallidas se depuren con datos, no con intuición.
  6. Como DevOps Engineer, quiero que los secretos roten automáticamente con referencias de Azure Key Vault, para que ninguna credencial de larga vida viva en un runner.

Puntos de dolor antes de la era AI-native

  1. Pipelines copy-paste. Cada nuevo servicio empieza desde el YAML del último servicio, divergiendo en semanas. Nadie es dueño de los invariantes.
  2. Revisión de Bicep de memoria. Los reviewers no pueden sostener el grafo de la suscripción en su cabeza. El drift llega a producción como un typo de parámetro.
  3. Promoción de entorno como conocimiento tribal. El checklist de promoción vive en la cabeza de un ingeniero senior; las promociones se estancan cuando esa persona está de licencia.
  4. Trenes de release armados manualmente. La nota de release se escribe rastreando Slack y mensajes de commit la noche anterior al cut.
  5. Secretos en variables de CI. Secretos de larga vida se copian en variables de GitHub Actions y grupos de variables de Azure DevOps. La rotación es anual, si acaso.

Flujo diario AI-native

El DevOps Engineer opera un ciclo fijo cada día. El ciclo usa primitivas de GitHub Copilot dentro de Visual Studio Code y Claude Code en la terminal, más un pequeño catálogo de MCPs validados para contexto externo.

Setup de la mañana

  1. Abrir el repo de plataforma en Visual Studio Code. GitHub Copilot Chat carga AGENTS.md y los .github/instructions/*.instructions.md con alcance para Bicep, YAML y PowerShell.
  2. En Claude Code, ejecutar el prompt diario de triage para extraer las fallas nocturnas de pipeline desde GitHub Actions y Azure DevOps vía el GitHub MCP y el Azure DevOps MCP.
  3. Revisar alertas de Azure Monitor por cualquier despliegue fallido o recurso con drift marcado por Azure Policy.
  4. Confirmar la ventana del tren de release del día en Azure Boards.

Ejecución al mediodía

Cada ciclo de mediodía es un único cambio de pipeline o IaC, típicamente 1 a 3 horas de trabajo enfocado.

  1. Scaffold o cambio. Invocar /pipeline-scaffold para generar un nuevo workflow de GitHub Actions o pipeline de Azure DevOps desde la plantilla del servicio. El agente Pipeline Smith emite el YAML más el cableado del módulo Bicep.
  2. Revisión IaC. Invocar /iac-review sobre el diff de Bicep. El agente consulta el Azure MCP para computar el grafo efectivo de recursos y marca violaciones de policy antes del merge.
  3. Self-review. Ejecutar bicep build, bicep lint y el deployment what-if contra la suscripción de dev. Los hooks aplican esto antes del commit.
  4. Promover. Cuando el cambio está verde en dev, invocar /env-promote para abrir la aprobación en GitHub Environments o Azure DevOps, con el checklist legible por máquina adjunto.
  5. Pull request. La descripción del PR se compone desde los mensajes de commit, el diff de what-if y la especificación vinculada. GitHub Copilot Code Review escanea el diff.

Tren de release en la tarde

  1. Invocar /release-train para ensamblar el release candidate desde los PRs mergeados desde el cut anterior. El agente agrupa cambios por servicio, computa el risk tier y redacta la nota de release.
  2. Entregar el borrador al Release Manager para signoff.
  3. Empujar el tag de release. Los pipelines de GitHub Actions y Azure DevOps despliegan el artefacto a staging, luego a producción con el patrón canary.
  4. Monitorear Application Insights durante los primeros 30 minutos tras el deploy. Si los smoke tests fallan, se invoca el prompt /rollback-plan del kit del Release Manager.

Primitivas recomendadas

Agentes

AgenteArchivoPropósito
pipeline-smith.github/agents/pipeline-smith.agent.mdAutorar y revisar pipelines, Bicep y artefactos de promoción de entornos

El agente Pipeline Smith usa claude-sonnet-4-6 por defecto. Tiene herramientas read, edit, search, grep, glob, bash y un binding MCP al Azure MCP Server para deployments what-if. El extended thinking está habilitado para razonar sobre el grafo Bicep.

Prompts

ComandoArchivoPropósito
/pipeline-scaffold.github/prompts/pipeline-scaffold.prompt.mdGenerar un nuevo workflow de GitHub Actions o pipeline de Azure DevOps desde la plantilla del servicio
/iac-review.github/prompts/iac-review.prompt.mdRevisar un diff de Bicep con grafo efectivo de recursos y chequeos de Azure Policy
/env-promote.github/prompts/env-promote.prompt.mdAbrir una promoción de entorno con el checklist legible por máquina
/release-train.github/prompts/release-train.prompt.mdEnsamblar el tren de release desde PRs mergeados y redactar la nota de release

Instructions

El applyTo con alcance reduce el costo de tokens en aproximadamente 68 por ciento comparado con instrucciones globales.

Alcance (applyTo)ArchivoPropósito
infra/**/*.bicep.github/instructions/bicep.instructions.mdEstructura de módulos, archivos de parámetros, naming de recursos, tagging
.github/workflows/**/*.yml.github/instructions/actions.instructions.mdWorkflows reutilizables, federación OIDC, sin secretos de larga vida
pipelines/**/*.yml.github/instructions/azdo.instructions.mdStages de Azure DevOps, gates de aprobación, grupos de variables vinculados a Key Vault

Skills

Los skills se cargan de forma perezosa, así que el DevOps Engineer puede instalar muchos y pagar tokens solo por los que se disparan.

  • policy-diff: llama al Azure MCP para computar deltas de cumplimiento de Azure Policy en cada cambio de Bicep
  • oidc-enforcer: rechaza workflows que referencian patrones de larga vida secrets.AZURE_CREDENTIALS

Hooks

Los hooks cuestan cero tokens de LLM. Son la capa de gobernanza más fuerte.

  • pre-commit: bicep lint, actionlint, scan de secretos vía GitHub Advanced Security
  • pre-push: bicep build y what-if contra la suscripción de dev
  • pre-merge: requerir cumplimiento verde de Azure Policy en el entorno objetivo

MCPs validados

Cada MCP a continuación está registrado en el catálogo de MCPs. No referencie ningún MCP que no esté en el catálogo.

MCPEstadoUso en esta persona
GitHub MCP ServerOficialLeer ejecuciones de workflows, gestionar releases y entornos, abrir PRs
Azure MCP ServerOficial (Microsoft)Deployments what-if, cumplimiento de Azure Policy, queries de Azure Monitor
Azure DevOps MCP ServerOficial (Microsoft)Leer pipelines, gestionar aprobaciones de release, actualizar work items de Azure Boards
Microsoft Learn Docs MCPOficialConsultar docs de referencia de Bicep y GitHub Actions durante la autoría
Playwright MCPOficial (Microsoft)Conducir smoke tests post-deploy contra el entorno canary
Microsoft 365 Agents SDK MCPOficial (Microsoft)Publicar notificaciones de release en Teams durante el tren de release

Ejemplos reales

Escenario A: levantar un nuevo pipeline de servicio

Entrada: Un nuevo microservicio claims-api necesita un pipeline CI/CD, módulo Bicep y entornos dev/staging/prod.

Invocación: /pipeline-scaffold con nombre del servicio y tier.

Salida esperada:

  1. Un workflow reutilizable de GitHub Actions .github/workflows/claims-api.yml que llama al workflow compartido de la organización build-test-deploy con federación OIDC hacia Azure.
  2. Un módulo Bicep infra/claims-api/main.bicep con archivos de parámetros para dev, staging y prod.
  3. Tres GitHub Environments configurados con reviewers requeridos y secretos respaldados por Key Vault.
  4. Un PR titulado feat(claims-api): scaffold CI/CD and infra vinculado al ticket de intake del servicio.

Escenario B: revisar un cambio de Bicep antes del merge

Entrada: Un PR cambia el tier del App Service plan de P1v3 a P2v3 en tres entornos.

Invocación: /iac-review.

Salida esperada:

  1. Un diff what-if obtenido vía el Azure MCP, resumido por entorno.
  2. Una estimación de delta de costo computada desde el endpoint de Azure Retail Pricing.
  3. Un reporte de cumplimiento de Azure Policy que confirma que el nuevo SKU está permitido por la policy Allowed SKUs for App Service.
  4. Un comentario de review publicado en el PR con los tres artefactos anteriores, más una recomendación de aprobación.

Anti-patrones

  1. Copy-paste de YAML inline. Cada repo de servicio que mantiene su propio workflow diverge en un trimestre. Mitigación: workflows reutilizables referenciados por tag, propiedad del equipo de plataforma.
  2. Secretos en variables. AZURE_CREDENTIALS de larga vida en GitHub Actions o grupos de variables de Azure DevOps. Mitigación: federación OIDC con Entra ID; referencias de Key Vault para secretos de runtime.
  3. Bicep sin archivos de parámetros. Cambiar un parámetro inline para desplegar a otro entorno. Mitigación: un archivo de parámetros por entorno, versionado, revisado por el agente.
  4. Notas de release manuales. Rastrear commits la noche anterior al cut. Mitigación: /release-train compone desde PRs mergeados con risk tiers.
  5. Saltarse el what-if. Desplegar Bicep sin un preview what-if. Mitigación: el hook pre-push falla el push si no se ejecutó what-if.

KPIs y métricas de impacto

La persona DevOps Engineer se evalúa con una mezcla de métricas DORA, SPACE y Agentic DevOps.

MétricaLínea base (manual)Meta (agéntico)Medición
Tiempo de scaffold de pipeline1 día< 15 minTiempo desde ticket de intake a PR verde
Tiempo de revisión IaC2 días< 2 horasTiempo desde apertura de PR al primer comentario /iac-review
Change failure rate18 por ciento< 5 por cientoPorcentaje de deploys revertidos en 24 horas
Frecuencia de despliegueSemanalMúltiples por díaAPI de GitHub Deployments
Mean time to restore3 horas< 30 minDuración de incidentes en Azure Monitor
Incidentes de drift de policy6 por trimestre0Recursos no conformes en Azure Policy
Edad del secreto (máx)365 días< 30 díasAuditoría de rotación en Key Vault
Eficiencia de tokensN/A< 500k tokens por tren de releaseReporte de uso de Copilot

Madurez en cuatro niveles

NivelNombreMarcadores
L1ManualYAML escrito a mano por repo, plantillas ARM, secretos en variables, sin enforcement de policy
L2AsistidoAutocompletado de GitHub Copilot en YAML, Bicep adoptado parcialmente, OIDC para algunos entornos
L3AumentadoUn agente Pipeline Smith, cuatro slash prompts, instrucciones con alcance, Azure MCP para what-if, workflows reutilizables
L4AutónomoKit completo de primitivas, hooks aplicados, solo MCPs validados, tren de release auto-redactado, Azure Policy verde por defecto

Integración con otras personas

Hand-offs:

  • Desde el Software Architect: topología objetivo, requisitos no funcionales, IMPLEMENTATION_PLAN.md
  • Desde el Developer: PR mergeado con tests pasando, artefacto de despliegue
  • Hacia el Release Manager: borrador del tren de release, risk tiers, plan de rollback
  • Hacia el SRE: artefacto desplegado, dashboards, configuración de SLO
  • Hacia el InfoSec Officer: reporte de cumplimiento de policy, auditoría de rotación de secretos, mapa de federación OIDC

Glosario

  • Agente: un rol LLM configurado con herramientas, instrucciones y una forma de salida definida. Vive en .github/agents/<name>.agent.md.
  • Prompt: un slash command reutilizable que invoca a un agente con una tarea específica. Vive en .github/prompts/<name>.prompt.md.
  • Instructions: guía con alcance aplicada por coincidencia de patrón en rutas de archivos vía applyTo.
  • Skill: capacidad cargada de forma perezosa que se activa por coincidencia de palabra clave. Cuesta tokens solo cuando se dispara.
  • Hook: una regla de cero tokens aplicada en un evento específico del ciclo de vida.
  • MCP: servidor Model Context Protocol que expone sistemas externos al agente.
  • Bicep: el lenguaje específico de dominio para Azure Resource Manager que compila a ARM JSON.
  • Federación OIDC: intercambio de tokens de corta vida entre GitHub Actions o Azure DevOps y Entra ID, reemplazando secretos de larga vida.
  • What-if: un preview de Azure Resource Manager que muestra el efecto de un deployment sin aplicarlo.

Referencias