Subido porErnesto Cardenas Cangahuala
El reto del DevOps agil
La presentación de Gartner Security Conference "Operation Zero Downtime" discutió cómo las organizaciones pueden implementar DevOps para lograr tiempo de inactividad cero mediante la integración continua, el despliegue continuo y la automatización de pruebas. La presentación recomendó recursos como entredevyops.es, itrevolution.com y microsoftvirtualacademy.com para obtener más información sobre cómo adoptar prácticas ágiles de DevOps como entrega continua.
El reto del DevOps agil
- 5. Gartner Security Conferencepresentation "Operation Zero Downtime," D. Scott
- 19.
- 29. http://www.entredevyops.es http://itrevolution.com/devops-blog/ http://www.microsoftvirtualacademy.com Continuous Delivery: The Agile Successor
Notas del editor
- #4 Mencionar el caso Direct Seguros y Ecoembes
- #5 Taken from: http://dev2ops.org/2010/02/what-is-devops/ Development kicks things off by “tossing” a software release “over the wall” to Operations. Operations picks up the release artifacts and begins preparing for their deployment. Operations manually hacks the deployment scripts provided by the developers or creates their own scripts. They also hand edit configuration files to reflect the production environment, which is significantly different than the Development or QA environments. At best they are duplicating work that was already done in previous environments, at worst they are about to introduce or uncover new bugs. Operations then embarks on what they understand to be the currently correct deployment process, which at this point is essentially being performed for the first time due to the script, configuration, process, and environment differences between Development and Operations. Of course, somewhere along the way a problem occurs and the developers are called in to help troubleshoot. Operations claims that Development gave them faulty artifacts. Developers respond by pointing out that it worked just fine in their environments, so it must be the case that Operations did something wrong. Developers are having a difficult time even diagnosing the problem because the configuration, file locations, and procedure used to get into this state is different then what they expect (if security policies even allow them to access the production servers!). Time is running out on the change window and, of course, there isn’t a reliable way to roll the environment back to a previously known good state. So what should have been an eventless deployment ended up being an all-hands-on-deck fire drill where a lot of trial and error finally hacked the production environment into a usable state.
- #8 Notese que a veces conseguir recursos es bien peleado.
- #9 Mencionar el caso de Nielsen cuando algo se colo en una aplicaciòn que nadie sabia que existia
- #10 Dev: ¿De que vale ser “ágil” y entregar código listo para producción cada quincena si el código tiene que esperar semanas o meses para ser desplegado? (ayer me hablaban de que solo tenian permiso para hacer 6 pases al año, pero podria tener sus razones) IT/Ops: “Estas entregas frecuentes están matando a mi equipo e impactando nuestra habilidad para tener un entorno estable!”
- #12 Indicar, que se puede ser agil pero que los IT Pro aun estar totalmente desconectados de lo que pasa aqui….
- #13 Escenario complejo cada vez mas, aplicaciones nuevas y antiguas, tecnologias diversas. Pelea por los recursos…
- #14 Un perfil que sepa programar y de infraestructura… que hable los dos idiomas… En un momento me dijeron que yo era DevOps y asi empezo todo
- #17 Todo el mundo tiene una respuesta para lo que es DevOps pero….
- #18 La palabra clave es sinergia…
- #19 People = Culture Fundamental attributes of successful cultures: Shared mission and incentives: infrastructure as code, apps as services, DevOps/all as teams You need to consider your hardware as a commodity, (don't give your servers names) , servers are like farm animals, it is just harder if you let theids name them Build deep instrumentation into services, push complexity up the stack Rally around agile, shared metrics, CI, service owners on call, etc. Changing the culture: any change takes time, changing culture is no exception and you can't do it alone, exploit compelling events to change culture: downtimes, cloud adoption, devops buzz PROCESS Definition and design, compliance, and continuous improvement PEOPLE Responsibilities, management, skills development, and discipline Products Tools and infrastructure
- #20 La Primera Vía enfatiza el rendimiento del sistema entero, en contra del rendimiento de un silo específico o un departamento concreto – este puede ser un departamento grande (p.e. Desarrollo u Operaciones IT) o uno pequeño como una sola persona (p.e. un desarrollador, administrador de sistemas). La atención se centra en todos aquellos elementos de valor de negocio que están funcionando gracias a la IT. En otras palabras, empieza identificando los requisitos (p.e. por negocio o por IT), implementándose en Desarrollo, y traspasándose hacia el equipo de Operaciones IT, donde se entregan al cliente en forma de servicio. Los beneficios de poner la Primera Vía en práctica incluyen que un defecto conocido nunca será propagado hacia otros centros, nunca se permite crear una optimización local que provoque una degradación global, siempre se busca aumentar el flujo, y siempre se busca adquirir un conocimiento profundo del sistema. La Segunda Vía trata sobre la creación de los ciclos de retroalimentación (feedback) de derecha a izquierda. El objetivo de casi cualquier iniciativa de mejora de proceso es reducir y ampliar los circuitos de feedback para que las correcciones necesarias se puedan hacer continuamente. Los beneficios de la Segunda Vía incluyen comprender y dar respuesta a todos los clientes, internos y externos, acortando y amplificando todos los ciclos de feedback, e integrando todos los conocimientos donde los necesitemos. La Tercera Vía trata sobre crear una cultura que fomente dos cosas: experimentación continua, correr riesgos y aprender del fracaso; y entender que la repetición y la práctica son un prerrequisito para llegar a dominar algo completamente. Necesitamos ambas cosas por igual. La experimentación y correr riesgos son lo que garantiza que podamos seguir empujando para mejorar, incluso si esto significa ir a la parte más profunda de la zona de peligro a la que nunca hayamos llegado. Y necesitamos el dominio de las habilidades que pueden ayudarnos a salir sin peligro de dicha zona cuando hayamos ido demasiado lejos. Los beneficios de la Tercera Vía incluyen encontrar tiempo cada día para mejorar el trabajo diario, creando rituales que premien al equipo por la toma de riesgos, y la introducción de errores en el sistema para incrementar la resistencia de este.