Problema

Muchos ingenieros con varios años de experiencia en SRE terminan en equipos de soporte L1/L2 después de una reestructuración o un contrato “seguro”. El día a día se reduce a tickets, runbooks y escalados, sin oportunidad de diseñar pipelines, escribir código de automatización o definir SLO/SLI. Con el tiempo el currículum muestra una brecha entre la experiencia real y la que el mercado espera para roles senior (L4/L5, Platform Engineer). El desafío es doble: seguir adquiriendo profundidad técnica mientras se mantiene la empleabilidad y se prepara una narrativa que no penalice el periodo de soporte.

Causa

  1. Reasignación de talento sin alineación de perfil – Las organizaciones a menudo desplazan a SREs a equipos de soporte porque ya poseen conocimiento del dominio y pueden reducir tiempo de onboarding.
  2. Falta de proyectos “propios” – Cuando el contrato no incluye ownership, el ingeniero pierde la práctica de arquitectura y de iteración de código.
  3. Visibilidad limitada – Los logros en tickets rara vez aparecen en métricas de negocio, lo que dificulta cuantificar impacto en entrevistas.
  4. Presión de estabilidad financiera – Aceptar un salario mayor en un rol de soporte es lógico a corto plazo, pero genera una “depresión de habilidades” a medio plazo.

Solución

1. Construir un laboratorio de observabilidad continuo

  • Objetivo: Replicar el stack de producción (Prometheus/Grafana, Loki, OpenTelemetry) en una VM o en un clúster local (k3s).
  • Acciones:
    • Despliega un micro‑servicio de prueba (por ejemplo, una API Go simple).
    • Instrumenta con OpenTelemetry SDK y exporta a Prometheus.
    • Configura alertas de SLO basadas en latencia y error rate.
    • Automatiza despliegues con Terraform y Helm para practicar IaC y GitOps.

Este entorno permite experimentar con métricas, crear dashboards y validar cambios sin depender del trabajo diario.

2. Practicar chaos engineering en entornos seguros

  • Objetivo: Ganar confianza en la resiliencia del sistema y demostrar capacidad de mitigación.
  • Acciones:
    • Usa kubectl y chaos-mesh o litmus para inyectar fallos (pod kill, network latency).
    • Documenta el tiempo de recuperación y los ajustes de auto‑escalado que aplicaste.
    • Convierte cada experimento en un caso de estudio para entrevistas.

3. Plan de capacidad y planificación de costos

  • Objetivo: Mostrar dominio de forecasting y optimización, habilidades muy valoradas en roles senior.
  • Acciones:
    • Exporta métricas de uso de CPU/memoria a un CSV.
    • Usa Python (pandas) para modelar tendencias y proyectar requerimientos a 6‑12 meses.
    • Genera un reporte que incluya recomendaciones de right‑sizing y ahorro en la nube.

4. Contribuir a proyectos open‑source relevantes

  • Busca repositorios de observabilidad (Grafana plugins, Prometheus exporters) que necesiten mejoras de documentación o pruebas.
  • Un PR aceptado brinda evidencia concreta de impacto y mantiene el ritmo de code review.

5. Certificaciones con ROI medible

  • AIOps / Generative AI Professional (AIP‑C01) – Vale la pena si puedes vincularla a proyectos de detección de anomalías usando ML en tu laboratorio.
  • Certified Kubernetes Administrator (CKA) – Refuerza credenciales de clúster y suele ser requisito para roles senior.
  • Google Cloud Professional SRE – Enfocado en SLO/SLI y gestión de incidentes, directamente alineado con la descripción de trabajo senior.

Elige certificaciones que complementen proyectos reales; no acumules sin evidencia práctica.

6. Redactar la narrativa de soporte para entrevistas

  • Enfócate en métricas: “Reduje el MTTR en un 30 % al crear runbooks automáticos que ejecutan scripts de remediación”.
  • Resalta ownership indirecto: “Lideré la migración de alertas a un nuevo esquema de SLO, coordinando con equipos de desarrollo”.
  • Muestra aprendizaje continuo: “Durante el periodo de soporte, construí un laboratorio de observabilidad que me permitió diseñar un exporter de métricas para X service”.

Cuándo aplicar esta solución

  • Señales de alerta: Más de 6 meses en un rol sin código, ausencia de proyectos de arquitectura en el CV, entrevistas que rechazan por “falta de experiencia práctica”.
  • Escenarios válidos: Ingenieros que ya poseen una base sólida en Docker, Kubernetes, Terraform y Python, y que pueden dedicar 5‑10 horas semanales a un laboratorio personal.
  • Exclusiones: Si el contrato incluye proyectos de automatización o mejora de procesos, la solución de “solo laboratorio” pierde fuerza; en ese caso, enfócate en documentar y escalar esos proyectos internos.

Código

# Instala k3s (Kubernetes ligero) y despliega Prometheus + Grafana con Helm
curl -sfL https://get.k3s.io | sh -
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set grafana.adminPassword=admin123

# Deploy de micro‑servicio de prueba
kubectl apply -f https://raw.githubusercontent.com/example/simple-api/main/deployment.yaml

Verificación

  1. Accede a http://<node-ip>:3000 y verifica que el dashboard de Grafana muestra métricas de http_requests_total.
  2. Genera tráfico con hey -z 30s -c 10 http://<service-ip>/health.
  3. Confirma que las alertas de Prometheus se disparan cuando la latencia supera 200 ms.
  4. Ejecuta un experimento de chaos (kubectl -n default exec -it chaos-pod -- curl http://service:8080) y valida que el auto‑escalado responde según la política definida.

Notas adicionales

  • Persistencia de datos: Usa PersistentVolumeClaims con hostPath en k3s para que los datos de Prometheus sobrevivan a reinicios de clúster.
  • Automatiza la recolección de logs: Configura Loki como sidecar en los pods de prueba; así tendrás un flujo completo de métricas‑logs‑traces.
  • Mantén un registro de experimentos: Un simple Markdown en el repositorio del laboratorio (fecha, objetivo, resultado) sirve como portafolio rápido para recruiters.
  • No subestimes el networking interno: La mayoría de fallos de observabilidad provienen de configuraciones de Service Mesh o Ingress; incluye pruebas de conectividad en tus runbooks.
  • Equilibrio tiempo‑trabajo / tiempo‑lab: Si tu contrato permite 8 h semanales de “learning”, agenda bloques fijos y trata ese tiempo como una tarea crítica del proyecto.

Con este enfoque, conviertes un periodo de soporte en una fase de crecimiento activo, mantienes la relevancia técnica y generas evidencia concreta para los próximos pasos de carrera.