release management - ¿Cómo se actualiza un sitio web en vivo y ocupado de la manera más educada posible?

release-management high-availability (13)

Cuando implementa cambios en un sitio web en vivo, ¿cómo hace para verificar que el sistema en vivo esté funcionando correctamente? ¿Qué herramientas usas? ¿Quien lo hace? ¿Bloquea el acceso al sitio para el período de prueba? ¿Qué cantidad de tiempo de inactividad es aceptable?

Ejecute su servidor principal en un puerto que no sea 80. Inserte un servidor liviano (por ejemplo, nginx) delante del puerto 80. Cuando actualice su sitio, inicie otra instancia en un nuevo puerto. Prueba. Cuando esté satisfecho de que se ha implementado correctamente, edite su archivo de configuración de proxy y reinícielo. En el caso de nginx, esto da como resultado un tiempo de inactividad cero o solicitudes fallidas, y también puede proporcionar mejoras de rendimiento sobre la opción de alojamiento más típica de Apache.

Por supuesto, esto no es un sustituto de un servidor de puesta en escena adecuado, es simplemente una forma "cortés" de realizar el traspaso con recursos limitados.

En el trabajo, pasamos un período de tiempo con el código congelado en el entorno de prueba. Luego, tras unas semanas de aviso, retiramos el sitio a la medianoche del viernes por la noche, trabajamos toda la noche desplegándolo y valiéndolo, y lo subimos el sábado a última hora de la mañana. Las estadísticas de tráfico nos mostraron que este era el mejor marco de tiempo para hacerlo.

En mi humilde opinión los largos tiempos de inactividad (horas) son aceptables para un sitio gratuito. Si educas a tus usuarios lo suficiente, entenderán que es una necesidad. Tal vez darles algo con lo que jugar hasta que el sitio web vuelva a funcionar (por ejemplo, un juego flash, una transmisión en vivo de webcam que muestre al equipo de desarrollo en el trabajo, etc.). Para un sitio web al que las personas pagan para tener acceso, mucha gente perderá su tiempo con quejas si les proporciona un tiempo de inactividad regular. Evitaría el tiempo de inactividad como la plaga y lanzaría actualizaciones muy lenta y cuidadosamente si estuviera ejecutando un servicio que cobra a los usuarios.

En mi configuración actual, tengo un sitio web secundario conectado a la misma base de datos y memoria caché que la copia en vivo para probar mis cambios.

También tengo varios scripts de "vigilante de página" que se ejecutan en tareas cron que usan expresiones regulares para verificar que el sitio web esté representando las páginas clave correctamente.

La única forma de hacerlo transparente para sus usuarios es ponerlo detrás de un proxy de equilibrio de carga. Usted toma un servidor mientras actualiza otro servidor. Luego, cuando termine de actualizar, coloque el que actualizó en línea y quite el otro. Así es cómo lo hacemos.

Si tiene algún tipo de compilación ''beta'', no lo despliegue en el servidor en vivo. Si tiene un ''sitio en vivo, ocupado'' es probable que la gente lo golpee y rompa algo.

Esta es una configuración típica de alta disponibilidad, para mantener una alta disponibilidad, necesitará 3 servidores como mínimo. 2 en vivo y 1 servidor de prueba. Además de cualquier otro servidor adicional si desea tener una base de datos dedicada o algo así.

La respuesta es que depende". En primer lugar, en el tipo de entorno en el que se está liberando. ¿Es el tipo de sitio web "hola, mundo" en un servidor compartido en alguna parte, o un google.com con servidores de medio millón? ¿Hay generalmente un usuario por día, o más como un par de millones? ¿Está publicando HTML / CSS / JPG, o hay un gran backend con servidores SQL, servidores de nivel medio, cachés distribuidos, etc.?

En general, si puede permitirse tener entornos separados para el desarrollo, control de calidad, puesta en escena y producción, sí los tiene. Si tiene los recursos, cree el ecosistema para que pueda compilar el paquete completo instalable con 1 (un) clic. Y asegúrese de que la misma instalación binaria se puede instalar con éxito en DEV / QA / STAGE / PROD con otro solo clic ... Hay toneladas de material escrito sobre este tema, y debe ser más específico con su pregunta para obtener un precio razonable. responder

Muchos buenos consejos ya.

