Ejemplo de CV

Ejemplo de currículum de Ingeniero SRE (Site Reliability Engineer)

Este ejemplo corresponde a una Ingeniera SRE con siete años de experiencia que empezó en operación de sistemas en una empresa de viajes de Barcelona y hoy trabaja en la plataforma de banca digital de una entidad con sede en Madrid. Fíjese en el patrón que se repite en cada punto de la experiencia: primero el comportamiento del sistema que estaba mal, después la intervención de ingeniería y al final el número que lo demuestra. Observe también lo que este currículum deliberadamente no hace: no compite en número de herramientas ni presume de pipelines rápidas, porque ese es el territorio de un Ingeniero DevOps. Aquí todo gira alrededor de objetivos de nivel de servicio, presupuesto de error, toil, capacidad y calidad de la alerta. Adáptelo a su realidad sin copiar las cifras: lo valioso de este ejemplo es la estructura de cada frase, no los números concretos.

Written & reviewed by the CVWon Editorial Team · Updated julio 2026

Cree su CV

Ejemplo vs. plantilla: Este es un CV real de Ingeniero SRE, completo y comentado, para aprender sección por sección. ¿Listo para escribir el tuyo? Usar la plantilla de CV de Ingeniero SRE →

Ejemplo de CV completo

Ingeniero SRE

Perfil profesional

Ingeniera SRE con 7 años de experiencia en plataformas de alta disponibilidad de banca digital, pagos y comercio electrónico. Gobierno un catálogo de 46 SLO sobre 12 servicios críticos y la política de presupuesto de error que condiciona el calendario de entregas de cuatro equipos de producto. Mi trabajo consiste en tres cosas: hacer que la fiabilidad se pueda medir, reducir el trabajo manual que impide mejorarla y preparar al sistema para el fallo antes de que ocurra. En los últimos tres años he llevado la disponibilidad del canal móvil del 99,82 % al 99,96 %, he bajado el toil del equipo del 58 % al 21 % de su tiempo y he reducido los avisos nocturnos de 19 a 3 al mes eliminando el ruido de alertas, no silenciándolo. Escribo en Go y Python, opero Kubernetes multizona y participo en una rotación de guardias de 8 personas con retén 24x7. Experiencia directa en las pruebas de resiliencia operativa exigidas por el Reglamento (UE) 2022/2554 (DORA).

Logros destacados

Construí desde cero el catálogo de SLI y SLO de 12 servicios críticos: 46 objetivos acordados uno a uno con los responsables de producto, con disponibilidad medida en el balanceador, latencia p99 por operación de negocio (inicio de sesión, consulta de saldo, transferencia inmediata) y frescura del dato en la aplicación móvil, todo sobre ventana móvil de 28 días. La disponibilidad efectiva del canal móvil pasó del 99,82 % al 99,96 % en 18 meses.

Redacté y conseguí que el comité de tecnología aprobara la política de presupuesto de error: por debajo del 20 % restante se congelan las funcionalidades nuevas y el equipo se dedica a fiabilidad hasta recuperarlo. Se activó dos veces en 2025, 9 y 5 días naturales, y liberó 6 semanas-persona de trabajo de fiabilidad que ningún trimestre anterior había conseguido priorizar.

Reescribí por completo el catálogo de alertas de la plataforma: de 214 reglas por umbral estático a 38 reglas basadas en síntomas y en alertado multiventana por burn rate (14,4x a 1 hora para aviso urgente, 6x a 6 horas, 1x a 3 días para ticket). Avisos por turno de guardia de 6,4 a 1,3, porcentaje de alertas accionables del 34 % al 91 % y avisos nocturnos de 19 a 3 al mes.

Medí el toil clasificando 1.400 tickets de operación durante dos trimestres y lo situé en el 58 % del tiempo del equipo. Automaticé la rotación de credenciales, el alta de tenants y la recuperación de réplicas de PostgreSQL con dos operadores de Kubernetes escritos en Go (unas 4.000 líneas, en producción desde 2024). El toil cerró el ejercicio en el 21 %, por debajo del techo del 40 % pactado con producto.

