Todo entorno operativo está lleno de comprobaciones: health checks, consultas de monitorización, pruebas tras un despliegue, controles tras un cambio en el firewall. Su valor no está en que estén en verde, sino en que se pongan en rojo cuando algo no cuadra. Precisamente esa segunda mitad rara vez se comprueba. Un control que nunca ha saltado puede significar que todo está en orden, o que ni siquiera puede saltar. Desde fuera, ambos casos tienen el mismo aspecto.
Los patrones de los que trata este artículo están muy extendidos y no dependen de la herramienta ni del tamaño del entorno. Los ejemplos son hipotéticos, pero típicos.
Cuatro resultados, no dos
La mayoría de las comprobaciones conocen dos desenlaces: superada o no superada. No basta. Hacen falta al menos dos resultados más:
- Superada: la medición se ha realizado y el resultado coincide con lo esperado.
- Fallida: la medición se ha realizado y ha encontrado un fallo.
- Error: la medición no se ha realizado: la conexión no llegó a establecerse, la consulta no era válida, la respuesta llegó vacía.
- Omitida: la comprobación se ha dejado fuera de forma deliberada, con una justificación que sigue siendo visible en el resultado.
La diferencia decisiva está entre «error» y «superada». «El sistema está averiado» y «no he podido averiguarlo» exigen reacciones distintas, pero ambos deben llamar la atención. Se vuelve peligroso cuando la ruta de error y la ruta «no se ha encontrado nada» devuelven el mismo valor: entonces la comprobación da el «todo en orden» justo en el momento en que menos legitimada está para ello.
Tampoco «omitida» puede pasar nunca por verde. Una ejecución en la que se ha omitido cada comprobación individual no ha medido nada, y debería informar exactamente de eso.
Cómo mienten las comprobaciones sin mentir
Los siguientes patrones no son espectaculares. Precisamente por eso suelen superar las revisiones.
La negación en lugar de lo esperado. Supongamos que un health check comprueba si una dirección responde «no con estado 200», porque allí se espera una redirección. Pero esa condición también se cumple con 403, con 500 y cuando ni siquiera llegó a establecerse una conexión. Compruebe el estado esperado por su nombre y trate la ausencia de respuesta como un resultado propio.
El objeto de error como cero. Supongamos que una consulta de monitorización cuenta coincidencias, por ejemplo inicios de sesión fallidos. Si la consulta no es sintácticamente válida, el sistema devuelve un objeto de error sin número de coincidencias. Un script que lee el campo ausente como 0 informa entonces de «sin anomalías». Un valor ausente no es cero. Asegúrese de que ha llegado una respuesta válida antes de evaluarla.
La búsqueda de texto que encuentra demasiado. Quien busca un mensaje de error en los registros encuentra también cada lugar en el que las personas hablan de ese mensaje de error: en tickets, historiales de chat, comentarios. Los campos estructurados como origen, tipo de evento o código de estado son más fiables que el texto libre.
La sonda que se encuentra a sí misma. Un clásico entre las comprobaciones de procesos: una búsqueda como ps aux | grep dienst devuelve a menudo una coincidencia: el propio comando grep (pgrep, en cambio, se excluye a sí mismo). El servicio buscado puede llevar tiempo detenido.
La pregunta correcta al destinatario equivocado
Una comprobación puede ser técnicamente impecable y aun así no dar en el blanco. Un patrón extendido: una comprobación que prueba una aplicación web directamente en el servidor no ve nada de los problemas de DNS, CDN o certificados con los que se encontraría un visitante. Esas comprobaciones directas tienen su finalidad, pero responden a otra pregunta. Entre el visitante y el servidor están la resolución de nombres, en su caso un balanceador de carga o una CDN, y la cadena de certificados. Un fallo en ese camino sigue siendo invisible para la comprobación en el servidor: informa en verde mientras el visitante ve una página de error.
Ambas mediciones tienen su razón de ser; simplemente no son intercambiables. El libro de SRE de Google distingue para ello entre la monitorización de caja blanca, que mira el interior de un sistema, y la monitorización de caja negra, que está orientada a síntomas y refleja problemas activos: «el sistema no funciona correctamente, ahora mismo» («The system isn’t working correctly, right now.»). Una comprobación desde la perspectiva del visitante –a través del nombre público, con la cadena de certificados validada– forma parte, por tanto, de toda autorización de puesta en producción de una aplicación accesible públicamente.
«Todo sigue funcionando» no es una comprobación del firewall
Tras un cambio en un firewall se suele comprobar si los servicios permitidos siguen siendo accesibles. Es necesario, pero solo demuestra que no se ha roto nada. Si el firewall filtra siquiera, esa prueba no lo muestra: un firewall sin ninguna regla activa la supera igual.
Para ello hace falta una prueba negativa: un intento de conexión desde un origen que debe bloquearse, hacia un puerto que debe estar cerrado. Solo cuando ese intento fracasa queda demostrado el filtrado. Es importante que la prueba venga de fuera del sistema comprobado; una prueba desde el propio host puede pasar por caminos a los que las reglas ni siquiera afectan.
Un control ausente no avisa
La variante más incómoda afecta a los propios mecanismos de protección: reglas de autorización, reglas de alarma, bloqueos automáticos. Un ejemplo: una empresa traslada su servidor de correo a una nueva plataforma. La regla que retiene los adjuntos con archivos ejecutables no se traslada. Nadie se da cuenta. No hay caída ni aviso, y en el registro no aparece nada inusual: una regla que no existe tampoco puede registrar nada. Para todos los implicados, la operación parece un mes tranquilo.
Por eso no basta con configurar un control. Su efecto solo queda demostrado cuando se ha comprobado que ha saltado, por ejemplo mediante un caso de prueba deliberado. Esa prueba debe repetirse en cuanto la configuración cambie de forma fundamental: tras un cambio de plataforma, una actualización importante o un traslado. Y no debería venir solo del propio sistema comprobado: lo que un entorno informa sobre sí mismo solo puede contener lo que él mismo conoce. Una mirada independiente –un envío de prueba desde fuera, una segunda herramienta, otra persona– descubre lo que se le escapa a la autoevaluación.
El BSI prevé en el módulo DER.1 del IT-Grundschutz que los sistemas de detección se revisen en auditorías periódicas para comprobar «si siguen estando actualizados y siendo eficaces». El mismo documento describe como amenaza que las configuraciones erróneas pueden hacer que los sistemas de detección «no funcionen correctamente». El libro de SRE extrae de una observación relacionada una consecuencia dura: la recopilación de datos, la agregación y la configuración de alarmas que rara vez se usan –en algunos equipos de SRE, menos de una vez por trimestre– deberían ser candidatas a su eliminación.
Lista de comprobación: toda comprobación debe fallar una vez
- Demuestre que la comprobación puede fallar. Ejecute cada comprobación nueva una vez contra una entrada conocida como errónea y observe cómo se pone en rojo. Una comprobación que nadie ha visto fallar no está demostrada como comprobación.
- Dé al error un resultado propio, separado de superada y no superada, con estado o código de salida propios.
- Compruebe lo esperado, no su negación: estado concreto, valor concreto, título de página concreto.
- Compruebe si ha llegado una respuesta antes de interpretarla. Vacío no es verde.
- Pregunte al destinatario correcto: medir por separado el origen y la perspectiva del visitante, y documentar ambos.
- Haga visibles las omisiones. «Omitida porque…» forma parte del resultado.
- Corrija la comprobación, no el umbral. Si una comprobación informa mal, lo que hay que reparar es su gestión de errores, no relajar la condición de modo que el caso dudoso caiga del lado verde.
Además, un control negativo debería construirse de manera que mañana siga dando el mismo resultado. Quien prueba una comprobación contra un fallo que existe en ese momento en producción tiene un control que se pone en verde en cuanto se corrige el fallo, y que entonces ya no demuestra nada. Para ello, los datos de prueba almacenados con un resultado conocido son más fiables que el estado en vivo.
Cómo apoya sector7
Le apoyamos en la implantación o la integración de plataformas de registros y SIEM y definimos con usted casos de uso, reglas de alarma y playbooks; más información en Ciberseguridad. Nuestro NOC supervisa de forma automatizada, las 24 horas, los entornos que atendemos; cómo es la operación continua lo describe Servicios gestionados y soporte.
Fuentes
- Site Reliability Engineering, capítulo 6: Monitoring Distributed Systems – Google, consultado el 30.09.2026
- IT-Grundschutz-Kompendium, Baustein DER.1 Detektion von sicherheitsrelevanten Ereignissen, Edition 2023 (PDF) – BSI, consultado el 30.09.2026