De ProdOps a DevOps: sobrevivir y prosperar

Lo recuerdo muy bien, ya mi antiguo manager le gusta recordármelo. Hace varios años hablaba de DevOps. ¿Mi reacción? Esta es una cita directa:

"Oh, ¿quieres decir que ProdOps está mal hecho?"

Para muchos de nosotros en operaciones de producción (ProdOps), el cambio es el enemigo. Si algo cambia, ahora existe la oportunidad de que las cosas que solían funcionar muy bien se conviertan en problemas. Es como un juego de Jenga. ¿Cuándo caerá la torre porque un cambio aparentemente menor desequilibra toda la pila de monedas? Los equipos de ProdOps odian tanto el cambio que se han inventado innumerables marcos para "gestionar" el cambio; de hecho, estos marcos hacen que el proceso de efectuar cambios sea tan oneroso que la mayoría de las personas se dan por vencidas y aceptan el statu quo.

De hecho, esta declaración es un poco injusta. Estos marcos son un intento de envolver la planificación y el consenso en torno a los cambios de producción, minimizando así el tiempo de inactividad potencial causado por cambios aleatorios o maliciosos (consulte Por qué la mentalidad de lobo solitario es un error del administrador del sistema).

En los entornos de trabajo centrados en los desarrolladores de hoy en día, los entornos completamente inmutables ya no son algo que los propietarios de negocios y los desarrolladores acepten. En ese momento, con antecedentes en ProdOps, la idea de realizar cambios impulsados ​​por nuestro equipo de desarrollo en nuestros entornos orientados al cliente era una pesadilla.

Durante el próximo año más o menos, cada seis meses, reemplazaríamos los sistemas de producción con nuevos sistemas para ocupar su lugar en nuestra infraestructura. La idea era que pudiéramos hacer todo nuestro trabajo y pruebas en este nuevo sistema y, cuando estuviera listo, reemplazarlo con sistemas más antiguos, ahora obsoletos.

Sin embargo, sin falta después de una de estas actualizaciones, los equipos de operaciones y desarrollo pasarían de tres a 10 días aplicando actualizaciones, ajustes y correcciones a este nuevo sistema que ahora estaba operativo y en uso por parte de los clientes. ¿Por qué? Porque durante la vida útil de seis meses de uno de estos entornos, se realizaron pequeños cambios para solucionar los problemas, pero de alguna manera esos cambios no se agregaron al proceso de construcción para crear los sistemas de reemplazo.

El párrafo anterior es un gran ejemplo de ProdOps mal hecho. No porque los desarrolladores de aplicaciones estuvieran integrando correcciones de código en nuestros sistemas de producción orientados al cliente. Tampoco porque durante los seis meses de vida de un sistema, estuviéramos haciendo cambios de configuración o de servicio. Es porque no teníamos forma de explicar estos cambios, esta deriva, a lo largo del tiempo. Este problema fue causado en parte por el proceso pero también por la gente. Alguien se despertaría o llamaría durante el fin de semana y rápidamente "solucionaría" el problema, pero más tarde, al construir su reemplazo, no tendríamos ninguna referencia organizacional a esta actualización.

Después de un año o 18 meses de eso, me acerqué al director y le dije: "Oye, quiero pasarnos a un proceso de lanzamiento más iterativo y menos invasivo. Quiero hacer DevOps".

Como puede imaginar, después de algunos "se lo dije", mi equipo se dispuso a mejorar el proceso. Cuando piensa en DevOps, también puede pensar en integración continua, entrega continua (CI/CD). Esta fue nuestra primera gran mejora: cambiar la forma en que se construyó el entorno. Además de los cambios de herramientas, también estamos comprometidos con el cambio de comportamiento. Cuando ajustamos una solución a producción, también se comprometió con el código base y, como resultado, ingresó a las pruebas de compilación para la próxima implementación para que pudiéramos verificar que el problema se había resuelto de forma permanente.

Como administradores del sistema, adoptamos un nuevo lema de equipo:

"Confiar pero verificar."

Confiamos en lo que el equipo de desarrollo nos dijo sobre el lanzamiento. Confiamos en lo que nos dijo el equipo de desarrollo sobre la conciliación de las actualizaciones retroactivas. Sin embargo, como administradores del sistema, era nuestra responsabilidad desarrollar los casos de prueba, después de la actualización, para verificar que estas afirmaciones fueran precisas.

Durante el próximo año, evolucionamos nuestros procesos de desarrollo e implementación para realizar actualizaciones cada dos semanas (para coincidir con el final de nuestros sprints de desarrollo AGILE). Debido a que estas actualizaciones eran mucho más pequeñas y más iterativas, en lugar de evolutivas, esos pocos días de tirarnos de los pelos tratando de solucionar problemas aleatorios se han ido.

Dado que nuestro proceso de compilación estaba altamente automatizado, estas actualizaciones también fueron rápidas y, por lo general, solo tuvieron 20 a 30 segundos de estado del sistema "extraño" después de que se aplicó la actualización. Este hecho significó que en lugar de pasar un fin de semana actualizando, podríamos implementar y probar uno antes de comenzar el día. También hemos trasladado las implementaciones a los miércoles para que tengamos algunos días de tiempo normal de guardia para tratar cualquier problema antes de salir para el fin de semana. (Los clientes también usaron nuestro servicio durante el fin de semana). Finalmente, además de mejorar nuestra capacidad de implementación y prueba, también mejoramos la capacidad de reversión de la implementación. Si una implementación no funcionaba correctamente, podíamos revertir el entorno en menos de cinco minutos.

Al final, cambiar a un modelo DevOps CI/CD hizo que los equipos de desarrollo y administración de sistemas estuvieran más contentos. Desde la perspectiva de un desarrollador, pudieron ver su código y funcionalidad en su lugar rápidamente después de la entrega. Si hubiera problemas o errores en las funciones, no solo se podrían revertir los cambios rápidamente, sino que los desarrolladores generalmente tenían un tiempo de respuesta más rápido para solucionar los problemas porque habían trabajado recientemente en el código. . Tampoco tuvieron que participar en llamadas de aprobación de cambios y una variedad de otros procesos obtusos.

Por el lado de la administración del sistema, nuestro entorno era mucho más robusto y menos propenso a interrupciones no planificadas. Como beneficio adicional, no perdíamos los fines de semana en mantenimiento y recibíamos menos llamadas fuera del horario laboral. Si una implementación no funcionaba correctamente, trabajábamos con los desarrolladores, que también estaban trabajando porque las implementaciones ahora se realizaban durante la jornada laboral, para solucionar el problema. Si no pudiéramos arreglarlo dentro de la ventana de mantenimiento de 30 minutos, lo revertiríamos; luego volvería a intentarlo en la próxima actualización dos semanas después.

Cambiar a DevOps fue un cambio drástico en mi experiencia con ProdOps, pero al final, trajo grandes mejoras a mi trabajo, relaciones con otros miembros del equipo e interrupciones no planificadas de mi tiempo personal. El proceso fue aterrador y frustrante a veces, pero finalmente valió la pena.

Artículos de interés

Subir