Elaboré el modelo de capacidad de la pasarela de pagos combinando pruebas de carga en k6 con la estacionalidad real del negocio (rebajas de enero, Black Friday, campaña de Navidad y picos de nómina a final de mes): curva de saturación por servicio, margen N+2 por zona de disponibilidad y previsión trimestral revisada con negocio. La campaña de Black Friday de 2025 se absorbió con 5,2 veces el tráfico medio y cero incidencias con impacto en cliente.

Puse en marcha el programa de chaos engineering con AWS Fault Injection Service y LitmusChaos: 22 experimentos en preproducción y producción acotada, cada uno con estado estable declarado, hipótesis previa, radio de impacto limitado y criterio de aborto automático. Se descubrieron tres modos de fallo en cascada provocados por reintentos sin jitter y un tiempo de espera mal propagado, todos corregidos antes de afectar a un cliente real.

Ejercí de mando de incidencia en 63 incidencias SEV1 y SEV2 en tres años, con reparto explícito de roles (operación, comunicación y cronista) y comunicación separada para negocio y para clientes. El MTTD bajó de 14 a 4 minutos, el MTTA de 11 a 3 y el tiempo medio hasta la mitigación de 68 a 19 minutos.

Implanté el post-mortem sin culpables como práctica obligatoria por encima de SEV2, con cronología, factores contribuyentes, acciones con responsable y fecha, y publicación interna abierta: 71 post-mortem en dos años, un 84 % de acciones cerradas en plazo y una caída de la reincidencia de la misma causa raíz del 31 % al 9 %.

Introduje patrones de resiliencia en las aplicaciones junto a los equipos de producto: cortacircuitos y presupuesto de reintentos en 34 servicios, limitación de carga con degradación controlada en el frontal del canal móvil y propagación coherente de tiempos de espera. Durante la caída de un proveedor externo de scoring, la aplicación siguió operativa en modo degradado y el impacto se limitó al 4 % de las operaciones en lugar de a la totalidad del canal.

Participé en las pruebas de resiliencia operativa digital exigidas por DORA (Reglamento UE 2022/2554): definición de los escenarios de indisponibilidad severa, ensayos de conmutación entre centros de proceso de datos con RTO de 30 minutos y RPO de 5 minutos verificados, y mantenimiento del registro de proveedores TIC críticos. Los dos simulacros anuales se cerraron dentro del objetivo, con un informe de resultados aceptado por auditoría interna.

Rediseñé el modelo de guardias tras heredar una rotación de 3 personas al borde del agotamiento: pasé a 8 personas con relevo semanal, runbooks revisados después de cada post-mortem, criterio explícito de qué merece despertar a alguien y traspaso formal de turno documentado. La rotación de personal del equipo cayó del 40 % anual al 8 % y dejó de haber vacantes internas sin cubrir.

Formé a 5 equipos de producto para que asumieran sus propios SLO y su turno de guardia sobre los servicios que escriben, con una revisión de preparación para producción obligatoria antes de cada alta. El tiempo que el equipo de SRE dedicaba a operar servicios ajenos bajó del 45 % al 12 %, sin que empeorara ningún objetivo de nivel de servicio.

Formación académica

