SRE fraccional: un equipo de fiabilidad por suscripción
El SRE fraccional es un servicio mensual que cubre la función de ingeniería de fiabilidad sin contratar un equipo de plataforma: definimos qué significa que vuestro servicio funcione, lo medimos con SLOs y error budgets, dejamos solo las alertas que alguien puede accionar, montamos el proceso de guardia y de incidentes, y escribimos los postmortems para que lo aprendido no se quede en una conversación de Slack. Se contrata por alcance y niveles de servicio, no por horas.
Última actualización:
Fiabilidad como función, no como heroísmo
Para quién es
Para scaleups y pymes tecnológicas que ya tienen producto en producción y clientes que lo notan cuando se cae, pero todavía no tienen —ni les toca todavía— un equipo de plataforma. También para equipos que sí lo tienen y van ahogados: el trabajo de fondo de fiabilidad es siempre lo primero que se aplaza.
Qué problema resuelve
Que la fiabilidad dependa de que esté disponible la persona que lo montó. Cuando no hay objetivos medidos, cada caída se discute por sensaciones; cuando las alertas no son accionables, se desactivan las notificaciones y la siguiente se pierde; y cuando no hay postmortems, el mismo fallo vuelve dos veces al año. Nada de eso se arregla con más herramientas: se arregla con método, y el método es lo que hay que tener a alguien haciendo todas las semanas.
Por qué no se resuelve contratando
Un SRE senior es un perfil escaso, con el salario que eso implica, y una sola persona no cubre una función que necesita continuidad. Un proceso de contratación largo deja el problema abierto mientras dura, y el día que la persona se va se va también todo lo que no estaba escrito.
Los tres cambios que más se notan
Objetivos medidos
SLIs y SLOs por servicio, con error budget. Se deja de discutir si va bien o mal y se empieza a mirar cuánto presupuesto de fallo queda este trimestre.
Alertas que alguien acciona
Cada alerta con dueño, umbral justificado y runbook. Las que no pasan ese filtro se van: una alerta que nadie mira es peor que no tenerla.
Incidentes con proceso
Severidades, roles, comunicación y postmortem sin culpa. Lo que se aprende acaba en un runbook o en una tarea, no en una conversación que se pierde.
Qué incluye la suscripción
Fiabilidad
Catálogo de servicios con su criticidad, SLIs y SLOs por servicio con su error budget, y un informe mensual de consumo de ese presupuesto. Es lo que convierte «la web iba lenta» en una decisión sobre si este trimestre toca invertir en fiabilidad o en funcionalidad.
Alertas y guardia
Revisión completa del inventario de alertas, con las que no son accionables retiradas y las que faltan añadidas. Rota de guardia con escalado, severidades y canales de aviso definidos, y un runbook por alerta que queda.
Incidentes
Proceso escrito de gestión de incidentes: clasificación, roles, comunicación interna y a clientes, y plantilla de postmortem. Conducimos los postmortems de los incidentes importantes y hacemos seguimiento de las acciones que salen de ellos, que es la parte que normalmente se queda sin hacer.
Production readiness
Revisión de servicios nuevos antes de que entren en producción, con una lista de comprobación propia: límites de recursos, sondas de salud, degradación, dependencias, copias con prueba de restauración y plan de vuelta atrás.
Entrega y automatización
Mejoras en CI/CD para que desplegar sea aburrido: despliegue reproducible, vuelta atrás rápida, entornos iguales entre sí. GitOps con ArgoCD cuando hay Kubernetes, e infraestructura como código con Terraform en cualquier caso, para que lo que está montado se pueda volver a montar.
Qué significa aquí «guardia»
Montamos y operamos tu proceso de guardia: la rota, el escalado, los niveles de severidad, los avisos y los runbooks para que quien reciba la llamada a las tres de la mañana sepa qué hacer sin despertar a nadie más. Nuestro propio compromiso de respuesta es de menos de 24 horas laborables, con prioridad por contrato para lo crítico. Si necesitáis que alguien de fuera coja el teléfono de madrugada, se acuerda aparte y se escribe en el contrato: no lo anunciamos como incluido porque no lo está.
Cómo se contrata
Suscripción mensual por alcance y niveles de servicio, no por horas. Lo que se firma es qué servicios entran, qué objetivos se persiguen, qué entregables hay cada mes y en cuánto tiempo respondemos; no una bolsa de horas que hay que gastar antes de que caduque. El importe depende del número de servicios y de su criticidad, así que sale de la primera conversación y se da cerrado.
Cómo trabajamos
Diagnóstico
Media hora de conversación y después acceso de lectura a lo que haya: paneles, alertas, repositorios y el historial de incidencias. Salimos con un inventario y una lista priorizada.
Plan de los tres primeros meses
Por escrito: qué se mide primero, qué alertas se retiran, qué proceso se monta y en qué orden. Con lo que no vamos a tocar todavía, y por qué.
Implantación
Trabajamos dentro de vuestro repositorio y vuestras herramientas, con revisión de código como cualquier otro miembro del equipo. Nada en sistemas nuestros.
Operación y revisión
Informe mensual de error budget, incidentes y acciones pendientes, y una revisión trimestral para ajustar objetivos. Si un SLO no sirve para decidir nada, se cambia o se quita.
Preguntas frecuentes
¿Cuántas horas al mes incluye?
No se cuenta así. Lo que se firma es el alcance —qué servicios, qué entregables cada mes, en cuánto respondemos— y el trabajo necesario para sostenerlo. Una bolsa de horas premia gastarlas, no resolver el problema.
¿Trabajáis dentro de nuestro repositorio o en uno vuestro?
En el vuestro, con vuestras herramientas y pasando por revisión de código. Los runbooks, el código de infraestructura y los paneles se quedan donde los pueda mantener vuestro equipo.
¿Y si nuestro problema no es la fiabilidad, sino el coste?
Entonces empezad por ahí: la optimización del coste de observabilidad es un trabajo acotado, con un informe por delante, y no necesita una suscripción.
¿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.
Cuéntanos qué tenéis en producción
Qué servicios, qué se rompe y qué pasa cuando se rompe. 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