En lugar de una gran y aterradora documentación, ¿qué necesitan los administradores de sistemas? Necesitas repositorios para almacenar la información que te ayudará desde la perspectiva de la gestión del tiempo. Tu jefe puede tener sus razones para querer que mantengas la documentación, pero te recomiendo que tu inspiración sea algo diferente. Construye repositorios de documentación que te sirvan a ti y a tus necesidades de gestión del tiempo, no a las necesidades aparentemente irrelevantes de tu jefe o del departamento de calidad. En concreto, los SA necesitan dos repositorios:
El primer repositorio le ahorra tiempo al hacer que los clientes sean más autosuficientes. Evita que te molesten. ¿Por qué iban a llamarte para preguntar algo cuando podían leerlo? De este modo, sólo le llamarán cuando necesiten una aclaración. Muchos clientes prefieren la vía de la autoayuda simplemente porque les evita la vergüenza de hacer preguntas tontas.
El segundo repositorio es útil porque tú lo haces útil. En concreto, registra todos los procesos, procedimientos y materiales de referencia que necesita al alcance de su mano. Es otra oportunidad de almacenar algo digitalmente para que no ocupe espacio en tu cerebro. Reduce el trabajo que tiene que hacer tu cerebro para que puedas estar más concentrado. La concentración es buena.
Sugiero dos repositorios porque uno debe ser de libre acceso para todos los clientes, mientras que el otro puede contener información sensible que debe ser restringida por razones de seguridad.
En estos dos repositorios deberías acumular:
Pondrás esta información en un sitio web con una zona pública y otra privada. Para que sea fácil empezar, incluiré una plantilla para cada depósito. Para facilitar la actualización, te recomiendo que utilices un Wiki. Si no estás familiarizado con los wikis, los describo en detalle en la próxima sección “Tecnología Wiki”. Por ahora, sólo recuerda que un Wiki es un sitio web que es muy fácil de actualizar.
Puedes eliminar el miedo a que el repositorio nunca esté terminado declarándolo como un documento vivo. En lugar de algo que hay que reimprimir cada vez que se hace un cambio, simplemente mantienes el repositorio en la intranet. Lo actualizarás cada vez que tengas que hacerlo. “Hecho” no significa que esté completo y listo para imprimir, sino que el repositorio inicial ha nacido y está listo para crecer.
El primer sitio web es de lectura pública y contiene la documentación de los clientes de TI.
Cuando un cliente navega a su repositorio de documentos, la página principal debe ser muy simple. He aquí una plantilla. Cree una página principal con los siguientes títulos
| Cómo obtener ayuda | Incluya algunas formas en una lista con viñetas. |
| Cómo solicitar nuevos servicios | Enumera unos cuantos servicios que alguien podría necesitar activar y proporciona una lista o un enlace sobre cómo empezar. Algunos ejemplos podrían ser el acceso a la VPN y cómo solicitar un espacio web externo. |
| Políticas | Una lista con viñetas de los enlaces a las políticas que tiene escritas, además de los enlaces a las páginas equivalentes de RRHH o Legal. |
| Un único lugar para encontrar todas las políticas escritas | Con enlaces a las páginas equivalentes de RRHH y del departamento jurídico. |
Esta plantilla debería ser suficiente para cualquier grupo pequeño de administración de sistemas que aún no tenga un sitio web similar. Si usted es una organización de TI o CIO tan grande que se ríe de mi pequeña plantilla, probablemente ya tiene una enorme página de inicio/sitio web y no necesita una plantilla de este tipo de todos modos. Sin embargo, me sorprende la cantidad de organizaciones de CIO que tienen sitios web a los que les falta al menos uno de los elementos anteriores. También me parece que las grandes organizaciones están formadas por equipos más pequeños, cada uno de los cuales puede beneficiarse de su propio repositorio.
Las políticas de TI son las normas por las que se rigen los usuarios de sus ordenadores/redes. Incluyen las políticas de seguridad, los acuerdos de nivel de servicio, las políticas de uso aceptable, las directrices éticas, las directrices de acceso/información privilegiada, etc. En Políticas de TI, enlaza con cada una de las políticas escritas que ya tienes, ya sea en formato HTML, Word o PDF. Si no tienes ninguna política, no incluyas este apartado todavía. Sin embargo, añada a su lista de tareas cualquier política que crea que debería tener. Si buscas inspiración sobre qué políticas añadir o cómo escribirlas, lee el Capítulo 7 (Seguridad) y el Capítulo 9 (Ética) de The Practice of System and Network Administration. Recomiendo empezar con una política de uso aceptable. Si tu departamento legal o de RRHH mantiene políticas relevantes, enlaza con ellas. Si estas secciones no hacen nada más que resaltar las políticas que te faltan, eso es algo bueno.
Esta plantilla es sólo un comienzo. Con el tiempo, se dará cuenta de las cosas que hay que añadir o de los cambios que hay que hacer.
Si tiene tiempo y recursos, el siguiente paso es mejorar esta página de inicio para que la gente quiera establecerla como su página web por defecto. Esto animará a la gente a ir a su sitio web con frecuencia y a utilizarlo cuando necesiten, por ejemplo, consultar una política de TI. Añade elementos útiles, como un cuadro de búsqueda en Google, teletipos o noticias de la empresa. Establécela como página por defecto en cualquier máquina nueva que instales.
El segundo repositorio contiene la documentación interna de TI: documentos que son útiles para ti y para la gente de tu equipo. Estos documentos contendrán información sensible y, por lo tanto, deberían estar protegidos de alguna manera, posiblemente con una simple contraseña. Este repositorio suele ser un área protegida por contraseña del otro repositorio.
Si aún no tienes un repositorio de este tipo, aquí tienes una plantilla:
Exploremos cada uno de ellos un poco más.
En Contactos con proveedores, cree un enlace a cada proveedor con el que trate. El destino de cada enlace debe ser una página para ese proveedor que enumere el número de teléfono de su vendedor, el número de teléfono de soporte y la información que necesitará cuando llame por un problema del sistema. Por ejemplo, en el caso de un proveedor, enumero el número de teléfono, los elementos de su menú telefónico y las respuestas a las preguntas que sé que me harán: el número de teléfono que utilizan para buscar mi perfil, mi número de contrato de mantenimiento, etc. Si un proveedor tiene un contrato de mantenimiento único para cada equipo que le he comprado, pongo toda esa información en una tabla. Esa tabla también incluye un enlace al procedimiento de recuperación de contraseñas para ese dispositivo, así como un enlace a una copia en caché local de ese procedimiento.
Puede que quieras utilizar algún tipo de función de inclusión del lado del servidor para hacer una página que contenga todas las demás páginas. Puedes imprimir la megapágina de vez en cuando y guardar una copia en tu sala de ordenadores para emergencias. Si eres realmente genial, escribirás un script que imprimirá automáticamente el documento a primeros de mes si ha cambiado desde el mes anterior.
Cada vez que trato con un proveedor, utilizo esta página para ponerme en contacto con él, aunque la información esté también en mi agenda personal. Así sé que la página está actualizada en el repositorio central. Si veo que ha quedado desfasada, la actualizo en ese mismo momento.
Nunca vas a enumerar todos los procedimientos de todo lo que haces, y no es necesario. Sin embargo, mi consejo es que documentes los procedimientos complicados que no haces con frecuencia y los procedimientos que odias hacer.
Un ejemplo de procedimiento complicado es romper un espejo RAID, y luego volver a unirlo/reconstruirlo. Puedes “romper el espejo” (es decir, separar el disco principal de su espejo) antes de hacer una actualización del sistema operativo. Si la actualización falla, puedes montar la mitad del espejo que no se actualizó. Si la actualización tiene éxito, puedes volver a unir y reconstruir el espejo. Los comandos para hacer todas esas cosas suelen ser relativamente complicados. Por lo tanto, la próxima vez que haga este tipo de cosas, cree una página web y registre los comandos que utilizó y tome notas sobre cómo construyó los comandos. En el futuro, puedes consultar esta página y todo será más rápido.
Si hay muchas formas de hacer algo pero sólo una de ellas es la adecuada para tu entorno, documenta esa forma específica (y por qué es la correcta). A menudo, un documento HOWTO que se encuentra en la web o como parte de una distribución de software enumera muchas maneras de hacer algo, pero usted ha aprendido que sólo una de ellas es apropiada para su entorno. Puede que quieras pegar todo el documento HOWTO en tu repositorio y añadir comentarios, como “Usa la opción 3”, “No hagas eso” o “Este atajo funcionó en el servidor B, pero haz la versión larga en todos los demás sistemas”. Utiliza colores para tus comentarios para que destaquen. Asegúrate de respetar los derechos de autor del documento original.
A menudo creo documentos que son simplemente listas de comprobación. No es tan intimidante como escribir un documento enorme que describa por completo cada pequeño detalle. No tengo facilidad para recordar los detalles, así que las listas de comprobación se han convertido en una forma de vida para mí. Como el repositorio es fácil de actualizar, otras personas contribuirán al documento con el tiempo. A menudo se convierte en un documento completo.
Los otros procedimientos que deberías documentar son los que no te gusta hacer. Por supuesto, estaría bien documentar todo lo que haces, pero ¿quién tiene tiempo? En lugar de eso, documente los procesos que no le gustan porque eso crea los materiales necesarios para formar a otra persona para que haga esos procesos. Personalmente, odio crear cuentas. Aunque he automatizado el proceso todo lo que he podido, sigue siendo un dolor. Muchas cosas no se pueden automatizar, especialmente mi lista de verificación de cosas como “Visitar al cliente en su primer día para ver si tiene alguna pregunta” y “Repetir la visita una semana después como seguimiento”. Así que he documentado el comando que ejecuto para crear la cuenta, cómo pruebo para asegurarme de que la cuenta se ha creado correctamente, y otras cosas que hay que hacer cuando se incorpora un nuevo empleado. No es Guerra y Paz; ni siquiera está en forma de párrafo. Es sólo una lista con viñetas y algunas anotaciones. Pero ahora que está documentada, tengo la esperanza de endosársela a otra persona. En el capítulo 2, hablé de delegar. Un buen repositorio de documentos es una forma excelente de facilitar la delegación de una tarea.
Diablos, esa es mi estrategia general para conseguir más personal. Documento todas las tareas que odio hacer, que daría a un asistente si tuviera uno. La próxima vez que haya una oportunidad de contratación, puedo consultar el repositorio para obtener una lista de lo que debo incluir en la descripción del trabajo para mi nuevo asistente: crear cuentas, cambiar las cintas de copia de seguridad, arreglar los problemas habituales de las impresoras, etc. Dios, ¿no es una coincidencia increíble que esas cosas ya estén bien documentadas y listas para que otra persona se haga cargo?
Las oportunidades de contratación son escasas, pero está bien. No necesito una persona a tiempo completo. Cuando el grupo de desarrollo contrata a alguien para mantener el sistema de construcción de software, ahí estoy yo con la página web de procedimientos y tareas que puedo endilgarle. ¿No soy un canalla?
Por último, incluya sus diagramas de red. Enlaza con los que ya existen. Si no tienes ninguno, haz uno sencillo para empezar, como un diagrama de la WAN o un diagrama que muestre tu LAN y el nombre de los principales servidores, y luego dibuja una gran nube que represente todos tus hosts de escritorio/portátiles. En un trabajo, me di cuenta de que tenía que dibujar repetidamente un diagrama de red concreto en una pizarra cercana para ilustrar mi idea. (El diagrama consistía en cuatro puntos que representaban nuestras cuatro sedes, los cinco enlaces WAN que las conectaban y una flecha hacia una nube que representaba la conexión a Internet). Añadir este diagrama sencillo y fácil de reproducir al repositorio fue una forma rápida de empezar. En 10 minutos, deberías ser capaz de crear tu primer diagrama y ponerlo en línea.
Los verdaderos administradores de sistemas de sangre caliente probablemente insisten en Visio con iconos de servidor fotorrealistas y colocaciones precisas al milímetro, pero eso es una ratonera. ¿Alguna vez has empezado a dibujar un diagrama y de repente te has dado cuenta de que te has pasado todo el día haciéndolo bien? No hay queso en ese agujero. Dedica 10 minutos, no 10 horas. De hecho, prefiero utilizar herramientas que no me permitan hacer un trabajo extremadamente detallado y perfecto, de modo que me vea obligado a captar la esencia de cómo debería ser el diagrama y no a juguetear con los detalles. A menudo hago los diagramas con PowerPoint y guardo el original y una copia en PDF en el repositorio.
Si realmente no puedes controlar el deseo de dibujar el diagrama perfecto, haz un boceto en una pizarra y saca una foto con una cámara digital barata; guarda la foto en el repositorio. Es rápido y funciona muy bien. (Si alguien se queja de que hay que volver a dibujarlo en un paquete de dibujo más serio, asegúrate de que tiene acceso por escrito al repositorio y dile: “Espero tus resultados”).
Documenta también los flujos de datos importantes en la empresa: cómo entra y sale el correo electrónico, dónde están tus servidores de directorio, etc.