NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux 4: Introduccion a la administracion de sistemas - Documentar todo
Red Hat Enterprise Linux 4: Introducci�n a la administraci�n de sistemas
Si se les da la opci�n de seleccionar entre instalar un nuevo servidor y escribir un documento procedimental sobre como realizar copias de seguridad, el administrador promedio escoger�a instalar un nuevo servidor. Aunque esto no es para nada inusual, usted debe documentar lo que hace. Muchos administradores de sistemas posponen la preparaci�n de la documentaci�n necesaria por una variedad de razones:
"M�s tarde lo hago."
Desafortunadamente, esto usualmente no es verdad. A�n si el administrador realmente tiene la intenci�n de hacerlo, la naturaleza del trabajo es tal que las tareas diarias son usualmente demasiado ca�ticas para "hacerlo m�s tarde". Peor a�n, mientras pasa m�s tiempo m�s se olvida, llevando a un documento mucho menos detallado (y menos �til).
"Para qu� escribirlo? Yo me recuerdo."
A menos que usted sea uno de esos raros individuos con una memoria fotogr�fica, usted no se recordar�. O peor a�n, s�lo recordar� la mitad, sin darse cuenta de que le falta la historia completa. Esto conduce a una p�rdida de tiempo tratando de reaprender lo que ha olvidado o reparando lo que ech� a perder debido a un entendimiento incompleto de la situaci�n.
"Si lo mantengo en mi memoria, no me despedir�n — as� tendr� seguridad laboral!"
Aunque esto puede funcionar por un tiempo, invariablemente conduce a menos — no m�s — seguridad laboral. Piense por un momento lo que puede pasar durante una emergencia. Puede que usted no est� disponible, la documentaci�n puede salvar el d�a dejando que alguien m�s resuelva el problema en su ausencia. Nunca olvide que las emergencias tienden a ocurrir justo cuando la gerencia est� m�s atenta. En tales casos, es mejor tener la documentaci�n como parte de la soluci�n a que el problema sea su ausencia.
Adem�s, si es parte de una organizaci�n en crecimiento, eventualmente habr� necesidad de otro administrador de sistemas. C�mo puede esta persona aprender a respaldarlo si todo est� en su cabeza? Peor a�n, el no tener documentaci�n lo puede hacer tan indispensable que no le permitir� avanzar en su carrera. Puede terminar trabajando para la misma persona que fue contratada para asistirlo a usted.
Con suerte, ya le vendimos la idea de los beneficios de la documentaci�n de sistemas. Lo que nos lleva a la siguiente pregunta: �Por qu� deber�a documentar? He aqu� una lista parcial:
Pol�ticas
Las pol�ticas son escritas para formalizar y clarificar la relaci�n que usted tiene con su comunidad de usuarios. Estas establecen la forma en que se manejan las solicitudes de recursos o de asistencia. La naturaleza, estilo y m�todo de diseminaci�n de las pol�ticas a su comunidad var�an de organizaci�n a organizaci�n.
Procedimientos
Los procedimientos son secuencias de pasos sobre acciones que deben ser tomadas para alcanzar una tarea determinada. Los procedimientos a documentar incluyen procedimientos de respaldo, procedimientos de administraci�n de cuentas de usuarios, procedimientos de reportes de problemas, etc. De la misma manera que la automatizaci�n, si un procedimiento es seguido m�s de una vez, es una buena idea documentarlo.
Cambios
Una gran parte de la carrera de un administrador de sistemas gira alrededor de ejecutar cambios — configurar sistemas para un m�ximo rendimiento, ajustar scripts, modificar archivos de configuraci�n, etc. Todos estos cambios deber�an estar documentados de alguna forma. De lo contrario, se puede encontrar completamente confundido sobre los cambios que realiz� unos meses atr�s.
Algunas organizaciones utilizan m�todos m�s complejos para hacer un seguimiento de los cambios, pero en muchos casos una simple revisi�n hist�rica al comienzo del archivo que est� siendo modificado, es todo lo que se necesita. Como m�nimo, cada entrada en la revisi�n hist�rica deber�a contener:
El nombre o iniciales de la persona que est� ejecutando el cambio
La fecha en que se realiz� el cambio
La raz�n del cambio
Esto genera entradas concisas pero �tiles:
ECB, 12-Junio-2002 — Entrada actualizada para la nueva impresora de Contabilidad (para apoyar la habilidad de impresi�n duplex de la impresora de reemplazo)
