¿Es difícil entender el punto cuando hablamos de DevOps? Hemos reunido para usted analogías vívidas, formulaciones de percusión y consejos de expertos que ayudarán incluso a los no especialistas a llegar al punto. Al final, el bono es el propio DevOps de Red Hat.
El término DevOps surgió hace 10 años y pasó de ser un hashtag en Twitter a un poderoso movimiento cultural en el mundo de TI, una verdadera filosofía que alienta a los desarrolladores a lograr resultados más rápido, experimentar y avanzar utilizando el método de iteración. DevOps se ha vinculado inextricablemente al concepto de transformación digital. Pero como suele ser el caso con la terminología de TI, más de una década, DevOps ha logrado adquirir muchas definiciones, interpretaciones y conceptos erróneos.
Por lo tanto, sobre DevOps a menudo puede escuchar preguntas como, ¿es lo mismo que ágil? ¿O es algún tipo de 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 aislar lo principal puede ser difícil, especialmente cuando eres parcial en el tema. Sin embargo, esta habilidad es muy útil, no importa si estás tratando de transmitir tus ideas a tus superiores o simplemente les estás contando a tus familiares o amigos sobre tu trabajo. Por lo tanto, por ahora, deje de lado los matices terminológicos de DevOps y concéntrese 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 el lector con cualquier nivel de capacitación técnica. Con base en los resultados de estas conversaciones, seleccionamos las analogías más sorprendentes y las formulaciones de percusión que lo 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 brinda beneficios reales hasta que alguien comienza a usarlo: clientes, clientes, empleados, no es el punto, dice Eveline Oehrlich, analista senior del Instituto DevOps. "Por lo tanto, ambas partes juntas proporcionan una entrega de software rápida y de alta calidad".
2. DevOps es lo que empodera a los desarrolladores
"DevOps capacita a los desarrolladores con la propiedad de las aplicaciones, su lanzamiento y gestión de entrega de principio a fin""Por lo general, hablan de DevOps como una forma de acelerar la entrega de aplicaciones a la producción mediante la creación y aplicación de procesos automatizados", dijo Jai Schniepp, Director de Plataformas DevOps, Liberty Mutual Insurance Company. "Pero para mí es una cosa mucho más fundamental". DevOps otorga a los desarrolladores la autoridad para poseer aplicaciones o ciertas partes del software, lanzarlas y administrar la entrega de principio a fin. DevOps elimina la confusión de responsabilidad y lleva a todos los participantes en el proceso a crear una infraestructura automatizada y dirigida por el desarrollador ".
3. DevOps es una 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 cuando todos trabajan juntos", dijo Gur Staf, Presidente y Jefe de Automatización de Negocios Digitales en BMC.
4. DevOps es una tubería
"El ensamblaje del transportador solo es posible si todas las piezas encajan"."Compararía DevOps con una línea de montaje de automóviles", continúa Gur Staf. - La idea es pre-diseñar y hacer todos los detalles para que luego puedan ser ensamblados sin un ajuste individual. El ensamblaje del transportador solo es posible si todas las piezas encajan entre sí. Aquellos que diseñan y fabrican el motor deben considerar cómo montarlo en el cuerpo o el marco. Los que hacen frenos deben pensar en las ruedas, etc. Debería ser lo mismo con el software.
Un desarrollador que cree una lógica de negocios o una interfaz de usuario debería pensar en una base de datos que almacene información sobre los clientes, sobre las medidas de seguridad para proteger los datos del usuario y cómo funcionará cuando el servicio comience a servir a un gran, posiblemente incluso multimillonario audiencia de usuarios ".
“Hacer que las personas cooperen y piensen en aquellas partes del trabajo que realizan otros, y no se centren únicamente en sus propias tareas; este es el mayor obstáculo que se debe superar. Si tiene éxito, tiene excelentes posibilidades de transformación digital ”, agrega Gur Staf.
5. DevOps es la combinación correcta de personas, procesos y automatización.
Jayne Groll, Directora Ejecutiva del Instituto DevOps, ofreció una gran analogía para explicar DevOps. Según ella, “DevOps es como una receta culinaria en la que hay 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, así como cualquier buena receta, es cómo elegir las proporciones correctas y mezclar estos ingredientes para aumentar la velocidad y la eficacia del trabajo al crear y lanzar aplicaciones ".
6. DevOps: esto es cuando los programadores trabajan como un equipo de Fórmula 1
"La carrera está planeada no de principio a fin, sino de principio a fin"."Hablando de qué esperar de la iniciativa DevOps, citaré al NASCAR o al equipo de carreras de Fórmula 1 como ejemplo", dice Chris Short, gerente general de marketing de plataforma en la nube de Red Hat y editor de la lista de correo de DevOps. - El jefe de dicho equipo tiene un objetivo: tomar el máximo lugar posible de acuerdo con los resultados de la carrera, teniendo en cuenta los recursos disponibles para el equipo y las pruebas que recayeron en su parte. Además, la carrera no está planificada de principio a fin, sino de principio a fin. 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 ".
“Toda la semana antes de la carrera, el equipo afina la parada en boxes. Está involucrado en entrenamiento de potencia y cardio para estar en forma en un agotador día de carrera. Realiza acciones conjuntas para resolver cualquier problema que pueda surgir en la carrera. Del mismo modo, el equipo de desarrollo debe entrenar las habilidades de lanzar nuevas versiones con frecuencia. Con tales habilidades y un sistema de seguridad que funciona bien, el lanzamiento de nuevas versiones en producción también ocurre con mayor frecuencia. Dentro de esta visión del mundo, un aumento en la velocidad significa un aumento en la seguridad ", dice Short.
"El punto no es hacer lo" correcto ", agrega Short," sino eliminar tantas cosas como sea posible que se interpongan en el camino del resultado deseado. Colabore y adáptese en función de los comentarios que reciba en tiempo real. Esté preparado para las anomalías y trabaje para mejorar la calidad para minimizar su impacto en el movimiento hacia la meta. Eso es lo que nos espera en el mundo de DevOps ".
Cómo escalar DevOps: 10 consejos de expertos
Solo DevOps y DevOps masivos son dos cosas completamente diferentes. Le diremos cómo superar las barreras de la primera a la segunda.Para muchas organizaciones, el camino hacia DevOps comienza de manera fácil y agradable. Se crean pequeños equipos apasionados, los viejos procesos se reemplazan por nuevos y los primeros éxitos no se hacen esperar.
Por desgracia, esto es solo un brillo falso, una ilusión de progreso, según Ben Grinnell, director gerente y jefe de tecnología digital de la firma de consultoría North Highland. Las primeras victorias son ciertamente alentadoras, pero no ayudan a lograr el objetivo final, es decir, el uso masivo de DevOps en la organización.
Es fácil ver que, como resultado, se forma una cultura de separación en "nosotros" y "ellos"."A menudo, las organizaciones lanzan proyectos tan pioneros, creyendo que allanarán el camino para DevOps masivos, sin dudarlo, pueden y querrán otros ir por este camino", explica Ben Grinnel. - Los equipos para la implementación de tales proyectos generalmente son reclutados de "Vikingos" 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 los alienta a romper y destruir las reglas que siguen siendo vinculantes para todos los demás. Es fácil ver que, como resultado, se forma una cultura de separación en "nosotros" y "ellos", que impide la transferencia de conocimientos y habilidades ".
“Y este problema cultural es solo una de las razones por las que DevOps es difícil de escalar. Los equipos de DevOps se enfrentan al crecimiento de dificultades puramente técnicas características de las compañías de rápido crecimiento que han confiado en la tecnología de TI ", dijo Steve Newman, fundador y presidente de la junta de Scalyr.
“En el mundo moderno, los servicios cambian tan pronto como surge una necesidad. Continuar implementando e implementando nuevas características es, por supuesto, excelente, pero coordinar este proceso y solucionar problemas es un verdadero dolor de cabeza ”, agrega Steve Newman. - En organizaciones de crecimiento muy rápido, los ingenieros, como parte de equipos multifuncionales, luchan por mantener la capacidad de rastrear los cambios y los efectos en cascada que generan en el nivel de dependencia. Además, los ingenieros no están nada contentos cuando se les priva de esa oportunidad y, como resultado, les resulta más difícil comprender la esencia de los problemas que surgen ".
¿Cómo superar estas dificultades descritas anteriormente y pasar al uso masivo de DevOps en una organización grande? Los expertos lo instan a ser paciente, incluso si su objetivo final es acelerar el ciclo de desarrollo de software y los procesos comerciales.1. Recuerda que el cambio cultural lleva tiempo
Jayne Groll, Directora Ejecutiva del Instituto DevOps: “En mi opinión, la extensión DevOps debe ser tan gradual e iterativa como el desarrollo ágil (y afectar igualmente la cultura). Agile y DevOps se centran en equipos pequeños. Pero a medida que crece el número y la integración de tales equipos, cada vez más personas aplican nuevos métodos de trabajo y, como resultado, surge una transformación cultural a gran escala ".
2. Pase suficiente tiempo planeando y eligiendo una plataforma
Eran Kinsbruner, Líder Evangelista Técnico, Perfecto: “Para escalar al trabajo, los equipos de DevOps primero deben aprender cómo combinar procesos, herramientas y habilidades tradicionales, y luego crecer lentamente cada fase de DevOps individual y estabilizarla. Todo comienza con una planificación cuidadosa de historias de usuarios y flujos de valor (flujo de valor), seguido de la etapa de escribir software y control de versiones utilizando el desarrollo basado en troncales u otros enfoques que son más adecuados para la ramificación y la fusión de código ".
“Luego viene la fase de integración y prueba, donde ya se requiere una plataforma de automatización escalable. Y aquí es importante que los equipos de DevOps elijan la plataforma adecuada que cumpla con su nivel de habilidad y con los objetivos finales del proyecto.
La siguiente fase es la implementación en un entorno de producción, y debe automatizarse completamente utilizando herramientas y contenedores de orquestación. Al mismo tiempo, es importante tener entornos virtualizados en todas las etapas de DevOps (un simulador de entorno de producción, un entorno de control de calidad y, de hecho, un entorno de producción) y utilizar siempre los últimos datos para las pruebas a fin de obtener conclusiones relevantes. La analítica debe ser inteligente y capaz de procesar grandes datos con comentarios rápidos y eficientes ".
3. Deshazte del sabor culpable
Gordon Haff, evangelista de RedHat: “Crear un sistema y una atmósfera que permita y aliente la experimentación nos permite darnos cuenta de las llamadas fallas exitosas en el desarrollo ágil de software. Esto no significa que nadie más sea responsable de las fallas. De hecho, se hace aún más fácil establecer una persona responsable, ya que "ser responsable" ya no significa "convertirse en el culpable del accidente". Es decir, la esencia de la responsabilidad está cambiando cualitativamente. En este caso, cuatro factores se vuelven extremadamente importantes: la magnitud del fracaso, los enfoques, los procesos de producción y los incentivos ". (Para más información sobre estos factores, vea las lecciones DevOps de Gordon Huff: 4 aspectos de los experimentos saludables).
4. Despeja el camino a seguir
Ben Grinnell, Director Gerente y Jefe de Tecnología Digital, North Highland Consulting: “Para ampliar, recomiendo que junto con los proyectos pioneros, hayamos lanzado el programa Clearing Path. El objetivo de este programa es limpiar la basura que queda con los pioneros de DevOps, como las reglas que han perdido relevancia y otras cosas similares, para que el camino a seguir permanezca claro ".
“Brinde apoyo organizacional a las personas y dé impulso a través de una comunicación que va mucho más allá del grupo pionero, celebrando ampliamente el éxito de los nuevos métodos de trabajo. Capacite a las personas que están involucradas en la próxima ola de proyectos DevOps y están nerviosas por usar DevOps por primera vez. Y recuerda que estas personas son muy diferentes de los pioneros ".
5. Hacer herramientas más democráticas
Steve Newman, fundador y presidente de Scalyr: “Las herramientas no deben ocultarse a las personas, y deben ser relativamente fáciles de aprender para cualquiera que esté dispuesto a pasar tiempo en esto. Si la capacidad de solicitar registros se proporciona solo a tres personas que están "certificadas" para trabajar con algún tipo de herramienta, siempre tendrá un máximo de tres personas que pueden resolver el problema correspondiente, incluso si tiene un entorno informático muy grande. En otras palabras, aquí surge un cuello de botella que puede tener graves consecuencias (para los negocios) ”.
6. Crear condiciones ideales para el trabajo en equipo.
Tom Clark, Jefe de Plataforma Común de ITV: “Puedes hacer cualquier cosa, pero no todas a la vez. Por lo tanto, establezca grandes objetivos, comience con poco y avance con iteraciones rápidas. Con el tiempo, ganará una reputación como un equipo que tiene éxito, por lo que otros también querrán usar sus métodos. Y no persigas construir un equipo altamente efectivo. En cambio, proporcione a las personas las condiciones ideales de trabajo y la eficiencia vendrá por sí sola ”.
7. No olvides la ley de Conway y los tableros Kanban
Logan Daigle, Director de Entrega y Estrategia de Software DevOps de CollabNetVersionOne: "Es importante comprender las consecuencias de la ley de Conway. En mi paráfrasis gratuita, esta ley establece que los productos que creamos y los procesos que utilizamos, incluido DevOps, resultan ser los mismos que nuestra organización ".
“Si la organización está muy fragmentada, y al planificar, crear y lanzar software, la administración pasa de una mano a otra muchas veces, el efecto de la escala será cero o de corta duración. Si la organización forma equipos multifuncionales en torno a productos que se financian con una orientación al mercado, entonces las posibilidades de éxito aumentan dramáticamente ”.
“Otro aspecto importante de la escala es mostrar en los tableros kanban todo el trabajo en progreso (WIP, workinprogress). Cuando una organización aparece en un lugar donde las personas pueden ver tales cosas, estimula enormemente la cooperación, lo que tiene un efecto positivo en la escala ”.
8. Busque viejas cicatrices
Manuel Pais, consultor de DevOps y coautor de las topologías de equipo: “Tomar las prácticas de DevOps más allá de Devi Ops y tratar de aplicarlas a otras funciones difícilmente puede llamarse el enfoque óptimo. Sin duda, esto dará un cierto efecto (por ejemplo, debido a la automatización del control manual), pero se puede lograr mucho más si comenzamos con una comprensión de los procesos de entrega y la retroalimentación ”.
"Si hay viejas cicatrices en el sistema de TI de la organización: procedimientos y mecanismos de gestión que se implementaron como resultado de incidentes pasados, pero que perdieron su relevancia (debido a un cambio en productos, tecnologías o procesos), entonces ciertamente deben ser eliminados o suavizados, y no automatizar procesos ineficientes o innecesarios ".
9. No generar opciones de DevOps
Anthony Edwards, director de producción de berenjenas: “DevOps es un término muy vago, por lo que cada equipo tiene su propia versión de DevOps. Y no hay nada peor cuando 20 variedades de DevOps aparecen inmediatamente en la organización, que no se llevan muy bien. Cada uno de los tres equipos de desarrollo no puede tener su propia interfaz especial entre el desarrollo y la gestión de productos. Como es imposible que los productos tengan sus propias expectativas únicas con respecto al procesamiento de la retroalimentación al transferir el entorno de producción al simulador. De lo contrario, nunca podrá escalar DevOps ".
10. Predique el valor de DevOps para empresas
Steve Newman, fundador y presidente de Scalyr: “Trabaja para reconocer el valor de DevOps. Aprenda y siéntase libre de hablar sobre los beneficios de lo que hace. DevOps ahorra increíblemente tiempo y dinero (solo piense: menos tiempo de inactividad, tiempo de recuperación promedio más corto), y los equipos de DevOps deben enfatizar (y predicar) implacablemente la importancia de estas iniciativas para el éxito empresarial. Para que pueda ampliar el círculo de adherentes y fortalecer la influencia de DevOps en la organización ".
BONIFICACIÓN
El 13 de septiembre, nuestros propios DevOps llegarán al Red Hat Forum Rusia ; sí, Red Hat, como fabricante de software, tiene sus propios equipos y prácticas de DevOps.Nuestro ingeniero Mark Birger, que está desarrollando servicios de automatización interna para otros grupos en toda la organización, cuenta su propia historia en ruso puro: cómo el equipo Red Hat DevOps migró las aplicaciones de los entornos administrados por Hat Virtualization por Ansible a un formato de contenedor completo en la plataforma OpenShift.
Pero eso no es todo:Después de que las organizaciones hayan transferido las cargas de trabajo a los contenedores, los métodos tradicionales de monitoreo de aplicaciones pueden no funcionar. En el segundo informe, explicaremos nuestra motivación para cambiar el método de registro y mostraremos la continuación del camino que nos llevó a los métodos modernos de registro y monitoreo.