DevOps es un término con diferentes significados para diferentes personas. De hecho, no hay –aún- algo como un “manifiesto”.

Tampoco es que un NetOp o un SysAdmin o algún otro rol se conviertan por arte de magia en un DevOp[1]. Tampoco es una tecnología en concreto[2]. No se trata de resolver un problema de TI sino de innovación, del negocio.

Bueno, sí, la relación entre desarrollo de software (valor traducido en la funcionalidad requerida) y operaciones (valor traducido en estabilidad tangible) está en las siglas pero, por la literatura que circula al respecto, aún no hay una definición estándar[3]. Pero, de hecho, usualmente encontramos el “yo me ocupo sólo de mi parte” o “en mi máquina funciona, es tu problema” o “es tu culpa”[4], entre otros muchísimos aspectos sociales o técnicos de la “relación”; así, la palabra “relación” es circunstancial –algo que DevOps e ITIL buscan eliminar.

Está el enfoque técnico pero también está la necesidad del negocio. Las personas, los procesos y la tecnología van de la mano en este moderno enfoque estratégico.

De hecho, cada negocio es distinto y cada empresa tendrá que analizar la velocidad de los despliegues y la frecuencia de los mismos para someter a consideración la más apropiada y mejor alternativa de solución –una solución a la medida para cada empresa, considerando que a algunas les contará más trabajo que a otras la adopción de este paradigma[5]. Flexibilidad, adaptabilidad y velocidad son aspectos que los usuarios y clientes valoran de los servicios que consumen porque están convencidos de que con estos servicios logran una ventaja competitiva -pueden llegar a ser más eficientes, efectivos, productivos.

En la siguiente figura se muestra la brecha entre Dev y Ops:

Así, es requerida una plataforma tecnológica (hardware, software, infraestructura) altamente automatizada (pruebas de código incluidas), con un flujo de trabajo automatizado (versiones, personalizaciones, configuraciones), y monitorizada de forma continua para asegurar que se cumple con los niveles de servicio comprometidos por el negocio (se valida y verifica que se alcanzan los objetivos estratégicos) y que el servicio está garantizado ya que satisface los requerimientos de: seguridad (seguridad de la información por supuesto, una necesidad en la estrategia DevOps[6] para generar confianza); capacidad (rendimiento, escalabilidad, tanto del hardware y software base como de las aplicaciones); disponibilidad, continuidad; soporte; confiabilidad –recordemos la garantía de valor según ITIL; ¿estarán los procesos de la organización preparados para este paradigma?

En ambos entornos hay bastante que mejorar ya que lo requerido por el negocio es la satisfacción del cliente o consumidor con el servicio recibido (el valor del servicio estratégico que ha sido diseñado y transicionado a producción se valida, verifica y aprecia en la operación con el cumplimiento de los SLA). Esto implica poner en práctica las mejores recomendaciones de nunca pasar un defecto conocido por los centros de trabajo, de no permitir nunca que una optimización local o particular genere una degradación global, de siempre buscar incrementar la fluidez de las comunicaciones, y de siempre buscar alcanzar una profunda comprensión del sistema (según Deming). Debemos entonces tener en cuenta el rendimiento del servicio completo, de extremo a extremo, y no de individuos, componentes, áreas o departamentos por separado.

La retroalimentación es entonces clave para saber y reconocer si las expectativas del negocio se están aterrizando completa y correctamente[7] –preguntemos a los stakeholders su visión y apreciación holística de los resultados[8]. Entendamos y respondamos sus inquietudes, acerquemos y amplifiquemos los lazos de retroalimentación cuando y donde sean necesarios, incorporemos el conocimiento donde –con conciencia- lo requiramos. ¿Serán efectivos los procesos de gestión de cambios, de configuraciones, de versiones, de accesos, y de problemas, entre otros?, ¿estarán a la altura de las nuevas necesidades?, ¿estarán a punto los ambientes de prueba necesarios[9]?, ¿estamos midiendo los resultados esperados –el valor para el cliente- o todavía medimos salidas de componentes/sistemas/áreas/departamentos individuales? Las profesiones son diferentes (know-how, habilidades, conocimientos, necesidades de capacitación, etc.), los roles son diferentes, y es claro que la responsabilidad es compartida[10].

Los marcos de trabajo y herramientas también son numerosas y diferentes para cada profesión; usualmente hablamos de “llevar” a la nube y tal vez también sea bueno considerar “traer” de la nube. Incluso las diferentes herramientas que existen también tienen enfoques digamos, “sesgados” en uno u otro entorno. Sin embargo, hay buenas noticias: existen varias alternativas; pero también hay malas noticias: existen varias alternativas. Esto implica adoptar e interiorizar una cultura que fomente: (a) experimentación continua, correr riesgos y aprender de los fracasos –la búsqueda de la innovación, reducir el “time-to-market”, salir de nuestra zona de confort, entre otros aspectos positivos; y (b) la comprensión de que la repetición y la práctica es el requisito previo para la maestría –incrementar la resiliencia, estabilidad, garantía, cumplimiento, seguridad de la información, eficiencia, efectividad, rapidez, flexibilidad y adaptabilidad para responder a nuevas o cambiantes necesidades, empleo eficiente de modernas tecnologías disruptivas, entre otros beneficios. Integrar las diferentes alternativas de solución es lo importante –y es lo riesgoso para el negocio, aunque a nosotros los especialistas esta integración nos resulte interesante. ¿Cuánta integración es necesaria, en cuántas fases lo lograremos, cuál es el plazo o cuáles son los plazos, quién realizará esta integración (o con quién), con qué se realizará?, son algunas preguntas que deberemos responder.