En España se llega a un puesto de SRE por tres caminos igual de válidos, y ninguno de ellos es una carrera específica de fiabilidad, porque no existe. El primero es universitario: Grado en Ingeniería Informática o en Ingeniería de Tecnologías y Servicios de Telecomunicación, en ocasiones completado con un máster en cloud, ciberseguridad o ingeniería del software. El segundo es la formación profesional de grado superior, sobre todo Administración de Sistemas Informáticos en Red (ASIR) y en menor medida Desarrollo de Aplicaciones Multiplataforma (DAM), seguida de varios años de operación real; en las empresas de producto esta vía se valora sin reservas cuando viene acompañada de logros medibles. El tercero es el trasvase interno: personas de backend que acaban asumiendo la producción de lo que escriben, o administradores de sistemas y técnicos de soporte de nivel 2 que se acercan a la programación. Conviene tener presente que en el mercado español SRE casi nunca es un puesto de entrada: lo habitual es incorporarse con tres o más años previos de sistemas, backend o DevOps. Por eso el bloque de formación pesa poco en el currículum a partir del quinto año, y lo que decide es el historial de servicios operados y de incidencias gestionadas. Indique la titulación con año y universidad o centro, sin nota media ni asignaturas, y reserve el espacio para las certificaciones vigentes.

Certificaciones

CKA — Certified Kubernetes Administrator (Linux Foundation), la más solicitada en ofertas españolas de SRE

CKS — Certified Kubernetes Security Specialist, muy valorada en banca y seguros

PCA — Prometheus Certified Associate (Linux Foundation), directamente alineada con el trabajo de SLI y alertado

Google Professional Cloud DevOps Engineer, la única certificación grande construida explícitamente sobre la práctica de SRE

HashiCorp Certified: Terraform Associate

AWS Certified DevOps Engineer – Professional o AWS Certified Solutions Architect – Professional

Microsoft Certified: Azure Solutions Architect Expert (AZ-305), habitual en entidades financieras con plataforma en Azure

RHCSA y RHCE (Red Hat), relevantes en banca, seguros y Administración pública, donde RHEL sigue siendo dominante

LFCS — Linux Foundation Certified SysAdmin

ITIL 4 Foundation, útil por el vocabulario de gestión de incidencias y problemas en grandes cuentas y consultoras

Formación acreditada en resiliencia operativa digital conforme a DORA (Reglamento UE 2022/2554), cada vez más pedida en banca, seguros y servicios de pago

Formación o experiencia acreditada en el Esquema Nacional de Seguridad (ENS) para proyectos con la Administración pública

Nivel de inglés B2 o C1 acreditado (Cambridge, EOI o Aptis), casi imprescindible en multinacionales y centros de desarrollo con matriz fuera de España

Competencias

¿Qué competencias debe destacar un CV de Ingeniero SRE?

Técnica

Definición de SLI y SLO por servicio y redacción de políticas de presupuesto de error con consecuencias reales sobre el calendario de entregas Alertado multiventana por burn rate y depuración sistemática del ruido de alertas (avisos por turno, porcentaje accionable, tasa de falsos positivos) Planificación de capacidad y pruebas de carga: modelado de la curva de saturación, previsión de demanda estacional y margen de sobra declarado Ingeniería del caos: diseño de experimentos con estado estable, hipótesis, radio de impacto acotado y criterio de aborto; simulacros y ensayos de continuidad Patrones de resiliencia en aplicación: cortacircuitos, presupuesto de reintentos con jitter y retroceso exponencial, limitación de carga, degradación controlada y propagación de tiempos de espera Operación avanzada de Kubernetes: autoescalado horizontal y vertical, PodDisruptionBudget, antiafinidad, despliegue multizona y ajuste fino de recursos Observabilidad a escala: Prometheus con almacenamiento de larga duración, control de cardinalidad y coste de métricas, trazas distribuidas y registros estructurados Programación en Go y Python aplicada a la operación: operadores de Kubernetes, exportadores de métricas y automatización de tareas repetitivas Fiabilidad de datos en producción: réplicas, conmutación por error, verificación de copias de seguridad y objetivos RTO y RPO medidos, no supuestos Dirección de incidencias como mando de incidencia y conducción de post-mortem sin culpables con seguimiento de acciones

Habilidades interpersonales

