Un cliente abre un ticket tres días después de tu última entrada a su servidor: “Algo cambió en nuestra caja. ¿Tu equipo tocó el config de correo el martes?”
Probablemente no. O sí, por un motivo distinto, y está todo bien. En cualquier caso ahora estás en la peor clase de conversación: una donde la respuesta honesta es “déjame revisar” y el único lugar donde revisar es tu propia memoria. Tú afirmas; ellos deciden si creerte. En una máquina que no es tuya, con un root que ellos te concedieron, “confía en mí” es una mano débil.
Lo que convierte esa conversación de defensiva a trivial no es más confianza. Es un registro — y en una flota de servidores que administras para otras personas, ese registro tiene que existir antes de la pregunta, no armarse después.
La asimetría que nadie menciona en la llamada de ventas
Administrar servidores para clientes es una posición de confianza disfrazada de técnica. Tienes root sobre infraestructura que hace correr su negocio. No pueden mirar sobre tu hombro, ni deberían tener que hacerlo. Lo que se les debe a cambio es poder preguntar, en cualquier momento, qué pasó en nuestro servidor — y obtener una respuesta directa y verificable.
La mayoría de los montajes no pueden dársela. SSH no deja nada atrás (una sesión de shell se olvida de sí misma en cuanto se cierra), el historial del shell es por usuario y editable, y “nuestro proceso es que somos cuidadosos” no es evidencia. Así que la respuesta queda en tu palabra. Eso funciona hasta la única vez que no — un incidente, una disputa, una auditoría —, que es exactamente cuando tu palabra vale menos.
Lo que de verdad puedes entregarles
En CentralHost, cada terminal de operador abierto contra un servidor se graba a través del plano de control. Así que cuando llega la pregunta, no reconstruyes nada: lo lees.
La vista de auditoría de su servidor lista cada sesión: quién la abrió, desde dónde, cuándo, cuánto duró y cómo terminó.
Ahí mismo está la respuesta a “¿alguien tocó esto el martes?” — sin abrir la caja, sin confiar en la memoria de nadie. Y si la conversación necesita más que una marca de tiempo, puedes reproducir la sesión.
Esta es la parte que termina la disputa. No es un resumen que escribiste tú; es la sesión misma — los comandos, la salida, el orden. Si tu equipo redimensionó un pool de FPM, ven el pool de FPM siendo redimensionado. Si tu equipo no tocó el config de correo, la ausencia es igual de visible. Puedes descargar un transcript en texto plano y pegar las líneas relevantes directo en el ticket.
Un registro solo vale para entregar si es honesto
Un registro falseado o selectivo es peor que ninguno — por eso la grabación está hecha para ser confiable sin que nadie tenga que dar fe de ella:
- Los secretos van redactados. Prompts de contraseña,
sudo,mysql -p— cualquier cosa tecleada con el eco del terminal apagado — aparecen como‹redactado›. Puedes compartir la grabación con un cliente sin filtrar una credencial en el proceso. - Se captura fuera del servidor. La grabación ocurre en el hub de control, no en la caja, así que la persona grabada no puede editarla ni borrarla. Un root puede limpiar su
history; no puede llegar al log de auditoría. - Admite sus propios huecos. Si una grabación se topó con el cap o perdió frames bajo carga, se marca
truncada/con pérdidas. El registro nunca dice ser más completo de lo que es — que es precisamente lo que hace creíbles las partes que sí muestra.
Ese último punto importa más de lo que parece. El valor del registro para un cliente escéptico es que no te adula. Exculpa e implica con la misma indiferencia — por eso “toma, mira” aterriza donde “confía en mí” no.
También corta en el otro sentido
El encuadre hasta aquí es defensivo, pero el mismo registro es como limpias a tu equipo. “Nuestra última sesión en ese servidor terminó el lunes a las 18:20 y no se acercó al config de correo — aquí está la reproducción” es una respuesta de cinco segundos, inapelable. Sin ella, estás litigando memoria contra la sospecha de un cliente, y esa la pierdes incluso cuando tienes razón.
Conserva las que importan
Las grabaciones caducan según una ventana de retención (10 días por defecto), comprimidas y cifradas por empresa. Para las sesiones que podrían salir a relucir más tarde — una migración en una cuenta sensible, un incidente con post-mortem —, las anclas con la estrella y se conservan indefinidamente, fuera del alcance de la limpieza. La pista de auditoría de tu trabajo más importante queda entonces permanente por elección, no por suerte.
El punto
En servidores que administras para otras personas, la rendición de cuentas no puede ser algo que enciendes después de un incidente — para entonces la sesión ya no está y vuelves a tu palabra contra la suya. Tiene que ser el default: grabada a medida que el trabajo ocurre, honesta por construcción, lista para entregar.
Así que la próxima vez que un cliente pregunte qué hiciste en su servidor, la respuesta no es un párrafo cuidadoso. Es un enlace a la reproducción.