Seis principios, cada uno con ejemplos de proyectos distintos. Ninguno es sobre tecnología: todos son sobre qué hacer cuando hay que elegir y nadie te va a decir si elegiste bien hasta que se rompa algo.
01
Una alerta que se ignora es peor que no tener alerta
En la empresa lo aprendí a la fuerza: vi equipos que dejaron de mirar el canal de alertas porque nueve de cada diez eran ruido. Cuando todo grita, no grita nada. Cuando armamos el monitoreo con Zabbix y Grafana, la mitad del trabajo no fue instalar nada — fue discutir qué merecía despertar a alguien.
En mi monitor de red apliqué la misma regla: una PC apagada se muestra como APAGADA, no como falla. No dispara alarma. Sería avisarte de que te fuiste a dormir. Y las alarmas de CPU, RAM y disco piden confirmación en varias muestras antes de sonar, porque un pico de tres segundos no es un incidente.
02
Prefiero que no arranque a que arranque mal
En TrincherFIN, las migraciones tienen contrato de esquema: una cadena SQL inmutable con checksums SHA-256, y la API no levanta si la base está atrasada, adelantada o con drift estructural. Un servicio caído se nota en un minuto; una base corrompiéndose en silencio se nota tres meses después, cuando ya no hay backup limpio.
La ingesta de correo va por el mismo camino: no confía en el filtro de IMAP, exige el remitente exacto y un DMARC alineado antes de interpretar un mail. Cualquiera puede mandarte un correo que diga que gastaste cincuenta mil pesos.
03
Decir que algo falla es fácil. Decir de quién es la culpa es el trabajo.
En las llamadas de incidente la pregunta nunca era "¿está caído?" — eso ya lo sabía todo el mundo. Era: ¿de quién es, a quién escalo, y con qué evidencia. Eso es root cause analysis antes de que suene a metodología.
En la plataforma de atención lo resolví con logs estructurados en JSON: se puede reconstruir el ciclo de vida completo de un mensaje sin reproducir el caso. En el monitor de red, con un diagnóstico que compara tres tramos y contesta casa, lan o isp con el número que lo justifica, en vez de un "hay un problema".
04
Nada irreversible pasa sin que alguien diga que sí
En la plataforma de atención, cualquier error del agente de IA deriva a un humano: el sistema nunca deja a la persona del otro lado sin respuesta. Y cada llamada al modelo registra tokens y costo estimado en dólares, porque una factura de API que sorprende a fin de mes es un incidente igual que una caída.
En el PC Optimizer la misma idea, sin IA de por medio: nada se ejecuta ni se selecciona solo, cada elemento muestra su nivel de riesgo con explicación, se arma un plan que hay que aprobar, se crea punto de restauración y queda registro de todo. Lo que es reversible se puede volver atrás desde la propia app; lo que no lo es te lo dice antes, no después.
Un sistema que puede romperte algo tiene que pedirte permiso primero. Vale igual para un agente que contesta un WhatsApp que para un botón que desinstala programas.
05
Un número sin referencia no dice nada
En la empresa, recién cuando implementé Odoo desde cero pudimos medir SLA con datos en vez de con impresiones. Antes se discutía si el equipo respondía rápido; después se sabía.
En el monitor de red pasa algo parecido: corre sobre una Raspberry Pi 3, donde la placa cuelga del bus USB 2.0 y techa cerca de 94 Mbps. Con un plan de 300, el número mide la Pi y no tu línea. Así que el veredicto se calcula contra min(plan contratado, techo del hardware) y el tablero avisa cuándo está midiendo sus propias limitaciones. Es más trabajo que mostrar el número pelado; también es la diferencia entre una herramienta y un adorno.
06
El deploy tiene que poder salir mal
En TrincherFIN, cada push corre los tests de backend y frontend, más una auditoría de dependencias y la validación del compose. Si eso no pasa, no se mergea.
En el monitor de red, el script de deploy respalda config y bases con fecha, fusiona las claves nuevas sin pisar mis valores, reinicia, verifica los endpoints y avisa por Telegram, guardando los últimos diez respaldos. Y si falla el chequeo de SSH, el mensaje distingue el motivo real —equipo apagado, sshd caído, huella cambiada, falta la clave— y da el comando exacto para cada caso. Porque el que lee ese error a las tres de la mañana probablemente sea yo, y a esa hora no quiero ponerme a adivinar.
