DEVOPS. UNO PARA TODOS Y TODOS PARA UNO
El termino DevOps se popularizo allá en el 2009, en una serie de eventos bautizados «DevOps Days» realizados en Bélgica. Se trata de un movimiento de IT cuyo objetivo es eliminar o reducir las barreras existentes entre los equipos de Desarrollo, QA y Operaciones. Al final se puede resumir como el nexo entre los distintos roles que forman parte del equipo de proyecto.
Hoy en día se está extendiendo el uso de metodologías ágiles y sus prácticas en las compañías, lo cual celebro enormemente. Estas prácticas se están enfocando en gestión de requisitos, desarrollo, testing, etc; pero se está dejando de lado llevar estas prácticas al mundo de las operaciones, es decir, se puede simplificar llevando la agilidad a los equipos de operaciones.
De nada sirve ser ágil en el desarrollo y hacer entrega de valor al negocio cada 3 o 4 semanas (sprint) para perder otro tanto en poner dicha funcionalidad en producción.
Es por esto que las compañías deben evolucionar sus prácticas de ALM (Application Lifecycle Management) para integrar en el ciclo a Negocio, Desarrollo, QA y Operaciones, y de esta forma mejorar la velocidad de la última milla y poder entregar valor con calidad de forma ágil.
Prácticas de Enterprise DevOps.
Las prácticas que vamos a describir y lo mencionado anteriormente no deben asustarnos a la hora de llevarlo a la práctica; esto puede y, en mi opinión debe hacerse, de forma gradual. Así, vamos a buscar por dónde empezar y manos a la obra:
- Operations readiness enablement. Los equipos de operaciones deben estar involucrados en el proyecto desde el principio para ayudar en la definición de los requisitos de operaciones y sus criterios de aceptación. Debemos tener especial cuidado con la gente de Negocio para que no releguen los requisitos de Operaciones a posiciones menos priorizadas del Product Backlog, esto provocará que los problemas afloren en producción con el coste que conlleva solucionarlos.
- Developing operations ready software. Durante la fase de desarrollo, los equipos de desarrollo y QA deben estar centrados en implementar los requisitos y satisfacer los criterios de aceptación tanto funcionales como no funcionales. Para automatizar los precesos de Build, Test, Deploy necesitaremos poder contar con entornos, en algunos de los casos, que se asemejen lo máximo a producción, también contar con entornos de test y, para todo esto deberíamos contar con la ayuda de Operaciones para que nos ayuden a montar dichos entornos.
- Continuos integrations and deployments. El uso de integración continua nos permitirá automatizar los procesos de Build, Test, Deploy y esto nos ayudará a acortar enormemente los ciclos de entrega. Estos procesos pueden llegar a ser muy complejos y más si hablamos de entornos en producción, en los cuales normalmente la gente de Operaciones no nos dejan como se diría vulgarmente “toquetear”. Para poder automatizar esto podemos hacer uso de una de las herramientas de la suite de System Center llamada Orchestrator, una herramienta orientada a la automatización de procesos IT.
- Integration incident management to reduce MTTR. Una vez que estamos en producción, uno de los temas que más nos debe preocupar es contar con herramientas que nos ayuden a monitorizar las aplicaciones, diagnosticar los errores que se produzcan y poder hacer llegar dicha información al equipo de desarrollo para su resolución, si procede. Todo esto nos ayudará a reducir enormemente el tiempo de resolución de los errores en producción (MTTR – Main Time To Resolution). Debe ser objetivo de las organizaciones invertir en la implantación de herramientas que nos permitan cubrir las necesidades antes expuestas, para esto Microsoft pone a nuestra disposición Visual Studio + SCOM (System Center Operation Manager).
Herramientas. ¡¡¡Visual Studio + SCOM, al rescate!!!
Para aquellos que no estáis familiarizados con SCOM, comentar que se trata de una de las herramientas que trae la suite de System Center. Resumiéndolo de forma breve, SCOM nos permitirá monitorizar el estado y la salud de los servidores, servicios, estaciones de trabajo y por supuesto nuestras aplicaciones.
Además si unimos ésta con Visual Studio nos permite tener dos magníficas herramientas a nuestro servicio, permitiendo que la información fluya entre los equipos de desarrollo y operaciones de forma muy sencilla y a tan solo un click de ratón, no quiero entrar en detalles pero solo comentar que una vez configurado tendremos en nuestro Team Foundation Server un nuevo elemento de trabajo (workitem) llamado Operation Issue que será el utilizado para hacer que dicha información fluya y podamos gestionar el estado de los problemas encontrados en producción.
En el tema de monitorización una de las novedades de la última versión es la inclusión del Management Pack para la monitorización de aplicaciones llamado APM (Application Performance Monitoring), este Management Pack viene de la compra por parte de Microsoft de AVICode que podía utilizarse en versiones antiguas de SCOM. AVICode fue utilizado por Microsoft para la monitorización de su plataforma de Xbox LIVE.
Algunas de las características que ofrece son:
- Monitorización de la capa servidora y cliente.
- No son necesarias modificaciones en el código de las aplicaciones a monitorizar.
- Impacto mínimo en el rendimiento.
- Información de KPI´s de monitoreo.
- Detección en tiempo real de fallos y problemas de rendimiento.
- Recopilación de datos, de todas las capas, hasta la causa del error.
- Generación de informes.
Qué información registra:
- Eventos
- Errores aplicación.
- Rendimiento.
- Información de operaciones.
- Fallos de sistema.
- Errores Aplicación
- Fallos aplicación.
- Problemas de conectividad.
- Problemas de seguridad.
También es importante saber qué nos permite monitorizar. En la última versión disponible SCOM 2012 SP1 podremos monitorizar:
- ASP.NET Web.
- ASP.NET MVC.
- ASP.NET Web Service.
- WCF Services.
- Windows Services.
- SharePoint.
- IIS 8.
- Monitorización 360º
- Capacidades de monitorización Unix y Linux.
En próximos post entraré en profundidad de todo lo que nos ofrece SCOM y Visual Studio.
¡¡¡Manos a la obra!!!
Para terminar, comentar que tenemos que hacer un cambio en la forma de hacer las cosas ya que si este cambio no se lleva a cabo la situación no va a cambiar por si sola.
Cuántos de nosotros no hemos sufrido o sufrimos cada vez que tenemos que hacer una subida a producción, cuántos no hemos tenido a todo el mundo encima de nosotros porque se ha dado un error en producción y no conseguimos dar con la solución, con la perdida de negocio que puede ocasionar a nuestras organizaciones, etc, etc, etc.
Solo dar algunos datos:
- Se gasta en torno al 40% del esfuerzo en rehacer trabajo.
- 60% de los errores de las aplicaciones son producidos en las entregas.
- El 90% del tiempo de caída proviene del 10% de los errores.
- El coste de solucionar un problema en producción se multiplica al menos x100 frente a hacerlo en desarrollo.
- En torno al 50% de las aplicaciones contienen errores no triviales.
- 75% del tiempo los equipos de operaciones se gasta en Release Management
- 15% de los ingresos anuales se pierden por errores humanos.
- Las revisiones, el testing y herramientas de análisis pueden detectar más del 60% de los errores.
Por todo lo mencionado os invito a incorporar (poco a poco) las prácticas de DevOps en vuestras organizaciones y apoyaros en herramientas como Visual Studio y SCOM.
En todos los eventos y en las empresas donde hemos enseñado en vivo y en directo el uso de SCOM más Visual Studio, os puedo asegurar que la gente se ha quedado enormemente sorprendida con la información tan detallada de los errores y problemas de rendimiento que se recogen de las aplicaciones monitorizadas, reduciendo así drásticamente los tiempos de resolución de los problemas y haciendo al final que vivíamos todos mejor ;).
Fuentes:
- – Estudio publicado por IDC en 2012
- – http://www.succeedingwithagile.com/resources/reported-benefits-of-agile
- – http://en.wikipedia.org/wiki/Software_testing
- – http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf
