Sala 6 · El comité de cierre

Un ticket cerrado no es un hallazgo corregido hasta que un reescaneo en las mismas condiciones lo confirma. Si el hallazgo reaparece, el cierre fue falso o hubo una regresión, y el ticket se reabre. Un host que no entró en la ventana del reescaneo no demuestra nada: ese cierre queda sin verificar, que es distinto de desmentido.

Con un equipo pequeño no se ordena por gusto: se llena la capacidad con las reglas escritas. La cola ya viene ordenada por prioridad; se toma cada ticket en ese orden mientras quepa en las horas que quedan y, si uno no cabe, se salta al siguiente que sí quepa. Lo que se aplaza no se olvida: se registra con dueño y fecha de revisión.

Cuando un servidor ya no recibe parches se decide con criterios escritos antes de puntuar, y el cálculo queda a la vista para que cualquiera lo repita. Un total alto puede esconder una debilidad que no debería tolerarse; por eso existe el veto, que se aplica antes de mirar quién suma más.

Los avisos de los proveedores llegan en inglés y por ramas de versión. La versión que corrige el fallo es la de la rama que corre el servidor de producción, no la más nueva del aviso: pasar de rama puede traer cambios que nadie pidió. Un servidor de pruebas con otra rama no cambia lo que hay que hacer en producción.

Una fecha de apagado no se promete antes de que terminen las tareas de las que depende el servidor. El apagado cae en la primera ventana disponible que sea posterior al fin de la última dependencia; una ventana del mismo día en que termina la última dependencia no sirve, y tampoco una marcada como no disponible.