Edelweiss - Fotolia

Lo básico Póngase al día con nuestro contenido introductorio.

Escale los procesos DevOps contra viento y marea

DevOps es el cambio que todos quieren, hasta que significa nuevos procesos. El cambio difícil, pero gratificante, hacia un flujo de procesos DevOps reinventa todo, desde lanzamientos hasta respuestas a incidentes.

A veces, los números cuentan la historia. Para 2020, Gartner predice que al menos el 80% de las grandes empresas utilizará DevOps o tendrá un proyecto piloto, en comparación con el 38% actual. Y el 87% de las organizaciones que implementan procesos de DevOps hoy en día ya están decepcionadas.

"Va a haber mucha desilusión [con DevOps] en los próximos tres o cuatro años", debido a los pilotos que no escalan, proveedores que limpian productos de DevOps y otras dificultades, dijo Ian Head de Gartner, en la Cumbre de Estrategias y Soluciones de Operaciones de TI de la firma en Orlando, Florida, en mayo pasado.

En la encuesta de Gartner a 400 organizaciones, el 50% de los encuestados culpó a las personas y los problemas culturales por frenar DevOps, y el 37% dijo que no podían encontrar los procesos existentes que funcionaban para DevOps. Solo el 8% reportó obstáculos tecnológicos.

Para evitar el destino demasiado común de las víctimas de DevOps, las organizaciones deben comprender los procesos de DevOps y diseñar tanto esos procesos como los equipos para escalar. Los departamentos de TI deben preguntar: ¿Para qué son mis procesos? ¿Cuáles son los objetivos de mi proceso? y ¿Cómo mediré el resultado?

Defina procesos y plataformas DevOps

Al menos la mitad de las organizaciones no alcanzan sus objetivos con DevOps, dijo Head. Parte de la culpa radica en los procesos operativos que no son adecuados para DevOps: demasiado control en las áreas incorrectas y una falta de confianza y responsabilidad compartida entre el desarrollo y las operaciones.

Head recomendó que Operaciones tomen prestado el concepto ágil de un producto viable mínimo y crearan sus propios procesos mínimos viables. Los procesos de DevOps deben desmantelar conjuntos de herramientas excesivamente complejos, proporcionar la protección suficiente para que la velocidad no conduzca al desastre y luchar contra los cambios no administrados.

Un conjunto mínimo viable de procesos DevOps hace que la plataforma sea tan iterativa como los productos que admite. "Su punto final puede ser solo una pequeña ganancia", dijo Larry Herz, ingeniero senior de centros de datos de AHEAD LLC, una firma consultora de adopción de nube, con sede en Chicago.

Comience con la aceptación absoluta de todos los equipos involucrados y una buena huella arquitectónica. Adopte el producto mínimo viable, y construya sobre él. Por ejemplo, si crea servidores manualmente, desarrolle procesos para crear e implementar una imagen dorada en su plataforma de virtualización de su elección. El siguiente paso: Implemente una imagen base segura y compatible en todos los sistemas Windows y otra en todos los sistemas Linux, luego generalice la pila de aplicaciones. Las organizaciones arraigadas pueden tener 50.000 servidores con igual número de configuraciones diferentes, señaló, por lo que deben ocurrir cambios iterativos en la plataforma antes de que los procesos de DevOps puedan traducirse a: "Puedo presionar un botón y obtener mi pila de aplicaciones".

"En última instancia, desea obtener [automatización de extremo a extremo], pero no lo espere", dijo Herz. "Haga un poco, mejore eso un poco y suba en la pila". A medida que los procesos de DevOps se complementan, la resistencia se derrite.

Aténgase a la fuente y poténciela

En lugar de forzar a las personas a lo largo de un flujo de trabajo, permítales hacer juicios basados ​​en la información que generan los procesos automáticos. Los procesos de DevOps mantienen las decisiones estrechamente ligadas a la información.

Las personas mejor pagadas no toman todas las decisiones; las personas responsables del producto lo hacen. Los gerentes de lanzamiento deben decidir sobre un curso de acción y corregir cualquier falla causada por la decisión.

"No cree un nuevo proceso: la integración a la práctica de trabajo estándar es realmente importante", dijo Jon Williams, CTO de Niu Solutions, una consultora de TI y proveedor de servicios de infraestructura en la nube en el Reino Unido. Mantenga las colas de trabajo normales para alentar la adopción de DevOps.

La gestión del cambio significa liberación temprana, y a menudo

Los procesos de DevOps para el lanzamiento ponen de cabeza la mentalidad de cascada. En los procesos de cascada, los grandes cambios con relaciones complejas aumentan los riesgos debido a las dependencias, por lo que las actualizaciones se acumulan y se asigna a una persona para que las administre en un gran paquete, destapando el mayor riesgo posible.

En cambio, DevOps exige que los equipos se destaquen en los lanzamientos y los hagan a menudo. Los propietarios de productos de negocios deben definir los criterios de aceptación de riesgo y servicio, dijo Head. Los procesos de DevOps favorecen los sprints pequeños en infraestructura y operaciones en grandes proyectos, por lo que los problemas se encuentran y se solucionan fácilmente.

"No queremos diseñar un gran proceso perfecto que se aplique en todas partes, [y] eso es constante en toda la organización", dijo Head. "Podemos diseñar un nuevo proceso solo para este producto en el que estamos trabajando, hacerlo bien, entenderlo y permitir que el proceso se expanda en escala y en función".

En otras palabras, emular la mentalidad ágil Scrum en Operaciones.

No todos los cambios son iguales, por lo que es necesario un análisis de impacto de cambio en un flujo de proceso DevOps. Cree un proceso en el que los equipos de productos puedan cambiar el producto de software sin la aprobación de operaciones, siempre que no afecten las configuraciones de la infraestructura. Los desarrolladores informan a operaciones de estos cambios de código y los peligros asociados como parte del proceso, y luego los cambios pasan por una cadena de herramientas con scripts gobernados. Los equipos de infraestructura y operaciones, mientras tanto, crean una plataforma común sin personalización para las dependencias de código. Para comprender, exponer y mitigar el riesgo de los cambios, la automatización de las entregas y las técnicas de implementación estratégica, como la implementación canaria y azul-verde, entran en juego.

Niu aplicó el enfoque DevOps de actualizaciones pequeñas y constantes a su proceso de auditoría. El proveedor de servicios se especializa en la nube financiera y, debido a una gran huella heredada, considera que el cumplimiento es un mejor punto de partida para DevOps que la automatización de la infraestructura. Niu usó la herramienta Chef InSpec para trazar estándares de construcción y estándares de industria y probar el cumplimiento de las tecnologías que entregan.

"La victoria masiva es continua", dijo Williams. Antes, las auditorías implicaban un frenesí de actividad preparatoria y una sensación de alivio cuando se completaban, hasta la siguiente.

Los procesos DevOps para el cumplimiento redujeron el retrabajo y el tiempo de inactividad no planificado para el equipo de operaciones, dijo Gary Bright, desarrollador de infraestructura en Niu, quien se presentó en ChefConf en mayo de 2017.

Niu usó el modelo de conformidad para iniciar la automatización con el código de entrega. "Estábamos desactivando las máquinas de Windows [y] los firewalls, y luego estábamos un poco molestos al descubrir que todavía eran máquinas de Windows [que necesitaban atención constante]", dijo Williams. Niu desarrolló sobre las comprobaciones de cumplimiento ya escritas para mejorar el despliegue, la configuración, la integración y la prueba, y se deshizo de muchos traspasos. Luego, se basaron en eso para crear procesos DevOps para la detección y corrección con el objetivo de la remediación automática.

Lo que usted monitorea importa

DevOps exige nuevas métricas. En cada decisión, las organizaciones de DevOps también deben considerar las métricas empresariales, como la retención de clientes y las ganancias por cliente.

"Históricamente, nos enfocamos en las métricas del tiempo medio entre fallas, número de incidentes por mes", dijo Head. Eso no servirá para el mundo de DevOps, donde las cosas como el tiempo medio para detectar y el tiempo medio para restaurar el servicio afirman la calidad del rendimiento.