Como han mencionado las personas, si no tiene un solo punto involucrado, es simple simplemente realizar cambios de fase actualizando un servidor de aplicaciones a la vez. Pero rara vez es así, así que ignorémoslo y concéntrese en las partes difíciles.

Usualmente hay un DB que es común a todo lo demás. Eso significa tiempo de inactividad para todo el sistema. ¿Cómo se minimiza eso?

Automatización Script todo el procedimiento de implementación. Esto (especialmente) incluye cualquier cambio en el esquema de la base de datos. Esto (especialmente) incluye cualquier migración de datos que necesite entre las versiones del esquema.

Control de calidad Asegúrate de que haya pruebas. Pruebas de aceptación automatizadas (lo que el usuario ve y espera desde una perspectiva de lógica / experiencia empresarial). Considere la posibilidad de tener cuentas de prueba en el sistema de producción, que puede ejecutar para probar actividades de solo lectura. Si no interactúa con otros sistemas externos, considere realizar actividades de escritura también. Es posible que deba filtrar la actividad de la cuenta de prueba en ciertas partes del sistema, especialmente si se trata de dinero y contabilidad. Los contadores de frijoles se molestan, por buenas razones, cuando los frijoles no coinciden.

Ensayar Despliegue en un entorno de etapas lo más idéntico posible a la producción. Haga esto con volúmenes de datos de producción y datos de producción. Necesitas sentir cuánto tiempo lleva una mesa alternativa. Y debe verificar que una tabla alternativa funcione estructuralmente y con todas las claves externas en los datos reales.

Si tiene volúmenes de datos masivos, los cambios de esquema llevarán tiempo. Tal vez más tiempo de lo que puede permitirse estar abajo. Una solución es usar migraciones de datos por fases , de modo que el cambio de esquema se llene con datos "recientes" o "actuales" (digamos uno o tres meses) durante el tiempo de inactividad, y los datos de los cinco años restantes pueden llegar después estás en línea otra vez Para el usuario final las cosas se ven bien, pero no se puede acceder a algunas funciones por otro par de horas / días / lo que sea.

Para probar todo lo mejor posible en un sitio de desarrollo por separado antes de lanzarlo, utilizo Selenium (un probador de páginas web) para recorrer todas las partes navegables del sitio, completar valores ficticios en formularios, verificar que esos valores aparezcan en la derecha lugares como resultado, etc.

Es lo suficientemente potente como para comprobar una gran cantidad de JavaScript o cosas dinámicas también.

A continuación, una rápida ejecución con Selenium nuevamente después de actualizar el sitio en vivo verifica que la actualización funcionó y que no faltan enlaces o errores en la base de datos.

Me ha salvado unas cuantas veces al detectar errores sutiles que me habría perdido al solo hojear manualmente.

Además, si coloca el sitio en vivo detrás de algún tipo de "proxy inverso" o balanceador de carga (si es grande), eso hace que sea fácil volver a la versión anterior si hay problemas.

Parte de eso depende de si también está actualizando una base de datos. En el pasado, si el DB se estaba actualizando, derribábamos el sitio para un período de mantenimiento planificado (y publicado), generalmente algo fuera de horario en el que el impacto era mínimo. Si la actualización no involucra la base de datos, en un entorno de equilibrio de carga, tomaríamos una caja de la mezcla, la implementación y la prueba. Si eso fue exitoso, entró en la mezcla y la otra caja (asumiendo 2 cajas) fue sacada y actualizada / probada.

Nota: NO estamos probando el código, solo que la implementación se realizó sin inconvenientes, por lo que el tiempo de inactividad fue mínimo. Como se mencionó, el código ya debería haber pasado las pruebas en otro entorno.

Si tiene un conjunto de servidores con equilibrio de carga, podrá desconectarse uno a uno por separado y actualizarlo. ¡Sin tiempo de inactividad para los usuarios!

Tener una linda y desarmante imagen y / o página de respaldo. Algunos sitios implementan juegos simples de JavaScript para mantenerte ocupado mientras esperas la actualización.

Por ejemplo, fallar la ballena.

-Adán

Tiendo a hacer todas mis pruebas en otro entorno (¡no el vivo!). Esto me permite enviar las actualizaciones al sitio en vivo sabiendo que el código debería estar funcionando bien, y solo realizo pruebas de cordura en los datos en vivo, asegurándome de que no olvidé un archivo en alguna parte, o que algo raro salió mal.

