A veces la vida ocupa todo tu tiempo.
No había escrito aquí desde enero.
No porque no hubiera nada que decir.
Tal vez era lo contrario.
Los últimos meses han estado llenos de pequeñas lecciones. No de esas que se convierten inmediatamente en una entrada de blog clara y ordenada, sino de las que poco a poco cambian la forma en que ves los sistemas, los equipos y el trabajo mismo.
Detalles de producción. Patrones de acceso. Permisos. Documentación. Sesiones de debugging. Pequeños riesgos operativos. Conversaciones con desarrolladores. El proceso silencioso de adaptarse a un nuevo país, a un nuevo entorno y a una forma distinta de trabajar.
Ninguna de esas cosas se sentía lo suficientemente grande por sí sola.
Pero juntas, me han estado enseñando algo.
El trabajo no se detuvo
Cuando empecé este blog, quería que fuera un lugar para escribir ideas prácticas sobre DevOps, plataformas y sistemas.
No teoría pulida.
No hype.
No “mejores prácticas” o “10 herramientas DevOps que debes usar” desconectadas de la realidad.
Quería escribir sobre el tipo de trabajo que ocurre cuando los sistemas necesitan seguir funcionando, cuando los equipos necesitan un camino más seguro y cuando las decisiones técnicas tienen que sobrevivir el contacto con personas reales, no solo verse bien en diagramas.
Luego, por un tiempo, dejé de escribir.
Pero el trabajo no se detuvo.
Hubo pequeñas fallas que entender. Hubo patrones de acceso que cuestionar. Hubo permisos que parecían simples hasta que tuvieron que operarse. Módulos de Terraform donde la respuesta técnicamente correcta no era automáticamente la más útil.
Y hubo muchos momentos en los que la pregunta importante no era:
¿Podemos hacer esto?
Sino:
¿Deberíamos hacerlo de esta manera?
Esa pregunta me ha estado siguiendo mucho últimamente.
Las mismas herramientas, una atención diferente
Mudarnos de México a Tokio no cambió las herramientas que uso.
AWS sigue siendo AWS. Terraform sigue siendo Terraform. Kubernetes todavía encuentra formas creativas de recordarte que YAML no es la parte difícil. CI/CD todavía necesita cuidado. Producción todavía no perdona las suposiciones.
Las herramientas son familiares.
Pero el entorno alrededor del trabajo se siente diferente.
He empezado a poner más atención en la preparación. En la comunicación. En el costo de una propiedad poco clara. En cuánta presión pone un sistema sobre las personas que tienen que operarlo.
Y últimamente, una pregunta ha estado apareciendo con más frecuencia:
¿Cuánto cuesta realmente esta solución?
A veces solo miramos la factura de AWS.
Pero el costo de infraestructura no es el único costo.
El tiempo de ingeniería también es un costo. La carga cognitiva es un costo. Esperar por acceso es un costo.
Por ejemplo, habilitar una herramienta como RDS Query Editor podría requerir una instancia más grande de lo que la base de datos estrictamente necesita. En papel, eso puede parecer un desperdicio.
Pero si ese costo extra permite que varios ingenieros inspeccionen datos relevantes de forma segura, depuren más rápido y eviten construir workarounds incómodos, el trade-off deja de ser tan obvio.
Unos cuantos centavos por hora pueden ser más baratos que varias horas de tiempo de ingeniería.
No todos los costos aparecen en la factura de la nube, aunque ese suele ser el costo más visible en los reportes.
A veces la diferencia no está en el diagrama de arquitectura.
Está en las preguntas que las personas hacen antes de hacer un cambio.
¿Quién necesita saberlo? ¿Qué podría verse afectado? ¿Cómo nos recuperamos? ¿Esto será suficientemente seguro para operarlo después? ¿Estamos haciendo esto más fácil para la siguiente persona, o solo estamos resolviendo la petición inmediata?
Esas preguntas son fáciles de saltar cuando el objetivo es únicamente terminar la tarea u optimizar la métrica más visible.
Pero no deberían ignorarse cuando empiezas a pensar en el sistema como algo con lo que las personas tienen que vivir.
Las pequeñas lecciones se acumulan
Mucho del crecimiento en ingeniería no llega como una gran lección.
Llega en silencio.
Notas que una excepción temporal se está convirtiendo en infraestructura permanente.
Notas que un permiso no es solo una configuración de seguridad, sino también una responsabilidad operativa.
Notas que un proceso manual no solo es molesto, sino un lugar donde el conocimiento puede desaparecer.
Notas que la documentación no es solo para onboarding. También es una forma de reducir incertidumbre.
Notas que una plataforma no solo entrega herramientas. También le enseña a las personas cuál es el camino normal.
Y a veces, notas que la tarea que te pidieron no es lo mismo que el problema que el equipo realmente necesita resolver.
Al inicio de tu carrera, hacer bien la tarea importa mucho.
Recibes una petición. La implementas. La pruebas. La cierras.
Eso construye confianza.
Pero en algún punto, el trabajo empieza a cambiar.
El valor ya no está solamente en completar la tarea. Está en entender por qué existe esa tarea, qué riesgo intenta reducir y si la forma actual de la solución tiene sentido.
Ese cambio es incómodo.
Requiere hacer más preguntas. Requiere comunicar antes. Requiere estar dispuesto a decir: “Creo que aquí hay un problema diferente.”
No de una forma dramática.
Solo con el suficiente cuidado para mejorar el trabajo.
El trabajo silencioso importa
Hay trabajo que es fácil de mostrar.
Un pull request mergeado. Un servicio desplegado. Un dashboard. Una nueva automatización. Una migración completada exitosamente.
Otro trabajo es más silencioso.
Hacer que una decisión sea más fácil de entender. Eliminar una suposición riesgosa. Escribir la razón detrás de un patrón. Mejorar el camino que todos los demás usan. Hacer una pregunta antes de que la solución incorrecta se vuelva costosa.
Este tipo de trabajo no siempre se siente productivo en el momento.
Pero los sistemas son moldeados por él.
Los equipos también.
Ahí es donde vive mucho de DevOps.
No solo en las herramientas.
En la forma en que reducimos incertidumbre.
Volver poco a poco
No quiero que este blog se convierta en un lugar donde solo escribo cuando tengo una idea perfectamente pulida.
Los sistemas no se aprenden así.
La mayoría de las lecciones llegan a medio formar: en sesiones de debugging, pequeños incidentes, revisiones, preguntas incómodas y conversaciones que te hacen darte cuenta de que la tarea original no era el verdadero problema.
He estado callado aquí, pero no he estado lejos del trabajo.
Y creo que las próximas publicaciones vendrán desde ese lugar: sistemas reales, restricciones reales y el proceso lento de aprender a apropiarse mejor de los problemas.
Las tareas son donde empieza el trabajo.
Los problemas son donde empieza el ownership.