Comunicación con negocio: traducir la fiabilidad a euros, a riesgo reputacional y a obligación regulatoria, en lugar de a porcentajes abstractos Serenidad y método bajo presión en incidencias de madrugada, con reparto explícito de roles y comunicación periódica aunque no haya novedades Capacidad de sostener un no con datos: mantener una congelación de entregas por presupuesto de error agotado sin convertirla en un conflicto personal Cultura sin culpables: conducir análisis que buscan factores contribuyentes del sistema y no responsables individuales, también cuando la dirección pide un nombre Pedagogía y acompañamiento: conseguir que los equipos de producto se apropien de sus SLO y de su turno de guardia en lugar de delegarlos Escritura técnica clara en castellano y en inglés: runbooks que funcionan a las cuatro de la madrugada, post-mortem legibles y revisiones de preparación para producción

Herramientas

Prometheus, Thanos, Grafana y Alertmanager OpenTelemetry, Grafana Tempo, Jaeger y Loki Sloth y Pyrra para generar reglas de SLO, con OpenSLO como formato de definición k6, Gatling y Apache JMeter para pruebas de carga y de estrés AWS Fault Injection Service, LitmusChaos y Chaos Mesh PagerDuty y Opsgenie para guardias, escalado y análisis de la carga de avisos Kubernetes, Helm, Argo CD y Argo Rollouts (canario y análisis automático de métricas) Terraform y Ansible Go, Python y Bash PostgreSQL, Redis y Apache Kafka en producción GitLab CI y GitHub Actions Backstage como catálogo de servicios, con revisión de preparación para producción integrada

Categoría	Competencias
Técnica	Definición de SLI y SLO por servicio y redacción de políticas de presupuesto de error con consecuencias reales sobre el calendario de entregas, Alertado multiventana por burn rate y depuración sistemática del ruido de alertas (avisos por turno, porcentaje accionable, tasa de falsos positivos), Planificación de capacidad y pruebas de carga: modelado de la curva de saturación, previsión de demanda estacional y margen de sobra declarado, Ingeniería del caos: diseño de experimentos con estado estable, hipótesis, radio de impacto acotado y criterio de aborto; simulacros y ensayos de continuidad, Patrones de resiliencia en aplicación: cortacircuitos, presupuesto de reintentos con jitter y retroceso exponencial, limitación de carga, degradación controlada y propagación de tiempos de espera, Operación avanzada de Kubernetes: autoescalado horizontal y vertical, PodDisruptionBudget, antiafinidad, despliegue multizona y ajuste fino de recursos, Observabilidad a escala: Prometheus con almacenamiento de larga duración, control de cardinalidad y coste de métricas, trazas distribuidas y registros estructurados, Programación en Go y Python aplicada a la operación: operadores de Kubernetes, exportadores de métricas y automatización de tareas repetitivas, Fiabilidad de datos en producción: réplicas, conmutación por error, verificación de copias de seguridad y objetivos RTO y RPO medidos, no supuestos, Dirección de incidencias como mando de incidencia y conducción de post-mortem sin culpables con seguimiento de acciones
Herramientas	Prometheus, Thanos, Grafana y Alertmanager, OpenTelemetry, Grafana Tempo, Jaeger y Loki, Sloth y Pyrra para generar reglas de SLO, con OpenSLO como formato de definición, k6, Gatling y Apache JMeter para pruebas de carga y de estrés, AWS Fault Injection Service, LitmusChaos y Chaos Mesh, PagerDuty y Opsgenie para guardias, escalado y análisis de la carga de avisos, Kubernetes, Helm, Argo CD y Argo Rollouts (canario y análisis automático de métricas), Terraform y Ansible, Go, Python y Bash, PostgreSQL, Redis y Apache Kafka en producción, GitLab CI y GitHub Actions, Backstage como catálogo de servicios, con revisión de preparación para producción integrada
Habilidades interpersonales	Comunicación con negocio: traducir la fiabilidad a euros, a riesgo reputacional y a obligación regulatoria, en lugar de a porcentajes abstractos, Serenidad y método bajo presión en incidencias de madrugada, con reparto explícito de roles y comunicación periódica aunque no haya novedades, Capacidad de sostener un no con datos: mantener una congelación de entregas por presupuesto de error agotado sin convertirla en un conflicto personal, Cultura sin culpables: conducir análisis que buscan factores contribuyentes del sistema y no responsables individuales, también cuando la dirección pide un nombre, Pedagogía y acompañamiento: conseguir que los equipos de producto se apropien de sus SLO y de su turno de guardia en lugar de delegarlos, Escritura técnica clara en castellano y en inglés: runbooks que funcionan a las cuatro de la madrugada, post-mortem legibles y revisiones de preparación para producción