Algunas mediciones teóricas ayudaron al personal de Niu a probar el valor de los procesos DevOps sobre el trabajo manual. Una configuración de firewall manual tomó aproximadamente 15 minutos en el mejor de los casos, que ascendió a 3.125 días para una sola ejecución. Con esta línea de base, el equipo sabría si los conductos y la infraestructura como código mejorarían la velocidad de operaciones.

Niu también calculó la pérdida de productividad en el back end para cada problema crítico para demostrar cómo los procesos controlados podrían reducir el trabajo no planificado para todos: ingenieros, administradores de servicios y cuentas, soporte técnico y ejecutivos. El equipo ahora está investigando cómo medir el efecto nocivo sobre los ingresos comerciales y las ganancias de un problema de operaciones.

"Tenemos múltiples audiencias para monitorear datos porque los equipos de aplicaciones son clientes de las funciones de monitoreo", dijo Head. Los equipos de productos deberían vivir y morir según la arquitectura que definieron, lo que significa que necesitan saber lo que está sucediendo. Los equipos de DevOps maduros promulgan datos de monitoreo a través de una combinación de autoinstrucción en la aplicación y análisis compartido a través de herramientas comunes.

El riesgo medido y la responsabilidad reemplazan la culpa

Los procesos DevOps toleran la inevitabilidad del riesgo y protegen el valor frente a niveles aceptables de riesgo.

Los cambios fallidos causan la mayoría de los incidentes en las implementaciones de producción anteriores a DevOps, a pesar del enfoque de infraestructura y operaciones en arquitecturas resistentes. Muchas empresas, incluso las que se suscriben a una metodología de servicio, como COBIT o ITIL, introducen una herramienta y siguen su flujo de trabajo sin análisis crítico. También rodean a operaciones con un gobierno que asfixia procesos para evitar fallas.

Los procesos de gestión de incidentes en los departamentos DevOps remodelan el proceso de la mesa de servicio. Una llamada de incidente conduce a una clasificación en lugar de un intento de reparación de primera ronda. El propietario del producto comercial y el maestro de scrum deciden cómo un incidente impulsa la cola de trabajo: ¿Resolver ahora o esperar la próxima versión? Si es posible, deténgase inmediatamente, reúna al equipo y descubra cómo detectar ese problema antes la próxima vez, y resuélvalo.

Head advirtió contra el riesgo moral, un riesgo que corre a cargo de otra persona, ya que ese alguien siempre parece ser operaciones. Es un escenario demasiado familiar: el proyecto se retrasa en el diseño, se producen retrasos en el desarrollo, las pruebas tardan más de lo esperado y la responsabilidad de un lanzamiento puntual recae en operaciones.

Qué pasa y cuándo

Las organizaciones deben enumerar todas las actividades a lo largo del flujo de procesos de DevOps desde el plan del producto, la creación y verificación del código, hasta la preproducción y el lanzamiento a través de la configuración y el monitoreo, de vuelta a la planificación, recomendó Head. Este ejercicio aclarará qué habilidades pertenecen al equipo y dónde la automatización permitirá cambios acelerados y escalables.

¿Las personas están dispuestas a poseer el código de la aplicación, el almacenamiento y las bases de datos, o la propiedad le echa la culpa a usted? DevOps se trata de productos construidos para ejecutarse, pero no porque los equipos eviten fallas.

"Cuanto más tiempo pase entre fallas, mayor será la falla", dijo Head. "Las fallas pequeñas son buenas, incluso en nuestras infraestructuras". Cree infraestructuras resistentes a las fallas, pero eluda las plataformas demasiado complicadas.

Los equipos integrados y las herramientas integradas obtienen la información correcta, en el formato correcto, en el momento correcto. La muerte por procesos puede matar a una organización por completo, así que entienda los objetivos y resultados que desea entregar, aconsejó Williams.

Este artículo se actualizó por última vez en noviembre 2017

Profundice más

PRO+

Contenido

Encuentre más contenido PRO+ y otras ofertas exclusivas para miembros, aquí.

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Enviando esta solicitud usted acepta recibir correos electrónicos de TechTarget y sus socios. Si usted reside afuera de Estados Unidos, esta dando autorización para que transfiramos y procesemos su información personal en Estados Unidos.Privacidad

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close