¿Es difícil captar el punto principal cuando se habla de DevOps? Hemos recopilado para usted analogías vívidas, formulaciones sorprendentes y consejos de expertos que ayudarán incluso a los no especialistas a ir al grano. Al final, el bono es el DevOps de los propios empleados de Red Hat.
El término DevOps se originó hace 10 años y pasó de ser un hashtag de Twitter a un poderoso movimiento cultural en el mundo de TI, una verdadera filosofía que alienta a los desarrolladores a hacer las cosas más rápido, experimentar e iterar hacia adelante. DevOps se ha vuelto indisolublemente ligado al concepto de transformación digital. Pero como suele ocurrir con la terminología de TI, en los últimos diez años DevOps ha adquirido muchas definiciones, interpretaciones y conceptos erróneos sobre sí mismo.
Por lo tanto, a menudo se pueden escuchar preguntas sobre DevOps como, ¿es lo mismo que ágil? ¿O se trata de alguna metodología especial? ¿O es simplemente otro sinónimo de la palabra “colaboración”?
DevOps incluye muchos conceptos diferentes (entrega continua, integración continua, automatización, etc.), por lo que resumir lo que es importante puede ser un desafío, especialmente cuando te apasiona el tema. Sin embargo, esta habilidad es muy útil, no importa si estás tratando de transmitir tus ideas a tus superiores o simplemente contándole a alguien de tu familia o amigos sobre tu trabajo. Por lo tanto, dejemos de lado los matices terminológicos de DevOps por ahora y centrémonos en el panorama general.
Qué es DevOps: 6 definiciones y analogías
Pedimos a los expertos que explicaran la esencia de DevOps de la manera más simple y breve posible para que su valor quede claro para los lectores con cualquier nivel de conocimiento técnico. Basándonos en los resultados de estas conversaciones, hemos seleccionado las analogías y formulaciones más llamativas que le ayudarán a construir su historia sobre DevOps.
1. DevOps es un movimiento cultural
"DevOps es un movimiento cultural en el que ambas partes (desarrolladores de software y especialistas en operaciones de sistemas de TI) reconocen que el software no aporta beneficios reales hasta que alguien comienza a usarlo: clientes, clientes, empleados, no es el punto", dice Eveline Oehrlich, investigadora senior. Analista del Instituto DevOps. "Por lo tanto, ambas partes garantizan conjuntamente una entrega de software rápida y de alta calidad".
2. DevOps trata de empoderar a los desarrolladores.
"DevOps permite a los desarrolladores poseer aplicaciones, ejecutarlas y gestionar la entrega de principio a fin".
"Normalmente se habla de DevOps como una forma de acelerar la entrega de aplicaciones a producción mediante la creación e implementación de procesos automatizados", dice Jai Schniepp, director de plataformas DevOps de la compañía de seguros Liberty Mutual. "Pero para mí es algo mucho más fundamental". DevOps permite a los desarrolladores poseer aplicaciones o piezas de software específicas, ejecutarlas y gestionar su entrega de principio a fin. DevOps elimina la confusión de responsabilidades y guía a todos los involucrados en la creación de una infraestructura automatizada impulsada por los desarrolladores”.
3. DevOps se trata de colaboración en la creación y entrega de aplicaciones.
"En pocas palabras, DevOps es un enfoque para la producción y entrega de software en el que todos trabajan juntos", dice Gur Staf, presidente y director de automatización de negocios digitales de BMC.
4. DevOps es un canal
"El montaje del transportador sólo es posible si todas las piezas encajan entre sí".
"Yo compararía DevOps con una línea de montaje de automóviles", continúa Gur Staff. – La idea es diseñar y fabricar todas las piezas con antelación para luego poder montarlas sin ajustes individuales. El montaje del transportador sólo es posible si todas las piezas encajan. Quienes diseñan y construyen un motor deben considerar cómo montarlo en la carrocería o en el bastidor. Quienes hacen los frenos deben pensar en las ruedas, etc. Lo mismo debería ocurrir con el software.
Un desarrollador que crea una lógica de negocios o una interfaz de usuario debe pensar en la base de datos que almacena la información del cliente, las medidas de seguridad para proteger los datos del usuario y cómo funcionará todo esto cuando el servicio comience a atender a una audiencia de usuarios grande, tal vez incluso multimillonaria. ".
“Lograr que las personas colaboren y piensen en las partes del trabajo que hacen otros, en lugar de centrarse únicamente en sus propias tareas, es el mayor obstáculo a superar. Si puedes hacer esto, tienes una excelente oportunidad de lograr una transformación digital”, añade Gur Staff.
5. DevOps es la combinación adecuada de personas, procesos y automatización
Jayne Groll, directora ejecutiva del DevOps Institute, ofreció una gran analogía para explicar DevOps. En sus palabras, “DevOps es como una receta con tres categorías principales de ingredientes: personas, procesos y automatización. La mayoría de estos ingredientes se pueden tomar de otras áreas y fuentes: Lean, Agile, SRE, CI/CD, ITIL, liderazgo, cultura, herramientas. El secreto de DevOps, como cualquier buena receta, es cómo obtener las proporciones y combinaciones adecuadas de estos ingredientes para aumentar la velocidad y la eficiencia de la creación y lanzamiento de aplicaciones”.
6. DevOps es cuando los programadores trabajan como un equipo de Fórmula 1
“La carrera no se planifica de principio a fin, sino al contrario, de fin a principio”.
"Cuando hablo de qué esperar de una iniciativa DevOps, pienso en un equipo de carreras de NASCAR o Fórmula 1 como ejemplo", dice Chris Short, gerente senior de marketing de plataforma en la nube de Red Hat y editor del boletín informativo DevOps. – El líder de dicho equipo tiene un objetivo: ocupar el lugar más alto posible al final de la carrera, teniendo en cuenta los recursos disponibles para el equipo y los desafíos que le sobrevinieron. En este caso, la carrera no se planifica de principio a fin, sino al contrario, de fin a inicio. Primero, se establece un objetivo ambicioso y luego se determinan las formas de lograrlo. Luego se dividen en subtareas y se delegan a los miembros del equipo”.
“El equipo pasa toda la semana previa a la carrera perfeccionando la parada en boxes. Hace entrenamiento de fuerza y cardio para mantenerse en forma para un día de carrera agotador. Prácticas trabajando juntos para solucionar cualquier problema que pueda surgir durante la carrera. Asimismo, el equipo de desarrollo debe entrenar la habilidad de lanzar nuevas versiones con frecuencia. Si tiene esas habilidades y un sistema de seguridad que funciona bien, el lanzamiento de nuevas versiones a producción también ocurre con mayor frecuencia. En esta visión del mundo, una mayor velocidad significa una mayor seguridad”, afirma Short.
“No se trata de hacer ‘lo correcto’”, añade Short, “sino de eliminar tantas cosas como sea posible que se interpongan en el camino hacia el resultado deseado. Colabora y adáptate en función de los comentarios que recibas en tiempo real. Esté preparado para anomalías y trabaje para mejorar la calidad para minimizar su impacto en el progreso hacia su objetivo. Esto es lo que nos espera en el mundo de DevOps”.
Cómo escalar DevOps: 10 consejos de expertos
Es sólo que DevOps y DevOps masivo son cosas completamente diferentes. Te contamos cómo superar barreras en el camino del primero al segundo.
Para muchas organizaciones, el viaje hacia DevOps comienza de manera fácil y placentera. Se crean pequeños equipos apasionados, los viejos procesos se reemplazan por otros nuevos y los primeros éxitos no se hacen esperar.
Por desgracia, esto es sólo una falsa ostentación, una ilusión de progreso, dice Ben Grinnell, director general y jefe de digital de la consultora North Highland. Los primeros logros son ciertamente alentadores, pero no ayudan a lograr el objetivo final de la adopción generalizada de DevOps en toda la organización.
Es fácil ver que el resultado es una cultura de división entre “nosotros” y “ellos”.
"A menudo, las organizaciones lanzan estos proyectos pioneros pensando que allanarán el camino para DevOps convencional, sin considerar si otros podrán o estarán dispuestos a seguir ese camino", explica Ben Grinnell. – Los equipos para implementar este tipo de proyectos generalmente se reclutan entre “varegos” seguros de sí mismos que ya han hecho algo similar en otros lugares, pero que son nuevos en su organización. Al mismo tiempo, se les anima a romper y destruir las normas que siguen siendo vinculantes para todos los demás. Es fácil ver que el resultado es una cultura de “nosotros” y “ellos” que inhibe la transferencia de conocimientos y habilidades”.
“Y este problema cultural es sólo una de las razones por las que DevOps es difícil de escalar. Los equipos de DevOps se enfrentan a mayores desafíos técnicos que son típicos de las empresas de rápido crecimiento que priorizan la TI”, dijo Steve Newman, fundador y presidente de Scalyr.
“En el mundo moderno, los servicios cambian tan pronto como surge la necesidad. Es fantástico implementar e implementar nuevas funciones constantemente, pero coordinar este proceso y eliminar los problemas que surgen es un verdadero dolor de cabeza, añade Steve Newman. – En organizaciones de muy rápido crecimiento, los ingenieros de equipos multifuncionales luchan por mantener la visibilidad del cambio y los efectos en cascada que crea en el nivel de dependencia. Además, los ingenieros no están contentos cuando se les priva de esta oportunidad y, como resultado, les resulta más difícil comprender la esencia de los problemas que surgen”.
¿Cómo superar estos desafíos descritos anteriormente y avanzar hacia la adopción masiva de DevOps en una organización grande? Los expertos instan a tener paciencia, incluso si su objetivo final es acelerar el ciclo de desarrollo de software y los procesos comerciales.
1. Recuerde que el cambio cultural lleva tiempo.
Jayne Groll, directora ejecutiva, Instituto DevOps: “En mi opinión, la expansión de DevOps debería ser tan incremental e iterativa como el desarrollo ágil (y tocar igualmente la cultura). Agile y DevOps hacen hincapié en los equipos pequeños. Pero a medida que estos equipos crecen en número e integración, terminamos con más personas adoptando nuevas formas de trabajar y, como resultado, hay una transformación cultural masiva”.
2. Dedique suficiente tiempo a planificar y elegir una plataforma
Eran Kinsbruner, evangelista técnico principal de Perfecto: “Para que la escalabilidad funcione, los equipos de DevOps primero deben aprender a combinar procesos, herramientas y habilidades tradicionales, y luego, lentamente, nutrir y estabilizar cada fase individual de DevOps. Todo comienza con una planificación cuidadosa de las historias de los usuarios y los flujos de valor, seguida de la escritura del software y el control de versiones mediante el desarrollo basado en troncales u otros enfoques más adecuados para bifurcar y fusionar código”.
“Luego viene la etapa de integración y prueba, donde ya se requiere una plataforma escalable para la automatización. Aquí es donde es importante que los equipos de DevOps elijan la plataforma adecuada que se adapte a su nivel de habilidad y a los objetivos finales del proyecto.
La siguiente fase es la implementación en producción y esto debe automatizarse completamente mediante contenedores y herramientas de orquestación. Es importante tener entornos virtualizados en todas las etapas de DevOps (simulador de producción, entorno de control de calidad y entorno de producción real) y utilizar siempre solo los datos más recientes en las pruebas para obtener conclusiones relevantes. Los análisis deben ser inteligentes y capaces de procesar big data con retroalimentación rápida y procesable”.
3. Saca la culpa de la responsabilidad.
Gordon Haff, evangelista de RedHat: “Crear un sistema y una atmósfera que permita y fomente la experimentación permite lo que se conoce como fracasos exitosos en el desarrollo ágil de software. Esto no significa que nadie más sea responsable de los fallos. De hecho, identificar quién es el responsable se vuelve aún más fácil, ya que “ser responsable” ya no significa “provocar un accidente”. Es decir, la esencia de la responsabilidad cambia cualitativamente. Cuatro factores se vuelven críticos: el alcance de la disrupción, los enfoques, los procesos de producción y los incentivos”. (Puede leer más sobre estos factores en el artículo de Gordon Huff “Lecciones de DevOps: 4 aspectos de experimentos saludables”).
4. Despeja el camino a seguir
Ben Grinnell, director general y jefe de digital de la consultora North Highland: “Para lograr escala, recomiendo lanzar un programa de “limpieza de caminos” junto con proyectos pioneros. El objetivo de este programa es limpiar la basura que dejan los pioneros de DevOps, como reglas obsoletas y cosas así, para que el camino a seguir siga estando claro”.
“Brinde a las personas apoyo e impulso organizacional a través de una comunicación que vaya mucho más allá del grupo pionero al celebrar ampliamente los éxitos de las nuevas formas de trabajar. Entrene a las personas que están involucradas en la próxima ola de proyectos DevOps y que están nerviosas por usar DevOps por primera vez. Y recuerda que estas personas son muy diferentes a los pioneros”.
5. democratizar las herramientas
Steve Newman, fundador y presidente de Scalyr: “Las herramientas no deben ocultarse a la gente y deben ser relativamente fáciles de aprender para cualquiera que esté dispuesto a dedicar tiempo. Si la capacidad de consultar registros está restringida a tres personas "certificadas" para utilizar una herramienta, siempre tendrá un máximo de tres personas disponibles para manejar el problema, incluso si tiene un entorno informático muy grande. En otras palabras, aquí hay un cuello de botella que puede tener consecuencias (comerciales) graves”.
6. Crear condiciones ideales para el trabajo en equipo
Tom Clark, director de Plataforma Común de ITV: “Puedes hacer cualquier cosa, pero no todo a la vez. Por lo tanto, establezca grandes objetivos, comience con poco y avance en iteraciones rápidas. Con el tiempo, desarrollará una reputación de hacer las cosas, por lo que otros también querrán utilizar sus métodos. Y no se preocupe por formar un equipo altamente eficaz. En lugar de eso, proporcione a las personas condiciones de trabajo ideales y la eficiencia se logrará”.
7. No te olvides de la Ley de Conway y los tableros Kanban
Logan Daigle, director de entrega de software y estrategia de DevOps en CollabNetVersionOne: “Es importante comprender las consecuencias de la Ley de Conway. En mi vaga paráfrasis, esta ley establece que los productos que creamos y los procesos que utilizamos para hacerlo, incluido DevOps, resultan estar estructurados de la misma manera que nuestra organización”.
“Si hay muchos silos en una organización y el control cambia de manos muchas veces al planificar, crear y lanzar software, el efecto de escalamiento será nulo o de corta duración. Si una organización crea equipos multifuncionales en torno a productos financiados con un enfoque de mercado, las posibilidades de éxito aumentan dramáticamente”.
“Otro aspecto importante del escalado es mostrar todo el trabajo en progreso (WIP, workinprogress) en tableros Kanban. Cuando una organización tiene un lugar donde la gente puede ver estas cosas, se fomenta enormemente la colaboración, lo que tiene un impacto positivo en el escalamiento”.
8. Busca viejas cicatrices
Manuel Pais, consultor DevOps y coautor de Team Topologies: “Llevar las prácticas de DevOps más allá de Dev and Ops e intentar aplicarlas a otras funciones no es un enfoque óptimo. Sin duda, esto tendrá cierto impacto (por ejemplo, al automatizar el control manual), pero se puede lograr mucho más si comenzamos por comprender los procesos de entrega y retroalimentación”.
“Si hay viejas cicatrices en el sistema de TI de una organización (procedimientos y mecanismos de gestión que se implementaron como resultado de incidentes pasados, pero que han perdido su relevancia (debido a cambios en productos, tecnologías o procesos), entonces ciertamente deben eliminarse). o suavizar, en lugar de automatizar procesos ineficientes o innecesarios”.
9. No generes opciones de DevOps
Anthony Edwards, director de operaciones de Berenjena: “DevOps es un término muy vago, por lo que cada equipo termina con su propia versión de DevOps. Y no hay nada peor cuando una organización de repente tiene 20 variedades de DevOps que no se llevan muy bien juntas. Es imposible que cada uno de los tres equipos de desarrollo tenga su propia interfaz especial entre el desarrollo y la gestión de productos. Los productos tampoco deberían tener sus propias expectativas únicas para manejar la retroalimentación cuando se transfieren a un simulador de producción. De lo contrario, nunca podrás escalar DevOps”.
10. Predicar el valor empresarial de DevOps
Steve Newman, fundador y presidente de Scalyr: “Trabajar para reconocer el valor de DevOps. Infórmate y siéntete libre de hablar sobre los beneficios de lo que haces. DevOps ahorra tiempo y dinero de manera increíble (piense: menos tiempo de inactividad, tiempo medio de recuperación más corto), y los equipos de DevOps deben enfatizar (y predicar) incansablemente la importancia de estas iniciativas para el éxito empresarial. De esta manera se puede ampliar el círculo de seguidores y aumentar la influencia de DevOps en la organización”.
BONUS
En Nuestro propio DevOps llegará el 13 de septiembre; sí, Red Hat, como fabricante de software, tiene sus propios equipos y prácticas de DevOps.
Nuestro ingeniero Mark Birger, que desarrolla servicios de automatización interna para otros grupos de la organización, contará su propia historia en ruso puro: cómo el equipo de Red Hat DevOps migró aplicaciones de los entornos virtuales Hat Virtualization administrados por Ansible a un formato de contenedor completo en la plataforma OpenShift.
Pero eso no es todo:
Una vez que las organizaciones hayan trasladado cargas de trabajo a contenedores, es posible que los métodos tradicionales de monitoreo de aplicaciones no funcionen. En la segunda charla explicaremos nuestra motivación para cambiar la forma en que registramos y mostraremos la continuación del camino que nos llevó a los métodos modernos de registro y monitoreo.
Fuente: habr.com