¿Cómo registrar los cambios del servidor?

Entonces, probablemente todos hemos tenido esta situación: depura algún problema, solo para darte cuenta de que fue causado por un cambio de configuración que hiciste hace seis meses, y no puedes recordar por qué lo hiciste. Entonces lo deshaces y solucionas el problema, y ​​ahora vuelve algún otro problema. Oh si, AHORA lo recuerdo! Luego lo arreglas correctamente.

¡Es porque no tomaste las notas adecuadas, tonto! Pero, ¿cuál es una buena manera de hacer esto?

En ingeniería, tenemos un montón de software destinado a ayudarnos a detectar y rastrear cambios. Control de fuente, revisiones de código, etc. Se realiza un seguimiento de cada cambio, cada cambio requiere un comentario sobre lo que es. Y los departamentos de ingeniería típicos requieren buenos comentarios para que, en seis meses, cuando descubras por qué lo rompiste así, puedas usar una característica histórica de 'culpa' o compilaciones de búsqueda binaria para identificar el problema. Estas herramientas son herramientas de comunicación y registros históricos muy efectivos.

Pero en serverland, tenemos 500 servicios diferentes, todos con diferentes formas de configurarlos. Y no siempre tienen un formato de texto (considere establecer permisos en una carpeta o alterar la ubicación del archivo de paginación) aunque pueden tener una representación textual.

En nuestro entorno, verificamos qué archivos de configuración podemos en Perforce, pero hay muy pocos de esos. No se puede registrar exactamente en la base de datos de Active Directory ... aunque quizás un volcado que podría diferirse ...

En el pasado, intenté mantener un registro de cambios manuales en nuestra wiki, pero es muy difícil mantener la disciplina para hacerlo (lo sé, no es una buena excusa, pero es realmente difícil).

MI PREGUNTA: ¿Qué estrategias y herramientas utiliza para hacer frente a este problema de seguimiento de los cambios de configuración en sus servidores?

- Actualización -

Nota: No busco herramientas para tomar notas compartidas (estoy familiarizado con OneNote, etc.), sino herramientas automatizadas específicamente destinadas a ayudar con el seguimiento de los cambios del servidor. No existe una herramienta integral para rastrear los cambios en la configuración del servidor, pero quizás haya algunas para aplicaciones específicas como GPO.

También estoy muy interesado en estrategias específicas que te han resultado útiles. "Compartimos notas en Sharepoint" es bastante vago. ¿Cómo mantienes la disciplina? ¿Qué formato utiliza para rastrear sus cambios? ¿Cómo organizas tus datos de cambio? Realmente me gustaría ejemplos e ideas.

En tierra de Linux, la gente está siguiendo un par de estrategias diferentes:

• Sistemas de restricción de configuración , como cfengine o puppet o chef . Estos son similares a los GPO de Windows. Señale que toda la configuración del servidor está documentada intencionalmente en un solo lugar y usted sabe con qué granularidad (sala de servidores, grupo, servidor específico) se promulga la política. Esto no te salvará de "¿qué demonios era diferente hace seis meses?" pero te permite destruir una configuración de servidor y reconstruir desde cero. Puede poner las políticas de cfengine y títeres bajo control de revisión para responder la pregunta.
• Revisión de control / etc . En general, los programas de Linux almacenan su configuración en un solo lugar, / etc. Los osados ​​están comenzando a escribir scripts para poner / etc en el control de revisión. Uno de esos programas que conozco es etckeeper :

Descripción: almacenar / etc en git, mercurial, bzr o darcs
 El programa etckeeper es una herramienta para permitir que / etc se almacene en un git, mercurial,
 repositorio bzr o darcs. Se conecta a APT para confirmar cambios automáticamente
 hecho a / etc durante las actualizaciones de paquetes. Realiza un seguimiento de los metadatos del archivo de esa versión
 los sistemas de control normalmente no son compatibles, pero eso es importante para / etc, como
 como los permisos de / etc / shadow. Es bastante modular y configurable, mientras que
 También es fácil de usar si comprende los conceptos básicos de trabajar con la versión
 controlar.

Uno de los problemas en esta situación es que, realmente, es una combinación de proceso de negocio / problema tecnológico. Y definitivamente es más grande que simplemente rastrear los cambios que hizo un administrador. También debe estar atento a los cambios inesperados, y una buena coordinación entre los administradores o las unidades para que un cambio en un controlador AD no rompa la configuración de permisos de la base de datos en algún servidor departamental. Es decir, tu pregunta es una lata gigante de gusanos :)

En mi organización, estamos cerca de un año en la implementación de procesos y sistemas para abordar esto. Por el lado del proceso comercial, formamos un equipo de Gestión del Cambio. Según SOP, todos los cambios en los entornos de producción se coordinan a través de ellos. Recopilan todos los cambios, junto con el alcance, los sistemas afectados, los servicios afectados, etc. Aplican una buena documentación sobre los cambios, así como los planes de implementación y de reversión. Organice reuniones semanales (abiertas) para revisar los próximos cambios en el entorno, luego envíe correos electrónicos que detallen todos estos cambios. El objetivo final de este proceso es que, efectivamente, todos en TI sepan todo lo que está sucediendo. Esto ayuda a detener el problema de, por ejemplo, que un SysAdmin instale un parche de kernel y reinicie un sistema que eliminará la base de datos de reloj.

