Cómo documentar correctamente un servidor Linux

Introducción

Documentar correctamente un servidor Linux significa dejar suficiente información para que una persona autorizada pueda comprender qué función cumple, cómo está construido, qué servicios ejecuta, de qué depende, cómo se administra y cómo debe recuperarse si algo falla. No consiste en copiar comandos sueltos, guardar capturas de pantalla ni redactar un manual tan extenso que nadie vuelva a abrirlo.

Un servidor puede funcionar durante años sin que su documentación parezca urgente. El problema aparece cuando hay que actualizarlo, sustituir un disco, renovar un certificado, investigar una caída, cambiar de proveedor, recuperar una copia o trabajar sin la persona que lo instaló. En ese momento, cada dato no registrado se convierte en tiempo de diagnóstico, riesgo de error y dependencia personal.

La documentación tampoco debe confundirse con el inventario. El inventario identifica que el servidor existe y resume su función. La documentación del servidor explica cómo está organizado, qué decisiones se tomaron, dónde están sus configuraciones, qué procedimientos deben seguirse y qué comprobaciones confirman que continúa funcionando correctamente.

Este artículo propone un sistema práctico para documentar servidores Linux utilizados por profesionales, microempresas, PYMES, sitios web, aplicaciones empresariales y plataformas LMS. El objetivo es crear una documentación útil para soporte, mantenimiento, seguridad y continuidad, sin convertirla en una carga administrativa imposible de mantener.

Índice

• Qué significa documentar correctamente un servidor Linux
• Diferencia entre inventario, documentación y procedimiento
• Principios de una documentación técnica útil
• Tres niveles de documentación del servidor
• Ficha de identificación y función empresarial
• Hardware, virtualización y capacidad
• Sistema operativo, versión y ciclo de vida
• Red, nombres, DNS y conectividad
• Discos, particiones, volúmenes y puntos de montaje
• Estructura de directorios y ubicación de activos
• Servicios, procesos y puertos
• Aplicaciones y dependencias
• Usuarios, grupos, sudo y acceso administrativo
• Controles de seguridad que deben quedar documentados
• Configuraciones, secretos y certificados
• Tareas programadas y automatizaciones
• Logs, monitorización y alertas
• Copias de seguridad y restauración
• Mapa de dependencias
• Procedimientos operativos
• Procedimientos de incidencia y recuperación
• Registro de cambios y decisiones técnicas
• Comandos útiles para construir la documentación inicial
• Dónde guardar la documentación
• Cómo mantenerla actualizada
• Plantilla práctica de ficha de servidor
• Ejemplo aplicado a un servidor de plataforma LMS
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué significa documentar correctamente un servidor Linux

Un servidor está correctamente documentado cuando una persona autorizada, con conocimientos adecuados de Linux, puede responder sin improvisar a preguntas como estas:

• ¿Para qué existe este servidor?
• ¿Qué procesos empresariales dependen de él?
• ¿Dónde está alojado y quién es su titular?
• ¿Qué distribución y versión utiliza?
• ¿Qué servicios ejecuta?
• ¿Qué puertos necesita realmente?
• ¿Dónde están las aplicaciones, los datos y los logs?
• ¿Qué usuarios pueden administrarlo?
• ¿Cómo se accede de forma segura?
• ¿Qué tareas se ejecutan automáticamente?
• ¿Qué copias existen y cómo se restauran?
• ¿Qué otros sistemas deben funcionar para que este servidor preste servicio?
• ¿Qué cambios importantes se han realizado?
• ¿Qué debe comprobarse después de reiniciar o actualizar?
• ¿Cómo puede reconstruirse en otro equipo o proveedor?

La documentación útil no pretende reproducir todo el contenido de /etc ni describir cada paquete instalado. Debe seleccionar la información que permite comprender, operar, cambiar y recuperar el sistema.

Documentar un servidor no significa explicar Linux; significa explicar qué tiene de particular ese servidor y cómo debe gestionarse sin depender de memoria informal.

Diferencia entre inventario, documentación y procedimiento

Estos elementos se complementan, pero cumplen funciones distintas.

