29 sept 2025·8 min
«You Build It, You Run It» de Werner Vogels, explicado
Aprende qué quiso decir Werner Vogels con “Tú lo construyes, tú lo operas” y cómo aplicarlo: propiedad, on-call, SLOs, respuesta a incidentes y despliegues más seguros.
Aprende qué quiso decir Werner Vogels con “Tú lo construyes, tú lo operas” y cómo aplicarlo: propiedad, on-call, SLOs, respuesta a incidentes y despliegues más seguros.
“Tú lo construyes, tú lo operas” es una de esas frases que se quedan porque es directa. No se trata de pósters motivacionales ni de “ser más DevOps”. Es una afirmación clara sobre la responsabilidad: el equipo que entrega un servicio también sigue siendo responsable de cómo se comporta ese servicio en producción.
En la práctica, esto significa que el mismo equipo de producto que diseña funcionalidades y escribe código también:
No quiere decir que todo el mundo se convierta en un experto en infraestructura de la noche a la mañana. Significa que el ciclo de retroalimentación es real: si publicas algo que aumenta las caídas, el ruido de pagers o el dolor del cliente, tu equipo lo nota directamente y aprende rápido.
Esta filosofía es fácil de repetir y difícil de implementar a menos que la trates como un modelo operativo con expectativas explícitas. “Operarlo” suele incluir estar on-call (de alguna forma), poseer la respuesta a incidentes, escribir runbooks, mantener dashboards y mejorar continuamente el servicio.
También implica restricciones: no puedes pedir a los equipos que “operenen” sin darles las herramientas, el acceso y la autoridad para arreglar problemas, además del tiempo en su hoja de ruta para hacer ese trabajo.
Antes de “Tú lo construyes, tú lo operas”, muchas empresas organizaban el trabajo de software como una carrera de relevos: los desarrolladores escribían código y luego lo “lanzaban por encima del muro” a un equipo de operaciones que lo desplegaba y mantenía.
Ese traspaso resolvía un problema a corto plazo—tenías a alguien con experiencia vigilando producción—pero creaba problemas más grandes.
Cuando un equipo de ops separado posee producción, los desarrolladores suelen enterarse de los problemas tarde (o nunca). Un bug puede aparecer como un ticket vago días después: “el servicio está lento” o “CPU alta”. Para entonces falta contexto, los logs se han rotado y la gente que hizo el cambio ya pasó a otra cosa.
Los traspasos también difuminan la propiedad. Si ocurre una caída, dev puede asumir “ops lo atrapará” y ops asume “dev lanzó algo arriesgado”. El resultado es predecible: resolución de incidentes más larga, modos de fallo repetidos y una cultura donde los equipos optimizan localmente en vez de por la experiencia del cliente.
“Tú lo construyes, tú lo operas” estrecha el ciclo. El mismo equipo que lanza un cambio es responsable de su comportamiento en producción. Eso empuja mejoras prácticas aguas arriba: alertas más claras, despliegues más seguros, mejores dashboards y código más fácil de operar.
Paradójicamente, a menudo conduce a entregas más rápidas. Cuando los equipos confían en su proceso de release y entienden el comportamiento en producción, pueden publicar cambios más pequeños con más frecuencia—reduciendo el radio de impacto de errores y facilitando el diagnóstico.
No todas las organizaciones empiezan con el mismo personal, requisitos de cumplimiento o sistemas heredados. La filosofía es una dirección, no un interruptor. Muchos equipos la adoptan gradualmente—comenzando con on-call compartido, mejor observabilidad y límites de servicio más claros—antes de asumir la propiedad de extremo a extremo.
Werner Vogels, CTO de Amazon, popularizó la frase “You build it, you run it” al describir cómo Amazon (y después AWS) quería que los equipos pensaran sobre el software: no como un proyecto que se entrega, sino como un servicio que se opera.
El cambio clave fue tanto psicológico como técnico. Cuando un equipo sabe que le van a avisar por fallos, las decisiones de diseño cambian. Te importa tener valores por defecto sensatos, alertas claras, degradación elegante y caminos de despliegue que puedas revertir. En otras palabras, construir incluye planear para las partes desordenadas de la vida real.
La mentalidad de servicios en la era AWS hizo que la fiabilidad y la velocidad sean no negociables. Los clientes de la nube esperan APIs disponibles las 24 horas y mejoras continuas—no oleadas de “grandes releases” cada trimestre.
Esa presión alentó:
Esta filosofía se solapa con el movimiento DevOps: cerrar la brecha entre “dev” y “ops”, reducir traspasos y hacer que los resultados (disponibilidad, latencia, carga de soporte) sean parte del bucle de desarrollo. También encaja con la idea de equipos pequeños y autónomos que pueden entregar de forma independiente.
Es tentador tratar el enfoque de Amazon como un template a copiar. Pero “Tú lo construyes, tú lo operas” es más una dirección que un organigrama estricto. El tamaño de tu equipo, las restricciones regulatorias, la madurez del producto y los requisitos de disponibilidad pueden requerir adaptaciones—rotaciones on-call compartidas, soporte de plataforma o adopción por fases.
Si quieres una forma práctica de traducir la mentalidad a la acción, ve a /blog/how-to-adopt-you-build-it-you-run-it-step-by-step.
“Tú lo construyes, tú lo operas” es, en esencia, una declaración sobre propiedad. Si tu equipo entrega un servicio, tu equipo es responsable de cómo se comporta en el mundo real—no solo de si pasa pruebas el día del release.
Operar un servicio significa preocuparse por resultados de extremo a extremo:
En una semana normal, “operarlo” tiene menos que ver con heroísmos y más con operaciones rutinarias:
Este modelo solo funciona cuando responsabilidad significa “nosotros arreglamos esto”, no “buscamos a alguien a quien castigar”. Cuando algo falla, el objetivo es entender qué en el sistema lo permitió—alertas faltantes, límites poco claros, despliegues arriesgados—y mejorar esas condiciones.
La propiedad se complica cuando los servicios son difusos. Define límites de servicio (qué hace, de qué depende, qué promete) y asigna un equipo propietario nombrado. Esa claridad reduce traspasos, acelera la respuesta a incidentes y hace obvias las prioridades cuando compiten fiabilidad y nuevas funcionalidades.
El on-call es central para “Tú lo construyes, tú lo operas” porque cierra el ciclo de retroalimentación. Cuando el mismo equipo que publica un cambio también siente el impacto operacional (picos de latencia, despliegues fallidos, quejas de clientes), las prioridades se aclaran: el trabajo de fiabilidad deja de ser “problema de otro” y la forma más rápida de entregar más a menudo suele ser calmar el sistema.
Un on-call sano se basa en predictibilidad y apoyo.
Define niveles de severidad para que el sistema no alerte por cada imperfección.
Una regla simple: si despertar a alguien no cambia el desenlace, que sea un ticket, no una página.
On-call no es castigo; es una señal. Cada alerta ruidosa, fallo repetido o arreglo manual debe retroalimentar trabajo de ingeniería: mejores alertas, automatización, despliegues más seguros y cambios del sistema que eliminen la necesidad de alertar.
Si “lo operas” es real, los equipos necesitan una forma compartida de hablar de fiabilidad sin que cada discusión se vuelva una opinión. Eso es lo que ofrecen SLIs, SLOs y presupuestos de error: objetivos claros y un comercio justo entre moverse rápido y mantener la estabilidad.
Una forma útil de recordarlo: SLI = métrica, SLO = objetivo, SLA = compromiso externo.
Buenos SLIs son específicos y están ligados a la experiencia de usuario, como:
Un presupuesto de error es la cantidad de “malo” que puedes permitirte mientras sigues cumpliendo el SLO (por ejemplo, si tu SLO es 99.9% de disponibilidad, tu presupuesto mensual es 0.1% de tiempo de inactividad).
Cuando el servicio está sano y estás dentro del presupuesto, los equipos pueden asumir más riesgo de entrega (lanzar features, experimentar). Cuando estás quemando el presupuesto demasiado rápido, el trabajo de fiabilidad pasa a primer plano.
Los SLOs convierten la fiabilidad en un insumo de planificación. Si tu presupuesto es bajo, el siguiente sprint podría priorizar limitación de tasa, despliegues más seguros o arreglar dependencias inestables—porque fallar el SLO tiene un coste claro. Si el presupuesto es amplio, puedes priorizar trabajo de producto con confianza.
“Tú lo construyes, tú lo operas” solo funciona si desplegar a producción es rutinario, no un evento de alto riesgo. El objetivo es reducir la incertidumbre antes del lanzamiento y limitar el radio de impacto después.
Antes de considerar un servicio “listo”, los equipos suelen necesitar unos básicos operativos:
En lugar de lanzar todo a todos a la vez, la entrega progresiva limita el impacto:
Si tu equipo estandariza el rollback, trátalo como una capacidad de primera clase: cuanto más rápido puedas revertir con seguridad, más realista es “tú lo operas”.
Dos pruebas reducen las "incógnitas desconocidas":
Mantenlo ligero: una página en tu repo o template de ticket (por ejemplo, “Observabilidad,” “Preparación on-call,” “Protección de datos,” “Plan de rollback,” “Capacidad probada,” “Runbooks vinculados”). Considera “no listo” como un estado normal—mucho mejor que aprender en producción.
Los incidentes son donde “tú lo operas” se vuelve real: un servicio se degrada, los clientes lo notan y el equipo debe responder rápida y claramente. El objetivo no es el heroísmo sino un flujo repetible que reduzca el impacto y genere mejoras.
La mayoría de equipos convergen en las mismas fases:
Si quieres una plantilla práctica para este flujo, mantén una checklist ligera a mano (ver /blog/incident-response-checklist).
Un postmortem sin culpas no significa “nadie cometió errores”. Significa que te centras en cómo el sistema y el proceso permitieron que el error llegara a producción, no en avergonzar a individuos. Eso hace que la gente comparta detalles pronto, esencial para aprender.
Documenta:
Los buenos postmortems terminan con seguimientos concretos y asignados, típicamente en cuatro áreas: mejoras de herramientas (alertas/dashboard), pruebas (regresiones y casos límite), automatización (deploy/rollback más seguros, guardrails) y documentación (runbooks, pasos operativos claros). Asigna un responsable y una fecha límite—si no, el aprendizaje queda teórico.
Las herramientas son la palanca que hace sostenible “Tú lo construyes, tú lo operas”—pero no pueden sustituir la verdadera propiedad. Si un equipo trata las operaciones como “problema de otro”, el dashboard más sofisticado solo documentará el caos. Buenas herramientas reducen fricción: hacen que lo correcto (observar, responder, aprender) sea más fácil que lo incorrecto (adivinar, culpar, ignorar).
Como mínimo, los propietarios de servicio necesitan una forma consistente de ver qué hace su software en producción y actuar rápido cuando no lo hace.
Si tu historia de monitorización está fragmentada, los equipos pasan más tiempo buscando que arreglando. Un enfoque unificado de observabilidad ayuda; ver /product/observability.
A medida que la organización crece, “¿quién es el dueño de esto?” se vuelve un riesgo de fiabilidad. Un catálogo de servicios (o portal interno de desarrolladores) resuelve esto manteniendo la propiedad y el contexto operacional en un solo lugar: nombre del equipo, rotación on-call, ruta de escalado, runbooks, dependencias y enlaces a dashboards.
La clave es metadatos de propiedad que se mantengan actualizados. Hazlo parte del flujo: los nuevos servicios no pueden ir a producción sin un propietario y los cambios de propiedad se tratan como cambios de código (revisados, rastreados).
Los mejores montajes empujan a los equipos hacia conductas saludables: plantillas para runbooks, alertas automatizadas ligadas a SLOs y dashboards que respondan en segundos “¿están los usuarios afectados?”. Pero el sistema humano sigue importando—los equipos necesitan tiempo para mantener estas herramientas, podar alertas y mejorar continuamente cómo operan el servicio.
Los equipos de plataforma facilitan que “Tú lo construyes, tú lo operas” sea viable. Su trabajo no es ejecutar producción para todos: es proporcionar un camino bien iluminado (a veces llamado “paved roads”) para que los equipos de producto posean servicios sin reinventar operaciones cada sprint.
Una buena plataforma ofrece valores por defecto que son difíciles de estropear y fáciles de adoptar:
Los guardrails deben prevenir conductas riesgosas sin bloquear el despliegue. Piensa en “seguro por defecto” en lugar de “abre un ticket y espera”.
Los equipos de plataforma pueden ejecutar servicios compartidos—sin asumir la propiedad de los servicios de producto.
El límite es simple: el equipo de plataforma posee el uptime y soporte de la plataforma; los equipos de producto poseen cómo su servicio la utiliza.
Cuando los equipos no tienen que dominar CI/CD, auth o secretos desde el día uno, pueden centrarse en el comportamiento del servicio y el impacto en el usuario.
Ejemplos que eliminan trabajo repetitivo:
El resultado es entrega más rápida con menos “operaciones-custom” mientras se mantiene la promesa central: el equipo que construye el servicio sigue corriendo con él.
“Tú lo construyes, tú lo operas” puede mejorar fiabilidad y velocidad—pero solo si la organización cambia las condiciones alrededor del equipo. Muchos fracasos parecen adoptar el eslogan, pero no las prácticas de soporte.
Unos cuantos patrones aparecen una y otra vez:
Algunos entornos requieren un enfoque a medida:
Esta filosofía fracasa más rápido cuando el trabajo de fiabilidad se trata como “extra”. El liderazgo debe reservar explícitamente capacidad para:
Sin esa protección, el on-call se convierte en un impuesto—en lugar de un ciclo de retroalimentación que mejora el sistema.
Desplegar esto funciona mejor como un cambio por fases, no como un anuncio a toda la compañía. Empieza pequeño, haz visible la propiedad y luego expande.
Elige un servicio único y bien acotado (idealmente con usuarios claros y riesgo manejable).
Define:
La clave: el equipo que publica cambios también es dueño de los resultados operativos de ese servicio.
Antes de expandir a más servicios, asegúrate de que el equipo piloto puede operar sin heroísmos:
Usa un pequeño set de indicadores que muestren si la propiedad está mejorando la entrega y la estabilidad:
Si adoptas “tú lo construyes, tú lo operas” mientras intentas acelerar la entrega, el cuello de botella suele ser el mismo: pasar de idea → servicio listo para producción con propiedad clara y una historia de rollback segura.
Koder.ai es una plataforma vibe-coding que ayuda a los equipos a construir apps web, backend y móviles mediante una interfaz de chat (React en web, Go + PostgreSQL en backend, Flutter en móvil). Para equipos que abrazan la propiedad del servicio, algunas características encajan bien con el modelo operativo:
Elige tu servicio piloto esta semana y agenda una reunión de kickoff de 60 minutos para fijar el primer SLO, rotación on-call y responsables de runbook. Si evalúas herramientas para apoyar esto (despliegue, rollback y flujos alrededor de la propiedad), consulta /pricing para las opciones gratuitas, pro, business y enterprise de Koder.ai—más opciones como hosting, despliegue y dominios personalizados.
Significa que el equipo que diseña, construye y despliega un servicio también es responsable de lo que ocurre después de que esté en producción: monitorización, respuesta on-call, seguimientos tras incidentes y mejoras de fiabilidad.
Es un modelo de responsabilidad (propiedad clara), no una elección de herramienta ni un cambio de título laboral.
No implica que cada ingeniero deba convertirse en un especialista en operaciones a tiempo completo.
Significa:
Con un equipo de operaciones separado, la retroalimentación llega tarde y la responsabilidad se difumina: los desarrolladores pueden no notar el impacto en producción y ops puede no tener contexto sobre cambios recientes.
La propiedad de extremo a extremo suele mejorar:
“Run it” normalmente incluye:
Empieza con valores humanos:
Un buen sistema de on-call pretende reducir los avisos el mes siguiente, no normalizar los héroes.
Usa una regla simple: si despertar a alguien no cambia el desenlace, que sea un ticket.
En la práctica:
Crean objetivos medibles y compartidos:
Cuando el presupuesto se consume rápido, prioriza fiabilidad; cuando sobra, puedes asumir más riesgo en entrega.
Adopta prácticas de release que reduzcan la incertidumbre y el blast radius:
Opera incidentes con un flujo repetible:
Luego escribe postmortems sin buscar culpables, centrados en huecos del sistema y del proceso, con seguimientos que sean:
Una checklist ligera como /blog/incident-response-checklist ayuda a estandarizar el flujo.
Un equipo de plataforma debe ofrecer caminos pavimentados (plantillas, CI/CD, guardrails, servicios compartidos) mientras los equipos de producto mantienen la propiedad de los resultados de sus servicios.
Un límite práctico: