Formación escrita en DevOps

¿Cómo resuelve DevOps sus problemas de TI?

Despliegue de forma continua

Desde empresas emergentes hasta compañías de Fortune 100, pasando por empresas de todos los tamaños y con toda clase de productos y servicios de software, ya se ha demostrado que con DevOps los equipos independientes, pequeños y autosuficientes realizan decenas de despliegues diarios en producción. Diseñe, construya, entregue y pruebe en entornos similares a producción. Deje de publicar código en producción una vez cada tres meses, pasada la medianoche, mientras los demás duermen. Publique código varias veces al día y, sobre todo, durante el horario de trabajo habitual, mientras los clientes y el mercado al que atiende siguen disfrutando de las ventajas de su software.

DevOps permite entregar funcionalidades muy pequeñas con frecuencia. Con técnicas de lanzamiento en la sombra también puede entregar frecuentemente a producción partes pequeñas de funcionalidades de gran envergadura. Esas partes se mantienen inactivas en producción hasta que activa la funcionalidad completa con un ajuste de configuración. Esta sola técnica puede mejorar considerablemente la calidad de vida del equipo al evitar los despliegues masivos de una sola vez, sus efectos adversos imprevisibles en los sistemas de producción, el caos y los reproches en la organización.

Organice sus equipos en torno a su misión

Para atender a su mercado, y dado que su organización y usted tienen una misión más amplia que la competencia, organice el departamento de TI en equipos estables centrados en productos, servicios, capacidades y microservicios que atiendan a clientes internos o externos. Evite los equipos temporales que se disuelven en cuanto terminan los proyectos o incluso antes.

En un equipo temporal, a sus integrantes les cuesta asumir la responsabilidad de sus aportaciones porque rara vez saben qué lugar ocupa el proyecto en la misión general de la organización y apenas reciben comentarios sobre su trabajo. Distintos proyectos les asignan sin cesar tareas de su especialidad (desarrollo de bases de datos, diseño de interfaces, traducción, etc.) y trabajan entre interrupciones constantes.

Con los equipos estables, sus integrantes asumen voluntariamente la responsabilidad de su trabajo y del rendimiento de TI y del negocio que su capacidad de entrega hace posible. Entienden perfectamente cómo encajan sus aportaciones en la misión de la organización y qué importancia tienen.

Construya sistemas que cumplan los objetivos de negocio

Usted y sus equipos saben perfectamente que les pagan para atender a los clientes y cumplir la misión de la organización. Por eso respetan el tiempo y los recursos de todos, tanto de la organización como de los clientes. Antes de comprometerse con un proyecto a largo plazo, pruebe y valide el valor de negocio previsto de la solución de TI. Muestre a sus clientes modelos, prototipos, distintas variantes A/B o versiones ligeras de lo que piensa construir. Después, mida y registre sus reacciones y comentarios para saber cómo ajustar el producto o servicio y comprobar si realmente les gusta.

No añada funcionalidades al producto solo por intuición. Pruebe las ideas y reúna pruebas concretas, demostrables y reproducibles de que lo que construye con los recursos de su organización probablemente mejorará los resultados y distinguirá favorablemente a su empresa de la competencia.

Desarrolle con calidad y monitorización integradas

Establezca ciclos de retroalimentación rápidos, fiables y amplios en todas las etapas del ciclo de vida de entrega y operaciones de software. La calidad no es monopolio de un equipo, así que todos se esfuerzan por integrarla. Para comprobar que ha hecho bien su trabajo, no espere los comentarios de otro equipo ni pida permiso a otra persona para desplegar código en producción. Confíe en las revisiones entre pares que hace su equipo del diseño, el código, las pruebas y la infraestructura.

Automatice las pruebas e incorpore monitorización (telemetría) para toda funcionalidad que se pueda medir o probar. Si una funcionalidad merece el tiempo de programarla y entregarla, también merece pruebas automatizadas continuas, fiables, rápidas y coherentes. Merece además monitorización continua y analítica integrada para validar que los resultados coinciden con el motivo por el que se creó. Esto se aplica a todos los entornos, tanto de producción como de otro tipo.

