Un camino práctico hacia la madurez de DevOps

Cualquier metodología ágil es inútil sin prácticas reales de DevOps. La palabra de moda fue mal utilizada en muchas organizaciones. Si dice que tiene equipos ágiles maduros y tiene un ingeniero de DevOps o un equipo de DevOps, que probablemente no vayan en la dirección correcta. DevOps es una cultura en lugar de un nombre o designación de equipo. Siguiendo el ejemplo de CMM (Modelo de Madurez de capacidades), este intento es ayudar a una organización a saber dónde se encuentra en un viaje de DevOps y el camino a seguir. Con una lluvia de ideas entre los equipos de Desarrollo y Operaciones, esto se puede ampliar y personalizar según las necesidades de la organización.

Ningún número es malo, ya que ayuda a un individuo u organización a crecer.

Cliente Feliz

a Diferencia de CMM, este no es un modelo que necesita para demostrar a cualquier organización de certificación. El único certificado que obtiene es de sus clientes satisfechos o socios comerciales. Es un modelo para auto-reflexionar y ayudar a los negocios a crecer. El propósito mismo de cualquier equipo de TI es crear valor mediante una entrega sostenible y predecible con calidad.

Este es un modelo simple que desde el Desarrollador hasta el CxO pueden entender y relacionarse.

Antes de discutir sobre el modelo. Necesitamos entender la necesidad de este modelo. Hace muchos años, Melvin Conway en su artículo » How do committees invent?»se le ocurrió una tesis que se hizo famosa como la ley de Conway.

Cualquier organización que diseñe un sistema (definido ampliamente) producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización.

La ley se basa en el razonamiento de que para que los módulos de software funcionen, varias personas deben comunicarse con frecuencia entre sí. Por lo tanto, la estructura de interfaz de software de un sistema reflejará los límites sociales de las organizaciones que lo produjeron, a través de los cuales la comunicación es más difícil.

Veamos cómo funciona esto en el desarrollo de software con un escenario real. Radha está construyendo una pantalla frontal que muestra los atributos detallados de un producto. Digamos que este producto es un teléfono móvil. Pocos detalles comunes del producto son el color, el precio, las dimensiones, las calificaciones, etc. Una nueva regulación llegó a mostrar el valor SAR del teléfono. La pantalla que diseñó funciona con micro llamada de servicio. Habló con Sunil, que trabaja en el equipo de datos. Dijo que solo pueden enviar datos en archivos planos. Hay una desconexión clara entre dos módulos. Este es un escenario con el que se encuentra cada equipo de TI, si no todas las veces del 100%, pero la mayoría de las veces. Esto es solo un problema de diseño. El problema es más amplio. ¿Qué pasa si las prioridades del otro equipo son muy diferentes de lo que está haciendo tu equipo? Sus requisitos pueden ser la prioridad más baja para ellos mientras sus partes interesadas están detrás de usted.

El primer paso para una implementación exitosa de DevOps es estar abierto con los cambios de organización.

Cambios en la organización

Permítanme hablar de 5 niveles de madurez:

  1. Inicial: En esta fase, los equipos trabajan en silos y solo hay colaboración basada en la necesidad. En una reunión con todos los equipos juntos, si preguntas a quién pertenece el «Producto», no tendrás que levantar ninguna mano. El tiempo de comercialización suele ser más largo, llegando a meses y a veces años. Las prioridades se establecen a nivel de equipo, pero no a nivel de producto. Esto hará que cada equipo tenga sus propias prioridades. Como no hay un proceso definido, cada intento es como reinventar la rueda. Esto dará lugar a problemas de calidad y plazos más largos. El equipo realiza principalmente despliegues manuales e intervenciones manuales. Bien.. este no es un mal estado. Así es como comenzaría la mayor parte del desarrollo.

2. Repetible: Los equipos siguen trabajando en silos. Hay cierto nivel de automatización dentro del equipo. Cuando llega una crisis, el equipo define su propio proceso y lo sigue hasta que la crisis termina. La única buena noticia es que algunos de estos pueden convertirse en procesos repetibles cuando la crisis vuelva a estallar.

3. Definido: Este es un buen punto de partida para sembrar la cultura DevOps con un equipo centralizado. Este equipo comprende las diversas tecnologías que están utilizando los equipos de desarrollo y las herramientas se basan en las necesidades actuales. Al ser un equipo centralizado, no es fácil monitorear lo que cada equipo está haciendo, por lo que algunas decisiones se dejan a los equipos para que experimenten. El equipo central suele estar formado por expertos y los equipos de desarrollo contarán con algunas personas con conocimientos y conocimientos básicos.

4. Administrado: A medida que el equipo central de DevOps comprende el panorama de las herramientas de la organización, se prueban múltiples entornos y herramientas. Los procesos consistentes y repetibles son seguidos por varios equipos. La cadena de herramientas se selecciona en función de los casos de uso en lugar de las elecciones personales. Se introducen herramientas de monitoreo para todos los procesos y los equipos las utilizan en gran medida para tomar decisiones.

5. Optimizar:

El éxito de un buen líder se define por no tener seguidores, sino por la capacidad de crear grandes líderes.

La etapa final de madurez de DevOps es hacer que el equipo de DevOps desaparezca. Esto podría parecer contra intuitivo. En esta etapa, DevOps es parte del equipo de desarrollo de productos en lugar de una entidad separada. Uso de infraestructura como código, contenedores, orquestación, etc. se logra la implementación sin contacto. Ahora, si llamas a todos los que están trabajando en un producto y preguntas a quién pertenece el producto, tendrás algunas manos seguras levantando sin dudarlo. Los datos de las herramientas de monitoreo se utilizan para seleccionar un nuevo conjunto de herramientas (incluida la infraestructura, los lenguajes de programación y las técnicas). Las decisiones se basan en datos y no en preferencias personales. El equipo de producto está listo para implementar el código en cualquier momento y día. Les encanta el «valor comercial» y lo tratan como una mascota. Todo lo demás es tratado como ganado.

DevOps Modelo De Madurez.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.