Ocho principios no negociables. No son "buenas prácticas": son la línea por debajo de la cual no firmamos un proyecto. Si tu equipo coincide, vamos a entendernos rápido.
Cada componente productivo asume que sus dependencias pueden caerse. Reintentos con backoff, circuit breakers, timeouts explícitos, cuotas y aislamiento de blast-radius son parte del diseño, no del troubleshooting. La pregunta nunca es ¿se va a romper?, es ¿qué pasa cuando se rompe?
Logs estructurados, métricas con etiquetas, trazas distribuidas y health checks son parte del MVP, no del backlog. Si un sistema entra a producción sin un dashboard que lo describa y alertas que despierten al on-call, no entró a producción: se filtró.
Si un cluster, una VM, una zona DNS, un secret o una regla de firewall no está descrito en un repo de Git, no existe oficialmente. Los cambios manuales en la consola del cloud son la peor deuda técnica posible: invisible y sin autor.
CI/CD desde el primer commit, deploys pequeños y frecuentes, trunk-based development y feature flags para desacoplar deploy de release. Si subir a producción genera ansiedad en el equipo, el problema es el pipeline, no la gente.
RPO y RTO se acuerdan antes del go-live, no después del incidente. Toda DB productiva tiene réplica, los backups se restauran periódicamente en un entorno aparte y las migraciones de esquema son siempre hacia adelante. Un backup que nunca se restauró no es un backup, es una creencia.
Secrets en vault (nunca en el repo), principio de menor privilegio en cada rol y cuenta de servicio, dependencias escaneadas en el pipeline, TLS también para tráfico interno, e identidades federadas en lugar de credenciales estáticas. El cumplimiento se construye desde el primer endpoint.
Adoptamos versiones LTS apenas se estabilizan y no acumulamos deuda de runtime. Pero en la pila crítica — base de datos, mensajería, runtime base, sistema operativo — elegimos aburrido y probado antes que nuevo y prometedor. La innovación va arriba; la base se mantiene previsible.
Cuando algo falla en producción, atacamos el proceso y la arquitectura, nunca a la persona. Cada incidente productivo genera un postmortem dentro de los 5 días hábiles y un runbook que deja el problema resuelto para la próxima guardia. Lo que aprendemos vuelve al diseño; lo que no documentamos lo vamos a repetir.
Si estos principios describen cómo te gustaría que se trabaje, hablemos.
Empezar conversación