Nota sectorial

El mercado español de SRE se concentra en Madrid y Barcelona, con núcleos consolidados en Valencia, Málaga, Bilbao, Sevilla y A Coruña. Madrid es el centro de la banca, los seguros, los medios de pago y las telecomunicaciones, además del principal empleador de perfiles de fiabilidad en sistemas de reserva y distribución de viajes; Barcelona concentra empresas de producto, marketplaces y centros de desarrollo de grupos industriales. La diferencia práctica para su candidatura es enorme: en banca, seguros y servicios de pago el puesto lleva incorporado el cumplimiento normativo, y desde la aplicación plena del Reglamento (UE) 2022/2554 (DORA) en enero de 2025 se exige un programa de pruebas de resiliencia operativa digital, la clasificación y notificación de incidentes graves al supervisor en plazos tasados y un registro de proveedores TIC críticos; conviene no confundir esta norma con las métricas DORA de entrega que cita el mundo DevOps, porque en una entrevista en banca la palabra significa siempre el reglamento. En el sector público y en quien licita con él manda el Esquema Nacional de Seguridad. En las empresas de producto, en cambio, lo que se examina es su criterio sobre SLO, capacidad y calidad de la alerta, con mucha menos ceremonia. Sobre condiciones: el contrato indefinido es el estándar en producto y en banca, mientras que en consultoría todavía abunda la fórmula de cesión a cliente, con el convenio estatal de consultoría y tecnologías de la información como marco de referencia. Como orientación salarial en bruto anual para 2026: de 42.000 € a 52.000 € con dos a cuatro años de experiencia, de 55.000 € a 72.000 € en perfiles sénior de cinco a ocho años, y de 75.000 € a 95.000 € en posiciones de referente técnico o responsable de fiabilidad, con la banca, los pagos y las empresas de producto internacionales en la parte alta y la consultoría generalista en la baja. Las guardias se retribuyen aparte mediante un plus de disponibilidad que suele moverse entre 100 € y 350 € por semana de retén, más el abono o el descanso compensatorio de las intervenciones; ese importe no está unificado por convenio y se pacta empresa a empresa, así que pregunte siempre por el tamaño de la rotación antes que por la cifra, porque una rotación de tres personas con un plus generoso es peor acuerdo que una de ocho con un plus discreto.

FAQ

Preguntas frecuentes

Como orientación en bruto anual para 2026: entre 42.000 € y 52.000 € con dos a cuatro años de experiencia; entre 55.000 € y 72.000 € en un perfil sénior de cinco a ocho años; y entre 75.000 € y 95.000 € en posiciones de referente técnico, staff o responsable de fiabilidad. Madrid y Barcelona marcan el techo, con la banca, los medios de pago y las empresas de producto internacionales en la parte alta y la consultoría generalista entre 8.000 € y 15.000 € por debajo para el mismo nivel. A esa cifra hay que sumarle siempre el plus de disponibilidad por guardias, habitualmente entre 100 € y 350 € por semana de retén más las intervenciones, y la retribución flexible (seguro médico, ticket restaurante, formación). Un perfil de SRE con experiencia demostrable en SLO y en resiliencia regulatoria suele situarse algo por encima de un perfil DevOps equivalente en entidades financieras, precisamente porque hay menos candidatos que puedan acreditarlo.