El artículo cómo inventariar servidores, aplicaciones y servicios se centra en identificar y relacionar elementos tecnológicos. El presente artículo profundiza en la documentación necesaria para administrar un servidor Linux concreto.

También conviene diferenciar este trabajo de cómo documentar toda la infraestructura tecnológica, cuyo alcance incluye equipos, aplicaciones, redes, proveedores, identidades y procesos empresariales completos. Aquí el objeto documental es una sola máquina o instancia Linux.

Principios de una documentación técnica útil

Debe representar el estado real

Una documentación desactualizada puede inducir a ejecutar acciones incorrectas. La exactitud importa más que la presentación.

Debe explicar decisiones, no solo resultados

No basta con indicar que una aplicación está en /opt. Conviene explicar por qué se eligió esa ubicación, qué debe permanecer fuera y qué procedimiento se utiliza para actualizarla.

Debe separar información estable y variable

La finalidad del servidor cambia poco. La dirección IP, la versión de un paquete o el espacio disponible pueden variar. Separar ambos tipos facilita actualizar sin reescribir todo.

Debe ser proporcional a la criticidad

Un servidor de laboratorio no necesita el mismo nivel de detalle que uno que sostiene ventas, facturación o acceso de alumnos.

Debe facilitar acciones concretas

La documentación debe ayudar a diagnosticar, mantener, restaurar o transferir el sistema. Una descripción que no mejora ninguna acción tiene valor limitado.

Debe evitar secretos en texto abierto

Puede indicar qué credencial se utiliza y dónde está custodiada, pero no debe copiar contraseñas, claves privadas, tokens o códigos de recuperación.

Debe poder consultarse durante una incidencia

Si toda la documentación está alojada en el mismo servidor que ha caído, no estará disponible cuando más se necesite.

Debe tener responsable

La documentación sin propietario termina obsoleta. Alguien debe validar su exactitud y actualizarla después de cambios.

Tres niveles de documentación del servidor

No toda la información necesita el mismo grado de detalle. Puede organizarse en tres niveles.

Nivel 1. Resumen operativo

Debe permitir comprender rápidamente el servidor:

• identificador y nombre;
• finalidad;
• criticidad;
• ubicación o proveedor;
• sistema operativo;
• servicios principales;
• responsable;
• método de acceso;
• estado de copias;
• enlaces a procedimientos.

Nivel 2. Ficha técnica

Describe red, discos, directorios, paquetes relevantes, configuraciones, usuarios, tareas programadas, logs, dependencias y capacidad.

Nivel 3. Procedimientos

Explica cómo ejecutar tareas y cómo actuar ante incidencias: actualizar, reiniciar, restaurar, ampliar almacenamiento, renovar certificados, migrar o reconstruir.

Esta división evita crear un único documento inmanejable. El resumen sirve para orientación; la ficha técnica, para diagnóstico; y los procedimientos, para actuación.

Ficha de identificación y función empresarial

La documentación debe empezar por la función, no por las especificaciones.

Datos mínimos

• identificador estable;
• nombre de host;
• nombre descriptivo;
• entorno: producción, pruebas, desarrollo o laboratorio;
• servicio empresarial soportado;
• propietario funcional;
• responsable técnico;
• criticidad;
• horario de disponibilidad necesario;
• tiempo de parada tolerable;
• fecha de alta;
• fecha de última revisión documental.

Describir el impacto

“Servidor web” es una descripción insuficiente. Resulta más útil indicar:

Servidor de producción que aloja la web comercial y la plataforma LMS. Su caída impide nuevas ventas, acceso de alumnos y administración de contenidos. La facturación externa puede continuar, pero la matriculación automática queda detenida.

Esta descripción ayuda a priorizar durante una incidencia y a comprender qué alternativas temporales deben existir.

Hardware, virtualización y capacidad

La ficha debe reflejar sobre qué infraestructura se ejecuta el sistema.

Servidor físico

• marca, modelo y número de serie;
• CPU;
• memoria instalada;
• controladora de almacenamiento;
• discos y configuración;
• interfaces de red;
• ubicación;
• garantía;
• SAI o alimentación;
• consola remota disponible.