Por lo tanto, las pruebas adecuadas en un entorno de ensayo o ensayo, y luego una comprobación de cordura trivial. Sin necesidad de tiempo de inactividad.

En el último lugar donde trabajé, QA realizaría pruebas en el entorno de control de calidad. Cualquier problema importante se solucionaría, probaría y verificaría antes de implementarlo.

Una vez que QA certificó la compilación, el equipo de soporte de producción envió el código al entorno de transición donde el cliente mira el sitio y verifica que todo sea como se desee.

El despliegue de la producción real ocurre durante las horas libres (después de las 9 pm si se trata de un envío nocturno de emergencia, o de 5 a. M. A 8 a. M. Si se trata de un despliegue normalmente programado).

El sitio está alojado en varios servidores, que se equilibran de carga con un F5 Load Balancer:

Un par de servidores se eliminan de la producción,
el código está instalado, y
se realiza una verificación superficial en los servidores antes de volver a colocar los servidores en la agrupación.

Esto se repite hasta que todos los servidores se actualicen al último código y permita que el sitio permanezca activo todo el tiempo.

Este proceso es ideal, pero hay casos en los que la base de datos debe actualizarse también. Si este es el caso, entonces hay dos opciones, dependiendo de si la nueva base de datos romperá el sitio o no.

Si la nueva base de datos es incompatible con la interfaz existente, no tiene otra opción que tener una ventana de tiempo donde el sitio está inactivo.

Pero si la nueva base de datos es compatible con la interfaz existente, aún puede expulsar el código sin ningún tiempo de inactividad real, pero esto requiere que haya dos servidores de bases de datos de producción.

Todo el tráfico se enruta al segundo DB y se tira del primer servidor de base de datos.
El primer DB se actualiza y, una vez completada la verificación, se vuelve a poner en producción.
Todo el tráfico se enruta al primer DB y se tira del segundo DB.
El segundo DB se actualiza y una vez completada la verificación, vuelve a la producción.
El siguiente paso es realizar las actualizaciones parciales como se describe arriba.

Entonces para resumir:

Cuando implementa cambios en un sitio web en vivo, ¿cómo hace para verificar que el sistema en vivo esté funcionando correctamente? En el mejor de los casos, esto se hace de forma incremental.
¿Qué herramientas usas? Verificaciones manuales para verificar que el código esté instalado correctamente junto con algunas pruebas automáticas básicas, utilizando cualquier herramienta de automatización. Usamos Selenium IDE.
¿Quien lo hace? DBA realiza actualizaciones de DB, Soporte Técnico / Administradores del Sistema empujan / arrastran los servidores e instala el código, y el soporte de QA o Producción realiza las Pruebas Manuales y / o ejecuta las pruebas Automatizadas.
¿Bloquea el acceso al sitio para el período de prueba? Si es posible, esto debe evitarse a toda costa, especialmente, como Gilles mencionó anteriormente, si se trata de un sitio pago.
¿Qué cantidad de tiempo de inactividad es aceptable? El tiempo de inactividad debe limitarse a los tiempos en que los usuarios tengan menos probabilidades de utilizar el sitio, y debe realizarse en menos de 3 horas.
Nota: 3 horas es muy generoso. Después de practicar y ensayar, como mencionó jplindstrom, el equipo tendrá todo el proceso inactivo y podrá entrar y salir a veces en menos de una hora.

¡Espero que esto ayude!

Cree una clase de host e implemente su sitio en vivo en esa clase de host. Por clase de host me refiero a un conjunto de hosts donde se configura el balanceo de carga y es fácil de agregar y eliminar hosts de la clase.

Cuando haya terminado con la prueba beta y esté listo para la producción, no es necesario que retire su sitio, simplemente elimine algunos host de la clase de host de producción, agréguelos a la nueva clase de host e implemente allí su último código y realice las pruebas correctamente. Una vez que esté seguro de que todo está funcionando bien, mueva todo su host gradualmente al nuevo y apunte a la nueva clase de host como clase de host de producción. O puede usar el mismo que estaba usando inicialmente, toda la idea detrás de esta actividad es asegurarse de que está probando su implementación en los cuadros de producción, donde su sitio se ejecutará después de la implementación, porque los problemas de implementación son aterradores y difíciles de depurar.