01
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Linux Core | Filesystem, permisos y procesos FHS, chmod/chown, inodos, signals, /proc, systemd units |
Navegar, administrar y depurar un sistema Linux desde cero entendiendo qué hace el kernel por debajo. | Fácil | Configurar un servicio systemd que arranque automáticamente un script de backup al inicio del sistema con logs en journald. | Servicio activo tras reboot; permisos mínimos (no root); logs visibles con journalctl -u. |
|
| Linux Core | Gestión de paquetes y usuarios apt/yum/dnf, sudoers, /etc/passwd, grupos, SSH keys, PAM |
Administrar usuarios, paquetes y acceso SSH de forma segura y reproducible siguiendo el principio de mínimo privilegio. | Fácil | Provisionar un servidor: crear usuarios con permisos mínimos, deshabilitar login root por SSH, instalar stack LAMP con apt. | Login root por SSH deshabilitado; autenticación sólo con clave pública; servidor web responde en puerto 80. | |
| Shell Scripting | Bash: variables, bucles, condicionales y funciones $?, exit codes, pipes, redirección, expansión de parámetros, trap |
Automatizar tareas operativas repetitivas con scripts robustos que manejen errores y sean mantenibles por el equipo. | Fácil | Script de health-check que verifique servicios, uso de disco y CPU; envíe alerta por email si supera umbrales; use trap para cleanup. |
0 errores en ShellCheck; sale con código ≠ 0 cuando detecta problema; idempotente al ejecutarlo múltiples veces. | |
| Redes | TCP/IP, DNS, HTTP y modelo OSI Subnetting, CIDR, resolución DNS, puertos, handshake TCP, HTTP codes |
Diagnosticar problemas de conectividad y entender cómo fluye el tráfico entre servicios en una red. | Fácil | Diagnosticar 5 escenarios de fallo de red usando dig, curl -v, netstat y tcpdump; documentar causa raíz de cada uno. |
Identifica correctamente si el fallo es DNS, TCP o HTTP en cada escenario sin pistas externas. | |
| Git | Git workflow: branches, commits semánticos, merge vs rebase Conventional Commits, feature branches, resolución de conflictos |
Colaborar en equipos mediante un historial de cambios limpio, rastreable y reversible en repositorios de infraestructura. | Fácil | Mantener un repositorio de scripts de infraestructura con +20 commits semánticos, 3 feature branches y un conflicto resuelto documentado. | Historial lineal; commits atómicos tipo feat(monitoring): add disk usage alert; sin binarios en el repo. |
|
| Python / Automation | Python para operaciones: boto3, requests, argparse Scripts CLI, manejo de archivos, llamadas a APIs, manejo de errores |
Escribir herramientas de automatización en Python que interactúen con APIs cloud y sean más mantenibles que scripts Bash complejos. | Fácil | CLI con argparse que liste instancias EC2, filtre por tag y exporte reporte en JSON/CSV usando boto3 con manejo de errores explícito. | Sin credenciales hardcodeadas; usa variables de entorno o IAM role; 0 errores con --help; maneja paginated responses. | |
| Docker Basics | Contenedores: imágenes, Dockerfile, volúmenes, redes docker build/run/exec, layers, bind mounts, bridge network, registry push |
Entender el modelo de aislamiento de contenedores y crear imágenes reproducibles para cualquier aplicación. | Fácil | Contenerizar una app web existente: imagen < 200MB, health check configurado, datos persistidos en volumen nombrado. | Contenedor reinicia solo ante fallo del proceso principal; datos del volumen sobreviven al docker rm. |
|
| Docker Basics | Docker Compose: servicios, dependencias, variables de entorno depends_on, healthcheck, .env files, override files |
Levantar entornos de desarrollo multi-servicio reproducibles en un solo comando para onboarding rápido del equipo. | Fácil | Compose con app web + PostgreSQL + Redis: healthchecks en todos los servicios, setup < 2 minutos desde cero en máquina nueva. | App sólo arranca cuando DB pasa healthcheck; 0 credenciales en el docker-compose.yml; usa .env. |
|
| Cloud Fundamentos | AWS Core: EC2, S3, IAM, VPC básica Security groups, subredes públicas/privadas, roles IAM, S3 bucket policies |
Desplegar y conectar recursos cloud básicos aplicando el principio de least privilege desde el primer recurso creado. | Medio | Desplegar una app web en EC2 con S3 para assets estáticos; acceso a S3 via IAM role (sin access keys); VPC con subnets pública y privada. | Sin credenciales en el servidor; bucket S3 sin acceso público innecesario; security group sólo abre puertos requeridos. | |
| Observabilidad Básica | Logging: niveles, formatos estructurados, centralización stdout vs archivo, JSON logs, syslog, rsyslog, CloudWatch Logs básico |
Producir y centralizar logs que permitan diagnosticar fallos sin acceso directo al servidor de producción. | Fácil | Configurar recolección de logs de una app Docker hacia CloudWatch; crear filtro de métricas para contar errores 5xx por minuto. | Logs en JSON con timestamp, level y message; métrica de error visible en CloudWatch sin acceder al servidor. |
02
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| CI/CD | GitHub Actions: workflows, jobs, steps, secrets, artifacts on push/PR, matrix strategy, reusable workflows, environments |
Automatizar el ciclo completo de build, test y deploy para eliminar deploys manuales y detectar regresiones automáticamente. | Medio | Pipeline completo: lint → test → build Docker image → push al registry → deploy a staging automáticamente en cada PR aprobado. | PR sin tests verdes bloquea el merge; imagen construida sólo si todos los checks pasan; secrets nunca en logs. | |
| CI/CD | GitLab CI/CD: stages, pipelines, runners, caching YAML structure, artifacts entre stages, Docker-in-Docker, caching de dependencias |
Dominar un segundo proveedor de CI/CD relevante en la industria para ser autónomo en entornos GitLab-based. | Medio | Pipeline multi-stage en GitLab con caché de dependencias que reduzca el tiempo de build en > 40% respecto al primer intento. | Cache hit en builds sucesivos; artefactos disponibles entre stages; runner configurado con permisos mínimos. | |
| Terraform | Terraform básico: providers, resources, variables, state terraform plan/apply/destroy, remote state en S3, data sources, outputs |
Provisionar y destruir infraestructura de forma declarativa y reproducible eliminando la configuración manual de consola. | Medio | Infraestructura completa en AWS: VPC, subnets, EC2, RDS y S3 en Terraform; remote state en S3 con locking en DynamoDB. | terraform destroy + terraform apply recrea el stack idéntico en < 10 minutos; 0 recursos creados manualmente. |
|
| Terraform | Terraform módulos reutilizables y workspaces module sources, input/output variables, workspace por entorno, terragrunt básico |
Estructurar Terraform para entornos múltiples (dev/staging/prod) sin duplicar código de infraestructura. | Medio | Módulo reutilizable de EC2 + ALB usado en 3 entornos distintos con variables; sin copy-paste de bloques entre entornos. | Un cambio en el módulo se propaga a todos los entornos con sólo terraform apply; cada entorno con su propio state. |
|
| Kubernetes | Pods, Deployments, Services, ConfigMaps, Secrets kubectl, readiness/liveness probes, resource limits, rolling updates |
Desplegar y operar aplicaciones en Kubernetes con zero-downtime y configuración externalizada del código. | Medio | Desplegar una API en minikube: rolling update sin downtime, readiness probe que retiene tráfico hasta que la app esté lista. | 0 requests fallidos durante rolling update; Secrets de DB nunca en imagen ni ConfigMap; resource limits definidos. | |
| Kubernetes | Ingress, Namespaces, RBAC y PersistentVolumes IngressController (nginx/traefik), RBAC roles, PVC, StorageClass |
Organizar un clúster multi-tenant con enrutamiento HTTP centralizado, aislamiento de equipos y almacenamiento persistente. | Medio | Clúster con 2 namespaces (backend/frontend), RBAC por equipo, Ingress con TLS y PVC para almacenamiento de datos de la app. | Usuario del equipo backend sólo puede ver recursos de su namespace; certificado TLS válido; datos persisten ante pod deletion. | |
| Ansible | Playbooks, inventory, roles y templates Jinja2 idempotencia, handlers, vault para secrets, dynamic inventory |
Configurar servidores de forma idempotente y auditable reemplazando procedimientos manuales documentados en wikis. | Medio | Playbook que provisione un servidor web con Nginx, configura TLS y despliega una app; idempotente — segunda ejecución sin cambios. | Segunda ejecución retorna "changed=0"; secrets en ansible-vault; playbook pasa ansible-lint sin errores. |
|
| Docker Avanzado | Multi-stage builds, imagen mínima y seguridad Distroless/Alpine, non-root user, .dockerignore, layer caching, image scan |
Crear imágenes de producción seguras, livianas y optimizadas para el registry cumpliendo estándares de hardening de contenedores. | Medio | Imagen multi-stage para app Python/Node: < 80MB, usuario no-root, scan con Trivy sin CVEs críticas/altas sin mitigación. | Imagen < 80MB; 0 vulnerabilidades críticas según Trivy; proceso no corre como root dentro del contenedor. | |
| Monitoreo | Prometheus + Grafana: métricas, alertas, dashboards PromQL básico, exporters (node, cadvisor), Alertmanager, dashboards |
Instrumentar la infraestructura para tener visibilidad de CPU, memoria, disco y latencia de servicios en tiempo real. | Medio | Stack completo: Prometheus scrape de 3 servicios + node_exporter, Grafana con dashboard RED (Rate, Errors, Duration), alerta a Slack. | Alert llega a Slack en < 1 min cuando un servicio cae; dashboard cargable por cualquier miembro del equipo vía URL. | |
| AWS Intermedio | ECS/Fargate, ALB, RDS, ElastiCache, SQS Task definitions, target groups, parameter store, VPC privada, auto scaling |
Desplegar una arquitectura de microservicios en AWS sin gestionar servidores, con escalado automático y alta disponibilidad. | Medio | Stack completo en Fargate: 2 servicios con ALB, RDS en subnet privada, ElastiCache y cola SQS; todo definido en Terraform. | RDS inaccesible desde internet; ALB distribuye tráfico entre tasks; auto scaling activa cuando CPU > 70%. |
03
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| GitOps | ArgoCD: aplicaciones, sync policies, App of Apps ApplicationSet, drift detection, progressive delivery, notifications |
Gestionar el estado de un clúster Kubernetes declarativamente desde Git, eliminando deploys manuales y drift de configuración. | Difícil | GitOps completo para 3 entornos (dev/staging/prod): cualquier cambio mergeado a main se despliega automáticamente sin kubectl apply manual. |
Drift detectado y corregido automáticamente en < 5min; rollback vía git revert sin acceso a kubectl en prod. |
|
| GitOps | Helm: charts, values, templates, repositorios hooks, subchart dependencies, Helmfile para multi-chart, chart testing |
Empaquetar y versionar aplicaciones Kubernetes de forma reutilizable para diferentes entornos y equipos. | Difícil | Chart Helm propio para una API con valores por entorno, hooks de migración de DB pre-upgrade y test de integración con helm test. |
Chart pasa helm lint y ct lint; upgrade sin downtime con hook de migración; rollback automatizable. |
|
| Kubernetes Avanzado | HPA, VPA, KEDA y resource management Metrics server, custom metrics, pod disruption budgets, priority classes |
Escalar cargas de trabajo automáticamente basándose en métricas de negocio reales, no solo en CPU del pod. | Difícil | KEDA que escale un worker de procesamiento de cola SQS de 1 a 50 pods según la longitud de la cola; PodDisruptionBudget que garantice 2 réplicas mínimo. | Scaling en < 30s ante pico de mensajes; 0 réplicas cuando la cola está vacía; PDB impide evicción completa. | |
| Kubernetes Avanzado | Network Policies, Ingress avanzado y TLS automation Calico/Cilium, cert-manager, Let's Encrypt, mTLS con annotations |
Implementar segmentación de red zero-trust en el clúster y gestionar certificados TLS de forma completamente automatizada. | Difícil | Network Policies que aíslan namespaces; cert-manager con Let's Encrypt que renueva certificados automáticamente; certificado rotado sin downtime. | Pod en namespace A no puede alcanzar pods en namespace B sin política explícita; certificado renovado 30 días antes de expirar. | |
| Observabilidad | OpenTelemetry: traces, métricas y logs correlacionados OTel Collector, auto-instrumentation, OTLP exporter, Jaeger, context propagation |
Instrumentar un ecosistema de microservicios para que cualquier petición sea rastreable de extremo a extremo en segundos. | Difícil | 3 microservicios con OTel auto + manual instrumentation; traces completas en Jaeger; correlación trace-log-metric por trace_id. |
Dada una petición fallida, identificar servicio y causa en < 2 minutos usando sólo la UI de observabilidad. | |
| Observabilidad | Loki + Promtail: logging stack cloud-native LogQL, label indexing, multiline parsing, alerting con Grafana |
Centralizar logs de todo el clúster Kubernetes con búsquedas eficientes en tiempo real sin la complejidad operativa de Elasticsearch. | Medio | Loki + Promtail desplegados en k8s vía Helm; dashboard Grafana con logs y métricas correlacionadas; alerta ante tasa de errores > 5%. | Búsqueda LogQL retorna resultados en < 3s sobre 7 días de logs; alert dispara en < 1min ante pico de errores. | |
| DevSecOps | Seguridad en CI/CD: SAST, DAST, container scanning Trivy, Semgrep, OWASP ZAP, Snyk, secret scanning, branch protection rules |
Integrar seguridad en el pipeline de CI para que vulnerabilidades críticas nunca lleguen a producción. | Difícil | Pipeline con 4 gates de seguridad: secret scan, SAST con Semgrep, image scan con Trivy, DAST con OWASP ZAP; merge bloqueado ante hallazgo crítico. | 0 secrets en historial de commits; build falla ante CVE crítica en imagen; reporte de seguridad publicado en cada PR. | |
| DevSecOps | HashiCorp Vault: secrets management dinámico Dynamic secrets, Vault Agent, Kubernetes auth, PKI backend, lease renewal |
Eliminar secrets estáticos de la infraestructura usando secrets dinámicos de vida corta que se generan y revocan automáticamente. | Difícil | Pods que obtienen credenciales de DB de Vault via Kubernetes auth; credenciales con TTL 1h que se renuevan automáticamente; 0 secrets en YAML de k8s. | Credencial revocada inmediatamente al eliminar el pod; 0 secrets de larga duración en etcd del clúster. | |
| IaC Avanzado | Terraform avanzado: testing, policy-as-code con OPA Terratest, Checkov, OPA/Conftest, Sentinel, pre-commit hooks para IaC |
Tratar la infraestructura como código de producción: con tests automatizados, revisión de pares y políticas que previenen misconfiguraciones. | Difícil | Módulo Terraform con tests de integración en Terratest y políticas OPA que bloqueen buckets S3 públicos o security groups con 0.0.0.0/0. | Pipeline falla si Checkov detecta misconfiguration crítica; tests de Terratest validan la infraestructura real desplegada. | |
| SRE Fundamentos | SLI/SLO/SLA, error budgets y runbooks Definición de SLIs, SLO burn rate alerts, postmortems blameless, on-call rotation |
Cuantificar la confiabilidad de los servicios con métricas objetivas y establecer prácticas de respuesta a incidentes sin cultura de culpa. | Difícil | Definir SLOs para 2 servicios críticos; dashboards de error budget en Grafana; runbook de incidente documentado; postmortem de un incidente real. | SLO con target medible y ventana de tiempo; burn rate alert dispara antes de consumir el 5% del budget en 1h. | |
| Cloud Avanzado | AWS EKS: cluster management, node groups, add-ons EKS Managed Nodes, Fargate profiles, VPC CNI, AWS Load Balancer Controller |
Operar Kubernetes en AWS de forma productiva usando los servicios managed que reducen la carga operativa del control plane. | Difícil | Clúster EKS con Terraform: node groups en subnets privadas, ALB controller para Ingress, IRSA para pods que acceden a S3/SQS sin EC2 instance role. | Pods usan IRSA (sin credenciales de instancia); nodos en subnets privadas; upgrades del control plane sin downtime en la app. |
04
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| Platform Engineering | Internal Developer Platform (IDP): diseño y adopción Golden paths, Backstage, self-service provisioning, paved roads, developer portals |
Crear abstracciones que permitan a los equipos de producto provisionar servicios con seguridad, observabilidad y CI/CD nativo desde el minuto uno. | Experto | Template en Backstage que provisiona: repo GitHub, pipeline CI/CD, monitoring, secrets en Vault, Namespace k8s y AlertManager rule en < 5 minutos. | Tiempo de creación de nuevo servicio: de días a < 10 minutos; adopción > 80% del engineering team sin soporte del platform team. | |
| Platform Engineering | Service Mesh: Istio o Linkerd — tráfico, observabilidad, mTLS Traffic management, canary deployments, circuit breaking, mutual TLS, Kiali |
Implementar comunicación inter-servicio segura, observable y resiliente sin modificar el código de las aplicaciones. | Experto | Istio con mTLS automático entre todos los servicios; canary deployment al 10% con auto-rollback si error rate > 1%; circuit breaker por servicio. | 100% tráfico inter-servicio con mTLS verificado en Kiali; canary rollback automático ante degradación; 0 cambios en código de apps. | |
| Resiliencia | Chaos Engineering: hipótesis, experimentos, steady state Chaos Mesh, LitmusChaos, Netflix Simian Army principios, GameDays |
Validar proactivamente la resiliencia del sistema inyectando fallos controlados antes de que ocurran en producción de forma inesperada. | Experto | GameDay: inyectar latencia de 500ms en el servicio de pagos y validar que el sistema degrada graciosamente sin cascada al servicio de catálogo. | Sistema principal mantiene SLO durante el experimento; fallo no se propaga a servicios no dependientes; resultado documentado como hipótesis validada. | |
| Resiliencia | DR/BCP: estrategias de backup, RTO/RPO, multi-región Cross-region replication, Velero para k8s backup, RDS snapshots, failover testing |
Diseñar y validar planes de recuperación ante desastres que cumplan los RTO/RPO comprometidos con el negocio. | Experto | Plan DR para un sistema crítico: backup de Kubernetes con Velero, RDS cross-region replica, failover simulado y tiempo real de recovery medido. | RTO medido < objetivo declarado; failover ejecutado y documentado; backup restaurado satisfactoriamente en entorno de test aislado. | |
| Observabilidad Avanzada | Prometheus avanzado: PromQL, recording rules, federation SLO burn rate alerts, cardinality control, Thanos/Mimir para long-term storage |
Diseñar una estrategia de métricas a escala que soporte alta cardinalidad, retención a largo plazo y multi-clúster sin degradar el rendimiento. | Experto | Thanos con retención de 1 año en S3; recording rules que precomputan SLO burn rates; dashboard mostrando tendencias de 90 días sin degradación de query. | Query de 90 días retorna en < 10s; cardinality < 10M series activas; alert dispara exactamente cuando burn rate > 5% del budget en 1h. | |
| Seguridad Avanzada | Kubernetes Security: PSA, RBAC granular, Falco runtime Pod Security Admission, admission webhooks, OPA/Gatekeeper, Falco alerting |
Implementar defensa en profundidad en el clúster para detectar y prevenir comportamientos maliciosos tanto a nivel de configuración como en runtime. | Experto | Clúster con PSA en modo Restricted, OPA Gatekeeper bloqueando imágenes sin tag digest, Falco alertando ante exec en contenedores de producción. |
Pod privilegiado rechazado en < 500ms por admission webhook; alert de Falco en < 30s ante proceso inesperado en pod de producción. | |
| Seguridad Avanzada | Supply Chain Security: SLSA, SBOM, cosign, sigstore Artifact signing, GitHub OIDC, OSSF Scorecard, dependency scanning automatizado |
Garantizar la integridad de la cadena de suministro de software desde el commit hasta el artefacto desplegado en producción. | Experto | Pipeline con SLSA Level 2: artefactos firmados con cosign via GitHub OIDC, SBOM publicado en cada release, OSSF Scorecard > 7/10. | Imagen en producción sólo si firma verificable con cosign; OSSF Scorecard público y > 7/10 en el repo principal. | |
| Multi-Cloud | Cloud-agnostic architecture: Terraform modules, Crossplane Provider-agnostic modules, Crossplane CRDs, workload portabilidad, CNCF landscape |
Diseñar la infraestructura para evitar vendor lock-in y mantener la flexibilidad de migrar cargas de trabajo según condiciones de negocio. | Experto | Módulos Terraform abstraídos que despliegan el mismo stack en AWS y GCP; Crossplane gestionando bases de datos cloud-agnostic vía CRDs de Kubernetes. | Deploy idéntico en ambas nubes en < 30 minutos; 0 recursos cloud-specific en módulos compartidos; apps sin código proveedor-specific. | |
| FinOps | Cost attribution, rightsizing y optimization Cost tagging, budget alerts, spot/preemptible strategy, Kubecost, savings plans |
Optimizar el gasto cloud con visibilidad por producto y equipo para tomar decisiones de arquitectura con consciencia de costo real. | Difícil | Dashboard de cost attribution por namespace/equipo con Kubecost; rightsizing plan que reduzca el bill en > 20% sin degradar SLOs; spot nodes para workers no-críticos. | Reducción > 20% en cloud spend documentada; cada squad con visibilidad de su costo semanal; 0 recursos huérfanos detectados mensualmente. | |
| Liderazgo Técnico | Architectural Decision Records (ADR) y RFC process Formato ADR (context/decision/consequences), revisión por pares, decisiones reversibles vs irreversibles |
Documentar decisiones de infraestructura con contexto y consecuencias para evitar repetir debates y facilitar el onboarding del equipo. | Medio | Escribir 3 ADRs para decisiones técnicas reales: elección de service mesh, estrategia de secretos y selección de GitOps tooling; revisar con el equipo hasta consenso. | ADRs con alternativas consideradas, pros/cons explícitos y consecuencias; aprobados en < 2 iteraciones de review. | |
| DORA Metrics | Deployment Frequency, Lead Time, MTTR, CFR Measurement instrumentation, GitHub + PagerDuty data, benchmark vs industria, actionable insights |
Cuantificar la capacidad de entrega del equipo con métricas objetivas para identificar bloqueos sistémicos y priorizar mejoras de proceso. | Difícil | Dashboard automatizado con DORA metrics desde GitHub + PagerDuty; tendencias de 90 días; identificar y atacar el cuello de botella más grande con plan de acción. | Equipo clasificado en tier "High" DORA en al menos 3 de las 4 métricas; cada métrica con objetivo SMART y dueño asignado. |
05
| Área | Tema Específico | Objetivo | Dif. | Recursos | Proyecto / Validación | Criterio de Éxito |
|---|---|---|---|---|---|---|
| AIOps | AI-assisted incident response y anomaly detection Datadog AI, PagerDuty AIOps, Prometheus anomaly detection, LLM para runbooks |
Reducir el MTTR integrando IA en el ciclo de detección-diagnóstico-resolución para que los ingenieros de guardia reciban contexto inmediato. | Experto | Pipeline de incident response que al activarse un alert: agrupa métricas relacionadas, genera un resumen con LLM, sugiere runbook y crea el ticket automáticamente. | MTTR reducido en > 30% medido en 90 días; 0 false positive escalations; runbook sugerido correcto en > 80% de incidentes. | |
| AIOps | MLOps infrastructure: serving, feature stores, drift detection MLflow, Ray Serve, Feast, Evidently, model registry, A/B model testing |
Diseñar la infraestructura MLOps que permita a los data scientists desplegar y monitorear modelos en producción de forma autónoma. | Experto | Plataforma MLOps: model registry en MLflow, serving en Ray Serve con A/B testing, monitoreo de data drift con Evidently; deploy de modelo en < 30min via PR. | Alert automático ante data drift > threshold; rollback de modelo via GitOps en < 5 minutos; DS puede desplegar sin ayuda del platform team. | |
| Platform Strategy | Platform as a Product: adoption metrics, developer journey SPACE framework, NPS de plataforma, feature roadmap con developers como customers |
Gestionar la plataforma interna como un producto con usuarios reales, feedback continuo y roadmap priorizado por impacto en developer experience. | Experto | Survey trimestral de DevEx con SPACE framework; roadmap de plataforma priorizado por impacto medido; NPS de la plataforma > 40 tras 2 ciclos de mejora. | NPS > 40; tiempo de onboarding de nuevo servicio < 10 minutos; adopción de golden paths > 85% de los equipos de producto. | |
| Platform Strategy | Kubernetes avanzado: Cluster API, multi-cluster federation Cluster API, Fleet (Rancher), Karmada, global load balancing, cluster lifecycle |
Operar decenas de clústeres Kubernetes de forma declarativa con políticas centralizadas y workload placement automático según disponibilidad y costo. | Experto | 5 clústeres EKS gestionados via Cluster API; políticas de placement que migran workloads automáticamente ante fallo de nodo o spike de costo de spot. | Failover automático entre clústeres en < 60s; nuevo clúster provisionado via Cluster API en < 20 minutos; 0 clústeres creados manualmente. | |
| Engineering Strategy | Tech Debt de infraestructura: cuantificación y roadmap Debt ledger de infra, kill-by dates, migración de herramientas legacy, refactor sprints |
Gestionar la deuda técnica de infraestructura como activo financiero: cuantificarla, priorizarla con el negocio y planificar su amortización. | Experto | Inventario de deuda de infra valorado en "engineering days"; roadmap de 18 meses con ROI estimado por ítem; aprobado por CTO y publicado al equipo. | Deuda priorizada por impacto en DORA y SLOs; cada ítem con fecha de resolución y responsable; tracking trimestral visible. | |
| Engineering Strategy | Engineering roadmaps: OKR alignment, capacity planning Technical strategy document, build vs buy framework, RFC process, stakeholder alignment |
Traducir la estrategia de negocio en inversiones técnicas de infraestructura concretas con impacto medible y alineación ejecutiva. | Experto | Documento de estrategia técnica de 18 meses: 3 iniciativas con OKRs (observabilidad, seguridad, developer experience), análisis de capacidad y plan de riesgos. | Aprobado en revisión con VPs; tracking trimestral de progreso con datos objetivos; cada iniciativa con impacto medible en DORA o SLOs. | |
| FinOps Estratégico | FinOps culture: unit economics, cost-per-request, budgeting Cost per transaction, RI/savings plans strategy, chargeback model, FinOps maturity model |
Empoderar a cada equipo de producto con visibilidad de sus costos cloud para que tomen decisiones de arquitectura con plena consciencia financiera. | Experto | Modelo de unit economics por servicio (costo por request, costo por usuario activo); chargeback automatizado a cada squad; reducción de 25% del gasto en 6 meses. | Cada squad conoce su costo semanal; anomalía de costo > 20% genera alert automático al responsable; forecast accuracy > 90% mensual. | |
| Seguridad Governance | Zero Trust Architecture: mTLS end-to-end, SPIFFE/SPIRE Workload identity, SVID, service-to-service auth, secrets rotation sin downtime |
Implementar identidad criptográfica para cada workload eliminando secrets estáticos de larga duración y habilitando comunicación zero-trust end-to-end. | Experto | SPIRE desplegado en k8s; cada servicio con SVID que se rota cada hora; mTLS entre todos los microservicios usando identidad SPIFFE sin Vault Kubernetes auth. | 0 secrets estáticos de larga duración en producción; SVID rotado automáticamente sin downtime; nueva identidad de servicio en < 5 minutos. | |
| Developer Experience | DevEx: local development parity, Telepresence, Tilt Dev loop en segundos, hot reload en k8s, local-remote hybrid, preview environments |
Reducir el inner loop de desarrollo de minutos a segundos para que los ingenieros experimenten en un entorno que replica producción sin fricción. | Experto | Setup de desarrollo con Tilt: cambio en código → deploy en k8s local en < 10s; Telepresence para intercept de tráfico real de staging hacia máquina local. | Inner loop < 10s medido; developer puede depurar un servicio de staging desde su IDE local sin VPN especial ni conocimiento profundo de k8s. | |
| Open Source & Community | Open Source contributions y thought leadership CNCF projects contributions, conference talks, internal tech blog, mentoring programs |
Amplificar el impacto técnico más allá de la organización construyendo reputación en la comunidad DevOps que atrae talento y genera credibilidad. | Experto | Contribución aceptada a proyecto CNCF; charla en KubeCon o conferencia regional; post técnico con > 500 lecturas; programa de mentoring con 2 ingenieros junior. | Contribución mergeada en repo con > 1k stars; charla aceptada por comité de selección; mentorado promovido o con objetivo técnico alcanzado. | |
| Incident Culture | Reliability culture: blameless postmortems, chaos GameDays, SRE teams Postmortem templates, GameDay facilitation, SLO review cadence, toil elimination strategy |
Establecer una cultura de ingeniería de confiabilidad donde los incidentes sean oportunidades de aprendizaje y el toil sea medido y atacado sistemáticamente. | Experto | Proceso de postmortem blameless institucionalizado; GameDay trimestral con 3 equipos; toil medido y reducido en > 20% en 6 meses; error budgets como decisión de negocio. | 100% de incidentes P1 con postmortem publicado en < 5 días; acción de cada postmortem trazable en backlog; equipo puede facilitar GameDay sin ayuda del Staff. |