Currículum de ingeniero/a SRE (site reliability engineer): ejemplos y guía para redactarlo

Este es un SRE de nivel medio-sénior en el equipo de plataforma de una empresa SaaS. Los nombres de las empresas son inventados. Cada logro vincula una acción de ingeniería con una cifra de fiabilidad, que es justo de lo que trata un currículum de SRE.

Las entrevistas de SRE ponen a prueba el criterio operativo, la programación y el conocimiento de sistemas. El filtro del currículum se fija sobre todo en la escala y en pruebas de que fuiste responsable de la fiabilidad, no de mirar dashboards.

• Escala y forma del sistema. Número de servicios, regiones, nivel de tráfico, volumen de datos, si es multicliente. Esto decide el encaje antes que cualquier lista de herramientas.
• Cifras de fiabilidad de las que eras responsable. Disponibilidad frente a un objetivo, MTTR, volumen de avisos, política de presupuesto de error, número de incidentes. Ser responsable de un SLO no es lo mismo que conocerlo.
• Comportamiento en incidentes. ¿Dirigiste la gestión de incidentes, escribiste postmortems, cerraste acciones? Se contrata pensando en la peor noche del trimestre, no en las tranquilas.
• Código, no solo configuración. SRE es un puesto de ingeniería. Di en qué lenguaje programas, qué herramientas entregaste y cuánto trabajo manual eliminaron.

“Enséñame un SLO del que fuiste responsable, una cifra que cambió y un incidente que llevaste de principio a fin. Una lista de veinte herramientas no dice nada sobre si eres capaz de sostener una llamada de crisis a las tres de la madrugada y tomar la decisión de hacer rollback.”

Los dos títulos se solapan y muchas empresas los usan sin precisión, pero cada currículum debe destacar cosas distintas. Si te presentas a los dos tipos de puesto, ten dos versiones.

La mayoría de los currículums SRE parecen un inventario de tecnología. Cada una de estas reformulaciones mantiene la herramienta, pero añade el resultado en fiabilidad.

Agrúpalas para que quien lea sepa en cinco segundos si vienes de sistemas y haces scripts o eres de ingeniería y además operas.

• Práctica de fiabilidad: SLI, SLO y política de presupuesto de error, diseño de guardias, calidad de las alertas y alertas basadas en síntomas, gestión de incidentes, postmortems sin culpables, medición del toil, revisiones de preparación para producción.
• Plataformas: Kubernetes y su ecosistema, una gran nube en profundidad y nociones de una segunda, service mesh si lo usas, balanceadores de carga y DNS, bases de datos gestionadas.
• Infraestructura como código y entrega: Terraform o Pulumi, Helm, ArgoCD o Flux, GitHub Actions u otro CI similar, entrega progresiva y despliegues canary.
• Observabilidad: Prometheus y PromQL, Grafana, OpenTelemetry, trazas distribuidas, logs estructurados y la capacidad de explicar qué instrumentarías a continuación.
• Programación: Go, Python o Rust a un nivel que te permita poner en producción servicios y operadores, no solo scripts. Di cuál y da un ejemplo de algo que hayas construido.
• Profundidad en sistemas: depuración de rendimiento en Linux, redes desde TCP hacia arriba, comportamiento del almacenamiento bajo carga, modos de fallo de bases de datos, comportamiento de la caché y cómo falla cada una de esas piezas en producción.

Las certificaciones por sí solas no consiguen un puesto de SRE, pero ayudan a pasar el filtro de selección y son útiles cuando vienes de la administración de sistemas.

• Certified Kubernetes Administrator (CKA). La más útil para SRE porque es práctica. Certified Kubernetes Security Specialist es un buen siguiente paso si trabajas en la seguridad de clústeres.
• Certificaciones cloud: AWS Certified Solutions Architect – Associate o DevOps Engineer Professional, Google Professional Cloud DevOps Engineer, Microsoft Azure Administrator. Elige la que corresponda a la nube de tu currículum.
• HashiCorp Certified: Terraform Associate. Se obtiene rápido y los responsables de selección la reconocen.
• Titulación: un grado en informática es habitual, pero ni mucho menos obligatorio. Muchos buenos SRE vienen de la administración de sistemas, la ingeniería de redes o el soporte.
• Lo que sustituye a una certificación: un repositorio público con herramientas reales, una charla en un congreso o meetup sobre un incidente, o un postmortem escrito que puedas compartir sin las partes confidenciales.

Muy poca gente empieza como SRE. La mayoría llega desde operaciones, soporte o un equipo de backend. El trabajo del currículum es demostrar responsabilidad sobre producción aunque tu puesto nunca lo dijera.

1. 1Localiza el trabajo de fiabilidad que ya has hecho: una rotación de guardias, una caída que resolviste, un runbook que automatizaste, un hueco de monitorización que cerraste. Escríbelo primero, antes que tus tareas diarias.
2. 2Ponle cifras aunque sean pequeñas: servidores gestionados, tickets eliminados con automatización, cumplimiento de parches, disponibilidad de la que eras responsable.
3. 3Enseña código. Un repositorio con módulos de Terraform, una herramienta en Python, un pequeño servicio en Go. Los filtros de SRE buscan con mucha exigencia a gente que sepa programar de verdad.
4. 4Aprende Kubernetes a fondo y saca la CKA. Es el requisito más común en las ofertas de SRE.
5. 5Usa el vocabulario de fiabilidad con precisión. Emplear bien SLO, presupuesto de error y toil le dice al entrevistador que conoces la disciplina, no solo la oferta.
6. 6Preséntate a equipos de plataforma y de infraestructura, no solo a puestos con el título SRE. Muchas empresas contratan a la misma persona con tres títulos distintos.

Una página hasta unos ocho años de experiencia; dos a partir de ahí. Tu currículum lo lee primero alguien de selección con una lista de palabras clave y después alguien del equipo técnico con opinión propia, así que tiene que superar a los dos.

• Pon un bloque de competencias sencillo con los nombres exactos de las tecnologías para selección, y deja que los logros aporten las cifras para el equipo técnico.
• Repite el título y las palabras de la oferta: site reliability engineer, ingeniero/a de producción, ingeniero/a de plataforma, ingeniero/a de infraestructura. Incluye «SRE» como sigla en algún lugar, porque los filtros buscan las dos formas.
• Términos que conviene incluir si son ciertos: SLO, SLI, presupuesto de error, MTTR, guardias, respuesta a incidentes, postmortem, Kubernetes, Terraform, observabilidad, planificación de capacidad, toil.
• Una sola columna, sin gráficos ni barras de nivel de competencias. La foto es opcional en España; la fecha de nacimiento y el DNI no hacen falta.
• Enlaza un perfil de GitHub solo si tiene algo real. Un perfil vacío es peor que no poner enlace.