Tema 1.3 - Principios DevOps

Aunque es posible encontrar diversa literatura en internet que hace referencia a los principios DevOps, en este curso vamos a centrarnos en el modelo CAMS el cual nos permite explicar los pilares bajo los cuales se fundamenta DevOps.

C = Culture (Cultura):

Adaptarse a una cultura DevOps significa transformarse en una organización que se enfoca en brindar un servicio de alta calidad. El servicio no solo significa poner el producto a disposición del cliente, sino también garantizar que el producto esté en su mejor forma y cumpla constantemente con los requisitos de los clientes

La cultura es la parte más importante del movimiento DevOps. La cultura traerá todo un conjunto de prácticas como lo son:

• El uso de Scrum
• La organización de retrospectivas
• La voluntad de limitar el nivel de deuda técnica

La mentalidad de servicio es un aspecto crítico de la cultura DevOps, ya que los productos desarrollados con mentalidad de servicio cumplirán las siguientes condiciones:

• La calidad tiene la mayor importancia desde la fuente.
• Descubrimiento temprano de errores, especialmente en la actividad donde se crean.
• Resolver problemas es más fácil y más barato.
• Clientes felices.

Establecer una cultura de DevOps: los equipos de DevOps se basan en ciertos aspectos para centrarse en brindar un servicio de alta calidad a los clientes. Son una atmósfera que promueve el aprendizaje continuo, la autonomía para experimentar, una mentalidad de pensamiento de producto, una cultura de ingeniería y un enfoque en la calidad.

Las organizaciones deberían centrarse en crear un entorno que propague los aspectos anteriores.

A = Automation (Automatización):

Los avances tecnológicos están conduciendo a la automatización de tareas rutinarias

La automatización satisface muchas necesidades y resuelve muchos problemas, por supuesto. ¡Pero cuidado, solo representan el 25% del trabajo de DevOps!

En un ciclo de vida de entrega de software, muchas de las tareas se repiten y se vuelven rutinarias. Al entregar el proceso también al equipo de operaciones, identificamos muchas tareas que son rutinarias y redundantes. Las pruebas y los controles de rutina se pueden automatizar para mejorar la eficiencia de todo el proceso de entrega.

La automatización de las tareas de rutina dará como resultado un cambio, donde los miembros del equipo de Software Delivery ejecutarán principalmente tareas con alta variabilidad y alta capacidad de análisis. En otras palabras, tareas de ingeniería. Esto requiere que una organización se base en una estructura orgánica, con equipos de ingeniería en gran medida autónomos, multidisciplinarios y autoorganizados.

Los procesos automatizados son repetibles. El costo de la ejecución del proceso se minimiza. En otras palabras, la automatización da como resultado resultados predecibles y estandarizados. Estos conceptos se pueden aplicar a los procesos de entrega de software.

¿Por qué automatizar?

Sobre todo, para acelerar el flujo de información y evitar el reclutamiento de personas.

Acelerar el flujo de información, por supuesto, lleva el software al cliente antes, pero también ayuda a obtener resultados antes. Entonces, si un problema ocurre antes (como la detección de un error), cuesta mucho menos que si se descubre más tarde.

Evitar reclutar personas, ¿por qué? Por supuesto, por razones financieras, pero también para evitar posibles problemas de comunicación entre humanos, para evitar conflictos de personas y para evitar errores cometidos por humanos. Y sí, porque cuantos más humanos hay, más errores hay ...

Con la automatización, el equipo obtiene resultados más rápidos, más repetibles y más consistentes.

M = Measurement (Medición):

La medición es fundamental para ofrecer continuamente valor y mejora. Hacer un seguimiento de las métricas importantes y ofrecer comentarios ayuda a mejorar el proceso.

¿Cómo puede tener una mejora continua sin la capacidad de medir la mejora? ¿Cómo saber si una tarea de automatización vale la pena? Basar las decisiones en datos, más que en instinto, conduce a un camino de mejora irreprochable. Los datos deben ser transparentes, accesibles para todos, significativos y capaces de visualizarse de manera ad hoc

El proceso de mejora continua (Kaizen) está en el corazón de DevOps. Pero para eso, aún es necesario poder saber si uno ha mejorado y poder probarlo. No es un milagro, las medidas son la clave, porque las decisiones deben tomarse sobre hechos, datos, no opiniones.

¿Por qué medir? La mejor manera de saber si estamos mejorando es midiendo lo que hacemos.

No confiemos en el instinto, midamos lo que estamos haciendo para saber si estamos mejorando o empeorando.

Ejemplos técnicos:

• Radiadores de información.
• Monitoreo con plataforma de instrumentación.
• Medición de proceso (tiempo de ciclo, MTTR, etc.)
• Calidad de código / configuración, calidad de CI, mejoras de implementación

Ejemplos de negocios:

• ¿Cuántas personas se inscribieron hoy?
• ¿Cuántas personas que se registraron se convirtieron en clientes que pagan?
• ¿Cuántos ingresos obtuvimos hoy?
• ¿Cuál es el costo operativo?
• ¿Cuántos boletos para el centro de llamadas están llegando?
• ¿Cuánta actividad de la sala de soporte hay?

Los desarrolladores son responsables de definir qué medir y la operación es responsable de monitorear

S = Sharing (Compartir):

DevOps, por definición, es la colaboración del desarrollo y las operaciones, y el intercambio es fundamental para esto. La implementación de DevOps implica una interacción constante y, lo más importante, el intercambio de conocimientos. 

El éxito de DevOps en cualquier organización es compartir las herramientas, los descubrimientos y las lecciones. Al encontrar personas con necesidades similares en toda la organización, se pueden descubrir nuevas oportunidades para colaborar, se puede eliminar el trabajo duplicado y se puede crear un poderoso sentido de compromiso entre el personal. Fuera de la organización, compartir herramientas y códigos con personas de la comunidad ayuda a implementar rápidamente nuevas funciones en el software de código abierto. La participación en la conferencia deja al personal sintiéndose energizado e informado sobre nuevas formas de innovar.

Este principio tiene tres componentes fundamentales:

Visibilidad

• Esto se trata de lo que hiciste.
• No queremos tener una optimización local (la primera forma) queremos pensar globalmente, por lo tanto, debemos dar a todos la visibilidad de lo que estamos haciendo.
• Por ejemplo, dé visibilidad al propietario del producto de lo que el equipo está haciendo durante todo el desarrollo del proyecto.
• Esto permite que el equipo reciba comentarios del propietario del proyecto y otros equipos antes.

Transparencia

• La transparencia se trata de hacer que todos trabajen por el mismo objetivo.
• Alineación con otro equipo y la organización, hacia el mismo objetivo.

Transferencia de conocimiento

• Comparta conocimientos entre todas las personas que trabajan en algo.
• El equipo de funciones cruzadas ayuda a lograr eso.
• Colectivamente somos más inteligentes.

• Standup diario.
• Retrospectivas, Revisiones de aprendizaje.
• Documentación, documentación de código, etc.
• Bolsos marrones, charlas tecnológicas, conferencias internas.
• ChatOps