Máquina virtual

• hipervisor o proveedor;
• host o región;
• vCPU;
• memoria asignada;
• discos virtuales;
• redes virtuales;
• política de snapshots;
• método de exportación o migración;
• identificador en la plataforma.

VPS o instancia cloud

• proveedor y cuenta titular;
• plan contratado;
• región;
• recursos;
• IP públicas y privadas;
• firewall del proveedor;
• almacenamiento adicional;
• coste y renovación;
• procedimiento de rescate.

Conviene registrar también utilización normal, picos y margen aproximado. La capacidad instalada no explica por sí sola si el sistema está cerca de un límite. Para este seguimiento puede enlazarse con cómo monitorizar recursos del servidor.

Sistema operativo, versión y ciclo de vida

La distribución y su versión deben quedar claramente identificadas.

Información recomendada

• distribución;
• versión;
• arquitectura;
• kernel;
• fecha de instalación;
• origen de la imagen;
• repositorios adicionales;
• política de actualización;
• fecha de fin de soporte;
• versión objetivo siguiente;
• excepciones o paquetes retenidos.

Comandos básicos:

cat /etc/os-release
uname -a
uname -m
hostnamectl

La documentación debe indicar si las actualizaciones son automáticas, manuales o mixtas, qué ventanas se utilizan y qué comprobaciones se realizan después.

No conviene limitarse a anotar la versión actual. El ciclo de vida debe incluir cuándo dejará de recibir soporte y qué dependencias podrían bloquear una actualización.

Red, nombres, DNS y conectividad

La documentación de red debe permitir identificar cómo se alcanza el servidor y qué comunicaciones necesita.

Datos principales

• nombre de host;
• dominio completo;
• direcciones IPv4 e IPv6;
• interfaces;
• subredes;
• puerta de enlace;
• servidores DNS;
• DNS directo e inverso;
• VLAN o red virtual;
• VPN necesaria;
• NAT o redirecciones;
• firewall perimetral;
• balanceador o proxy inverso;
• dominios asociados.

Comandos de captura

ip -brief address
ip route
resolvectl status
ss -lntup
hostname -f

No debe documentarse únicamente la IP. También conviene explicar si es fija, reservada, asignada por el proveedor o dependiente de DHCP.

Las reglas externas deben referenciarse sin revelar información innecesaria. Por ejemplo: “El puerto 443 se publica mediante proxy inverso; SSH solo es accesible desde VPN”.

Discos, particiones, volúmenes y puntos de montaje

La documentación de almacenamiento debe explicar tanto la estructura como la función de cada volumen.

Qué registrar

• discos físicos o virtuales;
• particiones;
• LVM;
• RAID;
• sistema de archivos;
• UUID;
• puntos de montaje;
• opciones de montaje;
• capacidad;
• uso normal;
• crecimiento;
• datos almacenados;
• copia asociada;
• procedimiento de ampliación.

Comandos útiles

lsblk -f
findmnt
df -hT
sudo blkid
sudo pvs
sudo vgs
sudo lvs

Una tabla puede resumir el diseño:

Para prevenir saturaciones, la documentación debe indicar umbrales y responsable de actuación. Este bloque puede complementarse con cómo detectar cuellos de botella tecnológicos antes de que aparezcan.

Estructura de directorios y ubicación de activos

La documentación debe responder dónde se encuentra cada tipo de activo.

• aplicaciones;
• datos persistentes;
• configuraciones;
• scripts;
• logs;
• temporales;
• copias locales;
• certificados;
• contenidos publicados;
• repositorios.

Ejemplo:

/opt/empresa/aplicacion/      aplicación instalada
/etc/empresa/aplicacion/      configuración
/srv/empresa/aplicacion/      datos empresariales
/var/log/empresa/aplicacion/  registros
/usr/local/sbin/               scripts de administración
/srv/backups-temporales/       área temporal controlada

La documentación debe indicar quién es propietario de cada ruta, qué permisos se esperan, qué contenido puede regenerarse y qué contenido es irremplazable.

El criterio general de organización se desarrolla en cómo organizar un servidor Linux para que siga siendo mantenible dentro de cinco años. En este artículo, el objetivo no es diseñar de nuevo la estructura, sino dejarla explicada para soporte y continuidad.

