¿Qué es la Evaluación de madurez DevOps?

La Evaluación de madurez DevOps abarca el recorrido desde el commit hasta producción en cinco grupos: Pipeline de CI/CD, Lanzamiento y despliegue, Fiabilidad y operaciones, Automatización de seguridad y cumplimiento, y Plataforma e infraestructura. Tu equipo valora 15 capacidades, como la frecuencia de integración, la reducción del riesgo en los despliegues, la sostenibilidad de las guardias o el cumplimiento como código, en una escala de cinco niveles que va de Ad hoc a Optimizado. Los equipos que publican con poca frecuencia suelen reconocer los síntomas: pasos manuales en cada lanzamiento y una rotación de guardias que agota a las personas. Las valoraciones muestran qué capacidad es el verdadero cuello de botella. Como cada nivel tiene una descripción escrita, desarrolladores, SRE y perfiles de producto valoran la misma capacidad con la misma referencia, y las diferencias entre sus puntos de vista indican por dónde empezar.

Dimensiones

Pipeline de CI/CD

Con qué eficacia el equipo compila, integra y obtiene feedback mediante pipelines automatizados.

  • Automatización de compilaciones

    Con qué fiabilidad y grado de automatización se generan y validan las compilaciones de software.

    1. Ad hocLas compilaciones son manuales, lentas y propensas a errores.
    2. EmergenteExiste una automatización básica, pero es frágil o incompleta.
    3. DefinidoLas compilaciones se ejecutan de forma fiable con un nivel moderado de automatización.
    4. GestionadoLas compilaciones están muy automatizadas y ofrecen un feedback rápido y fiable.
    5. OptimizadoLa automatización de compilaciones es fluida, estable y se optimiza continuamente, con fallos casi inexistentes.
  • Frecuencia de integración

    Con qué frecuencia los desarrolladores integran cambios en la base de código compartida.

    1. Ad hocLa integración es poco frecuente, lo que da lugar a fusiones grandes y arriesgadas.
    2. EmergenteEl equipo intenta integrar con más frecuencia, pero persisten las incoherencias.
    3. DefinidoLa integración diaria es habitual y reduce los conflictos de fusión.
    4. GestionadoLa integración es continua y estable en todo el equipo.
    5. OptimizadoIntegración casi en tiempo real con conjuntos de cambios pequeños y seguros que permiten un flujo rápido.
  • Feedback del pipeline

    Rapidez y claridad de la información que el pipeline devuelve a los desarrolladores.

    1. Ad hocEl feedback es lento, poco claro o poco fiable.
    2. EmergenteHay feedback, pero suele llegar tarde o con mucho ruido.
    3. DefinidoEl feedback del pipeline es razonablemente oportuno y accionable.
    4. GestionadoEl feedback es rápido y claro, y permite a los desarrolladores iterar con agilidad.
    5. OptimizadoEl feedback es inmediato y preciso, y permite una velocidad de ingeniería de primer nivel.

Lanzamiento y despliegue

Con qué seguridad, previsibilidad y frecuencia el equipo entrega cambios a los usuarios.

  • Automatización de despliegues

    Nivel de automatización y repetibilidad de los despliegues.

    1. Ad hocLos despliegues son manuales, arriesgados y propensos a errores.
    2. EmergenteSe introduce algo de automatización, pero se aplica de forma irregular.
    3. DefinidoLos despliegues están mayormente automatizados y son predecibles.
    4. GestionadoDespliegues totalmente automatizados con bajas tasas de fallo.
    5. OptimizadoDespliegue continuo con lanzamientos seguros, rápidos y reversibles.
  • Reducción del riesgo en los despliegues

    Con qué eficacia el equipo minimiza el riesgo durante los lanzamientos.

    1. Ad hocLos lanzamientos son eventos de alto riesgo, todo de una vez.
    2. EmergenteExiste cierta mitigación de riesgos, pero es limitada.
    3. DefinidoSe usan con regularidad feature flags y despliegues escalonados.
    4. GestionadoLos lanzamientos son de bajo riesgo, con salvaguardas y monitorización sólidas.
    5. OptimizadoEstrategias de lanzamiento avanzadas evitan caídas y permiten revertir al instante.
  • Frecuencia de entrega

    Con qué frecuencia se entrega valor a los usuarios.

    1. Ad hocLos lanzamientos son escasos, imprevisibles y muy variables.
    2. EmergenteLa cadencia de lanzamientos mejora, pero sigue siendo irregular.
    3. DefinidoEl equipo lanza siguiendo un calendario predecible.
    4. GestionadoCiclos de lanzamiento frecuentes y fiables.
    5. OptimizadoLa entrega continua garantiza un flujo de valor rápido y seguro.