Que aquí no se mide el proceso de entrega, sino el comportamiento del sistema. Un CV de DevOps se apoya en frecuencia de despliegue, tiempo de entrega del cambio y tiempo de compilación: cuenta cómo llega el código a producción. Este se apoya en objetivos de nivel de servicio con su umbral y su ventana, en un presupuesto de error que llegó a agotarse y detuvo entregas, en un porcentaje de toil que bajó, en un modelo de capacidad que aguantó un pico conocido y en unos experimentos de caos que encontraron un fallo antes que un cliente. Las herramientas se solapan casi por completo, así que la señal que busca un reclutador técnico no está en la lista de tecnologías sino en el tipo de número que acompaña a cada logro. Si en su CV todos los números son de la pipeline, se le encasillará como DevOps por mucho que el titular diga SRE.

Es poco frecuente en España. La mayoría de las ofertas piden tres años o más porque el trabajo exige haber visto fallar sistemas reales y haber estado de guardia: el criterio sobre qué merece despertar a alguien a las cuatro de la madrugada no se adquiere en un curso. Las vías realistas son incorporarse antes a un puesto de operación de sistemas, de backend con responsabilidad sobre su propia producción o de DevOps, y ganar desde ahí el vocabulario y la experiencia de fiabilidad. Si está empezando, el atajo más rentable es especializarse en observabilidad: montar Prometheus y Grafana de verdad, escribir reglas de alerta basadas en síntomas y practicar la definición de SLO sobre un servicio propio, aunque sea pequeño. Ese es un hueco que muchas empresas españolas no consiguen cubrir.

Empiece por lo que sí existía, aunque no tuviera nombre técnico: número de incidencias al mes, avisos que recibía en una semana de guardia, cuánto tardaba el equipo en darse cuenta de una caída, cuántas horas al mes se iban en una tarea manual concreta, cuántas veces se repitió el mismo problema. Cualquiera de esos datos se puede reconstruir con las herramientas de tickets, con el histórico del sistema de avisos o con su propia agenda. Indique el orden de magnitud y el periodo («de unas 20 a unas 5 incidencias recurrentes al trimestre durante 2025») y prepárese para explicar de dónde sale el número, porque se lo van a preguntar. Lo que nunca debe hacer es escribir cifras redondas y bonitas que no pueda defender: en una entrevista de SRE la repregunta llega siempre y es muy específica.

Mucho más que en otros perfiles técnicos y por una razón operativa: en incidencias graves de multinacionales la coordinación, el canal de comunicación y el post-mortem se hacen en inglés, y la documentación de referencia de la disciplina no está traducida. Un B2 sólido basta para la mayoría de los puestos en España, pero en centros de desarrollo con matriz extranjera y en entidades con equipos repartidos por Europa el proceso entero puede desarrollarse en inglés, incluida la parte técnica. Ensaye en voz alta dos explicaciones concretas: cómo definió un SLO y cómo condujo una incidencia de principio a fin. Son las dos exposiciones que salen en casi todas las entrevistas y las dos que peor se improvisan en un idioma que no es el propio.

Si no tiene experiencia real, no lo escriba en el currículum: en una entrevista en banca se nota en dos preguntas y el efecto es peor que la omisión. Lo que sí conviene es conocer el terreno para la conversación, porque en Madrid una parte importante de la demanda de SRE viene de entidades financieras, aseguradoras y proveedores de servicios de pago sujetos a DORA desde enero de 2025. Basta con manejar bien las ideas clave: programa de pruebas de resiliencia operativa digital, clasificación y notificación de incidentes graves al supervisor en plazos tasados, registro de proveedores TIC críticos y gestión del riesgo de terceros. Si en su trayectoria ha hecho ensayos de conmutación entre centros de datos, verificación de copias de seguridad o simulacros de continuidad, eso ya es material aprovechable: descríbalo con sus objetivos de RTO y RPO medidos y estará hablando el mismo idioma sin atribuirse una experiencia regulatoria que no tiene.