Servicios, procesos y puertos

Todo servicio relevante debe aparecer con una ficha mínima.

Campos por servicio

• nombre;
• finalidad;
• unidad de systemd;
• usuario de ejecución;
• puertos;
• configuración;
• datos;
• logs;
• dependencias;
• política de reinicio;
• comprobación de salud;
• impacto si se detiene.

Comandos útiles

systemctl --type=service --state=running
systemctl list-unit-files --type=service
systemctl status nombre-servicio
systemctl cat nombre-servicio
ss -lntup

No todos los servicios activos son empresariales. La documentación debe distinguir componentes estándar del sistema de servicios instalados para una función concreta.

También debe indicar el orden de dependencia. Por ejemplo, una aplicación puede requerir base de datos, red, almacenamiento montado y servicio de correo.

Aplicaciones y dependencias

Para cada aplicación instalada debe explicarse cómo se construye y opera.

Ficha de aplicación

• nombre y versión;
• finalidad;
• ubicación;
• método de instalación;
• repositorio o proveedor;
• lenguaje o runtime;
• dependencias;
• base de datos;
• usuario de ejecución;
• configuración;
• variables de entorno;
• servicio de arranque;
• procedimiento de actualización;
• procedimiento de reversión;
• prueba de funcionamiento;

Si la aplicación fue instalada mediante paquetes, debe indicarse el repositorio. Si se compiló, deben registrarse versión, opciones y dependencias. Si se despliega con contenedores, conviene documentar imágenes, volúmenes, redes, secretos y archivo de composición.

El objetivo es evitar instalaciones irrepetibles que solo pueden mantenerse porque alguien recuerda cómo se hicieron.

Usuarios, grupos, sudo y acceso administrativo

La documentación no debe incluir contraseñas, pero sí el modelo de acceso.

Qué registrar

• usuarios humanos autorizados;
• usuarios de servicio;
• grupos relevantes;
• reglas de sudo;
• método de autenticación SSH;
• ubicación de claves públicas autorizadas;
• acceso de proveedores;
• cuentas de emergencia;
• procedimiento de alta y baja;
• fecha de revisión.

Comandos de revisión

getent passwd
getent group
sudo -l -U nombre_usuario
sudo visudo -c
last
lastlog

Las cuentas de servicio deben distinguirse de las cuentas humanas. Debe quedar claro qué proceso utiliza cada cuenta y si tiene shell interactiva.

El modelo puede apoyarse en cómo crear usuarios seguros en Linux para administrar un servidor y en cómo proteger el acceso SSH en servidores Linux.

Controles de seguridad que deben quedar documentados

La documentación de seguridad debe explicar qué controles existen y cómo se verifican.

• firewall local;
• firewall externo;
• usuarios permitidos por SSH;
• autenticación por clave;
• acceso root;
• Fail2ban u otros bloqueos;
• actualizaciones de seguridad;
• protección de archivos sensibles;
• permisos especiales;
• servicios expuestos;
• cifrado de discos o copias;
• registros de auditoría;
• procedimiento ante compromiso.

No es necesario copiar todas las reglas dentro del documento. Puede enlazarse a la configuración versionada y resumir su finalidad.

Ejemplo:

El servidor solo publica HTTP y HTTPS mediante el firewall del proveedor. SSH está restringido a la red VPN. Fail2ban protege el servicio SSH. Las reglas locales se conservan en el repositorio de configuración y se validan después de cada cambio.

Para una guía de controles mínimos puede consultarse cómo proteger un servidor Linux básico.

Configuraciones, secretos y certificados

Debe quedar claro dónde se encuentran las configuraciones relevantes y cómo se protegen los secretos.

Configuraciones

• ruta del archivo;
• servicio asociado;
• propietario y permisos;
• copia o versionado;
• validación antes de aplicar;
• reinicio o recarga necesaria;
• forma de revertir.

Secretos

La documentación puede indicar:

• qué secreto existe;
• qué servicio lo utiliza;
• dónde está custodiado;
• quién puede recuperarlo;
• cómo se rota;
• qué debe reiniciarse después.

