Tarde o temprano, toda empresa SaaS en crecimiento oye que necesita SRE. Quizá un cliente grande preguntó por tu objetivo de uptime, quizá lo mencionó un inversionista, quizá una caída lo dejó claro por sí sola. La ingeniería de confiabilidad de sitios (SRE, por sus siglas en inglés) es una disciplina real con ideas útiles, pero el puesto y las prácticas no son lo mismo, y una startup de 15 personas rara vez necesita lo primero. Este artículo explica qué es SRE, cómo se relaciona con DevOps, dónde se solapan y qué debería poner en marcha primero un equipo pequeño. También analiza con honestidad el “AI SRE”, la versión más reciente de la pregunta.

Qué es la ingeniería de confiabilidad de sitios y cómo la empezó Google

SRE nació en Google, y la definición del propio Google es breve: “SRE es lo que pasa cuando le pides a un ingeniero de software que diseñe un equipo de operaciones.” En lugar de un grupo de operaciones aparte que corre el software que los desarrolladores le tiran por encima del muro, SRE trata la operación de producción como un problema de software, que se resuelve con código, medición y compromisos explícitos.

El libro gratuito de Google, Site Reliability Engineering, presentó un puñado de ideas que se extendieron mucho más allá de Google. Cuatro son las más importantes.

SLI y SLO

Un indicador de nivel de servicio (SLI) es una medición de lo que experimentan los usuarios, como el porcentaje de solicitudes que tienen éxito o el porcentaje que se atiende en menos de 300 milisegundos. Un objetivo de nivel de servicio (SLO) es la meta para esa medición en un periodo, por ejemplo, que el 99.9% de las solicitudes de pago tengan éxito en 30 días. Un SLA es la promesa contractual, con penalizaciones, que haces a tus clientes. Debería ser más laxo que tu SLO, para que notes los problemas antes de que te cuesten dinero.

El sentido de un SLO es definir qué es “suficientemente confiable”. Sin uno, cada incidente se vuelve un debate sobre si fue grave o no, y cada proyecto de confiabilidad compite con las funcionalidades por pura intuición.

Presupuestos de errores

Si tu SLO es 99.9%, se te permite un 0.1% de fallos. Esa holgura es el presupuesto de errores (error budget). Google lo describe como un recurso que desarrollo y operaciones gastan juntos: mientras quede presupuesto, se lanzan funcionalidades rápido; cuando se agota, se baja el ritmo y se dedica el esfuerzo a la confiabilidad. Una política de presupuesto de errores deja ese acuerdo por escrito de antemano, y convierte una discusión política en una regla que todos aceptaron con la cabeza fría.

Toil

Google define el toil como trabajo que es “manual, repetitivo, automatizable, táctico, sin valor duradero y que crece de forma lineal a medida que crece el servicio.” Reiniciar a mano un worker trabado, rotar una credencial desde la consola, copiar una base de datos para un cliente: si vuelve cada semana y una máquina podría hacerlo, es toil. Google limita el trabajo operativo de sus equipos de SRE a la mitad de su tiempo, para que la otra mitad se dedique a ingeniería que elimine el toil.

Post-mortems sin culpas

Después de un incidente, los equipos de SRE escriben un post-mortem centrado en las causas que contribuyeron, no en quién cometió el error. Lo vemos en detalle en nuestro artículo sobre gestión de incidentes para SaaS.

Qué es DevOps

DevOps es más antiguo como término y más amplio como idea. Es un conjunto de prácticas culturales y técnicas para que desarrolladores y operaciones trabajen como un solo equipo, de modo que el software llegue del commit a producción rápido y de forma segura. En la práctica significa integración y entrega continuas, infraestructura como código, pruebas automatizadas, monitoreo y propiedad compartida de producción. Nuestro artículo sobre los principios de DevOps cubre lo básico.

DevOps describe cómo se ve lo bueno. A propósito, no es prescriptivo sobre cómo medirlo ni sobre qué hacer cuando chocan la velocidad y la estabilidad.