Cada cambio registrado en el repositorio de código adapta, reestructura o, si hace falta, vuelve a construir los entornos operativos de forma automática. También vuelve a construir las aplicaciones afectadas y ejecuta todas las pruebas automatizadas para validar las funcionalidades existentes y el propósito del último cambio. Una vez que se completa la validación correctamente, los mismos cambios se aplican automáticamente en producción.

La analítica y la telemetría integradas en las aplicaciones monitorizan y registran de forma continua los eventos clave del software y sus entornos operativos. Las métricas clave, como el número de pedidos o inicios de sesión, el uso y la carga de la CPU, el uso de RAM, el número de errores y la duración de las consultas a la base de datos, se registran continuamente y se presentan en tiempo real. Así, el equipo detecta en minutos o incluso segundos cualquier efecto adverso de un despliegue. Por eso son vitales los ciclos de retroalimentación rápidos.

Aprenda de los errores y comparta lo aprendido

Si ocurre un error, resuélvalo con calma y confianza. Identifique la causa raíz del incidente con pruebas verificables obtenidas de las pruebas automatizadas y la telemetría. Si tras resolver el problema detecta que falta algún caso de prueba o algún dato de telemetría, añádalo al repositorio de código junto con la corrección.

En un sistema complejo como el suyo, nadie puede saberlo ni preverlo todo. Por eso, en su organización todos ven los errores como parte de la maduración de los productos y servicios. Los errores son oportunidades de aprender y crecer. Usted y su organización los conciben como un medio para adquirir conocimientos, tanto a título personal como colectivo.

Las revisiones de incidentes sin buscar culpables también le ayudarán a identificar mejor las causas raíz y a descubrir técnicas para evitar los mismos errores u otros parecidos en el futuro. Gracias al incidente, lo que su equipo aprendió sobre su software pasa a formar parte de la memoria de la organización y sirve a todos.

Su equipo y usted nunca reciben un castigo por este error. Se les recompensa por las lecciones que aprendieron y compartieron tras el incidente. Gracias a su aportación, muchos equipos de la organización saben cómo evitar un incidente similar en el futuro.

Sus equipos escalan aún mejor a medida que crece el negocio

Imagine una organización típica que pasa de 1 a 1,000 desarrolladores. Cuando era pequeña, los desarrolladores construían y desplegaban código continuamente en producción. A medida que crece, aumentan la jerarquía organizativa, la burocracia y el miedo a equivocarse. Desplegar código en producción exige más coordinación y comunicación. Por eso, el número medio de despliegues diarios por desarrollador suele caer o, como mucho, mantenerse cuando crecen las organizaciones.

Las organizaciones DevOps de alto rendimiento consiguen aumentar el número medio de despliegues diarios de código por desarrollador a medida que contratan más desarrolladores. Con la arquitectura, los equipos, la misión, el liderazgo y la cultura adecuados, organizaciones de alto rendimiento como Google, Amazon, Facebook, Netflix y Apple ya han demostrado que es posible. Su organización puede ser la siguiente.

El gráfico original compara cómo aumenta el número de despliegues diarios por desarrollador a medida que crecen los equipos.

Ver el diagrama original ↗

CONCLUSIÓN

Las organizaciones DevOps de alto rendimiento superan a sus competidores en los siguientes aspectos.

• Despliegues de código 46 veces más frecuentes.
• Tiempo del commit al despliegue 440 veces más rápido.
• Recuperación media tras una interrupción 96 veces más rápida.
• Tasa de fallos en los cambios 5 veces menor (la probabilidad de que fallen es de 1/5).
• Mayor productividad y capacidad de entrega.
• Mayor fiabilidad del código y de las operaciones.
• Mejor rendimiento organizativo y mayor satisfacción de los clientes.
• Mayor penetración y cuota de mercado y mejor rentabilidad (el doble de probabilidades de lograrlo).
• Mayor crecimiento de la capitalización bursátil.

La comparación abarca la frecuencia de despliegue, el tiempo de entrega de los cambios, el tiempo de recuperación y la tasa de fallos de los cambios.

Ver el diagrama original ↗