No deben copiarse contraseñas, claves privadas, tokens o archivos completos de credenciales.

Certificados

• dominio;
• autoridad emisora;
• método de renovación;
• ruta;
• servicios que lo utilizan;
• alerta de caducidad;
• procedimiento de renovación manual;
• comprobación posterior.

Tareas programadas y automatizaciones

Las tareas automáticas son una fuente frecuente de dependencias ocultas.

Qué revisar

• cron del sistema;
• cron de usuarios;
• temporizadores de systemd;
• scripts de copia;
• renovación de certificados;
• limpieza de temporales;
• sincronizaciones;
• importaciones y exportaciones;
• mantenimiento de base de datos;
• envío de informes;

Comandos útiles

systemctl list-timers --all
sudo crontab -l
crontab -l
ls -la /etc/cron.d /etc/cron.daily /etc/cron.weekly

Ficha de cada tarea

• nombre;
• finalidad;
• frecuencia;
• usuario;
• comando o script;
• entradas y salidas;
• log;
• alerta;
• impacto del fallo;
• forma de ejecución manual;

Una tarea que funciona en segundo plano debe ser tan documentada como un servicio visible.

Logs, monitorización y alertas

La documentación debe indicar dónde observar el estado del servidor y de cada servicio.

Logs

• journalctl;
• logs de autenticación;
• logs de aplicaciones;
• logs web;
• logs de base de datos;
• logs de copias;
• logs de tareas programadas;
• retención y rotación;

Monitorización

• disponibilidad;
• CPU;
• memoria;
• espacio;
• inodos;
• latencia;
• procesos;
• certificados;
• copias;
• colas;

Alertas

Debe registrarse quién recibe cada alerta, por qué canal, en qué horario y qué acción se espera.

Ejemplo:

Copias de seguridad y restauración

Una documentación de copias incompleta indica que “hay backup”. Una documentación útil explica qué se copia, dónde, con qué frecuencia, cuánto se conserva y cómo se restaura.

Por cada copia debe registrarse

• origen;
• destino;
• herramienta;
• frecuencia;
• retención;
• cifrado;
• cuenta utilizada;
• alertas;
• responsable;
• última ejecución correcta;
• última restauración probada;
• tiempo estimado de recuperación.

Separar tipos de activo

• sistema operativo;
• configuraciones;
• bases de datos;
• archivos empresariales;
• contenidos;
• certificados;
• scripts;
• documentación;

La restauración debe describir el orden. Por ejemplo: preparar servidor, instalar dependencias, restaurar configuración, recuperar base de datos, recuperar archivos, iniciar servicios y validar.

Puede ampliarse con cómo hacer backups automáticos del servidor y cómo implementar copias 3-2-1.

Mapa de dependencias

La documentación debe mostrar de qué depende el servidor y qué depende de él.

Dependencias externas

• proveedor de alojamiento;
• DNS;
• dominios;
• red;
• almacenamiento externo;
• correo;
• API;
• pasarela de pago;
• repositorios;
• servicios de identidad.

Dependencias internas

• base de datos;
• proxy inverso;
• servicios de aplicación;
• montajes;
• usuarios de servicio;
• certificados;
• tareas programadas;

Representación sencilla

Servicio de formación online
├── DNS y dominio
├── Servidor Linux
│   ├── nginx
│   ├── PHP
│   ├── aplicación LMS
│   ├── base de datos
│   └── almacenamiento de contenidos
├── correo transaccional
├── pasarela de pago
└── servicio de copias

El mapa permite localizar puntos únicos de fallo y definir el orden de recuperación.

Procedimientos operativos

La documentación debe enlazar con procedimientos para las tareas que se repiten o que implican riesgo.

• comprobar estado general;
• revisar espacio;
• revisar servicios;
• aplicar actualizaciones;
• reiniciar un servicio;
• reiniciar el servidor;
• renovar certificados;
• crear usuario;
• revocar acceso;
• desplegar aplicación;
• restaurar archivo;
• revisar copias;
• ampliar disco;
• recuperar contraseña administrativa.