Site reliability engineering vs. DevOps: en qué se solapan

El propio planteamiento de Google es que los dos se complementan. El workbook de SRE lo resume como “la clase SRE implementa la interfaz DevOps”: DevOps es la interfaz, un conjunto de principios, y SRE es una implementación concreta y con opiniones propias de esa interfaz.

	DevOps	SRE
Pregunta central	¿Cómo lanzamos más rápido y de forma más segura, trabajando juntos?	¿Qué tan confiable debe ser esto y cómo lo mantenemos ahí?
Herramientas principales	CI/CD, infraestructura como código, automatización, propiedad compartida	SLO, presupuestos de errores, reducción del toil, práctica de incidentes
Qué mide	Velocidad y estabilidad de las entregas	Confiabilidad que ve el usuario frente a un objetivo
Cuando chocan velocidad y estabilidad	Cultura y criterio	Decide el presupuesto de errores
Dónde suele vivir	En todos, a menudo con un rol de plataforma o de DevOps	En un equipo especializado, en empresas más grandes

Ambos valoran la automatización, la medición y la responsabilidad compartida sobre producción. La diferencia está en el énfasis. El trabajo de DevOps trata sobre todo del camino a producción: pipelines, entornos, infraestructura. El trabajo de SRE trata sobre todo de lo que pasa una vez que llegas: disponibilidad, latencia, capacidad e incidentes.

Qué necesita primero un equipo SaaS pequeño

Para una startup sin un equipo de operaciones dedicado, la respuesta casi siempre es empezar por las bases de DevOps y tomar prestadas pronto algunas prácticas de SRE. Contratar un equipo de SRE es algo para considerar mucho más adelante, si es que llega el momento.

La razón es el orden de las cosas. Las prácticas de SRE suponen que puedes medir, desplegar y hacer rollback de forma confiable. Si los despliegues son manuales, los entornos se desalinean y no hay más alertas que los clientes escribiendo a soporte, un SLO es un número sobre el que nadie puede actuar. Primero arregla el camino de entrega:

Despliegues automatizados y repetibles con un rollback probado.
Infraestructura como código, para poder reconstruir y revisar los entornos.
Monitoreo y alertas sobre lo que los usuarios notan: errores, latencia, disponibilidad.
Un esquema de guardia que no dependa de una sola persona.

Luego toma prestadas las ideas de SRE que cuestan poco y rinden rápido:

Uno o dos SLO para los recorridos que más importan, como el inicio de sesión y el pago. Empieza con metas laxas y ajústalas a medida que aprendas.
Alertas basadas en el impacto al usuario, no en cada pico de CPU. Alerta cuando el SLO esté en riesgo.
Post-mortems sin culpas para cualquier incidente visible para los clientes.
Una lista de toil. Anota las tareas manuales que siguen volviendo y automatiza una al mes.

Por ahora, deja de lado todo el aparato: políticas formales de presupuesto de errores en muchos servicios, personal de SRE dedicado y una planificación de capacidad elaborada. Retómalos cuando tengas varios equipos desplegando en el mismo entorno de producción y las disputas sobre confiabilidad empiecen a frenarte. Nuestros artículos sobre cómo escalar tu startup con DevOps y cuándo contratar un equipo de DevOps de tiempo completo cubren el lado de la contratación.

¿Y qué hay del AI SRE?

“AI SRE” suele describir software que usa modelos de lenguaje grandes y tus datos de observabilidad para investigar alertas: extrae logs, métricas y trazas, las correlaciona con los despliegues recientes y propone causas probables. Es una categoría real y útil. También es fácil venderla de más.

Lo que la IA hace bien hoy en operaciones:

