Cómo documentar correctamente toda la infraestructura tecnológica

Introducción

Documentar correctamente toda la infraestructura tecnológica no consiste en acumular capturas de pantalla, manuales de fabricantes y contraseñas dentro de una carpeta. Consiste en construir una representación fiable del entorno real: qué activos existen, qué función cumplen, cómo se relacionan, quién los administra, qué datos contienen, de qué dependen y cómo deben recuperarse cuando algo falla.

En una empresa pequeña, la documentación suele crecer de forma fragmentada. El inventario de equipos está en una hoja, las instrucciones del servidor en un documento, los accesos en un gestor de contraseñas, los contratos en administración, los diagramas en el ordenador de un técnico y las decisiones importantes enterradas en mensajes de correo. Cada pieza puede existir, pero el conjunto no permite comprender la infraestructura.

El problema se hace visible durante una incidencia, una baja, una migración o un cambio de proveedor. La empresa descubre entonces que conoce algunos componentes, pero no sus dependencias; sabe qué aplicación utiliza, pero no qué cuenta la administra; dispone de una copia, pero no del procedimiento para restaurarla; o conserva un diagrama que ya no coincide con la red actual.

Este artículo explica cómo crear un sistema documental completo, proporcionado y mantenible para equipos, servidores, aplicaciones, servicios cloud, usuarios, redes, copias, integraciones, proveedores y procedimientos. El objetivo no es producir burocracia, sino convertir la infraestructura tecnológica en un sistema comprensible, auditable y recuperable.

Índice

• Qué significa documentar toda la infraestructura tecnológica
• Diferencia entre inventario, documentación y conocimiento operativo
• Principios de una documentación útil
• Modelo documental por capas
• Definir el alcance antes de empezar
• Documentar equipos y activos físicos
• Documentar la red y la conectividad
• Documentar servidores, máquinas virtuales y contenedores
• Documentar aplicaciones y servicios cloud
• Documentar usuarios, grupos y accesos
• Documentar datos, almacenamiento y copias
• Documentar integraciones y automatizaciones
• Documentar proveedores, contratos y titularidad
• Documentar procedimientos operativos y de recuperación
• Construir el mapa de dependencias
• Qué diagramas conviene mantener
• Cómo organizar el repositorio documental
• Cómo documentar accesos sin exponer credenciales
• Versionado, historial de cambios y trazabilidad
• Responsables, propietarios y validadores
• Cómo mantener la documentación actualizada
• Auditoría periódica de la documentación
• Plan de implantación por fases
• Ejemplo aplicado a una empresa de formación online
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué significa documentar toda la infraestructura tecnológica

Documentar la infraestructura significa describir el sistema tecnológico de forma que una persona autorizada pueda entenderlo, administrarlo, comprobarlo y recuperarlo sin depender exclusivamente de la memoria de quien lo instaló.

La documentación completa debe responder, al menos, a estas preguntas:

• ¿Qué componentes existen?
• ¿Qué función empresarial cumple cada uno?
• ¿Dónde está ubicado o alojado?
• ¿Quién es su propietario y quién lo administra?
• ¿Qué usuarios y sistemas dependen de él?
• ¿Qué datos contiene o procesa?
• ¿Qué credenciales o certificados necesita?
• ¿Cómo se monitoriza?
• ¿Cómo se copia y se recupera?
• ¿Qué ocurre si deja de estar disponible?
• ¿Cómo puede sustituirse o migrarse?
• ¿Cuándo se revisó por última vez?

La documentación no es solo una descripción técnica. También debe reflejar la relación entre tecnología y negocio. Un servidor puede ejecutar varias aplicaciones; una aplicación puede sostener facturación; la facturación puede ser crítica para cobrar. Esa cadena debe ser visible.

Una infraestructura está realmente documentada cuando puede comprenderse por componentes, dependencias, responsabilidades y procedimientos de actuación.

Diferencia entre inventario, documentación y conocimiento operativo

Estos tres conceptos se relacionan, pero no son equivalentes.

Inventario

El inventario responde principalmente a la pregunta “qué existe”. Puede incluir equipos, aplicaciones, licencias, usuarios, servidores, dominios, proveedores y contratos.

Documentación técnica

Explica cómo está configurado cada elemento, qué relaciones mantiene, qué requisitos tiene, cómo se administra y qué limitaciones presenta.

Documentación operativa