Estructura de un procedimiento

1. Objetivo.
2. Cuándo utilizarlo.
3. Riesgos.
4. Requisitos previos.
5. Copia o punto de retorno.
6. Pasos.
7. Comprobaciones.
8. Reversión.
9. Registro del cambio.

Para reinicios puede consultarse cómo reiniciar servicios Linux correctamente sin romper nada.

Procedimientos de incidencia y recuperación

Los procedimientos de incidencia deben estar preparados antes de la caída.

Escenarios básicos

• servidor inaccesible;
• servicio detenido;
• espacio agotado;
• CPU o memoria saturadas;
• base de datos no disponible;
• certificado caducado;
• copia fallida;
• acceso SSH perdido;
• archivo borrado;
• actualización defectuosa;
• credencial comprometida;
• fallo de proveedor.

Cada procedimiento debe incluir

• síntomas;
• impacto;
• comprobaciones iniciales;
• criterios de escalado;
• acciones permitidas;
• acciones prohibidas;
• alternativa temporal;
• comunicación;
• validación de recuperación;
• registro posterior.

La documentación debe impedir que una incidencia se convierta en una sucesión de comandos improvisados.

Registro de cambios y decisiones técnicas

Los cambios relevantes deben dejar rastro.

Decisiones técnicas

Además de registrar qué cambió, conviene conservar por qué se eligió una opción. Una nota breve puede incluir:

• problema;
• alternativas;
• decisión;
• motivo;
• riesgos aceptados;
• fecha de revisión futura.

Esto evita que una excepción parezca un error años después o que se repitan debates sin conocer el contexto.

Comandos útiles para construir la documentación inicial

Los siguientes comandos ayudan a recopilar información, pero su salida debe interpretarse y resumirse. Copiarla sin criterio no constituye documentación.

Identidad y sistema

hostnamectl
cat /etc/os-release
uname -a
uptime

Hardware y recursos

lscpu
free -h
lsblk -f
df -hT
lspci

Red

ip -brief address
ip route
ss -lntup
resolvectl status

Servicios

systemctl --type=service --state=running
systemctl list-unit-files --type=service
systemctl list-timers --all

Paquetes

apt-mark showmanual
dpkg-query -W
snap list

Usuarios y acceso

getent passwd
getent group
last
lastlog

Firewall

sudo ufw status verbose
sudo nft list ruleset

Debe utilizarse el comando correspondiente al sistema. No es necesario ejecutar todos ni publicar su salida completa.

Dónde guardar la documentación

La documentación necesita una fuente oficial, control de acceso y copia separada.

Opciones

• wiki interna;
• gestor documental;
• repositorio Git para texto y configuraciones;
• carpeta estructurada con control de versiones;
• herramienta de inventario enlazada con procedimientos;

Estructura posible

/servidores/SRV-LMS-01/
  00_resumen.md
  01_ficha_tecnica.md
  02_red.md
  03_almacenamiento.md
  04_servicios.md
  05_aplicaciones.md
  06_accesos.md
  07_copias.md
  08_monitorizacion.md
  09_procedimientos/
  10_cambios.md
  11_diagramas/
  12_archivo/

Acceso durante incidencias

El resumen, los contactos, los procedimientos de recuperación y las referencias de credenciales deben tener una copia protegida fuera del servidor documentado.

Permisos

No toda la documentación debe ser accesible a todos. Los detalles de red, usuarios, proveedores y recuperación pueden requerir acceso restringido.

Cómo mantener la documentación actualizada

La documentación debe actualizarse como parte del cambio, no como tarea futura.

Eventos que obligan a actualizar

• instalación o retirada de servicio;
• cambio de IP o DNS;
• ampliación de disco;
• cambio de distribución o versión;
• nuevo usuario administrativo;
• cambio de proveedor;
• nueva tarea programada;
• cambio de copia;
• incidencia relevante;
• restauración probada;
• modificación de firewall;
• renovación de certificado;

Regla de cierre

Un cambio no debería considerarse completado hasta actualizar:

• ficha técnica;
• procedimiento;
• diagrama;
• inventario;
• registro de cambios.

Revisión periódica

