¿Es necesario prohibir el despliegue en producción en ciertos momentos? ¿O el movimiento #NoDeployFriday se convirtió en una reliquia de los tiempos en que no había pruebas integrales de integración y despliegue continuo?

En su equipo, puede enfrentar el mismo dilema. ¿Quién tiene razón y quién tiene la culpa? ¿Es el abandono de la implementación los viernes una estrategia razonable para reducir los riesgos, o es una cultura dañina que nos impide crear sistemas mejores y más estables?

Ding ding

Estoy seguro de que los ingenieros que tuvieron la suerte de estar "en contacto" perdieron sus días libres debido a todos los cambios del viernes que se rompieron. Yo también estaba en esta situación. Una llamada telefónica cuando salga con su familia o en medio de la noche, notificándole el bloqueo de la aplicación. Después de ingresar a la computadora y revisar los registros de rápido crecimiento, se hace evidente que todo fue arruinado por una rara excepción no controlada. Asqueroso

El análisis revela que para el escenario que condujo al fracaso, no se escribieron pruebas, aparentemente porque no se consideró probable. Después de una serie de largas llamadas telefónicas con otros ingenieros en busca de una mejor manera de revertir los cambios y arreglar todo, el sistema comienza a funcionar nuevamente. Fuh

El lunes se celebra una reunión de cinco razones.

" Dejemos de implementar los viernes. Luego, durante el fin de semana, todo funcionará de manera estable, y la próxima semana estaremos alerta después de todo tipo de lanzamientos ".

Todos asienten. Si algo no entra en funcionamiento antes del mediodía del jueves, entonces espera hasta el lunes por la mañana. ¿Este enfoque daña o ayuda?


Como sabes, las declaraciones de Twitter son a menudo muy subjetivas. Aunque la prohibición de los lanzamientos del viernes parece razonable, alguien señalará rápidamente que esto es solo una muleta debido a la fragilidad de la plataforma, que se debe a los pobres procesos de prueba e implementación.

Algunos incluso sugieren que solo le gustan las implementaciones silenciosas más que el fin de semana en sí:


Otros usuarios creen que la implementación de indicadores de función puede ser una posible solución.


Este usuario cree que los problemas de una implementación riesgosa no deberían surgir debido a los procesos y herramientas disponibles para nosotros hoy.

¿Quién toma las decisiones?

Todo este intercambio de opiniones indica que nosotros, como comunidad de ingenieros, podemos estar en total desacuerdo y no necesariamente estamos de acuerdo entre nosotros. ¿Quién lo hubiera pensado? Esta situación probablemente también demuestra que la imagen general con #NoDeployFriday contiene tales matices que no se reflejan demasiado bien en Twitter. ¿Es cierto que todos debemos aplicar la implementación continua, de lo contrario "lo hacemos mal"?

Al tomar tal decisión hay un aspecto psicológico. La hostilidad hacia los lanzamientos del viernes proviene del miedo a cometer errores durante la semana (debido a la fatiga o la prisa), lo que puede causar daño mientras la mayoría de los empleados descansan durante dos días. Como resultado, un compromiso del viernes que contiene un problema potencial puede arruinar el fin de semana para un grupo de personas: ingenieros de servicio, otros ingenieros que ayudarán de forma remota a resolver el problema y posiblemente especialistas en infraestructura que tengan que recuperar datos dañados. Si la falla resulta ser grave, entonces otros empleados de la compañía también pueden estar involucrados en la situación, quienes deberán contactar a los clientes y minimizar el daño.

Tomando la posición de un idealista, podemos suponer que en un mundo ideal con código perfecto, cobertura de prueba perfecta y control de calidad perfecto, ningún cambio puede conducir a un problema. Pero somos personas, y las personas tienden a cometer errores. Siempre habrá algunos casos fronterizos extraños que no se cierran durante el desarrollo. Esta es la vida Entonces, el movimiento #NoDeployFriday tiene sentido, al menos teóricamente. Sin embargo, esto es solo una herramienta ciega. Creo que es necesario evaluar los cambios realizados según la situación, y a priori es necesario proceder del hecho de que desplegamos cualquier día, incluso los viernes, pero al mismo tiempo debería poder aislar esos cambios que deberían esperar hasta el lunes.

Hay algunos problemas que podemos discutir. Los dividí en categorías:

1. Comprender el "radio de destrucción" del cambio.
   
2. La solidez del proceso de implementación.
   
3. La capacidad de detectar errores automáticamente.
   
4. ¿Cuánto tiempo lleva resolver los problemas?
   

Ahora hablemos.

