El disco tardó tres semanas en llenarse y nadie lo vio

Son las once y veinte de la mañana. Alguien de facturación se levanta de su lugar, camina hasta el área de sistemas y dice que el sistema no responde. Para cuando alguien empieza a revisar en serio, la operación lleva cuarenta minutos detenida y nadie sabe con precisión desde qué hora.

Lo grave de esa escena no es la caída. Las caídas van a ocurrir. Lo grave es el orden en que se enteró.

Enterarse por el usuario cuesta tres cosas

La primera es tiempo. Entre que el sistema falló y que alguien se armó de valor para reportarlo pasan minutos que nadie contabiliza. El usuario primero cierra y vuelve a abrir. Luego le pregunta a su compañera si a ella también le pasa. Luego lo comenta en el pasillo. La caída empezó mucho antes del reporte.

La segunda es evidencia. Cuando la falla se descubre en caliente, nadie sabe qué estaba pasando cinco minutos antes. Se pregunta qué cambió, nadie se acuerda, y se termina reiniciando el servidor porque es lo único que se puede hacer con la información disponible. El reinicio resuelve el síntoma y borra la evidencia. La misma falla regresa en dos semanas y el diagnóstico empieza otra vez de cero.

La tercera es más cara y no aparece en ninguna bitácora: su gente aprendió que la manera de reportar una falla es caminar. Y aprendió, también, que el área de sistemas se entera al mismo tiempo que ellos.

Las fallas ruidosas son la minoría

Casi todo lo que me llaman a atender de urgencia llevaba semanas avisando en voz baja.

Un disco que se llena. El primer lunes del mes quedaba cuarenta por ciento libre. A la tercera semana, doce. El día que la operación se detuvo, esa falla llevaba tres semanas anunciándose y era visible desde el primer día. Nadie la vio porque nadie estaba mirando el espacio libre como una línea que baja, sino como una foto que se consulta cuando ya hubo problema.

Un respaldo que dejó de correr. Nadie revisa un respaldo que nunca ha fallado de forma ruidosa. Deja de completarse y no pasa absolutamente nada: no hay mensaje, no hay usuario afectado, no hay síntoma. Pasa algo el día que hace falta restaurar, y ese día ya no hay nada que negociar. En la nota sobre SQL Express mencioné que esa edición no trae agente de tareas, así que los respaldos suelen depender de guiones sueltos que alguien armó hace años y que nadie volvió a tocar. Dejan de funcionar en silencio.

Un servicio que se reinicia solo cada noche. El servidor lleva ciento ochenta días encendido y todo el mundo lo lee como buena salud. El servicio que de verdad importa lleva nueve horas de vida, porque se cae de madrugada y vuelve solo. Nadie mira el tiempo de vida del servicio; solo el del servidor.

Ninguna de las tres produce un mensaje de error. Las tres eran medibles desde el primer día.

Lo que queda pendiente después de una calibración

En la primera nota escribí que nadie reprograma sin dinamómetro: se mide antes, se ajusta y se vuelve a medir contra la misma línea base. Ahí quedó una pregunta sin responder.

¿Y después?

Una corrida de dinamómetro dura minutos. Su operación dura años. Que el ajuste haya funcionado en la medición de agosto no prueba que siga funcionando en marzo, con dos empresas nuevas, el doble de pólizas y tres integraciones que antes no existían.

Sin medición continua, cada mejora se convierte en una discusión de percepciones. «¿Se siente más rápido?» es la peor pregunta de una junta, porque la respuesta depende del humor del día y de quién la contesta. Si el usuario que más se quejaba estaba de vacaciones esa semana, el sistema mejoró.

Esto también es una forma de protegerlo a usted de mí. Un consultor que le cambia la configuración y no le deja una línea medible antes y después le está pidiendo que le crea. Con historial continuo, «sirvió» deja de ser una opinión y se vuelve un compromiso que usted me puede cobrar.