• mensual: alertas, espacio, copias y accesos;
• trimestral: servicios, tareas programadas y dependencias;
• semestral: procedimientos de recuperación;
• anual: ciclo de vida, capacidad y sustitución.

Plantilla práctica de ficha de servidor

IDENTIFICACIÓN
- ID:
- Nombre de host:
- Entorno:
- Finalidad:
- Criticidad:
- Propietario funcional:
- Responsable técnico:

INFRAESTRUCTURA
- Tipo: físico / VM / VPS / cloud
- Proveedor o ubicación:
- CPU:
- Memoria:
- Discos:
- Consola de rescate:

SISTEMA
- Distribución:
- Versión:
- Kernel:
- Fecha de alta:
- Fin de soporte:
- Política de actualización:

RED
- IP:
- DNS:
- Interfaces:
- Puerta de enlace:
- VPN:
- Puertos publicados:
- Firewall:

ALMACENAMIENTO
- Particiones y volúmenes:
- Puntos de montaje:
- Datos por ubicación:
- Crecimiento:
- Umbrales:

SERVICIOS Y APLICACIONES
- Servicio:
- Unidad systemd:
- Usuario:
- Puerto:
- Configuración:
- Datos:
- Logs:
- Dependencias:
- Comprobación:

ACCESO Y SEGURIDAD
- Usuarios autorizados:
- Grupos:
- Sudo:
- SSH:
- MFA o VPN:
- Fail2ban:
- Gestor de secretos:

AUTOMATIZACIONES
- Tareas cron:
- Timers:
- Scripts:
- Alertas:

COPIAS Y RECUPERACIÓN
- Qué se copia:
- Frecuencia:
- Destino:
- Retención:
- Última restauración:
- Procedimiento:

OPERACIÓN
- Monitorización:
- Alertas:
- Reinicio:
- Actualización:
- Despliegue:
- Recuperación:

DEPENDENCIAS
- Servicios externos:
- Servicios internos:
- Personas o proveedores:

CONTROL DOCUMENTAL
- Última revisión:
- Responsable de revisión:
- Enlace a cambios:
- Enlace a procedimientos:

La plantilla debe adaptarse al servidor. No conviene completar campos sin utilidad únicamente para aparentar exhaustividad.

Ejemplo aplicado a un servidor de plataforma LMS

Una empresa que comercializa cursos y másteres online puede disponer de un servidor Linux que aloje WordPress, el LMS, la base de datos y servicios auxiliares.

Resumen funcional

El servidor sostiene la web comercial, el acceso de alumnos, la administración de cursos y parte del proceso de matriculación. Su indisponibilidad afecta a ventas y entrega, aunque la pasarela de pago y la facturación puedan residir en servicios externos.

Servicios principales

• nginx;
• PHP-FPM;
• MariaDB o MySQL;
• WordPress;
• plugin o plataforma LMS;
• cron de WordPress;
• correo transaccional externo;
• copias programadas;
• monitorización.

Activos que deben quedar localizados

• raíz web;
• configuración de nginx;
• pools de PHP;
• base de datos;
• archivos subidos;
• contenidos fuente fuera del LMS;
• certificados;
• scripts de copia;
• logs;
• credenciales referenciadas en gestor seguro.

Dependencias

• dominio y DNS;
• proveedor de servidor;
• servicio de correo;
• pasarela de pago;
• almacenamiento de copias;
• licencias de plugins;
• cuentas administrativas;

Pruebas posteriores a un cambio

1. La web responde por HTTPS.
2. Un usuario puede iniciar sesión.
3. El panel administrativo funciona.
4. La base de datos responde sin errores.
5. Se puede acceder a un curso.
6. El correo transaccional se envía.
7. Las tareas programadas se ejecutan.
8. La copia posterior al cambio termina correctamente.

La documentación debe conectar la infraestructura técnica con la experiencia real del alumno. Que todos los servicios estén “activos” no demuestra por sí solo que el proceso de formación funcione.

Errores frecuentes

Copiar salidas completas de comandos

Genera volumen sin explicación. Conviene resumir y enlazar la evidencia cuando sea necesario.

