Siempre me interesa cómo los equipos de TI abordan la planificación de los cambios de producción. Normalmente utilizamos runbooks para diseñar los pasos clave de un cambio, así como los planes de retirada. Tengo muchas ganas de ver si podemos aprender de los demás y cuál es la mejor manera de documentar los runbooks.
Respuesta1
Prefiero guiones con comentarios y estampados.
Tienen la doble ventaja de documentar y automatizar.
Pero, adoptando un enfoque más holístico, generalmente hay muchas cosas que rastrear,
las secuencias de comandos son solo para cosas que deben hacerse en una secuencia.
Cuando hay muchas notas involucradas, prefiero un Wiki alojado localmente (personalogrupo).
Se puede utilizar para
- Consulte sus herramientas con enlaces y escriba notas rápidas.
- enumerar contactos y referencias de escalada
- documentar los pasos de emergencia basados en palabras clave
- Ubicaciones de respaldo y secuencias de recuperación.
- alojar un registro con capacidad de búsqueda de requisitos y soluciones habituales; Entonces la gente acude a ti después de haberlo comprobado.
Pero simplemente mantenga la ubicación segura: no querrá que los datos queden inaccesibles en caso de emergencia.
Aquí hay un viejoRunbook de Microsoft Technet SQL Serverpágina para captar ideas genéricas.
Respuesta2
Lo que hago:
Toda la configuración del servidor que necesita cambiar desde la línea base del sistema operativo instalado es administrada por Chef, que se almacena en módulos (llamados libros de recetas), que luego se almacenan en el control de versiones a través de Git.
La mayor parte de la configuración se realizó manualmente en un sistema de prueba (a menudo una imagen de VM o simplemente una instancia EC2) y luego se escribió una receta de configuración para cubrir todos los distintos componentes de los cambios. La actualización del flujo de trabajo del entorno es algo como esto:
- Cree un ticket en el sistema correspondiente de que es necesario realizar un cambio.
- Documente todos los porqués y qués del cambio.
- Edite las recetas de configuración, plantillas, archivos, etc., necesarios para que el cambio se produzca en el sistema o sistemas de destino.
- Confirme el cambio en el repositorio local y envíelo al servidor de control de versiones maestro.
- Actualice el ticket para la revisión por pares de los cambios.
- Los cambios se aprueban y el cambio se implementa en el servidor Chef para que conozca los bits actualizados.
- Ejecute Chef manualmente en los clientes o déjelo ejecutar automáticamente según los requisitos del cambio. (No ejecutaría, digamos, más de media docena de sistemas a mano).
El modo de operación de Chef falla si hay un problema al ejecutar el cliente, como si no existe un paquete, no se encuentra un archivo de plantilla o muchos otros problemas. Solucione el problema, documente el ticket y luego vuelva a ejecutar el cliente.
La persona con el requisito comercial para el cambio verifica que se haya realizado correctamente y cierra el ticket.
Específico del chef porque eso es lo que uso. Sustituya la herramienta adecuada para su entorno y, si no está utilizando una herramienta de administración de configuración, debe considerar algo, porque hace que todo este proceso sea mucho más sólido y confiable. Por no hablar de escalable.
Respuesta3
Para cambios realmente críticos y sensibles, normalmente tendré un archivo de texto con los comandos reales que usaré con #comentarios que explican lo que está sucediendo. De esa manera, puedo cortarlos y pegarlos rápidamente en una terminal.
Respuesta4
Apoyaría la idea básica detrás de la publicación de jtimberman, siendo el títere mi herramienta preferida.