Mejores prácticas para la gestión del cambio en el centro de datos.La gestión del cambio puede ser un camino complejo lleno de baches. Aprenda algunos consejos de navegación para aplicar en su organización.
La ironía de trabajar en la administración de sistemas o redes es que usted está allí para mantener el statu quo (o como me gusta expresarlo, «preservar el orden en un mundo caótico») y, sin embargo, una gestión cuidadosa del cambio también es su trabajo.
La entrega efectiva de servicios y recursos exige que mantenga el mejor tiempo de actividad posible mientras realiza la transición de lo antiguo a lo nuevo, ya sea reemplazando la tecnología o simplemente mejorando.
La gestión de cambios (también conocida como gestión de configuración) no siempre es segura o fácil. Por otro lado, si solo hiciéramos lo que era seguro en TI, todos podríamos estar ejecutando Windows NT 4 SP6a. El lanzamiento de nuevos sistemas y tecnologías parece estar llegando más rápido e incluso más furioso todo el tiempo. He visto sistemas implementados un año y luego arrancados el siguiente para allanar el camino para algo mejor. El conservador fiscal en mí a veces está horrorizado por el posible desperdicio involucrado en esto; El lado tecnólogo de mi naturaleza se deleita en el despliegue de cosas nuevas.
A lo largo de los años, he recogido algunas pautas para la gestión del cambio que quería compartir. Algunos provienen de la experiencia directa, otros de mentores y algunos más de observar los peores escenarios en acción en las compañías de amigos o colegas.
Cuando me refiero a la gestión de cambios, me refiero a instalaciones tecnológicas, actualizaciones, parches y migraciones (como un servidor físico a una máquina virtual). Tenga en cuenta que existen procesos formales de gestión del cambio , como los relacionados con la Biblioteca de infraestructura de tecnología de la información (ITIL). También hay paquetes de software dedicados como Evolven y McCabe CM que ayudan a estos esfuerzos. Si bien parte de este material se superpone con este artículo (y puede ser el tema de futuras columnas), mi comentario aquí implica un conjunto más informal de consejos basados en las buenas prácticas que he observado en compañías exitosas.
Nunca puedes tener demasiada redundancia
La mayoría de los profesionales de TI no necesitarán ser vendidos en esto (el desafío puede estar en convencer a los departamentos de finanzas), pero cualquier cosa de misión crítica necesita un gemelo. Esto se aplica a servidores, hardware de red e incluso almacenamiento. Si lo necesita para administrar su negocio, asegúrese de que haya dos de todo. Si no puede tener dos, descubra cómo puede improvisar un sistema de reemplazo si el principal no está disponible. Por ejemplo, hace unos años configuré un servidor de archivos de Windows con todos los datos compartidos alojados en un volumen SAN. No teníamos el presupuesto para una solución oficial de agrupamiento o equilibrio de carga, por lo que desarrollé un plan de conmutación por error con un servidor de respaldo:
Analicé y probé el método para montar el volumen SAN del servidor en el servidor de respaldo.
Exporté el recurso compartido de archivos de configuración del servidor principal de registro en una base nocturna, guardarlo en la unidad C: del servidor de respaldo.
Configuré el tiempo de vida del registro DNS del servidor primario (TTL) durante 5 minutos.
Deshabité el nombre de la comprobación estricta en el registro del servidor de copia de seguridad para que los clientes puedan conectarse a él a través de cualquiera de nombres DNS que deseaba (por defecto el sistema operativo de servidor Windows impide que esto).
Documenté todo el procedimiento de conmutación por error.
Esto significaba que el servidor de respaldo podría «convertirse» en el servidor primario con mucha facilidad simplemente actualizando el registro DNS asociado y los usuarios podrían ser redirigidos a él en poco tiempo (muchos ni siquiera notarían la interrupción). Esto incluyó asignaciones de unidades y acceso a archivos compartidos. Documentarlo significaba que cualquiera de mis compañeros de trabajo también podía seguir los pasos.
Cuando se trata de componentes redundantes, hágalos idénticos en todas las formas posibles para que su compatibilidad sea lo más predecible posible: deben ser del mismo fabricante / modelo, ejecutar el mismo sistema operativo, tener los mismos controladores y revisiones, enchufados en el mismo puertos en diferentes conmutadores o PDU, y así sucesivamente.
Hay otro consejo crítico que implica la redundancia …
Espaciar los cambios entre sistemas redundantes
Su redundancia le dará una tremenda influencia cuando se trata de aplicar cambios, ya que puede reducir la mitad de un par redundante para moverlo o actualizarlo, luego haga lo mismo para la otra mitad. Sin embargo, nunca haga esto sin dejar un espacio de tiempo intermedio para asegurarse de que el primer cambio fue exitoso. Al parchear servidores, por ejemplo, no parchees el segundo conjunto de sistemas hasta que hayan pasado varios días para que tengas tiempo para detectar y corregir cualquier problema … durante el cual deberás confiar en los sistemas que siguen siendo funcionales.
Use una solución centralizada para implementar actualizaciones
Para la gestión del cambio de calidad, siempre debe optar por la menor cantidad de complejidad, lo que significa un sistema interno centralizado para enviar parches, software, actualizaciones de antivirus y ajustes de configuración. Esto le permitirá tener la mejor oportunidad de rastrear sus sistemas y planificar sus cambios, así como informar sobre los resultados. Los ejemplos incluyen Windows Server Update Services de Microsoft, System Center Configuration Manager de Microsoft, Microsoft Group Policy (parte de Active Directory), Symantec Endpoint Protection Manager y Dell Management Console. Estos productos le brindarán un punto de referencia único y garantizarán que sus clientes y servidores no solo descarguen actualizaciones de Internet de manera involuntaria (o peor aún, si no lo hacen y no le informan).
No destruir antes de terminar y validar
He visto muchas películas de terror en mi día, pero ninguna de ellas fue tan aterradora como el concepto de arrancar un sistema existente para reemplazarlo por uno nuevo. Ya sea un servidor de archivos, un servidor de correo electrónico, un dispositivo de almacenamiento u otra cosa, siempre debe migrar a un nuevo sistema, dejando el antiguo intacto hasta que haya pronunciado el cambio completo. No desmantele nada hasta que esté obsoleto.
Por ejemplo, si actualiza un servidor de archivos de Windows 2008 a un sistema Windows 2012, copie todos los datos (¡con permisos!) Del cuadro anterior al nuevo y haga que los usuarios prueben el acceso. En una ocasión, durante este esfuerzo, encontré algunos problemas con el controlador de red en el nuevo servidor que me obligaron a recortar a los usuarios en el sistema anterior. ¡No me importó este paso ya que me sentí afortunado de tener el viejo sistema disponible para usar!
Crecí en la década de 1970 y disfruté mucho del espectáculo «Los duques de Hazzard». Me gustaron especialmente las escenas en las que los viejos y buenos chicos de Duke saltaron un río o un cañón en el General Lee, ya que la policía generalmente los perseguía, generalmente no elección, pero tratar de hacer ese salto. Me gusta que la vida real sea menos emocionante que la televisión. Subir por la ventana del General Lee no es forma de comenzar un proyecto de cambio en el centro de datos.
Diseñe planes de cambio con múltiples entradas
Al igual que nunca puede tener suficiente redundancia, nunca puede tener suficientes pasos en su plan de cambio y, como cualquier buena fiesta, cuantos más participantes tenga, mayores serán sus posibilidades.
Obtenga tanta información de los demás como sea posible para detectar cualquier peligro que se avecina. Sin embargo, haga su plan inicial lo más exhaustivo posible para que otros no tengan que llenar los vacíos por usted. Entonces, ¿está actualizando el firmware en ese conmutador Cisco y luego reiniciando? ¿Cómo se asegura de que esto sea exitoso? Bueno, podrías hacer ping y luego pronunciar la actualización completa si responde … pero creo que eso solo está rascando la superficie. Inicie sesión, revise los registros de errores y pruebe todas las funciones. Inicie sesión más tarde y asegúrese de que no se bloqueó debido a una pérdida de memoria. Reiniciarlo. Reiniciarlo de nuevo. Conéctese desde otra subred. Tal vez, después de la revisión, alguien más sugiera probar algunas aplicaciones principales que se ejecutan en un servidor que se conecta a través de ese interruptor, lo que le ahorrará un momento de «¡Gotcha!».
No asumas que puedes hacer algo, entonces debe estar funcionando. Haga que alguien más inicie sesión e intente. He visto muchos problemas por los cuales alguien con derechos de administrador podría realizar una función muy bien, pero los derechos de usuario normales no funcionaron como se esperaba, al menos hasta que se modificaron.
Un último punto sobre esto: bajar su lista de verificación varias veces en diferentes sistemas será tedioso y aburrido, y puede sentirse tentado a omitir pasos o tomar atajos, pensando: «Sí, eso ya funcionó dos veces, ¿por qué molestarse?» esa tentación: resístela.
Utiliza múltiples métodos de aprobación
Es genial si puede recibir comentarios de otros sobre lo que debe agregar a su plan de cambio. Sin embargo, las compañías inteligentes hacen que los empleados pongan su dinero donde están sus bocas: promulgue un plan de método de aprobación para obtener la sanción de estas u otras partes apropiadas. Esto puede incluir su jefe, el director de un departamento relacionado o el vicepresidente de su base de clientes. Este proceso de aprobación asegurará que todos sepan, estén de acuerdo y respalden los cambios propuestos. Seamos realistas: si sé que voy a poner mi nombre en un plan que podría afectar el resultado final de mi empresa si explota, me aseguraré de que el proceso sea sólido.
Esta cobertura de seguridad no solo lo cubre si algo sale mal, sino que mantendrá a las personas informadas en caso de falla y puede ayudar a los grupos a trabajar juntos para encontrar soluciones.
Formular un plan de retroceso
Cada cambio debe tener un plan de retroceso asociado. ¿Cómo va a volver a poner las cosas como estaban si algo falla? ¿Utilizará instantáneas, como en un entorno virtual? ¿Reimportará claves de registro cruciales o aplicará una política de grupo de respaldo para devolver una configuración de servidor de Windows a su estado anterior? Debe documentar este plan y hacerlo lo más limpio y elaborado posible. Su creatividad puede verse afectada durante un cambio / actualización fallido y la búsqueda de opciones es lo último que desea hacer durante ese momento estresante. Su plan de retiro puede ser una póliza de seguro que nunca necesitará, pero el seguro también está ahí para su tranquilidad.
Si tiene que retroceder un cambio, asegúrese de hacerlo obteniendo la mayor cantidad de notas, capturas de pantalla u otra evidencia de respaldo que pueda para poder descubrir qué salió mal y corregirlo la próxima vez. La estrategia de «intentar algo por segunda vez y esperar que funcione» es una receta para una entrada desagradable.
Elija su horario de cambio cuidadosamente
Casi no hace falta decir que la mayoría, si no todos, los cambios en el centro de datos deben planificarse después de horas o durante períodos no críticos. Incluso la actualización de los sistemas redundantes puede suponer un riesgo si su servidor secundario decide ir a la huelga a las 10 am del lunes. Sin embargo, planifique su marco de tiempo con cuidado.
PODRÍAS realizar ese cambio de base de datos a las 11 pm del domingo. Pero, ¿qué pasa si algo causa un retraso y la conmutación sigue ejecutándose cuando los usuarios llegan a la oficina siete horas después?
Tal vez elegir las 5 pm de un viernes sería una mejor idea. Uh, bueno, solo tenga cuidado de no verse envuelto en su vida hogareña, de modo que se olvide de verificar los resultados de la actualización hasta que llegue al trabajo el lunes por la mañana.
¿Quizás tiene un sitio secundario que usa para fines de recuperación ante desastres (DR) y lo ha convertido en su sitio principal para probar sus capacidades de conmutación por error? No se esfuerce por actualizar los sistemas en su sitio primario original 12 horas antes de que esté programado para revertir el proceso.
Como dije anteriormente, su cronograma debe ser el producto de las partes interesadas y los grupos involucrados con el uso, el soporte y la administración de estos sistemas (cuando corresponda).
Usar auditorías y cuentas individuales.
Siempre que sea posible, utilice la auditoría en su entorno (incluso si tiene que activarla temporalmente durante un proyecto de cambio, luego desactívela para preservar los recursos). Esto ayudará a realizar un seguimiento de los comandos que se ejecutan en estos sistemas y el impacto resultante.
En una nota similar, no use cuentas compartidas o genéricas como «administrador» si puede evitarlo; estos comandos deben estar vinculados a cuentas individuales (preferiblemente cuentas privilegiadas que se usan solo para realizar este tipo de trabajo; normalmente debe usar una cuenta limitada cuando sea posible). Es cierto que esto no siempre es fácil en un entorno de Active Directory, donde muchas cosas todavía requieren obstinadamente el uso de la cuenta de «administrador» del dominio, incluso cuando se han otorgado (aparentemente) privilegios comparables a una persona nombrada. Sin embargo, siga esta política lo más que pueda.
Admito que este consejo me recuerda una cita del comediante Bill Cosby, quien me enseñó la mayor parte de lo que practico en la paternidad: «Si algo se rompe en la casa, tienes un hijo, ¡sabes quién lo hizo!» No se trata de señalar con el dedo, sino de documentar lo que sucedió y bajo qué cuenta. Si es necesario revertir un cambio o identificar un problema, necesitará esta información.
Siempre programe el tiempo de inactividad en su sistema de monitoreo
Voy a arriesgarme y asumir que tiene un entorno de monitoreo integral configurado para verificar la salud y el tiempo de actividad de sus sistemas críticos y notificarle cualquier problema. Cuando planee desconectar cualquiera de estos sistemas para fines de gestión de cambios, siempre debe programar un período de inactividad razonable en su sistema de monitoreo de antemano para que permanezca en silencio. Dar este paso puede ser una molestia, especialmente para sistemas múltiples, pero la estrategia de ignorar las alertas críticas es demasiado peligrosa.
Si está en medio de una actualización, realmente no sabe lo que está sucediendo aparte de la tarea inmediata en cuestión y puede verse engañado por las circunstancias. Por ejemplo, si recibe una página que le dice que su Cisco Ironport no responde, podría pensar: «¡Sí, sé que no responde ya que lo estoy actualizando!» ¿Qué pasa si luego descubre que esa página era para el OTRO Ironport supuestamente? en buen estado de funcionamiento que ha estado muerto durante treinta minutos?
Reuniendo todo
A menudo existe una presión excesiva (tanto externa como interna) sobre el personal de TI para finalizar una tarea y apresurarse a la siguiente para que puedan continuar demostrando valor para la organización. Sin embargo, esa presión es antitética al concepto de TI en sí mismo: mantener las cosas funcionando con una cantidad mínima de tiempo de inactividad e interrupción.
Muchas buenas técnicas de gestión del cambio se reducen al sentido común, a ser conservador y a ser seguro. Afortunadamente, estas pautas ayudarán a que el cambio en su entorno sea lo más predecible y controlado posible, para que pueda aprovechar las posibilidades en lugar de temerlas.
Leer también:Elementos críticos de un centro de datos eficiente; Puntos claves a considerar al elegir un centro de datos; Centro de datos vs sala de servidores (server room): ¿cuál es la mejor Opción?
This post is also available in:
Español