Describe cómo realizar tareas: crear una cuenta, sustituir un equipo, renovar un certificado, restaurar una copia o actuar ante una caída.

Conocimiento operativo

Incluye decisiones, excepciones, criterios y experiencia acumulada. Por ejemplo, por qué una aplicación no se actualiza inmediatamente, qué proveedor responde mejor ante una urgencia o qué procedimiento alternativo se utiliza durante una caída.

El artículo sobre cómo crear documentación tecnológica sencilla en una PYME aborda la documentación mínima y práctica. El presente enfoque amplía ese trabajo para representar de forma sistemática el conjunto completo de la infraestructura.

Principios de una documentación útil

Debe representar la realidad

Un documento elegante pero desactualizado es más peligroso que una nota sencilla y correcta. La prioridad es la fidelidad.

Debe tener propietario

Cada documento importante necesita una persona responsable de validarlo y actualizarlo.

Debe ser localizable

La información no debe repartirse sin criterio entre correos, chats, carpetas personales y herramientas aisladas.

Debe ser proporcional

No todos los componentes requieren el mismo detalle. Un servicio crítico necesita más documentación que una utilidad secundaria.

Debe separar secretos de instrucciones

Las contraseñas, tokens y claves privadas deben estar en sistemas seguros. La documentación puede indicar dónde se custodian, pero no debe copiarlos en texto abierto.

Debe facilitar la acción

Una buena ficha ayuda a decidir, mantener, diagnosticar o recuperar. Si solo sirve para describir, probablemente está incompleta.

Debe conservar historial

Los cambios relevantes deben dejar rastro para entender por qué el sistema es como es.

Debe poder utilizarse durante una incidencia

Parte de la documentación crítica debe seguir accesible cuando falla la red, el servidor documental o la cuenta principal.

Modelo documental por capas

Una estructura por capas evita mezclar en un único documento toda la información de la empresa.

La empresa puede implementar estas capas mediante varias herramientas, pero debe mantener una navegación coherente entre ellas.

Definir el alcance antes de empezar

Intentar documentarlo todo con el mismo nivel de detalle suele bloquear el proyecto. Conviene empezar por los elementos que sostienen la actividad.

Clasificar por criticidad

• Crítico: su fallo detiene ventas, producción, entrega, cobros o acceso a datos esenciales.
• Alto: afecta a un departamento o causa una interrupción relevante.
• Medio: existe alternativa temporal.
• Bajo: su indisponibilidad puede tolerarse varios días.

Clasificar por tipo

• activos físicos;
• red y comunicaciones;
• servidores e infraestructura;
• aplicaciones;
• servicios cloud;
• datos y almacenamiento;
• identidades y permisos;
• integraciones;
• copias;
• proveedores;
• procedimientos.

Definir niveles de detalle

Puede utilizarse un modelo de tres niveles:

1. Nivel 1: ficha mínima de todos los elementos.
2. Nivel 2: configuración y dependencias de componentes importantes.
3. Nivel 3: procedimientos detallados para servicios críticos.

Este enfoque permite cubrir primero el conjunto y profundizar después donde el riesgo lo exige.

Documentar equipos y activos físicos

Cada activo debe disponer de un identificador estable. El nombre puede cambiar, pero el identificador no debería reutilizarse.

Ficha mínima de un equipo

• identificador;
• tipo de activo;
• marca y modelo;
• número de serie;
• fecha de compra;
• garantía;
• ubicación;
• usuario o responsable;
• sistema operativo;
• estado de cifrado;
• perfil de configuración;
• software principal;
• estado de copia;
• fecha prevista de renovación;
• situación: activo, reserva, reparación o retirado.

Activos que suelen olvidarse

• routers;
• switches;
• puntos de acceso;
• SAI;
• discos externos;
• impresoras y escáneres;
• móviles corporativos;
• llaves de seguridad;
• adaptadores y equipos de reserva;
• dispositivos de copia;
• equipos entregados a colaboradores.

Retirada del activo

La ficha debe registrar borrado, destrucción, devolución, venta o reciclaje. El activo retirado no debe desaparecer del historial, porque puede haber licencias, datos o incidencias asociadas.

Documentar la red y la conectividad

La documentación de red debe permitir identificar cómo entra la conectividad, cómo se distribuye y qué servicios dependen de ella.

Información de conectividad