Guardar contraseñas en el documento

Debe utilizarse un gestor de secretos y referenciar la entrada.

Documentar solo la instalación inicial

El servidor cambia y la documentación queda congelada.

No explicar la función empresarial

Sin impacto y criticidad resulta difícil priorizar.

No registrar tareas automáticas

Los cron y timers se convierten en dependencias invisibles.

No documentar el orden de recuperación

Disponer de copias no garantiza poder reconstruir el servicio.

Confundir snapshot con backup

Un snapshot puede ayudar a volver atrás, pero no siempre protege frente a pérdida del host o del proveedor.

No registrar cambios pequeños

La acumulación de cambios menores transforma el servidor sin dejar trazabilidad.

Crear un documento único enorme

Es preferible separar resumen, ficha, procedimientos y cambios.

No probar la documentación

Una persona distinta debería poder localizar información y ejecutar una comprobación controlada.

Alojar toda la documentación en el propio servidor

Quedará inaccesible durante una caída.

Documentar la situación ideal

Deben aparecer excepciones, deuda técnica y limitaciones reales.

Lista de comprobación

• ¿El servidor tiene identificador y nombre claros?
• ¿Está descrita su función empresarial?
• ¿Se conoce su criticidad?
• ¿Tiene propietario funcional y responsable técnico?
• ¿Se documenta dónde está alojado?
• ¿Se conoce la distribución y versión?
• ¿Está registrado el fin de soporte?
• ¿Se documentan CPU, memoria y almacenamiento?
• ¿Se conocen interfaces, IP, DNS y rutas?
• ¿Están explicados discos y puntos de montaje?
• ¿Se sabe dónde están aplicaciones, datos, logs y scripts?
• ¿Están inventariados los servicios relevantes?
• ¿Cada servicio tiene finalidad, usuario, puerto y configuración?
• ¿Se documentan dependencias de aplicaciones?
• ¿Se conocen usuarios humanos y de servicio?
• ¿Están registradas las reglas de sudo?
• ¿Se documenta el modelo de acceso SSH?
• ¿Se conocen las reglas de firewall?
• ¿Los secretos están fuera de la documentación?
• ¿Se registran certificados y renovación?
• ¿Están inventariados cron y timers?
• ¿Se conocen rutas de logs y retención?
• ¿La monitorización tiene alertas y responsables?
• ¿Se documenta qué se copia?
• ¿Existe procedimiento de restauración?
• ¿Se ha probado la recuperación?
• ¿Existe mapa de dependencias?
• ¿Hay procedimientos de operación?
• ¿Hay procedimientos de incidencia?
• ¿Los cambios dejan registro?
• ¿Las decisiones técnicas conservan contexto?
• ¿La documentación está fuera del propio servidor?
• ¿Existe fecha de revisión?
• ¿Otra persona puede utilizarla?

Preguntas frecuentes

Conclusión

Documentar correctamente un servidor Linux significa convertir una instalación técnica en un sistema comprensible, mantenible y recuperable.

La documentación debe comenzar por la función empresarial y continuar con infraestructura, sistema operativo, red, almacenamiento, directorios, servicios, aplicaciones, usuarios, seguridad, automatizaciones, logs, copias y dependencias.

El valor de la documentación no está en su extensión, sino en la capacidad de reducir incertidumbre durante una actualización, una incidencia, una migración o un relevo técnico.

Un buen sistema separa resumen, ficha técnica, procedimientos y registro de cambios. También mantiene los secretos fuera, conserva una copia accesible durante caídas y asigna responsables de revisión.

La documentación debe actualizarse como parte de cada cambio. Si se deja para después, el servidor y el documento empiezan a describir realidades distintas.

Para una microempresa o una plataforma de formación online, esta disciplina reduce dependencia de una sola persona, acelera el soporte, mejora la seguridad y permite recuperar el servicio con menos improvisación.

ESTUDIO METADATOS desarrolla programas de formación online orientados a comprender y aplicar tecnología en entornos profesionales reales. Puedes consultar sus programas de formación tecnológica para profundizar en Linux, administración de sistemas, infraestructura, seguridad, datos y continuidad operativa.