Usa esta plantilla
La documentación interna sólida de la infraestructura protege a tu empresa frente a interrupciones, auditorías e incidentes de seguridad. Con Trupeer, puedes ahorrar horas en documentación de infraestructura empezando con una plantilla gratuita, personalizándola con tus directrices de marca y convirtiendo la documentación en recorridos en vídeo para equipos de TI y MSP.
La mayoría de la documentación de infraestructura se escribe una vez, durante un proyecto, y ya está desactualizada en seis meses. Se queda en la wiki, nadie confía en ella y, durante el siguiente incidente, alguien la lee, duda y llama a la persona que realmente sabe.
La solución no es más documentación. Es menos documentación que se mantenga veraz, elegida preguntando qué necesitaría alguien realmente a las tres de la mañana.
Descarga la plantilla de documentación de infraestructura
Formato | Ideal para |
|---|---|
Excel (.xlsx) | El inventario, la matriz de dependencias, los detalles de red y el seguimiento de revisiones |
Word (.docx) | Runbooks, visión general de la arquitectura y el plan de DR |
Versiones aprobadas y todo lo que pidan los auditores | |
Google Sheets | Un inventario compartido que el equipo mantiene |
Google Docs | Runbooks que se editan durante y después de los incidentes |
Gratis, editable y sin marca de agua. Excel hace la mayor parte del trabajo aquí, porque la documentación de infraestructura es, en gran medida, datos estructurados que fingen ser prosa.
¿Qué documentación necesitas?
Necesitas documentar | Usa |
|---|---|
Qué infraestructura existe y cómo se conecta | Esta plantilla |
Procesos de TI, políticas y guías generales | |
Un proyecto específico | |
Un producto de software para sus usuarios | |
Un procedimiento de TI | |
Arquitectura y diseño de software |
Cómo personalizar esta plantilla en Trupeer
Paso 1: Abre la sección Plantillas
Ve a la sección Plantillas desde la navegación principal.
Paso 2: Selecciona y abre una plantilla
Haz clic en cualquier plantilla con la que quieras trabajar para abrirla.
Paso 3: Amplía la vista de la plantilla
Si es necesario, amplía la vista de la plantilla para ver el diseño completo y los detalles con claridad.
Paso 4: Edita la plantilla
Haz clic en Editar para empezar a modificar la plantilla seleccionada.
Dentro del editor, puedes:
Añadir nuevas secciones
Definir o actualizar reglas de formato
Añadir un logotipo y ajustar su posición y la configuración relacionada
Paso 5: Guarda tu plantilla personalizada
Después de realizar todos los cambios necesarios, haz clic en Guardar para almacenar la plantilla actualizada como tuya.
Paso 6: Previsualiza y ajusta la plantilla
Cuando quieras ver cómo se ve tu plantilla personalizada, abre la Previsualización.
Desde la pantalla de previsualización, puedes seguir haciendo ajustes directamente si es necesario, asegurando que la plantilla aparezca exactamente como la quieres.
Con una plantilla de documentación interna de infraestructura puedes:
Ahorrar horas al escribir: Omite la página en blanco con una estructura creada para la infraestructura de TI.
Mejorar la postura de seguridad: Los campos integrados obligan a seguir prácticas seguras de gestión de credenciales.
Mantenerte alineado con la marca: Aplica tu logotipo, tipografías y colores usando el kit de marca de Trupeer.
Reducir el tiempo de inactividad: Una documentación clara reduce el MTTR durante los incidentes.
Mantenerte listo para auditorías: Alineado con SOC 2, ISO 27001 y marcos similares.
Conectar con equipos globales: Traduce la documentación a 65+ idiomas con un solo clic.
La prueba de las 3 a. m.
La única prueba que importa para la documentación de infraestructura.
Imagina un incidente a las tres de la mañana. La persona que construyó el sistema está en un avión. Alguien competente pero que no está familiarizado con tu documentación la está mirando. ¿Puede averiguar qué está roto, de qué depende, qué ocurre si lo reinicia y a quién hay que escalar?
Todo lo que ayuda con eso merece la pena escribirse. Todo lo demás es opcional, y la documentación opcional es lo que diluye las partes útiles y consume el presupuesto de mantenimiento.
Aplícalo sin piedad. Un historial detallado de por qué se eligió una tecnología en 2021 no supera la prueba. Una nota que diga que este servicio debe iniciarse después de la base de datos y antes del gateway de la API.
Qué supera la prueba de las 3 a. m.
Qué existe. Sistemas, servidores, servicios, con lo que hace cada uno en una frase.
Dónde vive. Proveedor de nube y región, o ubicación física y rack.
Qué depende de ello y de qué depende. Lo más valioso de la documentación de infraestructura.
Cómo llegar a ello. Nombres de host, direcciones, consolas, aunque nunca credenciales.
Cómo es lo normal. Para que una persona ajena pueda saber si algo está realmente mal.
Qué lo rompe. Modos de fallo conocidos y sus síntomas.
CÓMO reiniciarlo de forma segura, incluyendo el orden y cualquier cosa que deba hacerse primero.
Quién lo gestiona, y la ruta de escalado con datos de contacto reales.
Cuál es el radio de impacto. Qué se cae si esto falla.
Qué normalmente no supera la prueba
Escrita para la exhaustividad en lugar del uso y, por tanto, no merece la pena mantenerla.
Volcados completos de configuración que ya están obsoletos el día siguiente a la exportación. Razonamientos detallados de decisiones pasadas, que pertenecen a un registro de decisiones de arquitectura en lugar de a documentación operativa. Cada parámetro de cada sistema cuando solo unos pocos importan operativamente. Capturas de consolas, que envejecen mal y rara vez ayudan. Y cualquier cosa que duplique una fuente de verdad en otro lugar, ya que dos copias significan que una está mal y no puedes saber cuál.
El principio general: si se puede descubrir desde el sistema más rápido de lo que se puede leer en un documento, no lo documentes.
El inventario de infraestructura
La base. Una fila por sistema o servicio.
Campo | Introduce |
|---|---|
Nombre | Tal como aparece en el monitoreo y en una conversación |
Propósito | Una frase, en lenguaje claro |
Tipo | Servidor, servicio, base de datos, dispositivo de red, SaaS |
Entorno | Producción, staging, desarrollo |
Ubicación | Proveedor de nube y región, o sitio y rack |
Responsable | Equipo y un contacto de escalado con nombre |
Criticidad | Nivel 1 a 3, definido a continuación |
Depende de | Lo que necesita para funcionar |
Depende de ello | Lo que se rompe si se detiene |
Método de acceso | Consola, bastión SSH, VPN. No credenciales |
Monitoreo | Dónde van sus alertas |
Copia de seguridad | Frecuencia, ubicación, última restauración verificada |
Runbook | Enlace |
Última verificación | Fecha en la que alguien confirmó que esta fila es verdadera |
El último campo es el que la mayoría de inventarios omite y el que determina si alguien confía en el documento. Una fila que nadie ha revisado en dos años debería verse como no confiable, en lugar de estar mal en silencio.
Niveles de criticidad
Defínelos, porque determinan cuánta documentación merece cada sistema.
Nivel | Significa | Documentación esperada |
|---|---|---|
1 | La interrupción detiene el negocio | Runbook completo, DR probado, mapa de dependencias, revisado trimestralmente |
2 | La interrupción degrada una función | Runbook, dependencias, revisado dos veces al año |
3 | La interrupción es tolerable durante un día | Solo entrada de inventario y responsable |
La mayoría de organizaciones documentan el nivel 3 con la misma profundidad que el nivel 1, se quedan sin energía y acaban con todo a medias. Haz bien el nivel 1 y deja que el nivel 3 sea una única fila.
Dependencias
La parte más valiosa y más descuidada de la documentación de infraestructura.
Durante un incidente, rara vez la pregunta es qué está roto. Es qué más se ve afectado y qué necesita este elemento para volver. Ninguna de las dos cosas se puede descubrir desde una lista de servidores.
Documenta las dependencias en ambos sentidos:
Sistema | Depende de | Depende de él | Orden de inicio | Falla si la dependencia cae |
|---|---|---|---|---|
Order API | Postgres primary, Redis, Auth service | Web app, mobile app, integraciones con partners | Después de Postgres y Auth | Sí, inmediatamente |
Reporting service | Postgres replica | Solo paneles internos | Cualquiera | Degrada, sirve datos en caché |
Dos cosas hacen que esto sea útil. El orden de inicio, porque reiniciar cosas en el orden incorrecto convierte un incidente corto en uno largo. Y si la dependencia es dura o blanda, ya que un servicio que se degrada de forma gradual es un problema muy distinto al de uno que falla inmediatamente.
Incluye dependencias externas. Los proveedores de pago, los proveedores de identidad, DNS, las autoridades de certificados y las APIs de SaaS provocan interrupciones que no puedes solucionar, y saberlo rápidamente vale mucho a las 3 a. m.
Documentación de red
Elemento | Documenta |
|---|---|
Segmentos de red | Propósito, rango de direcciones, VLAN |
Enrutamiento | Entre segmentos y hacia internet |
Firewalls | Dónde están, quién gestiona las reglas y cómo solicitar un cambio |
VPN | Puntos de acceso, quién tiene acceso y cómo solicitarlo |
DNS | Zonas, dónde se alojan y quién puede modificarlas |
Balanceadores de carga | Qué hay detrás de cada uno y el comportamiento de los health checks |
Certificados | Qué cubren, caducidad, responsable de la renovación y método |
Conectividad externa | ISP, circuitos, contactos, referencias de contrato |
La caducidad de los certificados merece una atención especial. Provoca interrupciones totalmente predecibles, totalmente evitables y con una probabilidad desproporcionada de ocurrir un fin de semana. Documenta qué caduca y cuándo, quién lo renueva y si la renovación está automatizada.
Runbooks
El documento que alguien abre realmente durante un incidente.
Sección | Contenido |
|---|---|
Sistema y responsable | Con contacto de escalado |
Qué hace este sistema | Un párrafo |
Cómo es lo normal | Métricas, comportamiento esperado y carga típica |
Alertas comunes | Qué significa cada una y qué hacer |
Cómo reiniciarlo de forma segura | Pasos, orden y requisitos previos |
Modos de fallo conocidos | Síntoma, causa, solución |
Qué no hacer | Las acciones que empeoran las cosas |
Escalado | Cuándo y a quién |
Runbooks relacionados | Dependencias |
La sección de "qué no hacer" es rara y valiosa. Todo sistema maduro tiene una acción que parece razonable y empeora el incidente: reiniciar en el orden incorrecto, borrar una caché que tarda seis horas en reconstruirse, o hacer failover cuando el secundario está detrás.
Escribe runbooks para sistemas de nivel 1 y para cualquier cosa que haya causado un incidente. No para todo.
Acceso y credenciales
La sección en la que la documentación causa daño en lugar de prevenirlo.
Nunca pongas credenciales en la documentación. Ni contraseñas, ni claves de API, ni cadenas de conexión con secretos incrustados, ni claves privadas. No en la wiki, no en el archivo de Excel, no "temporalmente".
Documenta el método de acceso. Qué sistema guarda la credencial, quién puede conceder acceso y cómo alguien la solicita a las 3 a. m. Eso es lo que la persona realmente necesita y es seguro dejarlo por escrito.
En lugar de | Documentar |
|---|---|
La contraseña de administrador | Credenciales en [vault], accesibles para el equipo de la plataforma, procedimiento break-glass en [runbook] |
Una clave de API | Clave almacenada en [secrets manager] como [name], rotada trimestralmente por [owner] |
Un inicio de sesión compartido | Acceso mediante el grupo SSO [name], solicitud a través de [process] |
A continuación, documenta correctamente el procedimiento break-glass, porque el acceso de emergencia no disponible durante una emergencia es un fallo común y evitable.
Recuperación ante desastres
Lo que debe contener la documentación de DR para que valga la pena.
Los objetivos de tiempo de recuperación y de punto de recuperación por sistema de nivel 1, acordados con el negocio en lugar de asumidos por TI. Cuál es realmente el procedimiento de recuperación, paso a paso. Dónde están las copias de seguridad y, de forma crítica, cuándo se probó por última vez una restauración con éxito. Quién declara un desastre y quién activa el plan. Cómo se comunica el equipo cuando los sistemas normales están caídos, ya que un plan de DR guardado solo en los sistemas que están caídos es una vergüenza familiar.
La línea más importante de cualquier documento de DR es la fecha de la última prueba de restauración con éxito. Una copia de seguridad que nunca se ha restaurado es una hipótesis.
Diagramas
La infraestructura se beneficia de los diagramas más que la mayoría de la documentación, y se vuelven obsoletos más rápido.
Un diagrama de alto nivel que muestre los componentes principales y cómo se conectan. Este es el que la gente realmente usa.
Topología de red, donde el entorno sea lo bastante complejo como para necesitarla.
Flujo de datos, especialmente donde cruza límites de confianza o jurisdicciones.
Mantenlos simples. Un diagrama que nadie puede leer de un vistazo durante un incidente es decoración.
Fecháelos, y pon el responsable en ellos.
Prefiere diagramas-as-code donde tu equipo lo mantendrá, ya que un diagrama en un formato de texto con control de versiones se actualiza con el cambio en lugar de después.
Un diagrama incorrecto es peor que no tener diagrama, porque la gente confía más en las imágenes que en la prosa.
Mantenerlo preciso
El problema completo y la razón por la que la mayoría de la documentación de infraestructura falla.
Documenta menos. La precisión escala de forma inversa con el volumen. Quince páginas precisas superan a doscientas desactualizadas.
Asocia las actualizaciones de la documentación al proceso de cambios. Un cambio que altera la infraestructura no está completo hasta que la documentación lo refleje. Este es el único mecanismo que funciona de forma fiable.
Automatiza lo que se puede descubrir. El inventario, las direcciones, las configuraciones y la topología a menudo se pueden generar. La documentación generada no puede volverse obsoleta de la misma forma que la escrita a mano.
Escribe a mano solo lo que no se puede descubrir. Propósito, responsable, criticidad, dependencias, modos de fallo conocidos, qué no hacer. Las máquinas no pueden inferir nada de esto.
Fechalo todo, y muestra la fecha de forma destacada. Una fecha visible de última verificación permite a los lectores calibrar su confianza.
Revisa por calendario según el nivel, trimestralmente para el nivel 1.
Soluciónalo durante los incidentes. El momento en que alguien descubre que la documentación está mal es el momento en que ya tiene el conocimiento para corregirla. Haz que sea una tarea de cinco minutos, no un ticket.
Automatización y descubrimiento
Merece la pena invertir en ello, porque elimina el mayor modo de fallo.
Las bases de datos de gestión de configuración, los inventarios de proveedores de nube, los repositorios de infraestructura como código y las herramientas de descubrimiento de red pueden generar información precisa del estado actual de forma continua. Todo lo que puedan producir no debería mantenerse a mano.
La división que funciona: las máquinas documentan lo que existe, los humanos documentan lo que significa. Un inventario generado automáticamente te dice que existe un servidor y qué está instalado en él. Solo una persona puede decirte que es el que no debe reiniciarse entre las 2 a. m. y las 4 a. m. debido a la ejecución por lotes.
Cuando la infraestructura se define como código, el código es la documentación de lo que existe. Lo que queda por escribir es la intención, el conocimiento operativo y los modos de fallo.
Quién lo gestiona
Asigna la responsabilidad por sistema en lugar de convertir la documentación en el trabajo de una sola persona, que nunca sobrevive a la marcha de esa persona.
El equipo que opera un sistema es responsable de su documentación. Una persona con nombre se encarga del estándar general, las plantillas y la cadencia de revisión. Y el proceso de cambios obliga a actualizar, porque la responsabilidad sin un mecanismo es una intención.
El patrón de fallo es un responsable de la documentación que persigue a todos los demás. Eso funciona durante unos dos meses.
Probar la documentación
El equivalente a una prueba de restauración y, por tanto, igual de descuidada.
Toma a alguien que no haya construido el sistema, entrégale solo la documentación y pídeles que complete una tarea operativa rutinaria. Un reinicio controlado, un failover, una restauración a un entorno de pruebas.
Todo lo que no puedan hacer a partir de la documentación es un hueco. Todo lo que hagan mal es un defecto. Esto es incómodo y es la única forma fiable de saber si la documentación funcionaría a las 3 a. m., ya que la persona que la escribió siempre puede rellenar los huecos con memoria.
Haz esto al menos una vez al año para sistemas de nivel 1, idealmente como parte de un game day o un ejercicio de DR.
Buenas prácticas
Aplica la prueba de las 3 a. m. a todo antes de escribirlo.
Documenta correctamente el nivel 1 y de forma mínima el nivel 3.
Dependencias en ambos sentidos, con orden de inicio.
Nunca credenciales, siempre métodos de acceso.
Fecha de última verificación en cada registro.
Automatiza todo lo que se pueda descubrir; escribe a mano solo la intención y el conocimiento operativo.
Las actualizaciones de la documentación se aplican mediante el proceso de cambios.
Los runbooks incluyen qué no hacer.
Pruebas de restauración fechadas en el plan de DR.
Prueba la documentación con alguien que no esté familiarizado, anualmente.
Errores comunes
Credenciales en la wiki.
Todo documentado con la misma profundidad, así que no se mantiene nada.
Dependencias documentadas en un solo sentido.
Sin orden de inicio, así que la recuperación tarda más que la interrupción.
Volcados de configuración que llegan obsoletos.
Diagramas sin fecha y sin responsable, confiados mucho después de dejar de ser verdaderos.
La documentación como entrega de un proyecto, nunca actualizada después.
Una sola persona responsable nominal de todo.
Planes de DR guardados en la infraestructura que cubren.
Copias de seguridad documentadas, restauraciones nunca probadas.
Sin fecha de última verificación, así que los lectores no pueden juzgar qué confiar.
Escrita por la persona que lo construyó, probada por nadie.
Captura lo que solo sabe la persona que lo construyó
Abre las plantillas en Trupeer AI, aplica tu kit de marca para que la documentación coincida con tus estándares y edita cualquier sección directamente. La configuración está en la guía de la plantilla.
La automatización cubre lo que existe. Lo que no puede capturar es el conocimiento operativo: el orden en que vuelven las cosas, la comprobación que haces antes de hacer failover y la razón por la que nadie reinicia ese servicio un martes.
Ese conocimiento vive con una o dos personas y se va cuando ellas se van. Haz que lo expliquen durante un failover o una restauración mientras se graba, y Trupeer AI generará el runbook escrito y un recorrido en vídeo narrado a partir de la misma sesión, en el orden en que realmente lo hacen, en lugar del orden que recordarían al escribirlo.
Además, les quita menos tiempo que escribir, lo cual importa, porque la razón por la que el conocimiento operativo no se documenta es que las personas que lo tienen son las más ocupadas. Traduce ese contenido a 65+ idiomas para equipos distribuidos y mantén el conjunto en tu base de conocimiento junto a los runbooks.
Grábalo. Ponle marca. Tradúcelo. Trupeer it.
Preguntas frecuentes
¿Hay una plantilla gratuita de documentación de infraestructura en Word?
Sí. Word incluye los runbooks, la visión general de la arquitectura y el plan de DR, las partes que realmente son narrativas. Descarga gratuita, sin registro, sin marca de agua.
¿Hay una plantilla gratuita de documentación de infraestructura en Excel?
Sí, y Excel hace la mayor parte del trabajo. Incluye el inventario del sistema con niveles de criticidad y fechas de última verificación, la matriz de dependencias en ambos sentidos, los detalles de red, el seguimiento de caducidad de certificados y el calendario de revisiones.
¿Hay una plantilla gratuita de documentación de infraestructura en PDF?
Sí, como versiones aprobadas y para todo lo que un auditor o un cliente necesite ver. Mantén las copias de trabajo editables, ya que la documentación de infraestructura que no se puede actualizar rápidamente no se actualiza.
¿Puedo descargar una plantilla gratuita de documentación de infraestructura?
Sí, cada formato se puede descargar gratis sin necesidad de cuenta y sin atribución.
¿Hay plantillas gratuitas de documentación de TI?
Sí. Esta página trata específicamente la infraestructura. Para documentación de TI más amplia, incluidos procesos, políticas y material de cómo hacerlo, consulta Ejemplos y plantillas de documentación de TI, y para procedimientos de TI, la plantilla de SOP de TI.
¿Hay una plantilla de documentación de TI en Word?
Sí, en la página de ejemplos y plantillas de documentación de TI. Esta página es más específica y cubre los sistemas, redes y dependencias que forman tu infraestructura.
¿Hay una plantilla de documentación de proyectos en Word, gratis para descargar?
Sí, en la página de plantilla de documentación de proyectos. La documentación de proyectos cubre el alcance, el plan y los entregables de un proyecto, mientras que la documentación de infraestructura cubre lo que existe en producción independientemente de qué proyecto lo haya construido.
¿Qué es la documentación de infraestructura de TI?
Un registro de los sistemas, redes, servicios y dependencias que componen tu entorno, junto con el conocimiento operativo necesario para ejecutarlos y recuperarlos. Cubre lo que existe, de qué depende cada cosa, cómo es lo normal y cómo responder cuando algo se rompe.
¿Qué debe incluir la documentación de infraestructura?
Un inventario de sistemas con responsables y criticidad, dependencias en ambos sentidos con orden de inicio, detalles de red y conectividad, runbooks para sistemas críticos, métodos de acceso pero nunca credenciales, detalles de copias de seguridad y recuperación ante desastres, incluida la última prueba de restauración con éxito, y una fecha de última verificación en todo.
¿Cómo mantienes la documentación de infraestructura actualizada?
Documenta menos, automatiza todo lo que se pueda descubrir y asocia las actualizaciones de la documentación a tu proceso de cambios para que un cambio no esté completo hasta que la documentación lo refleje. Pon una fecha visible de última verificación en cada registro, revisa por nivel de criticidad y deja que cualquiera corrija errores de inmediato en lugar de abrir un ticket.
¿Las credenciales deben almacenarse en la documentación?
No. No contraseñas, claves de API, cadenas de conexión ni claves privadas, en ningún sistema, temporalmente o de otro modo. Documenta en su lugar qué vault o gestor de secretos guarda la credencial, quién puede conceder acceso y el procedimiento break-glass para emergencias. Eso es lo que alguien realmente necesita durante un incidente y es seguro dejarlo por escrito.
¿Cuánta infraestructura deberías documentar?
Lo suficiente para superar la prueba de las 3 a. m. en sistemas críticos y muy poco para el resto. Los sistemas de nivel 1 necesitan runbooks completos, mapas de dependencias y DR probado. Los sistemas de nivel 3 necesitan una fila de inventario y un responsable. Documentarlo todo con la misma profundidad es la razón por la que la mayoría de la documentación de infraestructura acaba desactualizada.
¿Qué es un runbook?
Un documento operativo para un sistema que cubre cómo es lo normal, qué significan las alertas comunes, cómo reiniciarlo de forma segura incluyendo el orden y los requisitos previos, los modos de fallo conocidos, qué no hacer y cuándo escalar. Es lo que alguien abre durante un incidente y debe escribirse para una persona competente que no esté familiarizada con ese sistema en particular.
¿Cómo documentas las dependencias?
En ambos sentidos, ya que durante un incidente necesitas saber tanto qué requiere este sistema como qué se rompe si se detiene. Incluye el orden de inicio, si cada dependencia es dura o blanda, y dependencias externas como proveedores de identidad, DNS y procesadores de pago, que provocan interrupciones que no puedes solucionar por tu cuenta.
¿Con qué frecuencia se debe revisar la documentación de infraestructura?
Según el nivel de criticidad: trimestralmente para el nivel 1, dos veces al año para el nivel 2 y con cada cambio para el nivel 3. Más allá de las revisiones programadas, el proceso de cambios debe forzar actualizaciones y cualquier persona que descubra un error durante un incidente debería poder corregirlo de inmediato.
¿Cómo sé si mi documentación funciona realmente?
Pruébala. Dale a alguien que no haya construido el sistema solo la documentación y pídeles que realicen una tarea operativa rutinaria, como un reinicio controlado o una restauración a un entorno de pruebas. Todo lo que no puedan hacer es un hueco. Hacer esto anualmente para sistemas de nivel 1 es equivalente a una prueba de restauración y, por tanto, también se omite con la misma frecuencia.
¿Puedo personalizar esta plantilla de documentación de infraestructura?
Sí, cada versión es totalmente editable. Ajusta los niveles de criticidad y los campos a tu entorno. Las dos cosas que merece la pena mantener son la fecha de última verificación y el mapeo de dependencias en ambos sentidos, ya que son las que determinan si la documentación se confía y si ayuda durante un incidente.