Vigilar de forma continua y detectar patrones en más señales que un humano cansado a las 3 de la mañana.
Reunir contexto rápido: el despliegue reciente, las alertas relacionadas, el runbook, el último incidente parecido.
Redactar: líneas de tiempo, actualizaciones de estado, primeros borradores de post-mortems y resúmenes.
Enrutar: decidir quién debe ver una alerta y con qué urgencia.

Lo que no hace de forma confiable:

Encontrar causas raíz por sí sola. En un experimento de ClickHouse de agosto de 2025, cinco modelos de frontera investigaron fallos inyectados en una aplicación de demostración con acceso completo a la telemetría, y los autores concluyeron que el análisis autónomo de causa raíz “todavía no está listo”. Los modelos mejoran rápido, pero lo seguro sigue siendo tratar lo que encuentra la IA como una hipótesis.
Tomar decisiones de criterio. Hacer rollback, cambiar a otro sistema (failover) o avisar a los clientes de una caída implica contexto de negocio y responsabilidad que corresponden a una persona.
Reemplazar las prácticas. Un agente de IA sin SLO, runbooks y alertas limpias está investigando ruido.

El planteamiento honesto es que la IA asume buena parte de la vigilancia y del primer análisis, y las personas siguen tomando las decisiones y entregando las correcciones.

Preguntas frecuentes

¿Qué hace exactamente un ingeniero de confiabilidad de sitios?

Un ingeniero de confiabilidad de sitios opera sistemas de producción con ingeniería de software. En la práctica, eso significa definir SLI y SLO junto con los equipos de producto, usar presupuestos de errores para equilibrar funcionalidades y estabilidad, automatizar el toil hasta eliminarlo, cargar con la guardia y liderar la respuesta a incidentes y los post-mortems sin culpas. En Google, el trabajo operativo se limita a la mitad del tiempo de un SRE, para que el resto se dedique a ingeniería que haga el sistema más fácil de operar.

¿Qué es SRE frente a DevOps?

DevOps es un conjunto amplio de prácticas culturales y técnicas para lanzar software rápido y de forma segura como un solo equipo. SRE es una manera específica y con opiniones propias de implementar esas prácticas, construida alrededor de objetivos de confiabilidad y presupuestos de errores. El workbook de SRE de Google lo resume así: “la clase SRE implementa la interfaz DevOps”.

¿La IA está reemplazando a SRE?

Hoy no. Las herramientas de IA son buenas para vigilar señales de forma continua, reunir contexto, redactar líneas de tiempo y enrutar alertas, pero en el experimento de ClickHouse de 2025 los modelos de frontera todavía no pudieron encontrar causas raíz por sí solos. Decisiones como hacer rollback, cambiar a otro sistema (failover) o avisar a los clientes siguen necesitando a una persona, así que la IA cambia la carga de trabajo de SRE más de lo que elimina el rol.

Cómo lo aborda Webera

Esa división es la forma en que trabaja Webera. Webera es una suscripción de DevOps para equipos SaaS en AWS, operada por ingenieros senior que trabajan con nueve agentes de IA. Sentinel se encarga de la observabilidad, incluido el seguimiento de los SLO y de las tendencias de capacidad. Dispatcher diseña los turnos de guardia y enruta los incidentes según su gravedad. Conductor construye los pipelines de CI/CD y los procedimientos de rollback que van primero en la lista de arriba. Los agentes vigilan, enrutan y hacen el primer análisis las 24 horas; los ingenieros toman las decisiones.

Todos los planes incluyen monitoreo 24/7 y respuesta a incidentes, solicitudes ilimitadas y los nueve agentes. Pro cuesta US$4,999 al mes, Elite US$9,999 y Platform US$14,999, con un mínimo de tres meses y, después, mes a mes. Todo el código es tuyo.

Si quieres las bases de DevOps y las partes útiles de SRE sin armar un equipo para cada una, compara los planes. Y si lo que te quita el sueño son los costos, lee nuestra guía de optimización de costos de AWS.

Site Reliability Engineering vs. DevOps: ¿cuál necesita primero una startup SaaS?