• proveedor y contrato;
• línea principal y alternativa;
• velocidad contratada;
• direcciones públicas;
• datos del circuito;
• canal de soporte;
• tiempo de reparación;
• equipos suministrados;
• fecha de renovación.

Topología física

Debe representar operador, router, firewall, switches, puntos de acceso, servidores, NAS, impresoras y enlaces principales.

Topología lógica

Debe reflejar redes, subredes, VLAN, rangos IP, DHCP, DNS, VPN, rutas y reglas principales. No es necesario copiar todas las reglas del firewall en un diagrama, pero sí explicar su estructura y finalidad.

Plan de direccionamiento

Copias de configuración

Router, firewall, switches y puntos de acceso deberían disponer de copias exportadas cuando la herramienta lo permita. La documentación debe indicar dónde están, cómo se restauran y qué versión corresponde al entorno actual.

Documentar servidores, máquinas virtuales y contenedores

Un servidor necesita una ficha que explique tanto su función como su configuración operativa.

Ficha de servidor

• nombre e identificador;
• función;
• ubicación física o proveedor;
• sistema operativo y versión;
• CPU, memoria y almacenamiento;
• direcciones y redes;
• servicios ejecutados;
• puertos necesarios;
• usuarios administrativos;
• método de acceso;
• actualizaciones;
• monitorización;
• copias;
• dependencias;
• responsable;
• procedimiento de recuperación;
• fecha de revisión.

Máquinas virtuales

Debe documentarse hipervisor, host, almacenamiento, red virtual, recursos asignados, snapshots, copias y método de migración. También conviene distinguir claramente snapshots de backups.

Contenedores

Para cada servicio deben registrarse imagen, versión, puertos, volúmenes, variables, secretos, dependencias, política de reinicio, logs y procedimiento de actualización.

Configuración reproducible

Cuando sea posible, scripts, archivos de configuración e infraestructura como código deben conservarse en control de versiones. La documentación debe explicar cómo utilizarlos y qué parte sigue requiriendo intervención manual.

Fin de soporte

La ficha debe incluir fechas de fin de soporte y una acción prevista. Una infraestructura documentada también permite anticipar obsolescencia.

Documentar aplicaciones y servicios cloud

Las aplicaciones contratadas pueden ser tan críticas como los servidores propios. El hecho de que el proveedor gestione la infraestructura no elimina la necesidad de documentación.

Ficha de aplicación

• nombre comercial y función;
• proceso empresarial soportado;
• propietario interno;
• administradores;
• usuarios o grupos;
• datos tratados;
• criticidad;
• método de autenticación;
• integraciones;
• proveedor y soporte;
• licencias y coste;
• fecha de renovación;
• exportación de datos;
• copias o retención;
• plan de salida;
• alternativa temporal.

Configuración funcional

Conviene documentar reglas importantes: numeraciones, estados, flujos, permisos, plantillas, campos personalizados y automatizaciones. No hace falta copiar toda la interfaz, pero sí los elementos cuya pérdida impediría reconstruir el uso empresarial.

Propiedad de la cuenta

La ficha debe indicar qué identidad controla la suscripción y cómo se recupera. Las aplicaciones críticas no deberían depender de un correo personal o de un proveedor como único administrador.

Salida y portabilidad

La documentación debe incluir cómo exportar clientes, documentos, facturas, usuarios, contenidos o configuraciones. La capacidad de salida no debe descubrirse el día de la migración.

Documentar usuarios, grupos y accesos

No conviene crear un documento con todas las contraseñas. Sí debe existir una documentación clara del modelo de identidad y permisos.

Directorio y fuentes de identidad

Debe quedar claro qué sistema crea las identidades, qué aplicaciones utilizan inicio de sesión centralizado y qué cuentas se gestionan por separado.

Grupos y roles

Cuentas privilegiadas

Debe existir un registro de cuentas administrativas, finalidad, custodio, segundo factor, mecanismo de emergencia y fecha de revisión. La contraseña permanece en el gestor seguro.

Altas, cambios y bajas

La documentación debe indicar quién solicita, quién aprueba, quién ejecuta y qué se verifica. También debe incluir accesos temporales, tokens, dispositivos, reenvíos y cuentas compartidas.

Revisión de acceso

Los propietarios de cada aplicación deben validar periódicamente qué usuarios conservan acceso y con qué nivel.

Documentar datos, almacenamiento y copias

La empresa debe saber qué información posee, dónde reside y cómo se recupera.

Mapa de datos

Para cada conjunto de información conviene registrar:

• nombre y finalidad;
• sistema de origen;
• ubicación principal;
• propietario;
• usuarios autorizados;
• sensibilidad;
• formato;
• retención;
• copias;
• integraciones;
• procedimiento de exportación;
• procedimiento de eliminación.

Fuentes de verdad

Debe declararse qué sistema contiene la versión válida de clientes, facturas, proyectos, cursos, usuarios y documentos. Las copias y exportaciones no deben confundirse con el origen oficial.

Almacenamiento

Conviene documentar carpetas principales, permisos, cuotas, versionado, archivo, sincronización y crecimiento previsto.

Copias de seguridad

La documentación de copia debe explicar también cómo restaurar, no solo cuándo se ejecuta. Puede ampliarse con cómo implementar copias 3-2-1.

Documentar integraciones y automatizaciones

Las integraciones son una de las partes más olvidadas de la infraestructura porque funcionan en segundo plano. Cuando fallan, pueden perder datos sin que nadie lo detecte.

Ficha de integración

• nombre;
• objetivo empresarial;
• sistema origen;
• sistema destino;
• disparador;
• datos transferidos;
• reglas y transformaciones;
• frecuencia;
• cuenta técnica utilizada;
• ubicación de secretos;
• logs;
• alertas;
• responsable;
• procedimiento manual;
• fecha de revisión.

Diagrama de flujo

Formulario web
    ↓
Validación
    ↓
CRM
    ↓
Creación de tarea
    ↓
Aviso al responsable
    ↓
Registro de resultado

Errores y reintentos

Debe explicarse qué ocurre si un sistema no responde, cómo se detectan duplicados, dónde quedan los registros fallidos y quién decide el reenvío.

Dependencias técnicas

API, webhooks, tokens, campos, formatos, IP autorizadas y límites de uso deben estar identificados.

El diseño puede relacionarse con cómo integrar servicios digitales sin añadir complejidad.

Documentar proveedores, contratos y titularidad

Los proveedores forman parte de la infraestructura aunque estén fuera de la empresa.

Ficha de proveedor

• razón social y contacto;
• servicio prestado;
• activos o sistemas afectados;
• responsable interno;
• canal de soporte;
• horario y tiempos;
• contrato;
• coste;
• fecha de renovación;
• accesos concedidos;
• datos tratados;
• entregables;
• procedimiento de escalado;
• procedimiento de salida;
• proveedor alternativo cuando proceda.

Titularidad

Debe quedar registrado quién es titular de dominios, cuentas, licencias, repositorios, datos y contratos. Usar un servicio no equivale a controlarlo.

Accesos del proveedor

La documentación debe indicar qué cuenta utiliza, qué permisos tiene, quién aprobó el acceso y cuándo debe revisarse o revocarse.

Fin de la relación

Conviene disponer de una lista de salida: revocar accesos, recuperar configuraciones, exportar datos, transferir cuentas, obtener documentación y comprobar copias.

Este bloque se complementa con cómo elegir proveedores tecnológicos sin perder control.

Documentar procedimientos operativos y de recuperación

Los procedimientos convierten la descripción de la infraestructura en capacidad de actuación.

Procedimientos rutinarios

• alta de usuario;
• baja de usuario;
• preparación de equipo;
• solicitud de acceso;
• instalación de software;
• cambio de responsable;
• revisión de copias;
• renovación de servicios;
• aplicación de actualizaciones;
• revisión de capacidad.

Procedimientos de incidencia

• pérdida de portátil;
• cuenta bloqueada;
• caída de Internet;
• servicio cloud no disponible;
• espacio agotado;
• copia fallida;
• correo comprometido;
• integración detenida;
• servidor inaccesible;
• error de certificado.

Estructura de un procedimiento

1. Objetivo.
2. Cuándo utilizarlo.
3. Responsable y autorizaciones.
4. Requisitos previos.
5. Pasos.
6. Comprobaciones.
7. Forma de revertir.
8. Registro que debe conservarse.
9. Escalado si no funciona.

Procedimientos de recuperación

Deben indicar prioridad, copia utilizada, credenciales necesarias, dependencias, tiempo aproximado, validación y comunicación. No basta con escribir “restaurar backup”.

Construir el mapa de dependencias

El inventario muestra elementos. El mapa de dependencias explica qué ocurre cuando uno falla.

Dependencias técnicas