Comprender el "radio de destrucción"

Cuando las lanzas en línea sobre los lanzamientos del viernes nuevamente comienzan a romperse, siempre se olvidan de lo importante, de la naturaleza misma de los cambios. No hay cambios idénticos en la base del código. Algunos commits gobiernan un poco la interfaz y nada más; otros refactorizan cientos de clases sin afectar la funcionalidad del programa; otros cambian los esquemas de la base de datos y realizan cambios importantes en el proceso de consumo de datos en tiempo real; los cuartos pueden reiniciar una instancia, mientras que los quintos pueden iniciar un reinicio en cascada de todo tipo de servicios.

Al observar el código, los ingenieros deberían tener una buena idea del "radio de destrucción" de los cambios realizados. ¿Qué parte del código y la aplicación se verán afectados? ¿Qué podría caerse si el nuevo código falla? ¿Es solo un clic en un botón que arrojará un error, o se perderán todas las nuevas entradas? ¿Se realiza un cambio en un solo servicio aislado, o muchos servicios y dependencias cambiarán simultáneamente?

No puedo imaginar quién se negará a hacer cambios con un pequeño "radio de destrucción" y un despliegue simple en cualquier día de la semana. Pero al mismo tiempo, los cambios importantes, especialmente los relacionados con la infraestructura de almacenamiento, deben llevarse a cabo con más cuidado, tal vez en un momento en que hay menos usuarios en línea. Será aún mejor si tales cambios a gran escala se ponen en funcionamiento en paralelo para probar y evaluar su trabajo bajo una carga real, y nadie lo sabrá.

Aquí debe tomar decisiones según la situación. ¿Todos los ingenieros conocen el "radio de destrucción" de los cambios en el entorno de producción, y no solo en el entorno de desarrollo? Si no, ¿por qué? ¿Es posible mejorar la documentación, la capacitación y la visualización de los efectos de los cambios de código en la producción?

¿Es pequeño el "radio de destrucción"? Lanzamiento el viernes.

¿Es grande el "radio de destrucción"? Espera hasta el lunes.

La solidez del proceso de implementación

Una forma de reducir los riesgos es mejorar continuamente el proceso de implementación. Si para lanzar una nueva versión de la aplicación todavía es necesario que un especialista sepa qué script ejecutar, qué archivo y dónde copiar, entonces es hora de automatizar. En los últimos años, las herramientas en esta área han avanzado mucho. A menudo usamos Jenkins Pipeline and Concourse , que le permiten configurar directamente las tuberías de ensamblaje, prueba e implementación con código.

El proceso de despliegue completo es algo interesante. Le permite dar un paso atrás e intentar abstraer lo que debería suceder desde el momento en que se inicializa la solicitud de extracción hasta que la aplicación se pone en funcionamiento. Una descripción de todos los pasos del código, por ejemplo, en las herramientas mencionadas anteriormente, lo ayudará a generalizar las definiciones de pasos y reutilizarlos en todas las aplicaciones. Además, será interesante para ti notar algunas decisiones extrañas o flojas que una vez tomaste y reconciliaste.

A cada ingeniero que haya leído los dos párrafos anteriores y haya reaccionado al estilo de “¡Bueno, por supuesto! ¡Hemos estado haciendo esto durante años! Puedo garantizar que otros 9 más presentaron su infraestructura de aplicaciones e hicieron una mueca, dándose cuenta de la cantidad de trabajo que debe hacerse para transferir el sistema a una tubería de implementación moderna. Esto implica aprovechar las herramientas modernas que no solo realizan una integración continua, sino que también le permiten suministrar continuamente errores al producto, y los ingenieros solo necesitan presionar el botón para la puesta en marcha (o incluso hacerlo automáticamente si es lo suficientemente valiente).

Mejorar el transportador de despliegue requiere la participación y el personal apropiado; esto definitivamente no es un proyecto paralelo. Una buena solución sería destacar un equipo para mejorar las herramientas internas. Si aún no conocen los problemas existentes, y probablemente lo sepan, puede recopilar información sobre las situaciones más dolorosas asociadas con el proceso de liberación, luego priorizar y solucionarlo junto con otros. Poco a poco, la situación mejorará: el código entrará en funcionamiento más rápido y con menos problemas. Cada vez más personas podrán aprender mejores enfoques y realizar mejoras por su cuenta. A medida que la situación mejore, los enfoques se distribuirán en equipos, y este nuevo proyecto se completará correctamente, sin la copia habitual de los viejos malos hábitos.

