.png)
Rundeck ha estado en el corazón de varias iniciativas que han entregado beneficios de negocio impactantes a Ticketmaster, un procesador de más de $9 billones en boletos de eventos y conciertos por año.
Permitió a un solo equipo desplegar de manera segura aplicaciones a través de los ambientes, todo el camino hasta producción
Removió múltiples días de esfuerzo a lo largo del ciclo de vida
Redujo incrementos en 30% – 40% y costos globales de servicio de incidentes en 55%
Tiempo medio de reparación reducido (MTTR, Mean Time To Repair) en 50% – 150%
Ticketmaster antes de Rundeck
Como muchas grandes empresas, el proceso de implementación heredado de Ticketmaster era fragmentado y engorroso. Había diversas herramientas específicas de equipo, demasiada intervención manual, y los procedimientos variaban por ambiente o grupo de producto. Esto hacía difícil y lento realizar el trabajo a través de los equipos. La velocidad de entrega de los productos de Ticketmaster estaba sufriendo y los errores eran difíciles de evitar.
Esta fue la situación heredada por Mark Maun, Director de Ingeniería de Plataforma en Ticketmaster. Mark tuvo el desafío de mejorar el rendimiento y calidad del proceso de implementación de Ticketmaster. Esto parecía ser una tarea monumental considerando que Ticketmaster es una gran organización internacional que soporta una transacción de negocios importantes y de gran escala.
¿Por qué Rundeck?
Rundeck fue escogido por Mark para proveer una interfaz coherente para que los equipos a lo largo de Ticketmaster puedan implementar y gestionar aplicaciones. A Mark le gustó la habilidad de Rundeck para manejar toda la diversidad en su tecnología subyacente así como la multitud de elecciones de automatización que han sido hechas independientemente de aplicación a aplicación y de un equipo a otro. Mark quería proveer todos los beneficios de la estandarización, pero aún así permitir que cada equipo tenga la libertad de tomar sus propias decisiones técnicas.
“Si puedes hacer un script, puede hacerlo en Rundeck”
El objetivo de Mark era permitir a un equipo o un individuo conducir una implementación a través de algún o todos los ambientes de Ticketmaster. Mark identificó que Rundeck le permitiría alcanzar este objetivo de autoservicio y al mismo tiempo proporcionar el control de acceso y transparencia que se necesita para cumplir las estrictas políticas de seguridad y gobernanza de Ticketmaster.
Más allá de la implementación, Mark vio que Rundeck permitiría que cualquier tarea de operación — programada o bajo demanda — se convierta en una llamada de un solo botón o llamada de API que pueda coordinar cualquier número de herramientas.
“Rundeck da acceso a las personas, pero deja las operaciones en control de la política”
Empezó con la automatización, evolucionó para permitir el cambio organizacional
Rundeck empezó como parte de un esfuerzo de automatización, pero pronto se convirtió en un punto de ventaja clave en la evolución de Ticketmaster lejos de su tradicional forma de trabajar en “silos”. Antes de Rundeck, un equipo desarrollaría una aplicación y luego se necesitarían cuatro o más equipos diferentes para implementar la aplicación en cada ambiente sucesivo (Desarrollo, QA, Integración, Producción). Es más, antes de Rundeck, no había un lugar en común en el que mirar para entender el proceso completo de hacer una implementación funcional o un registro accesible de lo que había sucedido durante o después de una implementación. Los retrasos y costosos traspasos eran habituales en Ticketmaster.
Con Rundeck en orden, los equipos individuales pueden tener el control. Los equipos pueden implementar de manera segura y gestionar sus aplicaciones en cualquier ambiente. Los procesos estandarizados pueden ser compartidos o adaptados entre equipos. El conocimiento sobre la implementación y actividades de operación está ahora fácilmente disponible — incluyendo que pasó, cómo pasó, quién lo hizo, y cuando lo hicieron. Los traspasos fueron suavizados o eliminados. Los retrasos fueron eliminados.
Objetivo 1: Permitir la implementación de autoservicio hasta la puesta en producción
Mark inicialmente introdujo Rundeck utilizando un enfoque de base para conseguir apoyo y demostrar los beneficios. Como con cualquier empresa, Mark primero necesitaba probar tanto la seguridad como el valor de utilizar una herramienta como Rundeck. Mark tomó un doble desafío: 1) introducir una herramienta “open source” a una organización que ha preferido anteriormente construir sus propias herramientas, 2) fomentar la idea de un estilo de “autoservicio” de trabajo.
El primer objetivo de Mark era encontrar equipos de desarrollo que aceptaran utilizar Rundeck en sus ambientes de pre producción. Las primeras preocupaciones del desarrollador incluían la pérdida de control sobre la automatización que tenían que utilizar y resistencia a los estándares únicos impuestos. Mark abordó esas preocupaciones mostrando como podían acelerar su ciclo controlando las implementaciones ellos mismos y también obtener una manera segura de entrega entre sí. Después de que esos primeros equipos de desarrollo subieron a bordo, los equipos rápidamente vieron el beneficio de promocionar su uso de Rundeck más adelante para cubrir QA y otros ambientes de pre-producción.
Con esos éxitos iniciales, otros equipos de producto decidieron utilizar Rundeck. Finalmente, Rundeck se convirtió en una pieza por defecto de las herramientas de apoyo de la plataforma de próxima generación de Ticketmaster. El número de equipos requeridos para implementar una aplicación en cada ambiente sucesivo paso de 4 a 2 (uno para implementar a pre-producción y otro para producción). Sin embargo, en este punto, el uso de Rundeck de Ticketmaster estaba limitado a ambientes de pre-producción.
A pesar del éxito inicial en esos ambientes de pre-producción, la idea de utilizar esta solución en producción fue inicialmente recibida con resistencia. Viendo los beneficios obvios de utilizar el mismo método en todos los ambientes, Mark y su equipo salieron a reducir esa resistencia. El registro fue incrementado, Rundeck estaba enlazado con el Active Directory para la autenticación, y se agregó un proceso de aprobación para administrar las solicitudes de acceso.
Con estas adiciones, los beneficios de cumplimiento de Rundeck pronto se volvieron más evidentes. Ahora había un lugar central para revisar toda la actividad de implementación (previamente la información tenía que ser recolectada manualmente de múltiples fuentes).
Una vez que Operaciones vio estas mejoras en acción, empezaron a ver que Rundeck hacia las cosas más fáciles, no más difíciles.
Mientras que el éxito se acumulaba y se atendieron las preocupaciones de los equipos de operaciones, la decisión fue hecha por la dirección para “hacer lo mismo” y Rundeck se convirtió en una herramienta estándar a lo largo de todos los ambientes, incluido producción.
Los nuevos equipos de productos que llegaban a Rundeck, demostraron que Rundeck les dio la libertad de tomar las decisiones que mejor se adecuaban a sus aplicaciones y automatización existente. Se proporcionaron dos métodos para crear “Jobs” que cubrían la mayoría de escenarios (siendo Java, PHP, y Shell los lenguajes más comunes utilizados):
Una plantilla Rundeck Ticketmaster estándar que viene con implementación y soporte básico. Los equipos pueden simplemente conectarse en su propia información de producto y empezar a funcionar
Los equipos pueden bifurcar la plantilla Rundeck Ticketmaster estándar (o aún construir los suyos desde cero si se necesita)
Objetivo 2: Empoderar al equipo de soporte con tareas autoservicio
Una vez que Rundeck estaba en uso como un método para equipos de entrega enviaran actualizaciones, quedó claro que Rundeck también podría ser la herramienta escogida para las acciones de soporte y operaciones.
El uso de Rundeck evolucionó para convertirse en la herramienta, estándar y flexible, utilizada a lo largo de equipos de entrega, soporte y operaciones. Rundeck también se convirtió en un punto común para políticas de control de acceso y asegurar la gobernanza.
Los equipos de entrega ahora tienen la capacidad de especificar, en la forma de Jobs de Rundeck, cómo controlar las cosas que han desarrollado y hacer disponibles esos controles a quien sea que los necesite. Además de la colaboración mejorada con la organización de Desarrollo, Operaciones ahora tiene una manera estándar de gestionar tareas administrativas como reinicios de servicio, acciones de limpieza (recuperar espacio), arrancando Máquinas Virtuales, trabajos cron, etc.
El beneficio más sorprendente fue cuando el uso de Rundeck fue extendido al TOC (Technical Operations Center, Centro de Operaciones Técnicas) de Ticketmaster agrupado bajo una iniciativa llamada “Soporte al Extremo”.
“TOC puede ahora tomar decisiones por sí mismo utilizando los Jobs de Rundeck examinados por los equipos de entrega. Esto acortó los incrementos y redujo el MTTR” – Mark Maun.
TOC es la función de soporte que es responsable por el monitoreo y operaciones las 24 horas del día de todos los servicios de Ticketmaster. En el pasado, la mayoría de las alertas recibidas por TOC resultaban en escalamientos. TOC tenía el conocimiento general del sistema, pero le faltaba la habilidad en la mayoría de los casos para tomar acciones exploratorias o correctivas. El número de escalamientos era alto y el Tiempo Medio de Reparación (MTTR) era alto. Esta situación era costosa e interfería con la calidad de los servicios de Ticketmaster por parte de sus clientes, ambas cosas que dañan los resultados de Ticketmaster.
Introducido bajo el liderazgo del nuevo CTO de Ticketmaster, Jody Mulkey, Soporte al Extremo es un programa diseñado para empoderar a TOC para tomar acción rápida y decisiva para resolver problemas de producción. Utilizando los Jobs de Rundeck, un equipo de Entrega proveerá a los usuarios de TOC con unos procedimientos operativos estándares para administrar las aplicaciones funcionando en producción. Vinculando alertas de monitoreo a Jobs de Rundeck específicos, se vuelve simple tomar acción rápida y reparar problemas conocidos tan pronto como ocurran.
Esta iniciativa Soporte al Extremo mostró resultados rápidos en cuestión de meses. El MTTR por aplicación disminuyó en un 50% – 150%. El número de incidentes por aplicación que necesitaban ser escalados se redujo en 30% – 40% y el costo global de servicio de incidentes se redujo en 55%.
Utilizando Rundeck como parte de la iniciativa Soporte al Extremo también tuvo otros beneficios. Rundeck se convirtió en un puente a través del cual información procesable puede ser compartida entre TOC y los equipos de entrega. Los Jobs de Rundeck son utilizados para comunicar procedimientos específicos a los usuarios de TOC y los reportes de Rundeck son utilizados para comunicar actividad de TOC reciente de vuelta a los equipos de entrega.