• una aplicación depende de una base de datos;
• la base depende de un servidor;
• el servidor depende de almacenamiento y red;
• el acceso depende de un directorio;
• los certificados dependen de DNS y renovaciones.

Dependencias externas

• operador de Internet;
• proveedor cloud;
• registrador de dominio;
• pasarela de pago;
• servicio de correo;
• proveedor de soporte.

Dependencias humanas

• una persona que aprueba;
• un técnico que conoce la configuración;
• un proveedor que conserva acceso;
• un responsable que valida datos;
• una persona que recibe alertas.

Mapa de servicio

Venta de programa formativo
├── Web
│   ├── Dominio
│   ├── DNS
│   ├── Hosting
│   └── Base de datos
├── Pasarela de pago
├── Facturación
├── LMS
│   ├── Usuarios
│   ├── Contenidos
│   └── Correo transaccional
└── Soporte al alumno

Este mapa permite priorizar documentación y continuidad. Una pieza con muchas dependencias merece especial atención.

Qué diagramas conviene mantener

No todos los diagramas son necesarios para todas las empresas. Deben utilizarse cuando ayudan a comprender relaciones.

Diagrama general de arquitectura

Muestra usuarios, red, servicios internos, servicios cloud, datos e integraciones principales.

Diagrama de red

Muestra conectividad, equipos, segmentos y rutas relevantes.

Diagrama de aplicaciones

Representa sistemas y flujos de información.

Diagrama de identidad

Explica directorio, grupos, inicio de sesión, cuentas separadas y recuperación.

Diagrama de copias

Muestra origen, destino, frecuencia, retención y aislamiento.

Diagrama de continuidad

Representa alternativas y orden de recuperación.

Criterios de calidad

• fecha de revisión visible;
• leyenda;
• nivel de detalle adecuado;
• nombres coherentes con el inventario;
• enlaces a fichas;
• responsable;
• sin credenciales ni secretos.

Un diagrama debe simplificar. Si requiere una hora para interpretarlo, probablemente mezcla demasiados niveles.

Cómo organizar el repositorio documental

La documentación necesita una estructura estable y una fuente oficial.

/Infraestructura
  /00_Resumen
  /01_Inventario
  /02_Arquitectura
  /03_Red
  /04_Servidores
  /05_Aplicaciones
  /06_Identidades
  /07_Datos_y_Copias
  /08_Integraciones
  /09_Proveedores
  /10_Procedimientos
  /11_Continuidad
  /12_Cambios
  /13_Archivo

Convenciones

• identificadores estables;
• nombres descriptivos;
• fecha de revisión dentro del documento;
• responsable visible;
• estado: borrador, validado, obsoleto o archivado;
• enlaces entre fichas relacionadas;
• plantillas comunes.

Wiki, gestor documental o archivos

Una wiki facilita enlazado y búsqueda. Un gestor documental puede aportar permisos y versiones. Los archivos convencionales pueden ser suficientes si se organizan bien. La herramienta debe adaptarse a la capacidad de mantenimiento.

Disponibilidad alternativa

Los procedimientos de emergencia, contactos y arquitectura básica deben poder consultarse si falla el repositorio principal. Puede existir una copia cifrada y controlada fuera del sistema habitual.

La publicación online de manuales y conocimiento puede ampliarse con cómo crear documentación técnica online clara y fácil de mantener.

Cómo documentar accesos sin exponer credenciales

La documentación debe explicar el acceso, no almacenar necesariamente el secreto.

Qué puede documentarse

• URL o punto de entrada;
• tipo de cuenta;
• nombre de usuario cuando no sea sensible;
• grupo autorizado;
• método de autenticación;
• ubicación del secreto en el gestor;
• segundo factor;
• procedimiento de recuperación;
• responsable;
• fecha de revisión.

Qué no debe aparecer en texto abierto

• contraseñas;
• claves privadas;
• tokens;
• semillas de autenticación;
• códigos de recuperación;
• secretos de aplicaciones;
• copias completas de archivos de credenciales.

Acceso de emergencia

Debe existir un mecanismo controlado para recuperar cuentas críticas cuando el administrador habitual no está disponible. La documentación puede indicar quién autoriza, dónde se custodia y cómo se registra el uso.

Rotación y revocación

Los secretos deben asociarse a responsables y sistemas. Cuando cambia una persona o proveedor, la documentación ayuda a identificar qué debe revocarse o rotarse.

Versionado, historial de cambios y trazabilidad

