Una infraestructura puede estar técnicamente bien diseñada y, al mismo tiempo, tener un riesgo enorme: que solo una persona sepa cómo funciona.
La documentación no es burocracia. Es una parte de la continuidad de negocio.
Lo que no está documentado depende de la memoria
Meses después de una implantación es fácil olvidar por qué se creó una regla, qué dependencia tiene una VM o cuál es el orden correcto de recuperación.
Y en una incidencia grave no queremos reconstruir esa información mientras los usuarios están esperando.
Inventario técnico
El mínimo debería incluir hardware, máquinas virtuales, servicios, versiones relevantes, almacenamiento, licencias, proveedores y responsables.
El inventario debe permitir responder rápidamente qué existe y qué impacto tendría perder cada componente.
Red y dependencias
Topología, VLAN, gateways, DNS, firewall, VPN y dependencias entre servicios necesitan quedar representados de forma comprensible.
No basta con una captura antigua. La documentación tiene que mantenerse junto con los cambios de infraestructura.
Credenciales sin convertir la documentación en un riesgo
Las contraseñas no deben escribirse en documentos compartidos. La documentación indica dónde y cómo se gestionan los secretos; las credenciales deben permanecer en un gestor diseñado para ello.
Procedimientos operativos
- Cómo arrancar y detener servicios críticos.
- Cómo restaurar una copia.
- Cómo acceder en una emergencia.
- Qué hacer ante una alerta de seguridad.
- Qué proveedor contactar según la incidencia.
- Qué orden seguir tras una caída completa.
Eliminar el punto único de conocimiento
En Tecnidom tratamos la documentación como parte de la propia infraestructura. El objetivo es que una intervención no dependa de recordar “cómo lo hicimos aquella vez”.
La continuidad no consiste únicamente en que sobrevivan los datos. También debe sobrevivir el conocimiento necesario para ponerlos de nuevo en servicio.
Qué documentación debe existir antes de una incidencia
| Documento | Para qué sirve |
|---|---|
| Inventario | Saber qué activos y servicios existen |
| Topología | Entender red, VLAN, dependencias y rutas |
| Matriz de accesos | Saber quién administra cada sistema |
| Runbooks | Ejecutar tareas y recuperaciones repetibles |
| Contactos | Escalar rápidamente a operadores y proveedores |
| Histórico de cambios | Relacionar una incidencia con modificaciones recientes |
Documentar decisiones, no solo configuraciones
Saber que existe una VLAN 30 ayuda; saber por qué se creó, qué servicios debe contener y qué comunicaciones están permitidas ayuda mucho más.
Las decisiones sobreviven mejor al tiempo que una colección de capturas de pantalla.
La documentación también necesita mantenimiento
Un documento exacto el día de la instalación puede ser peligroso un año después si todo el mundo asume que sigue actualizado.
Conviene vincular cambios relevantes a una revisión de inventario, diagramas y procedimientos.
Preguntas frecuentes
¿Dónde deben guardarse las credenciales?
En un gestor de secretos o contraseñas con control de acceso. La documentación debe indicar dónde están, no contenerlas en texto plano.
¿Hace falta documentarlo todo?
No con el mismo detalle. Debe priorizarse aquello que afecte a continuidad, seguridad, recuperación y operación recurrente.
¿Un diagrama de red es suficiente?
No. Es una pieza importante, pero no explica procedimientos, proveedores, permisos ni orden de recuperación.
Documentar para reducir dependencia
La documentación convierte conocimiento individual en capacidad operativa. Es una parte del servicio gestionado que explicamos en soporte informático para pymes.
Para profundizar
Si este tema te interesa, estos artículos amplían la parte técnica y operativa:
- Backups con Proxmox
- Una restauración termina cuando vuelve el negocio
- Qué debe tener una infraestructura IT profesional
¿Necesitas ayuda con la tecnología de tu empresa?
Podemos revisar contigo qué está ocurriendo, qué riesgos existen y por dónde tiene sentido empezar.