Requisitos y beneficios podrían verse mezclados y esto podría ocasionar confusión –y problemas- en su adopción; así, cada empresa deberá establecer los principios, métodos y prácticas DevOps que sean más apropiados para sus negocios.

Creo que a todos nos duele la cabeza el sólo pensar las mejoras que debemos implementar en nuestros respectivos ecosistemas tecnológicos, empezando por un cambio de cultura para eliminar los silos; aportar transparencia en las actividades de desarrollo y de operaciones; adoptar e interiorizar la calidad[11] y la colaboración[12]; trabajar en equipo, de forma más cercana, en un marco de respeto mutuo, generando confianza, aportando mayor agilidad al negocio y notables incrementos de productividad [13]; establecer procesos y responsabilidades claras; identificar mejoras necesarias en los procesos, tecnología y capacidades, habilidades, y conocimiento de las personas.

Para tener éxito con un DevOps disciplinado, necesitamos ocuparnos de las 5P de la mejora [14] (donde tal vez sean las personas lo más importante, como ya hemos visto):

Propósito/Objetivo: involucra todos los elementos que constituyen la intención de la organización. Esto incluye la misión, visión, objetivos y estrategias de la organización. Implica identificar los principales puntos fuertes, puntos débiles, oportunidades y amenazas;
Principios: son las filosofías que guían la empresa, los supuestos, o actitudes sobre las que la organización debe operar y cómo debería conducir sus negocios. Esto incluye la base de integridad, ética, y valores nucleares a los cuales se espera que los empleados se comprometan cuando son contratados. Implica identificar la cultura y los valores de la organización;
Procesos: son las estructuras organizacionales, sistemas, y procedimientos que se utilizan para fabricar los productos o desarrollar los servicios que provee la organización, así como la infraestructura y reglas que apoyan estos sistemas y procedimientos. Implica una lista de todos los procesos y exponerlos mediante diagramas de flujo, mapas de procesos, técnicas como 6W-2H; identificando los responsables de cada proceso;
Personas: son los individuos (y equipos de personas) que realizan el trabajo que es consistente con los Principios y Procesos de una organización para lograr su Propósito. Son los componentes activos que obtienen resultados. Implica determinar en qué medidas las personas están calificados para las funciones que desempeñan; identificar las necesidades de formación;
Rendimiento: involucra todas las métricas, mediciones y resultados esperados que muestran el estado de la organización, y son utilizados para la toma de decisiones. Los resultados son re‑alimentados al proceso de gestión estratégica con el fin de proveer retro‑alimentación y control. Implica identificar las medidas de rendimiento usados; establecer indicadores clave de rendimiento (KPI); establecer un sistema métrico.

El modelo de negocio determinará el marco de trabajo, mejor práctica, o norma que se empleará[15] y el contexto en el que actuarán (ITIL y DevOps, por ejemplo, complementándose ambos), enderezando el timón cuando y cuantas veces sea necesario. Es buscar agregar/obtener valor a/de los servicios que la empresa entrega. Esto implica buscar convertirnos en seres realmente proactivos –una nueva especie en el mundo informático de más de una empresa.

[1] Fuente: https://www.quora.com/Is-DevOps-the-new-name-for-SysAdmin-Why-are-all-DevOps-tools-related-to-infrastructure-and-system-admin; disponible en agosto/2016

[2] Fuente: http://searchdatacenter.techtarget.com/es/consejo/Definicion-de-DevOps-mejor-explicamos-lo-que-no-es; disponible en agosto/2016

[3] Fuente: https://www.youtube.com/watch?v=o7-IuYS0iSE; disponible en agosto/2016

[4] Fuente: http://es.slideshare.net/therobot/que-demonios-es-eso-de-devops-y-porquedebera-interesarme; disponible en agosto/2016

[5] Fuente: http://www.javiergarzas.com/2014/12/devops-en-10-min.html; disponible en agosto/2016

[6] Fuente: https://www.newcontext.com/devops-needs-security/; disponible en agosto/2016

[7] Fuente: http://itrevolution.com/the-three-ways-principles-underpinning-devops/; disponible en agosto/2016

[8] Fuente: http://www.drdobbs.com/architecture-and-design/getting-devops-right-the-lay-of-the-land/240062639; disponible en agosto/2016

[9] Fuente: http://www.itproguy.com/devops-practices/; disponible en agosto/2016

[10] Fuente: https://www.youtube.com/watch?v=_I94-tJlovg; disponible en agosto/2016

[11] Fuente: https://www.paradigmadigital.com/techbiz/que-es-devops-y-sobre-todo-que-no-es-devops/; disponible en agosto/2016

[12] Fuente: http://blog.itlinux.cl/blog/2013/10/23/que-es-devops/; disponible en agosto/2016