Formación escrita en DevOps
¿Por qué facilitar la retroalimentación para lograr despliegues más seguros en producción?
En mercados competitivos como el suyo, separar al equipo de desarrollo de los departamentos de aseguramiento de la calidad y operaciones no es viable si quiere atender a los clientes con rapidez y satisfacer sus demandas continuamente. Sin embargo, aunque la mayoría de los desarrolladores se quejan de la burocracia, cuando pueden colaborar con especialistas de calidad y operaciones en su propio equipo todavía temen desplegar en producción por su cuenta y sin supervisión. Veamos qué técnicas y medidas permiten desplegar con más seguridad.
Cómo facilitar un flujo continuo con DevOps
Para mantener un flujo fluido y continuo, las organizaciones DevOps más exitosas despliegan con frecuencia lotes pequeños de cambios en producción. Así todo el equipo puede evaluar y entender los cambios y corregirlos cuando haga falta.
Crear una canalización de despliegue automatizada no basta. Incorpore telemetría operativa a la canalización para recibir información rápida sobre el resultado de los cambios en producción y preproducción. Fomente también una idea compartida en la organización: todos los integrantes del equipo de DevOps son responsables de que funcionen bien y sin interrupciones el flujo de valor y la canalización de despliegue completos.
Use la telemetría para desplegar con más seguridad
No dé por terminado un cambio ni su despliegue hasta demostrar que funciona como se diseñó y programó. Tras desplegar, vigile de cerca las métricas de los módulos modificados, las métricas recién creadas, si las hay, y las de los demás componentes del sistema que el cambio pueda afectar.
Aunque ejecute pruebas automatizadas en preproducción y monitorice el sistema sometido a pruebas con la infraestructura de telemetría, seguirán surgiendo problemas en producción. No puede evitarlos todos, pero sí prepararse bien para corregirlos. Si un cambio interrumpe la canalización, reúna a los especialistas necesarios para corregir el problema y restablecer el buen funcionamiento de la canalización. Estos son tres métodos habituales para resolver problemas:
- Desactivar la funcionalidad: Es la forma más fácil de resolver un problema. No exige desplegar código de urgencia. Basta con desactivar la funcionalidad mediante un conmutador. Como no tiene que corregir de inmediato las partes erróneas del despliegue, el equipo puede tomarse el tiempo necesario para identificar bien la causa raíz y mejorar sus técnicas para que sea improbable que vuelva a ocurrir.
- Solucionar el problema con un cambio posterior: Despliegue código nuevo para corregir el problema. Aunque este método es arriesgado para los problemas de producción en organizaciones de TI tradicionales, puede funcionar muy bien, con eficiencia y seguridad, en organizaciones DevOps que cuenten con pruebas y despliegue automatizados y con telemetría completa en producción.
- Revertir el cambio: Retire el código erróneo para que el problema desaparezca, si todo va bien.
Haga que los desarrolladores aprendan de las operaciones reales
Rote al personal de su equipo de DevOps para que asuma responsabilidades de operaciones y atienda incidentes operativos. Así, todos en el flujo de valor entienden los retos y responsabilidades de los centros de trabajo posteriores. Asigne a desarrolladores, responsables de pruebas, arquitectos, diseñadores, gerentes y directivos tareas operativas no programadas, para que también reciban llamadas de alerta de incidentes a las 3 de la madrugada. Esto les ayuda a entender las consecuencias de las decisiones que toman a diario.
La rotación ayuda a que los especialistas de operaciones no se sientan aislados. Todo el equipo contribuye a equilibrar la resolución de incidentes en producción, la reducción de la deuda técnica y el desarrollo de funcionalidades nuevas. Cuando se despierta a arquitectos y desarrolladores a las 3 de la madrugada, está claro que los incidentes se resuelven más rápido que nunca.
Cuando los desarrolladores observan a los clientes usando su software, suelen darse cuenta de inmediato de muchas cosas que deben mejorar. Lo mismo ocurre cuando arquitectos, diseñadores, desarrolladores y responsables de pruebas observan otros centros de trabajo posteriores en el ciclo de vida de ingeniería. Al comprender el impacto de su trabajo en esas áreas, adquieren una perspectiva nueva que les permite mejorar su calidad y ajustar los resultados para facilitar el trabajo de quienes vienen después. Todo el equipo empieza a incorporar los requisitos operativos no funcionales a sus listas de trabajo diario. Esto solo es posible con ciclos de retroalimentación rápidos y continuos en la organización DevOps.
Haga que los desarrolladores operen su propio sistema
Es muy difícil transmitir a desarrollo lo que se aprende en producción. Por eso, organizaciones DevOps destacadas, entre ellas Google, hacen que los equipos de desarrollo sean responsables de las operaciones durante y después de los primeros lanzamientos. Mientras desarrollo se encarga del producto, los ingenieros de operaciones actúan como asesores. Cuando se demuestra que el producto se mantiene suficientemente estable en producción durante unos 6 meses, se transfiere a operaciones. El traspaso solo puede realizarse si el producto supera varias comprobaciones en producción, como las relativas a defectos pasados y actuales, cobertura de telemetría, incidentes fuera del horario laboral, diseño de arquitectura débilmente acoplada y seguridad de los cambios y despliegues.
Si se detectan problemas importantes de diseño y programación mientras operaciones se encarga del producto, puede devolverse a desarrollo. En esa etapa, los desarrolladores se ocupan de estabilizar el software y los ingenieros de operaciones actúan como asesores.
CONCLUSIÓN
En este capítulo se han explicado varias técnicas para que las canalizaciones de despliegue de su organización DevOps funcionen de forma fluida y más segura.
Estas técnicas muestran el respeto mutuo y la colaboración entre desarrolladores e ingenieros de operaciones de sus equipos de DevOps.