Desde el momento de la fusión, la solicitud de extracción para la confirmación debe automatizarse para que ni siquiera necesite pensar en ello. Esto no solo ayuda a aislar los problemas reales en el control de calidad, porque la única variable es el código cambiado, sino que hace que escribir el código sea mucho más agradable. La puesta en marcha está descentralizada, lo que aumenta la autonomía y responsabilidad personal. Y esto, a su vez, lleva a decisiones más deliberadas sobre cuándo y cómo implementar un nuevo código.

Transportador de despliegue confiable? Lanzamiento el viernes.

¿Copiar guiones manualmente? Espera hasta el lunes.

Capacidad para detectar errores.

La puesta en marcha no se detiene después de que el código comienza a funcionar. Si algo sale mal, necesitamos saberlo, y es aconsejable que estemos informados al respecto, y que no tengamos que buscar información por nuestra cuenta. Para hacer esto, debe escanear automáticamente los registros de la aplicación en busca de errores, realizar un seguimiento explícito de las métricas clave (por ejemplo, la cantidad de mensajes procesados ​​por segundo o la proporción de errores), así como un sistema de advertencia que informa a los ingenieros sobre problemas críticos y muestra una tendencia negativa para ciertas métricas.

La operación siempre es diferente del desarrollo, y los ingenieros necesitan monitorear la operación de ciertas partes del sistema. Debe responder preguntas sobre cada cambio posterior: ¿aceleró o ralentizó el sistema? ¿Hay más o menos tiempos de espera? ¿Estamos limitados por el procesador o la E / S?

Los datos sobre métricas y errores deben transmitirse al sistema de advertencia. Los equipos deberían poder determinar qué señales indican una situación negativa y enviar mensajes automáticos al respecto. Para nuestros equipos y los incidentes más graves, utilizamos PagerDuty.

La medición de las métricas del sistema de producción significa que los ingenieros pueden ver si algo ha cambiado después de cada implementación, para bien o para mal. Y en el peor de los casos, el sistema informará automáticamente a alguien sobre el problema.

¿Buen monitoreo, notificaciones y especialistas de guardia? Implementar el viernes.

Ver manualmente los registros a través de ssh? Espera hasta el lunes.

¿Cuánto tiempo lleva resolver los problemas?

Finalmente, el criterio principal es cuánto tiempo tomará solucionar los problemas. Esto depende en parte del "radio de daño" de los cambios realizados. Incluso si tiene una canalización de implementación lamida, algunos cambios son difíciles de solucionar rápidamente. La reversión de los cambios en el sistema de extracción de datos y en el esquema del índice de búsqueda puede requerir una reindexación laboriosa, además de corregir alguna línea de código. La implementación, validación, corrección y redistribución promedio de los cambios de CSS pueden llevar minutos, mientras que los cambios importantes en el repositorio pueden requerir días de trabajo.

Para todos los trabajos dentro de la tubería de implementación, que a nivel macro puede aumentar la confiabilidad de los cambios, no hay cambios iguales, por lo que debe evaluarlos por separado. Si algo sale mal, ¿podemos arreglarlo rápidamente?

¿Está completamente solucionado con una única confirmación de restauración? Implementar el viernes.

¿Hay grandes dificultades si algo sale mal? Espera hasta el lunes.

Piensa por ti mismo, decide por ti mismo

¿Cuál es mi posición en #NoDeployFriday? Creo que todo depende del lanzamiento. Los cambios con un pequeño "radio de impacto" que son fáciles de revertir pueden implementarse en cualquier momento, cualquier día. Con grandes cambios, cuyo impacto debe ser monitoreado de cerca en el sistema de producción, recomiendo esperar hasta el lunes.

De hecho, depende de usted implementar los viernes. Si está trabajando con un sistema frágil y frágil, es mejor evitar los viernes hasta que haya hecho todo lo necesario para mejorar el proceso de implementación. Solo asegúrese de hacerlo, no lo cepille. Rechazar los lanzamientos del viernes es una forma normal de cubrir fallas temporales de infraestructura. Esta es una reducción de daños razonable para el bien del negocio. Pero es malo si esta regla cubre defectos constantes.

Si no está seguro del efecto que tendrán los cambios, posponga hasta el lunes. Pero piense en lo que puede hacer la próxima vez para comprender mejor este efecto y mejorar la infraestructura asociada para esto. Como siempre en la vida, cada decisión tiene sus propios matices. Las soluciones no se dividen en "negro" y "blanco", en "correcto" e "incorrecto": mientras estamos haciendo todo lo posible para los negocios, las aplicaciones y entre nosotros, mejorando nuestros sistemas, estamos haciendo todo bien.

Despliegue exitoso.