La herramienta es la parte fácil

Para esto uso Zabbix. El historial queda en un servidor suyo y el costo no crece por cada equipo ni por cada usuario. Si un día decide trabajar con alguien más, el monitoreo sigue corriendo sin mí.

Instalarlo es lo de menos. El trabajo está en decidir qué se mide y qué amerita despertar a alguien a las tres de la mañana.

Qué conviene medir, y por qué

Tendencias, no fotos. El espacio libre no dice nada como número suelto; lo dice todo como pendiente. La pregunta no es «cuánto queda», sino «cuándo se acaba al ritmo de las últimas dos semanas». Eso convierte una emergencia de viernes en una compra planeada.

El resultado del respaldo, no su existencia. Que la tarea haya arrancado no significa que el archivo sirva. Vigilo su peso, su antigüedad y la fecha de la última restauración de prueba. Un respaldo que nunca se ha restaurado es una suposición.

Lo que el motor de base de datos está esperando. El procesador y la memoria pueden verse tranquilos mientras las consultas se forman esperando al almacenamiento. Ese número anticipa las quejas de lentitud y es el mismo que sirve para medir antes y después de una calibración.

Un latido del proceso de negocio. Que la interfaz de CONTPAQi haya dejado registro en la última hora. Que el timbrado conteste. Un servidor puede verse impecable en todos sus indicadores mientras el negocio está detenido.

Y encima de todo, la marca de cada cambio: después de una falla, la única pregunta que importa es qué cambió.

Una alerta que se ignora es peor que ninguna

Un sistema con la configuración de fábrica manda avisos por todo. A la tercera semana alguien crea una regla en el correo y los manda a una carpeta. Desde ese día sigue costando y ya no sirve: el aviso que sí importaba va a caer ahí, junto a los otros cuatrocientos.

Por eso trabajo con tres reglas que no negocio:

1. Toda alerta tiene un dueño con nombre. La que llega a una cuenta genérica no le llega a nadie.
2. Toda alerta implica una acción. Si al recibirla no hay nada que hacer distinto, es un dato de tablero, no una alerta.
3. Una falla, un aviso. Si se cae el enlace no deben llegar cuarenta correos. Eso obliga a declarar qué depende de qué: análisis, no instalación.

Y arranco con pocas: seis que de verdad importen; la séptima llega el día que una falla la pida.

Lo que Zabbix no hace

No es bonito de fábrica: las pantallas de las demostraciones son trabajo posterior que se paga en horas. Es un servidor más que cuidar, con su propia base de datos y su propio disco, que también se llena; hay que resolver quién vigila al vigilante.

Y la curva no está en instalarlo, sino en definir qué es normal en su operación. Un umbral puesto el primer día es una adivinanza con apariencia de dato. Le va a decir qué falló y cuándo empezó; el porqué sigue siendo trabajo humano.

Cuándo no le hace falta esto

Si tiene un servidor, cinco usuarios y puede tolerar medio día detenido sin que le cueste dinero real, no monte nada de esto. Revise el respaldo una vez por semana y siga con lo suyo.

Si nadie va a atender un aviso de madrugada, tampoco. Primero se acuerda quién contesta y con qué facultades; herramienta sin dueño solo genera correos. Ese acuerdo no cuesta dinero y es la mitad del beneficio.

Y si el sistema está lento todo el día, todos los días, eso ya lo sabe. Ahí toca medir y calibrar el motor, no vigilarlo.

Cómo empieza

Con dos semanas de observación en silencio, sin una sola alerta encendida.

Al terminar se sabe qué es normal en su casa, qué llevaba meses funcionando mal y qué tan cerca está el disco de acabarse. Con eso defino pocas alertas, cada una con dueño y con acción, y el sistema queda como dinamómetro permanente.

La siguiente caída va a ocurrir de todos modos. Lo único que se decide hoy es quién se entera primero.