01
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Linux Fundamentals |
Filesystem, permisos, procesos y systemd
FHS ·
chmod/chown · users/groups · ps/top/htop · systemctl · journald · signals · cron/crontab |
Navegar y administrar un sistema Linux con fluidez — el substrato de todo servidor, contenedor y pipeline de CI/CD de la industria. | Fácil | Configurar un servidor Ubuntu desde cero: crear usuarios con sudo restringido, programar un cron que rota logs, crear un servicio systemd que sobrevive reinicios y diagnosticar un proceso zombie. | Servicio arranca automáticamente tras reboot; cron ejecuta sin errores en 3 ciclos consecutivos; permisos mínimos verificados con ls -la; no existe ningún usuario con UID 0 adicional a root. |
|
| Shell Scripting |
Bash: variables, condicionales, bucles, funciones y exit codes
$? · set -euo pipefail · trap · here-docs · pipes · redirecciones · getopts · scripts idempotentesLinux fundamentals
|
Escribir scripts Bash robustos que fallen de forma predecible, sean idempotentes y puedan ejecutarse en cualquier pipeline de CI/CD sin sorpresas. | Fácil | Script de backup incremental que comprime directorios, gestiona retención de 7 días, notifica por email si falla y pasa ShellCheck sin warnings. Segundo script de health check de un servidor HTTP. | PythonShellCheck sin warnings; set -euo pipefail en todo script; idempotente (ejecutar dos veces produce el mismo resultado); exit code no-zero si el health check falla. |
|
| Networking |
TCP/IP, DNS, HTTP/HTTPS y SSH — la base de toda infraestructura
Modelo OSI simplificado · subnets · CIDRs · DNS resolution · TLS handshake · puertos bien conocidos ·
curl · dig · netstat/ss · SSH keysLinux fundamentals (herramientas de red en el SO)
|
Diagnosticar problemas de conectividad con herramientas nativas de Linux — el 80% de los incidentes de infraestructura tiene raíz en DNS, rutas o TLS mal configurados. | Fácil | Diagnosticar 5 escenarios de fallo: DNS roto, puerto cerrado, certificado expirado, ruta bloqueada y latencia alta. Documentar el proceso de triage con comandos exactos y output esperado. | PythonCada escenario resuelto con comandos en ≤3 pasos; script Python con socket/requests que verifica conectividad y TLS de una lista de endpoints; 0 dependencias externas. |
|
| Git |
Git: branching, merge vs rebase, pull requests y GitFlow
git rebase -i · git bisect · conventional commits · .gitignore · git stash · git cherry-pick · branch protection rules |
Gestionar el historial del código como activo de auditoría y colaboración — la base de cualquier pipeline de CI/CD y estrategia de deployment. | Fácil | Repositorio de infraestructura con GitFlow: rama main protegida, PRs con revisión obligatoria, historial limpio con commits convencionales y un rebase interactivo que consolida 10 WIP commits en 3 atómicos. |
Sin commits directos a main; 100% conventional commits; rebase sin conflictos no resueltos; git log --oneline narra la historia del proyecto de forma comprensible. |
|
| Python para DevOps |
Python: scripting de sistema, manipulación de archivos y llamadas a APIs
os · subprocess · pathlib · argparse · requests · JSON/YAML parsing · manejo de errores · loggingShell scripting (Python como alternativa más potente) + Networking (HTTP requests)
|
Usar Python para automatizar tareas de infraestructura que superan las capacidades de Bash — APIs, parsing de datos complejos y lógica de orquestación robusta. | Fácil | Script Python que llama a la GitHub API para listar los últimos 10 deployments de un repositorio, parsea la respuesta JSON y genera un reporte en Markdown con estado de cada deployment. | PythonScript maneja errores HTTP con mensajes claros; token en variable de entorno (no hardcodeado); reporte generado correctamente; ejecutable desde CLI con argparse para distintos repos. |
|
| Docker Intro |
Docker: imágenes, contenedores, Dockerfile y Docker Hub
Layer model ·
FROM · RUN · COPY · CMD/ENTRYPOINT · volúmenes · redes bridge · docker logs · docker execLinux fundamentals (namespaces, cgroups conceptually) + Networking (puertos y bridge)
|
Contenerizar aplicaciones para entornos reproducibles — el estándar de empaquetado de la industria que elimina el "en mi máquina funciona". | Medio | Containerizar una app web en Python (Flask o FastAPI): Dockerfile que sirve la app, volumen para datos persistentes y red bridge entre el contenedor y una instancia de Redis. Imagen publicada en Docker Hub. | PythonContenedor arranca con docker run sin configuración manual; datos persisten entre reinicios del contenedor; imagen publicada correctamente; sin secretos en el Dockerfile ni en la imagen. |
|
| Cloud Concepts |
Fundamentos de Cloud: IaaS/PaaS/SaaS, regiones, AZs y responsabilidad compartida
AWS/GCP/Azure overview · región vs AZ · modelo de responsabilidad compartida · billing basics · free tier · consola vs CLI · IAM conceptos
Networking (VPC usa conceptos de red) + Linux (instancias son servidores Linux)
|
Comprender el modelo de nube pública para tomar decisiones informadas sobre dónde y cómo desplegar — la base de toda infraestructura moderna en empresas como Netflix, Shopify y MercadoLibre. | Fácil | Desplegar manualmente una VM en AWS (EC2) con una app en Python, accesible vía HTTP desde Internet. Configurar un Security Group correcto y conectarse via SSH con par de claves generado. Luego, terminarla y analizar el costo. | PythonApp accesible públicamente en el puerto correcto; SSH funciona solo con la clave correcta; Security Group con mínimo privilegio (sin 0.0.0.0/0 en SSH); instancia terminada y costo analizado en Cost Explorer. |
02
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Docker Avanzado |
Docker: multi-stage builds, Compose, registry privado y seguridad de imágenes
Builder + runtime layers · imagen <150MB · non-root user ·
healthcheck · Compose con múltiples servicios · docker scout · .dockerignoreDocker intro (Trainee) + Cloud concepts (ECR/Artifact Registry)
|
Construir imágenes mínimas, seguras y reproducibles; orquestar stacks locales completos en un comando para onboarding en < 5 minutos — estándar en Shopify y Stripe. | Medio | Imagen multi-stage para una API Python <150MB; usuario non-root; Compose con app + PostgreSQL + Redis + healthchecks; API sólo arranca cuando DB pasa healthcheck; imagen escaneada con docker scout. |
PythonImagen <150MB; 0 vulnerabilidades críticas con docker scout; depends_on con condición de healthcheck; setup < 2 min desde cero en máquina limpia. |
|
| CI/CD Básico |
GitHub Actions: workflows, jobs, steps, artifacts y secrets
Triggers (
push, pull_request, schedule) · matrix builds · caching dependencies · GITHUB_TOKEN · environments · reusable workflowsGit + Docker (build en pipeline) + Cloud (deploy target)
|
Automatizar el ciclo test → build → deploy para que ningún código llegue a producción sin pasar validaciones automáticas — práctica fundamental en toda empresa de tecnología 2026. | Medio | Pipeline completo para una app Python: lint (ruff) + test (pytest con cobertura) + build Docker + push a ECR/GHCR + deploy automático a staging en PR merge. Pipeline de producción con aprobación manual. | PythonPipeline falla si tests no pasan; imagen con digest en el registry; caching activo (dependencias y capas Docker); secretos en GitHub Secrets nunca en código; deployment de producción requiere aprobación. | |
| AWS Core |
AWS: EC2, S3, VPC, IAM y RDS — los bloques fundamentales
Security Groups · subnets públicas/privadas · IAM roles vs users vs policies · least privilege · S3 bucket policies · RDS parameter groups · AWS CLI
Cloud concepts (Trainee) + Networking (VPC = red virtual) + Linux (EC2 es Linux)
|
Provisionar infraestructura cloud segura con el menor privilegio posible — base de toda arquitectura en AWS que siguen Netflix, Shopify y MercadoLibre. | Medio | Arquitectura en AWS para una app Python: EC2 en subnet privada, ALB en subnet pública, RDS Postgres con acceso solo desde la subnet privada, S3 con lifecycle policy y un IAM role con permisos mínimos para la app. | PythonRDS no accesible desde Internet; S3 sin acceso público; IAM role sin *:*; script Python boto3 que lista recursos y detecta configuraciones inseguras (S3 público, Security Groups 0.0.0.0/0). |
|
| Terraform Básico |
Terraform: providers, resources, variables, outputs y state
terraform init/plan/apply/destroy · tfstate · remote state en S3 + DynamoDB lock · terraform.tfvars · data sources · depends_onAWS Core (lo que se provisiona) + Git (state en remoto, código en repo)
|
Gestionar infraestructura como código reproducible y auditable — la diferencia entre infraestructura clickeada y infraestructura que puede reconstruirse en minutos. Estándar de HashiCorp adoptado en toda la industria. | Medio | Infraestructura AWS completa en Terraform: VPC + subnets + IGW + EC2 + SG + S3 + RDS; remote state en S3 con locking; terraform plan sin errores en entorno limpio; destroyed y re-created sin intervención manual. |
PythonInfraestructura reproducible en < 10 min; sin recursos huérfanos tras destroy; state en S3 con locking; script Python que valida que la infra desplegada coincide con las variables declaradas. | |
| Ansible |
Ansible: playbooks, inventarios, roles e idempotencia
ansible-playbook · módulos: apt, copy, template, service, user · handlers · Ansible Vault · roles con defaults/ y vars/ · idempotencia verificadaLinux (lo que se configura) + SSH (transporte) + Git (roles en repositorio)
|
Configurar servidores de forma declarativa, idempotente y auditable — eliminar la "configuration drift" que convierte la infraestructura en un sistema frágil con el tiempo. | Medio | Role de Ansible que instala y configura Nginx + aplicación Python en 3 entornos (dev/staging/prod) con variables por entorno; segundo run produce 0 cambios; secretos con Ansible Vault. | PythonSegundo run con 0 changed tasks; secretos nunca en texto plano en el repo; configuración diferente por entorno sin duplicar código; playbook ejecutable desde cero en servidor limpio. |
|
| Observabilidad Básica |
Prometheus + Grafana: métricas, dashboards y alertas básicas
Pull model · exporters ·
node_exporter · PromQL básico · Grafana datasource · paneles de CPU/mem/disk · Alertmanager rules · PagerDuty/Slack webhookDocker Compose (stack de monitoring local) + Cloud (servidores a monitorear)
|
Visibilizar el estado de la infraestructura en tiempo real con alertas que notifiquen antes de que los usuarios lo experimenten — el primer paso hacia el uptime de las empresas top. | Medio | Stack de monitoring con Prometheus + Grafana + Alertmanager en Docker Compose; dashboards para CPU, memoria, disco y latencia HTTP; alerta que dispara Slack cuando CPU >80% por 5 minutos. | PythonAlerta dispara en escenario de prueba en <1 min; dashboards exportados como JSON en el repo; script Python que expone métricas custom de la app vía prometheus_client; 0 false positives en 24hs. |
|
| Logging |
Logging estructurado: ELK Stack / Loki + Grafana y correlation IDs
JSON logs · Filebeat/Promtail · Elasticsearch/Loki · Kibana/Grafana Explore ·
request_id por request · log levels · retención y rotaciónDocker (contenedores generan logs) + Python para DevOps (structlog) + Observabilidad básica
|
Centralizar y estructurar los logs para diagnosticar fallos en producción en minutos sin acceso SSH al servidor — fundamento del debugging en entornos distribuidos. | Medio | Stack Loki + Promtail + Grafana que centraliza logs de 3 contenedores; app Python emite JSON con request_id; query LogQL que filtra todos los logs de un request por ID en < 5 segundos. |
PythonTodos los logs del mismo request con request_id correlacionable; sin print() en la app; nivel de log configurable por env var; query de diagnóstico documentada como runbook. |
|
| Gestión de Secretos |
HashiCorp Vault y AWS Secrets Manager: secretos dinámicos y rotación
Static vs dynamic secrets · AppRole auth · lease TTL · secret rotation · AWS Secrets Manager ·
vault agent · env vars vs ficheros vs API · aws-vaultAWS Core (integración nativa) + CI/CD (secretos en pipelines) + Ansible Vault
|
Gestionar secretos de forma centralizada con rotación automática — eliminar credenciales hardcodeadas y reducir el radio de explosión de una brecha a cero credenciales de larga vida. | Medio | Vault local en Docker con AppRole; app Python obtiene credenciales de DB dinámicas con TTL de 1 hora; pipeline CI/CD obtiene secretos de AWS Secrets Manager sin variables de entorno expuestas en logs. | Python0 secretos en código ni en logs; credenciales DB expiradas al cabo del TTL verificado; pipeline sin secretos visibles en outputs; script Python que audita variables de entorno buscando patrones de secretos. |
03
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Kubernetes Core |
Kubernetes: Deployments, Services, Ingress, ConfigMaps, RBAC y HPA
Rolling update · liveness/readiness/startup probes · resource requests/limits · ConfigMap vs Secret · Ingress con TLS · RBAC por namespace · HPA · PDB
Docker avanzado + AWS (EKS) + CI/CD (deployment step en pipeline)
|
Operar aplicaciones en Kubernetes con zero-downtime deployments, autoescalado real y acceso controlado por namespace — el estándar de orquestación de contenedores en 2026. | Difícil | Deploy de una app Python en EKS/kind: rolling update sin downtime con load test continuo; HPA escala 2→10 pods cuando CPU >70%; RBAC que impide a developers ver Secrets de otro namespace; PDB configurado. | Python0 requests fallidos durante rolling update; HPA activa en <60s; RBAC verificado con usuario de test sin permisos; script Python con kubernetes-client valida health del cluster post-deploy en CI. | |
| GitOps |
ArgoCD: declarative deployments, sync policies y app-of-apps
Pull vs push model · ApplicationSet ·
auto-sync · selfHeal · Helm + ArgoCD · multi-cluster · Image Updater · rollback automáticoKubernetes Core + Git (repositorio de manifests) + CI/CD (pipeline genera imagen)
|
Implementar GitOps como single source of truth para el estado del cluster — el modelo adoptado por Shopify, Atlassian y la mayoría de empresas CNCF-mature en 2026. | Difícil | App-of-apps en ArgoCD que gestiona 5 microservicios en 3 entornos (dev/staging/prod); deploy a prod vía PR merge; rollback automático si health check falla; drift detection activo. | Ningún cambio al cluster cluster sin commit en Git; rollback ejecutado en <2 min en escenario de prueba; PR a prod requiere aprobación + pipeline verde; drift detectado y reportado en Slack en <5 min. | |
| Terraform Avanzado |
Terraform módulos, workspaces, Terragrunt y remote state avanzado
Módulos reutilizables ·
for_each / count · locals · Terragrunt DRY · terraform_remote_state · workspaces · pre/post-hooks · tflint · checkovTerraform básico + AWS Core + Git (módulos en repos separados)
|
Escalar IaC a múltiples entornos y equipos sin duplicación ni state conflicts — la diferencia entre Terraform de un dev y Terraform listo para producción multi-equipo como en Stripe o MercadoLibre. | Difícil | Módulos internos para VPC, EKS y RDS reutilizados en 3 entornos con Terragrunt; pipeline CI que ejecuta terraform plan en PR y apply en merge; Checkov sin hallazgos CRITICAL en todos los módulos. |
PythonMismo módulo desplegado en dev/staging/prod sin copiar código; Checkov en CI bloquea PRs con hallazgos críticos; script Python valida que el estado desplegado coincide con las variables declaradas por entorno. | |
| CI/CD Avanzado |
Pipelines avanzados: caching, matrix builds, blue/green y canary deployments
Cache de dependencias y capas Docker · matrix strategy · deployment strategies · feature flags · pipeline as code · self-hosted runners · GitHub OIDC para AWS
GitHub Actions básico + Kubernetes (donde se despliega) + GitOps (ArgoCD como target)
|
Diseñar pipelines de entrega que minimicen el tiempo de feedback, soporten múltiples estrategias de despliegue y sean seguros sin depender de secretos de larga vida. | Difícil | Pipeline con GitHub OIDC (sin access keys en Secrets); matrix build para 3 arquitecturas; blue/green deployment con traffic shift del 10% automático; rollback en <30s si error rate >1%; tiempo total de pipeline <8 min. | 0 access keys de larga vida en CI/CD; pipeline <8 min con caché activo; blue/green sin downtime verificado con Locust; rollback en <30s documentado con runbook en el repo. | |
| Observabilidad Distribuida |
OpenTelemetry: trazas distribuidas, métricas y logs correlacionados
Spans · baggage · context propagation · OTel Collector · OTLP exporter · auto-instrumentation Python · Jaeger/Tempo · correlación trace-log-metric
Prometheus + Grafana (métricas base) + Logging (correlación) + Kubernetes (servicios a instrumentar)
|
Instrumentar un ecosistema de microservicios para que cualquier petición sea rastreable de extremo a extremo — estándar de observabilidad adoptado por Netflix, Uber y Stripe. | Difícil | 3 microservicios Python con OTel auto + manual instrumentation; traces completas en Jaeger/Tempo; correlación trace-log-metric por trace_id; diagnóstico de petición fallida en <2 min sin SSH. |
PythonDada petición fallida, identificar servicio y causa en <2 min; spans de queries SQL visibles; context propagado a través de HTTP y mensajería; dashboard con correlación en Grafana exportado como código. | |
| SLIs y SLOs |
Prometheus: SLI/SLO, error budgets y burn rate alerts
RED method · PromQL avanzado · recording rules · SLO burn rate alerts · Alertmanager routing · 0 false positives · Multi-window alerting · Thanos
Prometheus básico + OpenTelemetry (métricas ya exportadas) + Kubernetes
|
Definir y monitorear Service Level Objectives que reflejen la experiencia real del usuario, alertando antes de consumir el error budget — práctica estándar de SRE en Google, Netflix y Atlassian. | Difícil | Dashboard con métricas RED para cada microservicio; SLO de disponibilidad 99.9% con error budget de 43.8 min/mes; alert que dispara cuando el burn rate consume el 5% del budget en 1 hora; 0 false positives en 48hs. | PythonAlert dispara en escenario de prueba en <1 min; 0 false positives en 48hs; dashboards como código (Grafana Terraform provider); script Python genera reporte semanal del error budget consumido via Prometheus API. | |
| DevSecOps |
Seguridad en el pipeline: SAST, DAST, container scanning y SBOM
Semgrep · Trivy · Snyk · OWASP Dependency-Check ·
grype · SBOM con Syft · secrets scanning (gitleaks) · OPA/Conftest para políticas · supply chain securityCI/CD (donde se integra) + Docker (imágenes a escanear) + Kubernetes (políticas de admisión)
|
Integrar seguridad en el pipeline sin ralentizarlo — detectar vulnerabilidades antes de llegar a producción siguiendo el modelo "shift left" adoptado por Stripe y Shopify. | Difícil | Pipeline CI con Semgrep (SAST) + Trivy (container scan) + gitleaks (secrets) + SBOM generado con Syft; pipeline bloquea si CRITICAL encontrado; política OPA que rechaza pods sin resource limits en Kubernetes. | Python0 secretos commiteados jamás (gitleaks en pre-commit + CI); CRITICAL bloquea merge; SBOM generado y firmado en cada release; script Python parsea reporte Trivy y genera ticket Jira automático para CVEs críticos. | |
| Incident Management |
On-call, runbooks, postmortems blameless y gestión de incidentes
Incident severity levels · incident commander · PagerDuty/OpsGenie · runbooks ejecutables · blameless postmortem · 5 Whys · MTTR/MTBF · action items tracking
Observabilidad (alertas que generan incidentes) + SLOs (error budget como contexto)
|
Responder a incidentes de producción de forma coordinada y estructurada, documentar aprendizajes y mejorar el sistema sistemáticamente — cultura operacional de Google y Netflix. | Medio | Runbook ejecutable para los 5 incidentes más comunes del sistema; postmortem blameless de un incidente simulado con timeline, impact, root cause y 3 action items con dueño y fecha; reducción MTTR en ≥30%. | PythonRunbook ejecutable paso a paso sin conocimiento previo del sistema; postmortem sin lenguaje de culpa; action items en Jira con DRI asignado; script Python que parsea logs y genera timeline del incidente automáticamente. |
04
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Platform Engineering |
Internal Developer Platform (IDP): golden paths y self-service con Backstage
Backstage service catalog · software templates · paved roads · Tech Docs as code · TechInsights · plugins · developer portal · onboarding automation
Kubernetes + CI/CD + GitOps + Vault (componentes de la plataforma)
|
Reducir el tiempo de creación de un nuevo microservicio de días a minutos con seguridad, CI/CD y observabilidad incluidos — el modelo Platform Engineering adoptado por Shopify, Atlassian y Netflix. | Experto | Template en Backstage que crea: repo GitHub, pipeline CI/CD, namespace k8s con RBAC, secretos en Vault, dashboards en Grafana y alert rules en Alertmanager en <10 minutos; catálogo con 20+ servicios. | Tiempo de onboarding de nuevo servicio: de días a <10 min; desarrollador nuevo desplegando a staging en el primer día sin ayuda del platform team; adopción >80% del equipo de ingeniería. | |
| Kubernetes Avanzado |
Kubernetes: KEDA, Karpenter, Operators y multi-cluster
Event-driven autoscaling · CRDs · Operator pattern ·
controller-runtime · Karpenter node provisioning · Cluster API · multi-cluster federation · Velero backupsKubernetes Core + GitOps (operadores desplegados via ArgoCD) + Observabilidad
|
Diseñar la capa de cómputo para escalado basado en señales de negocio reales con aprovisionamiento de nodos just-in-time — modelo de Shopify y MercadoLibre para absorber picos de tráfico. | Experto | KEDA que escala workers de SQS de 1→50 pods según longitud de cola; Karpenter provisiona nodos Spot en <30s cuando no hay capacidad; Operator custom en Python gestiona el ciclo de vida de un recurso propio. | PythonScaling reactivo en <30s verificado bajo load; Karpenter reduce costo de EC2 en ≥30% vs node groups fijos; Operator custom en Python pasa tests e2e; velero backup/restore probado en <15 min. | |
| Service Mesh |
Istio: mTLS, traffic management, canary analysis y observabilidad de malla
Sidecar proxy · VirtualService · DestinationRule · mTLS automático · canary con Flagger · traffic splitting · circuit breaker · Kiali · Jaeger integración
Kubernetes avanzado + Observabilidad distribuida + DevSecOps (mTLS como zero trust)
|
Garantizar comunicación inter-servicio cifrada, observable y con control de tráfico granular sin modificar el código de las aplicaciones — estándar de zero trust networking en empresas CNCF-mature. | Experto | Istio en cluster de producción con mTLS automático; Flagger para canary progressivo al 5/25/100% con análisis de métricas; rollback automático si latencia P99 >200ms; visualización completa en Kiali. | Python100% tráfico inter-servicio con mTLS verificado en Kiali; canary rollback automático en escenario de prueba; script Python valida mTLS de todos los servicios en CI via Istio API; 0 tráfico en texto plano entre pods. | |
| SRE Prácticas |
SRE: error budgets, chaos engineering y toil elimination
Error budget policy · Chaos Monkey / LitmusChaos · GameDays · toil measurement · toil elimination roadmap · capacity planning · reliability reviews · SLO-driven decisions
SLIs/SLOs + Incident Management + Observabilidad avanzada + Kubernetes
|
Aplicar ingeniería de fiabilidad para que las decisiones sobre velocidad vs estabilidad sean objetivas y basadas en datos — el modelo SRE que Google documentó y Netflix, Atlassian y Stripe adoptaron. | Experto | Error budget policy documentada y aceptada por producto; GameDay con LitmusChaos que prueba 5 escenarios de fallo (pod kill, latency injection, network partition); toil eliminado en ≥30% con automatización medida. | PythonSistema responde correctamente a todos los escenarios de chaos; toil reducido documentado en horas/semana; script Python que calcula error budget consumido automáticamente y publica a Slack; feature freeze activado si budget >90% consumido. | |
| FinOps Básico |
FinOps: Kubecost, rightsizing, tagging strategy y cost attribution
Cost allocation por namespace/equipo · Kubecost · AWS Cost Explorer · rightsizing recommendations · spot instances · savings plans · tagging policy · cloud waste detection
Kubernetes (costo por namespace) + AWS Core (servicios a costear) + Python (automatización)
|
Dar visibilidad de costos cloud por equipo y servicio para tomar decisiones de arquitectura con plena consciencia financiera — práctica estándar en empresas cloud-native desde Netflix hasta MercadoLibre. | Difícil | Dashboard Kubecost con costo por namespace y por equipo; plan de rightsizing que reduce el bill en >20% sin degradar SLOs; tagging policy aplicada en 100% de recursos AWS; reporte semanal automático por squad. | PythonReducción >20% documentada con screenshots de Cost Explorer; script Python semanal detecta recursos sin tag y sin actividad en los últimos 30 días; cada squad recibe reporte de costo por email automáticamente. | |
| Seguridad Avanzada |
Zero Trust, OPA/Gatekeeper, audit logging y compliance as code
OPA/Rego policies · Gatekeeper admission controller · audit logging K8s + CloudTrail · Falco runtime security · RBAC mínimo · CIS Benchmarks · SOC2/PCI compliance automation
DevSecOps (shift left) + Kubernetes RBAC + Vault + Service Mesh (mTLS)
|
Implementar controles de seguridad automatizados que no bloqueen al equipo de desarrollo pero garanticen cumplimiento continuo — el modelo de seguridad de Stripe y Shopify. | Experto | Gatekeeper con 10 políticas OPA (sin privileged pods, sin latest tag, resource limits obligatorios, etc.); Falco que detecta y alerta execve en contenedores en producción; audit log de CloudTrail analizado con Python. | Python0 pods sin resource limits desplegados; Falco alerta en <30s ante ejecución anómala en contenedor; script Python analiza CloudTrail y detecta accesos de root o accesos cross-account no autorizados; CIS Benchmark score >85%. | |
| Infraestructura Multi-Env |
Terraform at scale: módulos internos, Atlantis y governance
Módulos privados en registry · Atlantis (plan en PR) · policy as code con Sentinel/Checkov · terraform-docs ·
tfsec · drift detection · blast radius controlTerraform avanzado + Git (workflow con Atlantis) + DevSecOps (policy enforcement)
|
Gobernar la infraestructura de múltiples equipos de forma centralizada sin crear cuellos de botella — el modelo que escala IaC de 2 a 20+ equipos sin perder control ni velocidad. | Experto | Registry de módulos internos con 5 módulos documentados y versionados; Atlantis que ejecuta plan en cada PR con comentario automático; política Sentinel que bloquea instancias sin tag team; drift detection en CI nightly. |
PythonNingún terraform apply manual en prod en los últimos 30 días; Sentinel bloquea recursos no etiquetados; script Python detecta drift entre state y recursos reales y notifica en Slack; módulos con terraform-docs auto-generados. |
|
| Liderazgo Técnico |
ADRs de infraestructura y code review de alto impacto en DevOps
Formato ADR (context/decision/consequences) · RFC process · revisión de IaC · feedback constructivo · decisiones reversibles vs irreversibles · runbooks como código revisado
Toda la experiencia Senior acumulada + Platform Engineering
|
Documentar decisiones de infraestructura con contexto y alternativas para evitar repetir debates y elevar el nivel de las revisiones de IaC y pipelines del equipo. | Medio | Escribir 3 ADRs para decisiones técnicas reales: elección de container registry, estrategia de secret management y diseño del IDP; facilitar el proceso de revisión hasta consenso con el equipo. | ADRs con alternativas consideradas, pros/cons y consecuencias; aprobados en ≤2 iteraciones; equipo puede referenciarlos sin explicación verbal; decisión adoptada sin necesidad de reuniones adicionales. |
05
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Platform as Product |
Platform Engineering como producto: DX metrics, NPS interno y adoption funnel
Developer Experience (SPACE framework) · platform NPS · adoption funnel · support burden · golden paths effectiveness · product roadmap de plataforma · OKRs de DX
IDP (Backstage) + DORA Metrics + toda la plataforma construida en niveles anteriores
|
Gestionar la plataforma interna como un producto con usuarios, métricas de adopción y roadmap — la diferencia entre una plataforma que se usa porque es obligatoria y una que se usa porque es mejor. | Experto | NPS interno de la plataforma medido trimestralmente; funnel de adopción: awareness → onboarding → daily use → advocacy; dashboard de DX metrics (time to first deploy, cognitive load score, support tickets/dev); roadmap con OKRs. | PythonNPS >40 en medición; tiempo de onboarding <1 día; support burden <1 ticket/dev/mes; script Python recolecta DX metrics de Backstage API + GitHub + Jira y genera reporte ejecutivo mensual automáticamente. | |
| Kubernetes Enterprise |
Kubernetes multi-cluster, Crossplane y platform abstraction
Crossplane (infra desde K8s) · Cluster API · multi-cluster federation (Flux/Argo) · vCluster · control plane customization · KubeVirt · edge deployments · multi-tenancy avanzado
Kubernetes avanzado + Terraform at scale + Platform as Product (cliente del IDP)
|
Diseñar la plataforma de cómputo que permite a los equipos provisionar infraestructura compleja vía Kubernetes sin conocer el proveedor de nube — la abstracción que define las plataformas líderes de la industria. | Experto | Crossplane que provisiona bases de datos RDS, buckets S3 y colas SQS vía CRDs K8s sin Terraform directo; multi-cluster con 3 clústeres (prod/staging/dev) gestionados desde un control plane; vCluster para entornos de preview por PR. | PythonDesarrollador provisiona DB completa via kubectl apply sin conocer AWS; vCluster creado en <5 min por PR automáticamente; script Python valida composición Crossplane en CI; migración de entorno en <30 min ante fallo de AZ. | |
| DORA Metrics |
DORA Metrics, Developer Experience (SPACE) y toil elimination a escala
Deployment Frequency · Lead Time for Changes · MTTR · Change Failure Rate · SPACE framework · toil measurement · feedback loops · dashboards desde GitHub + PagerDuty
CI/CD (datos de deployments) + Observabilidad (MTTR) + Platform Engineering
|
Cuantificar la capacidad de entrega del equipo con métricas objetivas para identificar bloqueos sistémicos y priorizar mejoras con impacto medible en el negocio. | Experto | Dashboard automatizado con DORA metrics desde GitHub + PagerDuty via Python; tendencias de 90 días; equipo clasificado en tier "High" DORA en ≥3 métricas; toil reducido en >30%; reporte ejecutivo mensual. | PythonScript Python ingesta datos de GitHub API y PagerDuty; dashboard actualizado automáticamente; cada métrica con objetivo SMART y dueño asignado; toil eliminado documentado con tiempo ahorrado por semana. | |
| Estrategia Técnica |
Tech debt de infraestructura: inventario, cuantificación y roadmap de amortización
Infra debt ledger · interest rate calculation · kill-by dates · migration sprints · deuda de plataforma vs configuración · priorización con DORA impact · legacy deprecation strategy
ADRs + DORA Metrics + Platform Engineering (iniciativas de migración)
|
Gestionar la deuda técnica de infraestructura como activo financiero: cuantificarla en días de ingeniería, priorizarla con el negocio y planificar su amortización con ROI demostrable. | Experto | Inventario de deuda de infraestructura valorado en "engineering days"; roadmap de 18 meses con ROI estimado por ítem; deuda priorizada por impacto en DORA; aprobado por CTO con tracking trimestral. | Deuda expresada en tiempo y costo; impacto de cada ítem en Deployment Frequency o MTTR documentado; roadmap aprobado en revisión con VPs; 3 ítems críticos (ej: AMIs obsoletas, versiones de K8s EOL) amortizados en el primer trimestre. | |
| Estrategia Técnica |
Engineering roadmaps: OKR alignment y DevOps transformation a escala
Technical strategy document · DevOps maturity model · build vs buy framework · RFC process · stakeholder alignment · capacity planning del platform team · hiring plan técnico
Tech Debt + DORA Metrics + Platform as Product (iniciativas a planificar)
|
Traducir la estrategia de negocio en inversiones de plataforma concretas con impacto medible y alineación ejecutiva — la diferencia entre un Staff que ejecuta pipelines y uno que dirige la evolución técnica de la empresa. | Experto | Documento de estrategia técnica de 18 meses: 3 iniciativas con OKRs (Platform v2, observabilidad AI-powered, developer experience), análisis de capacidad del platform team y plan de riesgos con mitigaciones. | Aprobado en revisión con VPs; tracking trimestral de progreso con datos objetivos publicados al equipo; cada iniciativa con impacto medible en DORA o en métricas de negocio; roadmap comunicado y comprendido por todo el equipo de ingeniería. | |
| Multi-Cloud |
Cloud-agnostic architecture: Crossplane/Terraform módulos y FinOps maduro
Provider-agnostic abstractions · CNCF landscape · portabilidad de workloads · cost attribution por squad · rightsizing automatizado · FinOps maturity model · cost-aware architecture decisions
Kubernetes multi-cluster + Terraform at scale + FinOps básico
|
Diseñar infraestructura sin vendor lock-in con visibilidad de costos por producto y equipo para tomar decisiones de arquitectura con plena consciencia financiera. | Experto | Stack desplegable en AWS y GCP con el mismo Crossplane/Terraform sin modificar configuración de app; dashboard cost attribution por namespace y squad con Kubecost; rightsizing automatizado reduce bill en >20% sin degradar SLOs. | PythonDeploy idéntico en ambas nubes en <30 min; reducción >20% documentada con datos de Cost Explorer; script Python semanal detecta recursos huérfanos y los reporta a los dueños; cada squad recibe alerta si su costo sube >15% semana a semana. | |
| Open Source & Comunidad |
Open source contributions, thought leadership y mentoring en DevOps
Contribuciones a proyectos CNCF (ArgoCD, Flux, Crossplane) · KubeCon talks · DevOpsDays · internal tech blog · mentoring program · RFCs públicas · CNCF Landscape contributions
Todo el nivel Staff — impacto acumulado que se amplifica externamente
|
Amplificar el impacto más allá de la organización construyendo reputación en la comunidad DevOps/CNCF que atrae talento, genera credibilidad y retroalimenta con inteligencia del ecosistema. | Experto | Contribución aceptada a proyecto CNCF con >1k stars; charla en KubeCon, DevOpsDays o conferencia regional; post técnico con >1000 lecturas; 2 ingenieros junior mentorados al nivel SSR en <12 meses. | PythonPR mergeada en repo CNCF con >1k stars; charla aceptada por CFP con revisión ciega; mentorado promovido o alcanza objetivo técnico acordado; script Python del talk o contribución publicado y con ≥50 stars en GitHub propio. |