Fiabilidad y operaciones

Lo bien que el equipo observa los sistemas en ejecución, responde ante ellos y mantiene su buen estado.

  • Monitorización y observabilidad

    Lo bien que el equipo entiende el estado y el comportamiento del sistema.

    1. Ad hocMonitorización limitada o reactiva; los problemas se detectan demasiado tarde.
    2. EmergenteExisten paneles básicos, pero la visibilidad tiene grandes lagunas.
    3. DefinidoLa monitorización ofrece una visibilidad adecuada de la mayoría de los componentes.
    4. GestionadoObservabilidad sólida con logs, métricas y trazas que permiten un diagnóstico rápido.
    5. OptimizadoObservabilidad integral con información predictiva y detección automatizada.
  • Respuesta a incidentes

    Con qué eficiencia el equipo responde a los incidentes y los resuelve.

    1. Ad hocLos incidentes son caóticos y no está clara la responsabilidad.
    2. EmergenteHay cada vez más estructura, pero la resolución sigue siendo irregular.
    3. DefinidoLos incidentes se gestionan de forma metódica con una eficiencia moderada.
    4. GestionadoRespuesta rápida y coordinada con un MTTR bajo.
    5. OptimizadoGestión de incidentes muy madura con postmortems centrados en el aprendizaje.
  • Sostenibilidad de las guardias

    Equidad y eficacia de los procesos de guardia.

    1. Ad hocLas guardias son agotadoras, imprevisibles o injustas.
    2. EmergenteLa carga de trabajo es más llevadera, pero siguen los problemas.
    3. DefinidoLa rotación es justa y el volumen de alertas es razonable.
    4. GestionadoBuenas prácticas de guardia con alertas bien ajustadas y buenas herramientas.
    5. OptimizadoAlertas fuera de horario mínimas; la automatización resuelve la mayoría de los problemas.

Automatización de seguridad y cumplimiento

Hasta qué punto la seguridad y el cumplimiento están automatizados e integrados en todo el pipeline de entrega.

  • Integración de la seguridad

    Con qué eficacia las prácticas de seguridad están integradas en los flujos de desarrollo.

    1. Ad hocLas comprobaciones de seguridad son manuales o se hacen tarde en el proceso.
    2. EmergenteExisten análisis automatizados básicos, pero con poca cobertura.
    3. DefinidoLa seguridad está integrada en CI/CD con análisis sistemáticos.
    4. GestionadoComprobaciones de seguridad automatizadas y exhaustivas en todo el pipeline.
    5. OptimizadoSeguridad continua e inteligente que evita las vulnerabilidades desde el principio.
  • Gestión de vulnerabilidades

    Con qué rapidez y eficacia se detectan y se corrigen las vulnerabilidades.

    1. Ad hocLas vulnerabilidades se detectan tarde y se corrigen con lentitud.
    2. EmergenteLos procesos mejoran, pero siguen siendo irregulares.
    3. DefinidoLa respuesta a las vulnerabilidades es predecible y se mide.
    4. GestionadoCorrección rápida y eficiente con prevención proactiva.
    5. OptimizadoIdentificación, priorización y corrección automatizadas a escala.
  • Cumplimiento como código

    Uso de la automatización para hacer cumplir los requisitos normativos, de seguridad y de políticas.

    1. Ad hocLas tareas de cumplimiento son manuales y reactivas.
    2. EmergenteSe han introducido algunas comprobaciones automatizadas.
    3. DefinidoLas políticas críticas están integradas en los flujos de automatización.
    4. GestionadoEl cumplimiento se verifica de forma rutinaria mediante comprobaciones automatizadas.
    5. OptimizadoCumplimiento continuo con aplicación de políticas en tiempo real.

Plataforma e infraestructura