La documentación debe evolucionar con la infraestructura. El historial permite comprender cambios y recuperar versiones anteriores.

Qué debe versionarse

• diagramas;
• procedimientos;
• configuraciones;
• inventarios;
• fichas de servicios críticos;
• scripts;
• decisiones de arquitectura;
• planes de recuperación.

Registro de cambios

Decisiones de arquitectura

Conviene registrar decisiones relevantes: problema, opciones, decisión, razones, riesgos y fecha de revisión. Esto evita repetir debates y ayuda a comprender excepciones.

Git para documentación técnica

Los archivos de texto, scripts y configuraciones pueden gestionarse con Git. Para documentos binarios puede utilizarse un gestor con control de versiones.

Responsables, propietarios y validadores

La documentación se degrada cuando nadie sabe quién debe mantenerla.

Propietario del servicio

Es la persona responsable de su función empresarial, presupuesto, usuarios y prioridad.

Responsable técnico

Administra configuración, mantenimiento, seguridad y recuperación.

Validador

Confirma que la documentación representa la realidad y que el procedimiento funciona.

Usuario clave

Aporta conocimiento sobre la operativa y las excepciones.

Proveedor

Puede mantener parte de la documentación, pero la empresa debe conservar acceso y capacidad de revisión.

Cómo mantener la documentación actualizada

La actualización debe integrarse en los procesos de cambio. Documentar después, cuando haya tiempo, suele significar no documentar.

Regla de cierre

Un cambio tecnológico no debe considerarse terminado hasta actualizar inventario, diagrama, procedimiento o ficha correspondiente.

Eventos que deben generar actualización

• alta o baja de equipo;
• cambio de versión;
• nueva aplicación;
• nueva integración;
• cambio de proveedor;
• modificación de red;
• cambio de permisos;
• incidente;
• prueba de restauración;
• renovación contractual;
• cambio de responsable.

Fechas de caducidad documental

Los documentos críticos pueden incluir una fecha máxima de revisión. Si se supera, deben marcarse como pendientes de validar.

Revisión ligera y frecuente

Es preferible actualizar cinco minutos después de un cambio que dedicar semanas a reconstruir toda la documentación una vez al año.

Eliminar o archivar

La documentación antigua debe archivarse, no mezclarse con la vigente. Debe quedar claro qué versión se utiliza.

Auditoría periódica de la documentación

Una auditoría documental comprueba tanto la existencia como la calidad.

Comprobaciones

• ¿Todos los servicios críticos tienen ficha?
• ¿Los diagramas coinciden con la realidad?
• ¿Los responsables siguen siendo correctos?
• ¿Las cuentas administrativas están registradas?
• ¿Las copias tienen procedimiento de restauración?
• ¿Las integraciones tienen logs y alternativa?
• ¿Los proveedores conservan solo los accesos necesarios?
• ¿Las fechas de renovación están actualizadas?
• ¿Los documentos obsoletos están separados?
• ¿La documentación crítica es accesible durante una caída?

Pruebas por muestreo

Puede elegirse un activo, una aplicación y un procedimiento cada mes. La persona revisora intenta localizar la ficha y ejecutar una comprobación. Esto revela rápidamente enlaces rotos, instrucciones incompletas y dependencias ocultas.

Indicadores

• porcentaje de activos inventariados;
• porcentaje de servicios críticos documentados;
• documentos con revisión vencida;
• procedimientos probados;
• integraciones sin responsable;
• cuentas privilegiadas sin revisión;
• tiempo necesario para localizar información;
• incidencias causadas por documentación incorrecta.

Plan de implantación por fases

Fase 1: identificar servicios críticos

Seleccionar los elementos cuya caída tendría mayor impacto y asignar responsables.

Fase 2: crear inventario mínimo

Registrar activos, aplicaciones, cuentas principales, proveedores y copias.

Fase 3: documentar identidad y accesos

Definir directorio, grupos, administradores, recuperación y altas y bajas.

Fase 4: crear mapas

Dibujar arquitectura general, red, aplicaciones, datos y dependencias.

Fase 5: documentar configuraciones críticas

Completar fichas de servidores, aplicaciones, red, copias e integraciones.

Fase 6: crear procedimientos

Priorizar recuperación de cuentas, restauración, caídas, pérdida de equipos y cambio de proveedor.

Fase 7: separar secretos

Migrar credenciales a un gestor y dejar referencias seguras en la documentación.

