¿Alguna idea sobre cómo ejecutar el mantenimiento en un sitio que siempre está en uso?

Ayudo con un gran sitio de juegos en Australia. Realizamos competiciones desde las 7 a. M. Hora local hasta la 1 a. M. Del día siguiente, todos los días de la semana. No nos hemos saltado un día desde que se lanzó el sitio. Naturalmente, esto hace que el mantenimiento sea extremadamente difícil de ejecutar, y descubrimos que nuestro servidor intermedio tiene hasta 50 confirmaciones por delante de nuestra rama de producción. Por lo general, el desarrollador principal tiene que levantarse extremadamente temprano para fusionar ramas y asegurarse de que todo funcione correctamente.

Hemos estado tratando de hacer que nuestro sitio de preparación sea lo más similar posible al sitio de producción, pero solo podemos hacerlo tan similar.

Nuestro sitio se basa en Laravel con un servidor Node.JS en tiempo real. Estamos usando Laravel Forge.

¿Alguien tiene alguna sugerencia sobre cómo podríamos enviar actualizaciones con más frecuencia? Estamos abiertos a cualquier cosa.

Hay muchas cosas que podría estar haciendo para mejorar su proceso de implementación. Algunos de ellos son:

• Asegúrese de que su código esté bien probado.

  Idealmente, debe tener una cobertura de prueba de unidad del 100%, así como pruebas de integración para cada escenario concebible.

  Si no tienes esto, probablemente deberías dejarlo todo y solucionarlo.

  Examina el desarrollo basado en el comportamiento.

  Tener un conjunto de pruebas completo le permitirá ...

• Ejecute la integración continua.

  Cada vez que alguien comete un cambio, CI puede ejecutar automáticamente el conjunto de pruebas en él. Si se aprueba el conjunto de pruebas, se puede implementar de inmediato (o programar una implementación). Para los cambios que no requieren ningún cambio significativo en sus bases de datos, esto solo le ahorrará mucho tiempo y dolor de cabeza.

  En caso de un problema, CI también puede darle una reversión de un clic.

  CI es mucho menos útil si su conjunto de pruebas no está completo y es correcto, ya que toda la premisa se basa en poder validar su código de manera automatizada.

• Haz actualizaciones atómicas.

  Idealmente, no debería simplemente copiar nuevos archivos sobre los antiguos en el servidor de producción. En su lugar, use una herramienta como capistrano, que copia cada archivo a una nueva ubicación, y luego usa un enlace simbólico para señalar la implementación deseada. Retroceder es instantáneo, ya que implica simplemente cambiar el enlace simbólico para que apunte a la implementación anterior. (Aunque esto no necesariamente cubre la migración de su base de datos).

  También revise si los contenedores como Docker pueden ayudarlo.

• Haga cambios más pequeños y más frecuentes.

  Ya sea que tenga pruebas, CI o nada, esto solo puede ayudarlo significativamente. Cada cambio debe tener su propia rama git, y una implementación debe tener la menor cantidad de cambios posible. Debido a que los cambios son más pequeños, hay menos que pueda salir mal durante una implementación.

  En esa nota, haga los cambios más aislados siempre que sea posible. Si ha realizado un cambio en el juego de Omaha, y no afecta a Texas Hold'em, 5 card stud o cualquier otra cosa, entonces ese es el único juego que debe suspenderse por mantenimiento.

• Analiza cualquier cosa de larga duración.

  Usted mencionó que algunas partes de sus implementaciones llevan mucho tiempo. Esta es , probablemente, los cambios de esquema de base de datos. Vale la pena echar un vistazo al DBA en su base de datos, junto con cada cambio de esquema, para ver qué puede estar funcionando mejor.

  Haga que un experto en la materia analice cualquier otra parte de una implementación que requiera grandes bloques de tiempo.

• Trabaja horas impares.

  Puede que ya estés haciendo esto, pero vale la pena mencionarlo. No debería esperarse que los desarrolladores (¡y los administradores de sistemas!) Trabajen más de "9 a 5", especialmente para una operación 24x7. Si se espera que alguien pase las horas de la noche cuidando un despliegue, arreglando cualquier problema y luego mantenga un horario diurno, sus expectativas no son realistas y está preparando a esa persona para el agotamiento.

Por lo que dices, parece que tiene un período de mantenimiento de 1 am a 7 am todos los días, el problema no es el tiempo sino la comodidad. Esto es normal y muchas personas simplemente lo tratan como parte de los negocios.

Podría tener un sistema 2 (o más backend) con un front-end que dirija el tráfico al que esté actualmente en vivo. Una vez que esté contento de que una versión vaya a funcionar, le dice al front end que cambie al nuevo sistema. Esto debería ser fácil de escribir y tomar poco tiempo.

Ahora tiene la opción de dejar el sistema antiguo como está para poder retroceder o actualizarlo para que pueda usarse como repuesto para el sistema en vivo hasta que sea el momento de compilar / probar las próximas actualizaciones.