En cuanto al aspecto tecnológico, solo puedo hablar de los chicos de Unix / Linux, ya que no trato con Windows. Han estado implementando Puppet, por Reductive Labs, para la gestión de la configuración de todos esos sistemas. Simplemente, es un sistema cliente / servidor donde se define una configuración de máquina en el servidor, y el cliente aprovecha esas oportunidades de vez en cuando (30 minutos por defecto). Además, si se da alguna posibilidad a los archivos administrados localmente, también se revierten en ese momento. Lo usamos para administrar servicios en ejecución, configuraciones de firewall, autorización de usuario, etc.

También recomendaría buscar algo como TippingPoint. Es un servicio al cliente que vigila la configuración del sistema y envía alertas sobre los cambios. Nos hace más felices a la gente de seguridad. Se utiliza principalmente para rastrear cambios maliciosos o inéditos.

He estado en 4 o 5 empresas ahora realmente no recuerdo.

Todos tuvimos este problema. Ninguno de nosotros lo hemos resuelto al 100 por ciento, pero en la compañía en la que estoy ahora tenemos lo que creo que es la mejor estrategia hasta la fecha.

Sharepoint / Wiki / Evernote / PIN

• Sharepoint
  • gemir todo lo que quieras ... tiene algunas características muy buenas de la lista.
  • Listas de direcciones IP
  • inventario
  • cuentas de servicio y uso
  • cambiar registros de notificaciones
• Wiki
  • Cómo hacerlo
  • listas de tareas de largo alcance
• Evernote
  • mi compañero y yo usamos esto para poner todo lo que no queremos en Wiki
  • Más instrucciones prácticas de naturaleza técnica.
  • notas de scratch que ambos necesitamos ver
  • contabilidad de tareas para la semana
  • listas de tareas del contratista
  • evernote clipper facilita la captura de pantalla de la configuración de AD / derechos
  • disponible en todas partes
• Patas
  • Repositorio de contraseñas

Probablemente haya mejores herramientas para algunos de estos, pero esto es lo que usamos:

• Rastree cambios de configuración y actualizaciones / parches por servidor en una wiki privada
• También conserve los howtos y un registro de problemas / soluciones en la wiki
• Use Sharepoint o Google Docs para mantener copias autorizadas de cosas como listas de IP estáticas
• use Subversion para rastrear cambios en los archivos de configuración

Para Windows, consulte la serie Microsofts System Center o cualquier otro competidor en configuración y administración de servicios para esa plataforma.

Los cambios deben enrutarse a través de una rutina de gestión de cambios decente que los apruebe y registre antes de que realmente se realicen. Esto puede ser 100% manual para principiantes. Con algunas de las mejores herramientas integradas, puede pedirle a la herramienta que realice los cambios reales y logre el cierre de sesión "automático" en una base de datos de configuración central, en lugar de ir directamente a la consola de un servidor individual, cavando la configuración manualmente para intenta solucionar un problema al estilo vaquero.

Absolutamente debe tener un proceso de gestión de cambios, especialmente si hay varias personas que tienen la capacidad / acceso para realizar cambios en el nivel del sistema en su entorno. Esto también proporciona una forma para que la administración apruebe los posibles cambios, sin embargo, la desventaja es que induce latencia en el proceso de cambio si no puede hacer cambios sobre la marcha.

Algunas formas de rastrear cambios pueden incluir la validación de eventos en su SEM (suponiendo que tenga un Administrador de eventos de seguridad) o herramientas como Nessus (con mucho trabajo puede auditar su entorno para encontrar cambios).

Esta es una respuesta más localizada, basada en * nix. No he encontrado ninguna buena herramienta para emularlo en Windows.

Hay algunas maneras de implementar esto ... y atraparlo cuando lo olvides.

Los sistemas de control de revisiones como subversion, git, cvs o RCS son una buena forma de rastrear el historial de un archivo de configuración. Si no desea instalar un sistema de control de revisión en sus servidores de producción, el almacenamiento de directorios de archivos de configuración de forma local o remota utilizando algo como rsnapshot le dará la mayoría de los beneficios de un RCS, pero pierde la posibilidad de auditar o dejar el compromiso registros (aunque esto podría solucionarse con comentarios dentro de los propios archivos).

Para ayudarle a acordarse de registrar los cambios, generación automática de informes de cambios de configuración a través de una noche, cron'ed cable trampa Run es un buen inicio. Después de construir la base de datos de Tripwire del estado actual de los archivos, cualquier cambio en ellos generará un correo electrónico durante la próxima ejecución. Continuará recibiendo este correo hasta que se actualice la base de datos, lo que "restablecerá" el cable trampa.

