Fiabilidad de nivel SRE senior sin montar un equipo de plataforma
Una empresa con producto en producción necesita que alguien defina qué significa «funcionar», lo mida, reduzca el ruido de las alertas y convierta cada incidente en algo que no vuelva a pasar igual. Eso es trabajo de SRE, y no hace falta montar un equipo de plataforma para tenerlo: lo prestamos por suscripción, con ingenieros senior, objetivos escritos y entregables que se quedan en vuestro repositorio. Empezamos siempre por un diagnóstico, y si de ahí sale que no hace falta un servicio continuado, se dice.
Última actualización:
¿Te suena esto?
Si os reconocéis en tres o más, el problema no es de herramientas.
- Las alertas suenan de noche, casi siempre por nada, y ya nadie las mira.
- Los incidentes los resuelve de memoria la misma persona, y no queda nada escrito para la próxima vez.
- Nadie sabe decir si el servicio cumple lo que promete el contrato, porque no hay nada medido.
- La factura de observabilidad crece más rápido que el tráfico y no está claro qué parte de esos datos se mira alguna vez.
- Un despliegue tarda una tarde y hace falta que esté delante quien lo montó.
- Las copias de seguridad existen, pero nadie ha probado nunca a restaurar una de verdad.
- El auditor pide el inventario de dependencias y las pruebas de recuperación, y hay que montarlo a mano cada vez.
- Buscáis un SRE senior desde hace meses y las candidaturas que llegan piden lo que cuesta medio equipo.
Por qué esto es un problema ahora
Un SRE senior es escaso y caro
La ingeniería de fiabilidad es un perfil con mucha menos oferta que demanda, y eso se nota en el plazo de contratación y en el salario. Para muchas empresas el problema no es el presupuesto: es que una sola persona no cubre una función que necesita continuidad, y que un proceso de contratación de meses deja el problema abierto mientras dura.
La observabilidad se ha encarecido
Las plataformas de observabilidad facturan por volumen ingestado, y el volumen crece solo: más servicios, más contenedores, más etiquetas. La reacción típica es recortar retención y apagar trazas, que es exactamente lo que hace falta el día de la investigación difícil. Lo que de verdad baja la factura es dejar de enviar lo que nadie mira, y para eso hay que saber qué se mira.
La norma ya pide demostrarlo
DORA (Reglamento UE 2022/2554) se aplica desde el 17 de enero de 2025 al sector financiero y a sus proveedores tecnológicos, y NIS2 (Directiva UE 2022/2555) amplía considerablemente el número de entidades obligadas y endurece la notificación de incidentes. Las dos piden lo mismo en el fondo: gestión de incidentes con criterios, pruebas de resiliencia que se hacen de verdad y evidencias que se pueden presentar. Eso ya no es una buena práctica, es un requisito con fecha.
Qué cambia si se hace bien
Nada espectacular, y eso es la señal: menos avisos de madrugada, incidentes que se resuelven sin que tenga que estar una persona concreta, despliegues que no dan miedo y una respuesta por escrito cuando un cliente grande pregunta cuánto aguanta vuestro servicio.
Los cinco servicios
Se pueden contratar por separado. Lo habitual es empezar por el que tenga el plazo o el dolor encima.
SRE fraccional
Un equipo de fiabilidad por suscripción: SLOs, alertas útiles, guardias, gestión de incidentes y production readiness, con ingenieros senior y entregables que se quedan contigo.
Coste de observabilidad
Auditamos qué telemetría generáis, qué se mira de verdad y qué parte de la factura paga datos que nadie consulta. Con un plan para filtrar, muestrear y enrutar antes de enviar.
Resiliencia DORA y NIS2
La parte técnica de DORA y NIS2: clasificación y notificación de incidentes, pruebas de resiliencia y de recuperación, mapa de dependencias y evidencias recogidas solas.
Cloud soberana europea
Salir de un hiperescalador no europeo sin quedarse atado al siguiente: evaluación, arquitectura y migración a Exoscale, STACKIT u OVHcloud con Kubernetes e infraestructura como código.
Operaciones asistidas por IA
Runbooks agénticos y copilotos de incidentes conectados por MCP a Kubernetes, logs y métricas, desplegados en vuestro entorno para que los datos de operación no salgan de ahí.
Cómo empezamos
Llamada de diagnóstico
Media hora: qué tenéis en producción, qué se rompe y qué duele. Sin presentación comercial.
Propuesta por escrito
Qué haríamos, en qué orden, con qué entregables y en cuánto tiempo. Y lo que no haríamos todavía.
Primer trabajo acotado
Una revisión de alertas, unos SLOs o una auditoría de observabilidad. Algo que se termina y se puede juzgar.
Servicio continuado, si tiene sentido
Suscripción por alcance y niveles de servicio. Si con el trabajo acotado os basta, ahí se queda.
Llamada de diagnóstico de 30 minutos
Media hora con ingenieros senior para contar qué tenéis en producción, qué se rompe y qué duele. Al terminar os decimos qué haríamos primero y si hace falta algo más que una tarde de trabajo. Sin presentación comercial y sin compromiso.
Si de la conversación sale que no necesitáis un servicio continuado, os lo decimos ahí mismo. Preferimos eso a una suscripción que no mejora nada.
Preguntas frecuentes
¿Esto sustituye a nuestro equipo de plataforma?
No. Si ya tenéis equipo, trabajamos con él: ponemos el método, las revisiones y el trabajo de fondo que nunca llega a hacerse porque siempre hay algo más urgente. Si no lo tenéis, cubrimos la función mientras no haya volumen para contratarlo, y dejamos todo documentado para el día en que lo haya.
¿Estáis de guardia por nosotros 24 horas?
No lo anunciamos porque no es lo que vendemos. Diseñamos y operamos vuestro proceso de guardia —rota, escalado, severidades, runbooks— y nuestro compromiso de respuesta es de menos de 24 horas laborables, con prioridad por contrato para lo crítico. La cobertura fuera de horario se acuerda aparte y se escribe en el contrato.
¿Con qué herramientas trabajáis?
Kubernetes y Terraform para la infraestructura, ArgoCD para GitOps, OpenTelemetry para la telemetría y Prometheus, Grafana, Loki y Tempo para mirarla. Son herramientas abiertas y estándar a propósito: cualquier ingeniero del mercado puede continuar el trabajo, y vosotros podéis dejar de contar con nosotros sin tener que rehacerlo.
No tenemos Kubernetes. ¿Sirve igual?
Sí. Los SLOs, las alertas con dueño, el proceso de incidentes y los postmortems valen igual sobre máquinas virtuales, contenedores sueltos o servidores propios. Kubernetes es una herramienta frecuente, no un requisito, y no lo recomendamos cuando no hay volumen que lo justifique.
¿Hace falta cambiar de proveedor de cloud para empezar?
No. El trabajo de fiabilidad se hace sobre lo que ya tenéis, sea AWS, Azure, Google Cloud, un proveedor europeo o vuestro propio hardware. La migración es otro servicio y solo tiene sentido si hay una razón para hacerla.
¿Cuánto tardamos en notar algo?
Lo primero que se nota es el ruido: una revisión de alertas suele dar resultado en las primeras semanas, porque buena parte de las que suenan no son accionables. Los SLOs tardan más, porque antes hay que medir, y no sirven de nada hasta que hay unas semanas de datos detrás.
¿Firmáis un acuerdo de confidencialidad?
Sí, si lo queréis, y nada de lo que veamos se usa como ejemplo en ningún sitio sin permiso por escrito. Los accesos se piden al mínimo necesario y se documentan.
¿Qué pasa si decidimos dejarlo?
Os quedáis con todo: los SLOs definidos, los runbooks, el código de infraestructura en vuestro repositorio, los paneles y la documentación. No hay permanencia ni nada que solo sepamos nosotros.
Hablemos de lo que tenéis en producción
Qué servicios, qué se rompe, qué os están pidiendo. Respondemos en menos de 24 horas laborables con una primera valoración y lo que haríamos primero.
o escríbenos a info@esdis.es