Cómo cuidamos un producto después de lanzarlo: cinco hábitos para medir en producción

Una cabecera Server-Timing cuesta una línea y se lee en la pestaña Red del navegador. La nuestra dice cuánto tardó la lectura, cuántos días salieron de la caché, cuánto costó descomprimir, mapear, agregar y recolectar. Sin eso, habríamos optimizado la base de datos cuando el problema era un formateador de fechas.

Cada ejecución de una función serverless deja en CloudWatch una línea con duración, arranque y memoria máxima. Es la fuente que dice cuánto margen queda antes de que un pico de uso se note en la pantalla de alguien.

Añadimos al Server-Timing la memoria viva, la comprometida y el techo real del proceso. Con eso las decisiones sobre caché y concurrencia dejan de ser opiniones.

Un presupuesto de tiempo que arranca cuando empieza el trabajo pesado ignora el arranque en frío, las credenciales y la serialización. El reloj debe arrancar cuando entra la petición, y la respuesta parcial debe decir que lo es.

Una Lambda de 1024 MB tiene poco más de media CPU. Un bucle que en un portátil tarda un segundo allí tarda diez. Medimos localmente contra datos de producción para entender la memoria, pero las decisiones de CPU se tomaron con números de la función real.

Con esos cinco hábitos, la consola de operación de uno de nuestros clientes pasó a entregar un mes completo de métricas en seis segundos. Ninguno requiere herramientas nuevas: solo mirar lo que ya está ahí, todas las semanas.