Que demonios es eso de Devops (y porquedebería interesarme)
•
28 gostaram•13,771 visualizações
Charla del mes de febrero del grupo madrid-devops.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Semelhante a Que demonios es eso de Devops (y porquedebería interesarme)
Semelhante a Que demonios es eso de Devops (y porquedebería interesarme) (20)
Último
Último (20)
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.
- 3. La encuesta
- 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. El equipo de desarrollo quiere poner un nuevo site en producción. Developer Sysadmin
- 8. Refleja (a mano) los cambios en la configuración necesarios.
- 9. Instala las librerias necesarias (con el sistema de paquetes en el mejor caso).
- 10. Realiza una carga de datos en la BBDD.
- 11. Etc.
- 12. Por supuesto. Durante todo ese proceso algo falla y hablamos con el equipo de desarrollo para ver como lo solucionamos.
- 13. ¿ Y que es lo que nos responde el desarrollador ?
- 14. En mi máquina funciona.
- 16. Un desarrollador nos pide que instalemos el paquete wadus3-dev que no esta en la distro que usamos. Otro ejemplo
- 17. ¿Cual es nuestra respuesta? Otro ejemplo
- 19. Both development and operations 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. El concepto.
- 22. Tienen un conjunto de herramientas optimizado para desarrollar rápidamente.
- 23. Tienen un sistema operativo optimizado para el uso de escritorio.
- 24. Ejecutan el código localmente 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 doing it wrong!
- 28. We are doing it 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 doing it 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 ¿En que consiste?
- 32. Definir un conjunto nuevo de procedimientos para operaciones.
- 33. Utilizar un conjunto de herramientas que de soporte a los dos puntos anteriores.
- 34. Establecer mecanismos de comunicación efectivos entre todas las partes implicadas en la puesta en producción de un producto.
- 37. Procedimientos Tenemos que modificar los procedimientos actuales. Una vez más, nuestro objetivo es evitar situaciones como esta:
- 38. Procedimientos
- 40. La configuración es código, separado del codigo de la aplicación.
- 41. Herramientas consistentes entre los equipos de operaciones y desarrollo.
- 43. Automatización de los builds y las releases.
- 44. Automatización de la infraestructura y el provisionamiento.
- 45. Auditoría de los cambios en toda la plataforma.
- 47. Gestion del ciclo de vida de los SO. Planificación de stacks.
- 50. Deployment.
- 51. Orquestación.
- 54. Servicios de nombres de hosts.
- 56. Inventario.
- 57. Monitorización.
- 58. Informes.
- 59. Gestión de la configuración .
- 60. Comunicación
- 61. Respeto No ocultes hechos. No digas NO (sin dar ninguna explicación). No estereotipes a tus compañeros de trabajo.
- 62. Confianza Operaciones necesita confiar en desarrollo para implicarlos en futuras discusiones sobre su aplicación. Desarrollo necesita confiar en operaciones para discutir los cambios de infraestructura Todo el mundo necesita confiar en que el resto esta haciendo lo mejor para el negocio.
- 63. Actitud positiva ante los fallos Asumir que el fallo va a suceder. Responsabilidad y empatía. Para los devs: Cuando algo de tu aplicación se rompe despiertas a un sysadmin. Para los ops: Dar feedback constructivo de los problemas.
- 66. ¿Que tiene que Devops ver con el negocio?
- 67. ¿Que tiene que ver con el negocio? “ The whole point of DevOps is to enable your business to react to market forces as quickly, efficiently, and reliably as possible. Without the business, there is no other reason for us to be talking about DevOps problems, much less spending any time solving them.”
- 68. ¿Que tiene que ver con el negocio? “ For the business, DevOps contributes directly to enabling two powerful and strategic business qualities, "business agility" and "IT alignment". These may not be terms that the troops in the IT trenches worry about on a daily basis, but they should definitely get the attention of the executives who approve the budgets and sign the checks. ”
- 70. Buscamos un sysadmin junior http://blog.aspgems.com/2011/01/27/buscamos-un-sysadmin-junior/ [email_address] One more thing...
- 71. ¿Preguntas?
Notas do Editor
- 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.
- ¿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.
- Awareness = entendimiento ,conciencia, comprensión, realización Yo me di cuenta de esto en mi primer trabajo como sysadmin.
- Preguntar: ¿que necesitamos para poner el proyecto en producción?
- Hemos entendido cual es la problemática.
- 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..
- Preguntar ¿Como aportan valor los desarrolladores a la empresa? ¿Y los sysadmins?
- 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.
- Necesitamos un cambio de mentalidad.
- 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.
- 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.
- 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