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

18

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.

queso5505
fuente
¿Por qué una implementación tarda tanto?
Michael Hampton
@MichaelHampton Nuestras implementaciones no tardan mucho, es solo que no podemos permitirnos el tiempo de inactividad si algo sale mal.
cheese5505
1
Supongo que la pregunta, entonces, es: ¿por qué tarda tanto un rollback?
Michael Hampton
@MichaelHampton no hemos analizado adecuadamente los retrocesos, sin embargo, a veces hacemos grandes actualizaciones que desactivarán el sitio durante demasiado tiempo.
cheese5505
55
Lo que sea que tome los grandes bloques de tiempo, eso es lo que necesita mirar.
Michael Hampton

Respuestas:

22

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.

Michael Hampton
fuente
La solución más simple aquí es usar scripts de implementación en una herramienta como Capistrano y quizás incluso hacer balanceo de carga también.
JakeGould
Gracias por el consejo. Miraremos esto. Por el momento no tenemos un conjunto de pruebas en absoluto, y realmente me gustaría examinarlo, sin embargo, el sitio ha estado en desarrollo durante más de 8 meses y es tan grande que tomaría más de una semana hacer uno. Estamos ejecutando Laravel Forge, que simplemente vincula la nueva versión a la carpeta para la que está configurado nginx. No puedo trabajar horas extra debido a la escuela, y lo mismo es para el otro desarrollador.
cheese5505
1
@ cheese5505 Sé que esto es frustrante y esto no resuelve su problema, pero cuando dice esto, "... es tan grande que tomaría más de una semana hacer uno". Eso parece patentemente ridículo. Cualquier proceso de desarrollo e implementación sensato permitiría construir un servidor en menos de un día o tal vez de unas pocas horas a una hora. Realmente deberías revisar lo que hiciste para construir este montón de cosas inmanejables para evitar esto. El problema no es la complejidad sino la previsión básica en la planificación.
JakeGould
1
"Por el momento no tenemos un conjunto de pruebas en absoluto" - solucione esto ahora , antes de desarrollar nuevas funciones. Este es su mayor problema y será un riesgo de disponibilidad. Las pruebas automatizadas ayudarán en gran medida a prevenir interrupciones y reducirán significativamente el dolor de operaciones.
Josh
6

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.

user9517 es compatible con GoFundMonica
fuente
Cuando diferencia el backend del frontend, ¿se refiere a una arquitectura de software completamente modular? ¿O la arquitectura del servidor, como un equilibrador de carga?
JakeGould
2
simplemente algo que acepta conexiones y las entrega al backend primario actual.
user9517 es compatible con GoFundMonica el
5

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.

usr
fuente
Ya tenemos un servidor de preparación que usamos para probar, pero en este momento la producción y la preparación se encuentran en diferentes proveedores de servidores en diferentes ubicaciones. Estamos tratando de mover la producción a donde está la puesta en escena, ya que nos proporciona un mejor rendimiento.
cheese5505
1
La clave es simplemente tener que cambiar el balanceador de carga a una versión de trabajo probada. Con ese modelo actual no tienes eso.
Usr
1
Lo bueno que sea este modelo depende mucho de lo que esté haciendo el sitio. Si el sitio no tiene estado, entonces es genial, pero si no lo es, debes averiguar cómo vas a transferir ese estado al cambiar.
Peter Green
@PeterGreen es muy difícil para los sitios web tener estado porque eso no permite la agrupación y el estado puede perderse en cualquier momento en la redistribución / reinicio / bloqueo / bloqueo de pantalla azul, etc. Por lo tanto, esto es muy poco común.
Usr
@ usr la mayoría de los sitios web tienen estado. Ese estado puede almacenarse en archivos o en una base de datos. En este último caso, la base de datos puede ser local o remota. Es probable que algunas actualizaciones tengan un impacto en ese estado, lo que significa que la actualización y la reversión no son tan simples como simplemente cambiar el código.
Peter Green
3

¿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.

Mike Scott
fuente
2

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.

John Keates
fuente
0

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.

nahk
fuente