Fase 8: implantar versionado y cambios

Definir cómo se aprueban, registran y documentan modificaciones.

Fase 9: probar

Entregar un procedimiento a una persona autorizada que no lo haya escrito y comprobar si puede utilizarlo.

Fase 10: mantener

Crear revisiones mensuales, trimestrales y anuales según criticidad.

Ejemplo aplicado a una empresa de formación online

Una empresa que comercializa cursos y másteres mediante una plataforma LMS combina infraestructura comercial, educativa y técnica.

Servicios principales

• dominio y DNS;
• web comercial;
• plataforma LMS;
• pasarela de pago;
• facturación;
• correo corporativo;
• correo transaccional;
• almacenamiento de contenidos;
• analítica;
• soporte al alumno;
• copias de seguridad;
• servidor o hosting.

Ficha del LMS

• URL y proveedor;
• versión y componentes;
• administradores;
• roles de alumno y gestión;
• método de matriculación;
• integración con pago;
• correo utilizado;
• ubicación de contenidos fuente;
• base de datos;
• copias;
• procedimiento de restauración;
• plan de comunicación si no está disponible.

Mapa de venta y entrega

Artículo o página de programa
    ↓
Formulario o compra
    ↓
Pago
    ↓
Facturación
    ↓
Creación o actualización de usuario
    ↓
Matrícula en LMS
    ↓
Correo de acceso
    ↓
Soporte y seguimiento

Contenidos formativos

La documentación debe distinguir materiales fuente, archivos publicados, versiones, propiedad, ubicación y copia. El LMS no debería ser la única ubicación de los originales.

Continuidad comercial

Debe existir un procedimiento para comunicar incidencias, validar pagos manualmente, restaurar acceso y ampliar plazos si la plataforma queda indisponible.

En este modelo, documentar la infraestructura no es una tarea auxiliar. Protege el producto, la venta, la entrega y la relación con el alumno.

Errores frecuentes

Crear un único documento enorme

Mezclar inventario, configuración, procedimientos y credenciales dificulta mantener y consultar.

Documentar solo hardware

Aplicaciones, cuentas, datos, proveedores e integraciones pueden ser más críticos que los equipos.

Guardar contraseñas en los manuales

La documentación debe referenciar el sistema seguro de secretos, no duplicarlos.

No asignar responsables

La documentación sin propietario se queda obsoleta.

Crear diagramas decorativos

Un diagrama debe ayudar a entender dependencias y actuar, no solo parecer profesional.

Documentar la situación ideal

Debe reflejar lo que existe, incluidas excepciones y limitaciones.

Esperar al final del proyecto

Cuando la documentación se deja para después, se pierden decisiones y detalles.

No documentar servicios cloud

La gestión externa no elimina cuentas, datos, configuraciones, costes ni riesgos.

No probar procedimientos

Una instrucción puede parecer correcta y fallar por permisos, rutas o dependencias.

No retirar documentos antiguos

Varias versiones activas generan decisiones contradictorias.

Confundir extensión con calidad

La documentación útil puede ser breve si contiene la información correcta.

No disponer de copia alternativa

La documentación crítica no debe quedar inaccesible durante la misma incidencia que intenta resolver.

Lista de comprobación

Preguntas frecuentes

Conclusión

Documentar correctamente toda la infraestructura tecnológica significa construir una representación utilizable del sistema real.

La documentación debe cubrir activos, red, servidores, aplicaciones, identidades, datos, copias, integraciones, proveedores, dependencias y procedimientos. También debe indicar responsables, revisiones, accesos y capacidad de recuperación.

La documentación de calidad no se mide por el número de páginas, sino por la capacidad de comprender, mantener, cambiar y recuperar la infraestructura sin improvisar.

El inventario permite saber qué existe. Los diagramas muestran cómo se relaciona. Las fichas explican cómo está configurado. Los procedimientos indican cómo actuar. El historial conserva por qué se tomaron determinadas decisiones.

Una empresa pequeña no necesita una plataforma documental compleja. Necesita una fuente oficial, plantillas coherentes, responsables y una disciplina de actualización integrada en los cambios.

Cuando la documentación representa la realidad, la empresa reduce dependencia de personas y proveedores, acelera el soporte, mejora las migraciones y convierte su conocimiento tecnológico en un activo empresarial.

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 infraestructura, sistemas, datos, seguridad y productividad digital.