Modificación de las otras respuestas: debe seguir el modelo de implementación azul-verde . Cuando desea lanzar una nueva versión, la implementa en un sitio web de preparación interno. Luego, puede ejecutar pruebas automatizadas en el sitio de producción de la próxima versión. Cuando pasan las pruebas, apunta el equilibrador de carga para usar el nuevo sitio web.

Esto ayuda de la siguiente manera:

1. Siempre se encuentran problemas graves con cero tiempo de inactividad.
2. Cambiar a una nueva versión tiene exactamente cero tiempo de inactividad porque la nueva versión ya se inició y se calentó.
3. Puede volver a la versión anterior en cualquier momento porque todavía se está ejecutando físicamente.

Todos los otros problemas que usted y otros han mencionado se vuelven menos severos cuando puede implementarlos en cualquier momento de manera libre de estrés. El modelo de implementación azul-verde es una solución bastante completa para problemas de implementación.

¿Qué hará si su centro de datos principal sufre una interrupción, que ocurre en todos los centros de datos de vez en cuando? Puede aceptar el tiempo de inactividad, puede fallar a otro centro de datos, puede estar ejecutándose en modo activo-activo en múltiples centros de datos todo el tiempo, o puede tener algún otro plan. Cualquiera que sea, hágalo cuando realice lanzamientos, y luego puede eliminar su centro de datos principal durante un lanzamiento. Si está preparado para tener tiempo de inactividad cuando su centro de datos tiene una interrupción, entonces está preparado para tener tiempo de inactividad, por lo que no debería ser un problema durante un lanzamiento.

Para agregar a las respuestas anteriores:

• Utilice una estrategia de implementación que permita retrocesos y conmutación instantánea, Capistrano o prácticamente cualquier otro sistema de implementación ayudará con esto. Podría usar cosas como instantáneas de bases de datos y enlaces simbólicos de código para poder volver rápidamente a un estado anterior.

• Utilice la gestión de configuración completa, no deje nada gestionado manualmente. Sistemas como SaltStack, Ansible y Puppet son ejemplos. También se pueden aplicar a configuraciones de contenedores Docker y cajas vagabundas.

• Use HA para asegurarse de que puede entregar solicitudes al actualizar un nodo. Si la actualización falla, simplemente baje el nodo, y cuando se revierta, vuelva a subirlo y su solución de HA notará y enviará solicitudes a dicho nodo nuevamente. HAProxy es un ejemplo, pero nginx también funciona bien.

• Asegúrese de que la aplicación pueda manejar instancias concurrentes, repositorios de datos con versiones centrales utilizadas para datos sin código que deben almacenarse en el disco, como la memoria caché. De esta manera, nunca tendrá una aplicación actualizada ejecutada en archivos de caché de una versión diferente. Esto se haría además de purgar cachés y hacer calentamientos de caché, por supuesto. (Lo del almacenamiento en caché es solo un ejemplo)

Por lo general, configuro flujos de trabajo donde los gerentes de equipo pueden aprobar solicitudes de fusión a una rama especial que hace todas las cosas de CI normales, pero como último paso adicional también comienza a empujar a los nodos de producción. Lo que básicamente hace es ejecutar una implementación manual de CI en una instancia de producción. Si esa instancia no genera respuestas inválidas, se rompe o hace cosas extrañas a sus datos, entonces actualice en masa todos los nodos utilizando la solución de CI que elija. De esta manera, si una implementación funciona, sabrá que todas las implementaciones funcionarán para una etiqueta / confirmación específica.

En este momento, parece que está ejecutando una aplicación de producción en un solo nodo, con un proceso de implementación, un origen y un destino. Esto prácticamente significa que cada paso en ese flujo de trabajo es un punto de falla que por sí solo puede romper el sitio web. Asegurar que tal cosa no pueda suceder es la base de todos los procesos de CI, HA y failover. No ejecute solo un nodo, no ejecute solo un proceso HA, no ejecute solo una dirección IP, no ejecute solo un CDN, etc. Puede sonar costoso, pero poner un duplicado de lo que ya tiene en un rack en un servidor con su propia conexión generalmente cuesta menos de una hora de tiempo de inactividad en un sitio comercial.

A nivel mundial, estoy de acuerdo con Michael en cada uno de sus puntos ( /server//a/739449/309477 ).

En mi opinión, la primera mejora que debe hacer es usar una herramienta de implementación (Capistrano).

Le permitirá desplegarse pacíficamente y luego cambiar a la versión más nueva al instante. Si algo sale mal, puede volver a la versión de trabajo al instante, simplemente cambiando el enlace simbólico actual a una versión de trabajo.

Y Capistrano es bastante rápido de manejar primero (en comparación con comenzar a usar pruebas y CI, que será una inversión de tiempo más grande).

En segundo lugar, si el dinero no es su problema principal , debe tener un servidor de desarrollo iso-prod para probar su aplicación antes de implementarla en producción. Use una solución industrial (Ansible, Chef, Puppet) para administrar instancias de VPS.