Con los años administrando servidores e infraestructuras hemos aprendido algo que parece obvio, pero que muchas veces solo se interioriza después de algún susto:
Hay trabajos que, aunque técnicamente puedan hacerse en horario laboral, simplemente no merece la pena hacerlos mientras los usuarios están trabajando.
Actualizar un servidor, modificar una configuración de red, reiniciar un firewall, ampliar recursos de una máquina virtual o tocar una infraestructura de copias puede parecer una intervención sencilla.
Y muchas veces lo es.
El problema es que en informática el riesgo no siempre está en lo que esperas que ocurra, sino en lo que ocurre después.
El clásico “esto son cinco minutos”
Probablemente es una de las frases más peligrosas cuando trabajas con sistemas en producción.
“Esto son cinco minutos.”
Instalas una actualización.
Reinicias.
Y el servidor tarda más de lo esperado en arrancar.
Un servicio decide no iniciarse.
Una aplicación empresarial deja de conectar con SQL.
Una actualización cambia alguna configuración.
El firewall vuelve, pero una VPN no.
O simplemente Windows decide que ese reinicio que debía durar cinco minutos va a durar bastante más.
No significa que se haya hecho nada mal.
Significa que cuando trabajas sobre sistemas complejos siempre existe una variable que no controlas completamente.
Por eso hemos ido cambiando nuestra forma de trabajar.
Si una intervención puede afectar a producción, preferimos realizarla cuando la empresa ya no depende de esos sistemas para trabajar.
El mantenimiento no termina cuando acaba la actualización
Este es probablemente uno de los errores más habituales.
Actualizar un servidor y comprobar que vuelve a aparecer el escritorio no significa que el trabajo haya terminado.
Después de una intervención hay que revisar.
- ¿Ha arrancado correctamente?
- ¿Funcionan los servicios?
- ¿Responde SQL?
- ¿Funcionan los accesos remotos?
- ¿Se comunica con el resto de servidores?
- ¿Funcionan las copias de seguridad?
- ¿Los usuarios podrán entrar mañana?
Porque una máquina puede estar encendida y, sin embargo, tener parte de sus servicios detenidos.
Por eso una intervención de mantenimiento tiene normalmente tres partes:
Hacer el cambio, comprobar el entorno y disponer de tiempo para reaccionar si algo no ha salido como estaba previsto.
Y esa tercera parte es precisamente la que hace tan importante trabajar fuera de horario.
Hemos visto suficiente para saber que Murphy también trabaja en informática
Hay una cierta ironía en esto.
Puedes actualizar veinte servidores sin ningún problema.
Y será precisamente el servidor que necesitabas tener disponible a las nueve de la mañana el que decidirá que ese día no quiere arrancar correctamente.
También ocurre con el hardware.
Un disco puede llevar años funcionando y fallar justo después de un reinicio.
Un servicio que llevaba meses funcionando puede no volver a arrancar.
Una aplicación puede comportarse de forma distinta después de instalar una actualización de Windows.
No es algo excepcional.
Forma parte del trabajo.
La diferencia está en encontrarte ese problema a las once de la mañana con veinte personas esperando, o encontrarlo a las once de la noche con varias horas por delante para solucionarlo.
Las actualizaciones de seguridad no pueden posponerse eternamente
También hemos encontrado infraestructuras donde los servidores llevaban meses, e incluso años, sin actualizarse.
Normalmente la explicación suele ser la misma:
“Como funciona, mejor no tocarlo.”
Es comprensible.
Pero también es peligroso.
Muchos ataques aprovechan vulnerabilidades para las que ya existe una actualización.
El fabricante ha detectado el problema.
Ha desarrollado el parche.
Lo ha publicado.
Y semanas después hay servidores en producción que continuan expuestos porque nadie quiere asumir el riesgo de reiniciarlos.
En realidad, simplemente estamos cambiando un riesgo conocido y controlable —realizar una actualización— por otro mucho menos controlable: mantener una vulnerabilidad abierta.
La solución no es dejar de actualizar.
La solución es crear ventanas de mantenimiento donde poder hacerlo con seguridad.
Antes de tocar algo importante queremos saber cómo volver atrás
Otra lección que se aprende rápidamente administrando sistemas es que un backup no sirve de demasiado si nunca has pensado cómo recuperarás realmente ese sistema.
Antes de determinados cambios comprobamos las copias.
En entornos virtualizados podemos disponer también de snapshots o mecanismos adicionales de recuperación.
En bases de datos podemos realizar copias específicas.
En dispositivos de red podemos exportar configuraciones.
No porque esperemos que algo vaya a fallar.
Precisamente porque si alguna vez falla, queremos que el problema sea reversible.
Es una diferencia importante de mentalidad.
No se trata únicamente de saber hacer el cambio.
Se trata de saber qué vamos a hacer si el cambio no funciona.
De noche trabajamos nosotros para que por la mañana trabajen los demás
Hay algo curioso en el mantenimiento informático bien realizado.
Normalmente nadie lo ve.
Un servidor se actualiza.
Una infraestructura se reinicia.
Se aplican parches de seguridad.
Se verifica una copia.
Se actualiza un firewall.
Se revisan los servicios.
Y a la mañana siguiente los usuarios llegan, encienden sus ordenadores y trabajan exactamente igual que el día anterior.
Desde su punto de vista no ha ocurrido nada.
Y probablemente esa sea la mejor señal de que el mantenimiento se ha hecho bien.
Porque gran parte de nuestro trabajo consiste precisamente en eso:
Hacer cambios importantes sin que esos cambios se conviertan en un problema para quien utiliza la tecnología.
No todo tiene que hacerse fuera de horario
Tampoco tendría sentido llevar esta filosofía al extremo.
Hay muchas tareas que pueden realizarse perfectamente durante la jornada laboral:
Monitorización, pequeñas modificaciones, creación de usuarios, revisión de alertas, comprobaciones o trabajos que no afectan al servicio.
La clave está en valorar el riesgo.
Si existe posibilidad de reinicio, interrupción, pérdida de conectividad o afectación a varios usuarios, preferimos disponer de una ventana de mantenimiento adecuada.
No porque pensemos que algo va a salir mal.
Sino porque sabemos que algún día algo saldrá mal.
Y cuando ese día llegue, queremos tener tiempo para solucionarlo.
La experiencia cambia la forma de administrar sistemas
Al principio es fácil pensar únicamente en realizar una tarea.
Con el tiempo empiezas a pensar en todo lo que rodea esa tarea.
- Qué depende de ese servidor.
- Quién está trabajando.
- Qué servicios podrían verse afectados.
- Dónde están las copias.
- Cuánto tardaríamos en recuperar.
- Qué ocurriría si la máquina no vuelve.
Ese cambio de mentalidad probablemente sea una de las mayores diferencias entre simplemente mantener sistemas y administrar infraestructura crítica.
La tecnología nunca es totalmente predecible.
Nuestro trabajo consiste en intentar que, para los usuarios, lo parezca.