Subido porJacobo García López de Araujo
Que demonios es eso de Devops (y porquedebería interesarme)
El documento explica qué es DevOps. Señala que tradicionalmente el desarrollo y operaciones han estado desconectados, lo que causa problemas. DevOps busca implementar métodos ágiles en operaciones, automatizar procesos, y mejorar la comunicación entre equipos para habilitar cambios rápidos que satisfagan las necesidades del negocio de forma segura y estable.
Más contenido relacionado
Que demonios es eso de Devops (y porquedebería interesarme)
- 1. ¿Que demonios es eso de Devops? (y porqué debería estar interesado) Jacobo García López de Araujo.
- 2.
- 3.
- 4. ¿Que demonios es eso de Devops? (y porqué debería estar interesado)
- 5. ¿Que demonios es eso de Devops? (y porqué debería estar interesado) DevOps is a response to the growing awareness that there is a disconnect between what is traditionally considered development activity and what is traditionally considered operations activity.
- 6. Un ejemplo. Elequipo de desarrollo quiere poner un nuevo site en producción. Developer Sysadmin
- 7. Para poner elproyecto en producción el equipo de sistemas realiza las siguientes operaciones: Prepara el script de deployment (si hay script).
- 8. Refleja (a mano)los cambios en la configuración necesarios.
- 9. Instala las libreriasnecesarias (con el sistema de paquetes en el mejor caso).
- 10. Realiza una cargade datos en la BBDD.
- 11.
- 12. Por supuesto. Durantetodo ese proceso algo falla y hablamos con el equipo de desarrollo para ver como lo solucionamos.
- 13. ¿ Y quees lo que nos responde el desarrollador ?
- 14. En mi máquinafunciona.
- 15.
- 16. Un desarrollador nospide que instalemos el paquete wadus3-dev que no esta en la distro que usamos. Otro ejemplo
- 17. ¿Cual es nuestrarespuesta? Otro ejemplo
- 18.
- 19. Both development andoperations fundamentally see the world, and their respective roles in it, differently. Each believe that they are doing the right thing for the business... and in isolation they are both correct! So... What Happens?
- 20.
- 21. El concepto. Situaciónactual. Los (malditos) desarrolladores: No tienen conocimiento sobre el impacto de su código en los sistemas.
- 22. Tienen un conjuntode herramientas optimizado para desarrollar rápidamente.
- 23. Tienen un sistemaoperativo optimizado para el uso de escritorio.
- 24. Ejecutan el códigolocalmente en una sola máquina. Incluso cuando hay entornos de testing/staging/integración.
- 25. Una diferencia clave.Los desarrolladores aportan valor al negocio implementando requisitos funcionales. Sistemas aporta valor al negocio implementando seguridad, estabilidad y rendimiento. Ambas metas entran en conflicto ya que poner nuevas funcionalidades en producción implica asumir riesgos.
- 26. Una diferencia clave.Sistemas intenta minimizar riesgos intentando evitar el cambio o ralentizandolo. ¿ Al final qué sucede? Todo el proceso de puesta en producción se ralentiza y se aumenta el riesgo ya que acabamos poniendo en producción grupos de cambios simultáneamente.
- 27. We are doingit wrong!
- 28. We are doingit wrong! El objetivo de operaciones no es (únicamente) mantener un sistema seguro, estable y rápido. El objetivo de operaciones es habilitar los objetivos de negocio. El negocio requiere cambio. Y el cambio es la raiz de la inestabilidad.
- 29. We are doingit wrong! Nuestro objetivo es favorecer el cambio según las necesidades del negocio lo requieran, mientras minimizamos los riesgos que implican ese cambio.
- 30. El concepto ¿Enque consiste?
- 31. El Concepto ¿enque consiste? Implementar Agile en el departamento de sistemas.
- 32. Definir un conjuntonuevo de procedimientos para operaciones.
- 33. Utilizar un conjuntode herramientas que de soporte a los dos puntos anteriores.
- 34. Establecer mecanismos decomunicación efectivos entre todas las partes implicadas en la puesta en producción de un producto.
- 35. Agile en SistemasScrum
- 36.
- 37. Procedimientos Tenemos quemodificar los procedimientos actuales. Una vez más, nuestro objetivo es evitar situaciones como esta:
- 38.
- 39. Procedimientos Implicación enlas primeras fases del de desarrollo.
- 40. La configuración escódigo, separado del codigo de la aplicación.
- 41. Herramientas consistentes entrelos equipos de operaciones y desarrollo.
- 42.
Notas del editor
- #3 La transparencias son bastante informales y pretenden mostrar mi concepción de devops, basado en mi experiencia + conocimientos. Las transpas son un poco caóticas, parte de la culpa la tiene openoffice y mi desconocimiento sobre software de presentaciones. A última hora se me ha ocurrido llenar la charla de fotos absurdas, la idea es hacer la charla más amena. Algunas de las cosas que voy contar llevan haciendose años, otras son nuevas. Todas son de sentido comun. Las transpas las colgaré mañana por la mañana en slideshare, se anunciará por la lista y twitter. Operaciones y sistemas lo uso intercambiablemente.
- #4 ¿Quien ha hecho la encuesta? Vamos a verla (preguntar cual es la respuesta correcta) Os felicito! La idea de usar la encuesta básicamente consistía en llamar la atención un poco, bueno, tambien la usaré algo en la charla.
- #6 Awareness = entendimiento ,conciencia, comprensión, realización Yo me di cuenta de esto en mi primer trabajo como sysadmin.
- #7 Preguntar: ¿que necesitamos para poner el proyecto en producción?
- #16 Hemos entendido cual es la problemática.
- #18 Comparado con: Distinto SO orientado a sistemas No siempre las mismas, herramientas que estan orientadas a seguridad, estabilidad, rendimiento. Ejecutamos en varias máquinas, muchas veces siguiendo arquitecturas de distintas capas, frontales, caché, etc..
- #19 Preguntar ¿Como aportan valor los desarrolladores a la empresa? ¿Y los sysadmins?
- #20 El objetivo de operaciones no es mantener un sistema seguro, estable y rápido. El objetivo de operaciones es habilitar el negocio. El negocio requiere cambio. Y el cambio es la raiz de la inestabilidad. Hasta ahora la visión desde ops es retrasar o desmotivar el cambio. Necesitamos cambiar esta mentalidad, necesitamos permitir el cambio según las necesidades lo requieran, mientras minimizamos el riesgo de cambio.
- #23 Necesitamos un cambio de mentalidad.
- #26 Preguntar: ¿Conoceis scrum y kanban? Scrum va de separar grupos y el proyecto en unidades mas pequeñas. Separar el tiempo de desarrollo en iteraciones más pequeñas e integrar los resultados regularmente para ir viendo el avance. Kanban tambien separa el trabajo en historiasy el progreso de cada historia en fases (todo, ongoing, done...). Se utiliza una herramienta sencilla para visualizar y medir el avance. Asimismo se limita el número de historias que puede haber al mismo tiempo. Scrum tiene más reglas a seguir, tiene iteraciones cerradas vs abiertas de Kanban.
- #29 Herramientas consistentes: utilizar entornos similares Administración abstracta: no pensar en maquinas y ficheros de configuración sino en conjuntos de servicios a proveer, pensar en “features”. Cuando digo toda la plataforma hablo no solo de los repositorios de las aplicaciones y la configuración, hablo tambien del deployment, scriptación de los cambios en la base de datos y la gestión de infraestructura.
- #31 Todos conocemos la serie, ¿no? Esta serie se desarrolla enteramente basandose en los problemas de comunicación entre los usuarios normales y los técnicos. ¿No nos ha pasado lo mismo con los desarrolladores u otros usuarios técnicos? Respeto Confianza Actitud saludable hacia el fallo. Evitar la culpa