Grado de automatización, coherencia y resiliencia de la plataforma y la infraestructura subyacentes.

  • Automatización de la infraestructura

    Cómo se aprovisiona, gestiona y escala la infraestructura.

    1. Ad hocLa infraestructura se aprovisiona manualmente, con un alto riesgo de desviaciones.
    2. EmergenteAutomatización parcial mediante scripts o herramientas.
    3. DefinidoInfraestructura como código implantada en las áreas clave.
    4. GestionadoInfraestructura totalmente automatizada con entornos coherentes y repetibles.
    5. OptimizadoInfraestructura autorreparable y totalmente orquestada, con escalado inteligente.
  • Coherencia entre entornos

    Grado de coherencia entre los entornos de desarrollo, preproducción y producción.

    1. Ad hocLos entornos difieren mucho; los problemas suelen ser específicos de cada entorno.
    2. EmergenteHay cierta estandarización, pero persisten las incoherencias.
    3. DefinidoLos entornos están mayormente alineados y su comportamiento es predecible.
    4. GestionadoEntornos muy coherentes gestionados mediante automatización.
    5. OptimizadoEntornos totalmente reproducibles, en contenedores y estables en todas partes.
  • Fiabilidad de la plataforma

    Disponibilidad, resiliencia y tolerancia a fallos del sistema.

    1. Ad hocCaídas frecuentes y pocas prácticas de fiabilidad.
    2. EmergenteLa fiabilidad mejora ligeramente, pero los problemas persisten.
    3. DefinidoFiabilidad aceptable con mejoras en marcha.
    4. GestionadoAlta fiabilidad con sólidas medidas preventivas.
    5. OptimizadoResiliencia excepcional con recuperación automatizada y arquitecturas tolerantes a fallos.

Cuándo debe realizarse esta revisión médica

  • Para establecer una línea base de las capacidades de DevOps y entrega continua de tu equipo.
  • Durante la planificación de ingeniería, para decidir si lo siguiente es la automatización, la fiabilidad o la seguridad.
  • Para seguir la evolución de la madurez DevOps a lo largo del tiempo en distintos squads o en toda la organización.
  • Cuando estés creando o ampliando prácticas de ingeniería de plataformas y SRE.
  • Durante una transformación DevOps, para dar a los equipos una hoja de ruta de mejora compartida.

Consejos y trucos

  • Pide a ingenieros, SRE y responsables de producto que valoren por separado, para que afloren las distintas visiones sobre la madurez.
  • Empieza por las dimensiones con mayor dispersión de puntuaciones. Suelen señalar cuellos de botella que nadie ha nombrado.
  • Para cada dimensión con puntuación baja, acordad un paso para avanzar al siguiente nivel. No intentéis llegar a Optimizado en todo a la vez.
  • Repite la evaluación cada trimestre para que los pequeños avances sean visibles.
  • Leed juntos las descripciones de los niveles antes de debatir las puntuaciones, para que todos coincidan en qué significa hacerlo bien.

Preguntas frecuentes

¿Qué es un modelo de madurez DevOps?
Es una forma estructurada de evaluar el grado de avance de las prácticas de DevOps y entrega continua de tu equipo. Las capacidades se valoran en niveles progresivos, de Ad hoc a Optimizado, para que puedas ver las carencias y planificar qué mejorar.
¿Quién debería participar en esta evaluación?
Cualquiera que desarrolle, entregue u opere software: desarrolladores, SRE, ingenieros de plataforma, especialistas en seguridad y responsables de ingeniería. Cada uno ve una parte distinta del recorrido de entrega.
¿Cómo se valoran las dimensiones?
Cada dimensión se puntúa en una escala de cinco niveles, de Ad hoc a Optimizado, con una descripción para cada nivel. Así las valoraciones son coherentes y el equipo tiene algo concreto sobre lo que hablar.
¿Con qué frecuencia deberíamos hacerla?
Trimestralmente es lo adecuado para la mayoría de los equipos. Da tiempo a que las mejoras se consoliden y muestra el progreso de una sesión a la siguiente.
¿Podemos personalizar las dimensiones?
Sí. Los administradores de cuenta y de equipo pueden crear modelos de salud personalizados en TeamRetro, de modo que podéis añadir, eliminar o reformular dimensiones para adaptarlas a vuestras herramientas y prioridades.