Usaría un sistema de seguimiento de problemas como flyspray (cualquiera servirá, pero me gusta flyspray para cosas que no son de programación). Antes de que alguien toque una configuración, la mejora / problema debe registrarse. Cuando lo arregla / implementa, los cambios van en el ticket.

Un wiki puede ser bueno para documentar la configuración actual, pero es fácil que se desactualice, y parece que toma más esfuerzo actualizar la OMI.

No va a encontrar algo automatizado para hacer esto, aunque probablemente podría configurarlo para que los cambios en ciertos archivos de configuración se envíen automáticamente al rastreador de problemas si lo desea.

Creo que se trata solo de una buena política, herramientas y disciplina de baja barrera.

Creamos algo de cosecha propia para hacer el seguimiento del registro de cambios en nuestro entorno; No es nada súper complicado, y funciona bastante bien.

• Una política de autocontrol se configura para que cualquier cambio que, en su estimación, se desvíe de una configuración lista para usar o pueda causar problemas, debe documentarse en el sistema de registro de cambios.
  • El lado opuesto de esta 'moneda' es si está solucionando un problema, busque entradas de registro de cambios recientes o relacionadas.
• Inicie sesión en el sistema y elija el servidor, servicio o componente de hardware que está cambiando
  • los componentes se ingresaron previamente en el mismo sistema con información básica 'demográfica' (ubicación, proveedor, número de serie, departamento responsable)
• Elija de un menú desplegable de categorías básicas
  • Tiempo de inactividad no programado
  • Parchear
  • Mantenimiento de hardware
  • Instalación de software
• Poner detalles de lo que hizo, vio, observó
• Se envía una copia a la parte responsable y se almacena como archivos XML indexados por un dispositivo de búsqueda.
• Lucro

Como dije, nada lujoso. Utiliza PERL CGI (fue escrito hace mil millones de años) y un dispositivo de búsqueda de Google para la indexación.

Deficiencias:

• Es difícil trabajar con grupos de servicios, por ejemplo, acaba de agregar el mismo parche a los 25 controladores de dominio; no tenemos un grupo "Controlador de dominio", por lo que tenemos que seleccionarlos manualmente
• No se integra con el hardware, el software o el informe de errores del registro de eventos para ayudar con la resolución de problemas
• en relación, entrada manual de datos para todos los datos 'demográficos' como dije anteriormente

De todos modos, si después de todo lo que le interesa el código, hágamelo saber y probablemente pueda obtenerlo para compartirlo.

Como se dijo, a menudo es un problema cultural: después de todo, algunas tiendas de desarrollo ya no se molestan con los comentarios (¡el código de autodocumentación es una palabra de moda hoy en día!) Y algunos usan un sistema de control de versiones como un santo grial de registros históricos. Obviamente, estos no son perfectos.

Entonces, la única forma verdadera de solucionarlo es hacerlo una solución cultural. Asegúrese de que todos los motivos del cambio estén registrados en un rastreador de errores (o base de conocimiento o wiki), y asegúrese de que todos los cambios estén registrados en un sistema de control de cambios.

Tenemos clientes de servicio de emergencia, cada cambio que ocurre en su sistema se registra, y cada vez que iniciamos sesión en su sistema, tenemos que registrarlo. Para algunos de ellos, primero tenemos que pedir permiso por teléfono (¡y supongo que también lo registran!). Cada cambio se registra, y será un delito disciplinario cambiar el sistema del cliente sin registrarlo.

Suena oneroso, pero no lo es. Rápidamente se acostumbra a agregarse al registro de acceso y al registro de cambios; no es peor que tener que escribir un comentario al registrar un cambio de código.

Recomiendo un rastreador de errores como registro de razón de control de cambios, ya que generalmente son fáciles de actualizar (uso Mantis).

Si está buscando la "solución empresarial" (es decir, tiene más dinero que Dios y quiere tener una herramienta realmente genial), la herramienta que solía apoyar y proporcionar trabajo en el sitio lo hace como una de sus múltiples funciones.

No tengo idea de cuál es el precio base, pero antes de que HP comprara Opsware, era de ~ $ 350,000 US (sin soporte, y créanme, querían soporte cuando comencé con Opsware).

Varios de los clientes que teníamos mientras trabajaba allí utilizaron la configuración de la aplicación y las características de la instantánea junto con Tripwire .

Por supuesto, si no tiene presupuesto, esta es una Bad Choice ™ :)

Y, fwiw, el anuncio que apareció en la parte superior de esta página para mí cuando lo volví a cargar fue para spiceworks . Se ve muy similar a HPSA :)

Si todo lo que desea hacer es realizar un seguimiento de los cambios y no administrar todo el proceso (es decir, a través de Chef o Puppet), solo rsyncsu etcdirectorio (donde sea que esté) en un repositorio local de git.

for HOST in alpha bravo charlie delta ...; do

    rsync -avz --exclude-from=exclusions -e ssh admin@$HOST:/opt/local/etc/ ./$HOST

done

Por supuesto, puede agregar otras fuentes según sea necesario.