Gestión de activos de aplicaciones y servicios para equipos de desarrollo
Before you start, this guide covers:
What does application and service asset management for application development teams mean.
Why service context, application dependencies, and configuration data matter for engineering teams.
How Service Collection supports developer workflows with Assets, a CMDB, Data Manager, and service relationships.
A practical walkthrough example from service modeling to incident and change context.
Service Collection products referenced: Jira Service Management, Assets, Customer Service Management, Rovo
Reading time: 9 minutes
Desarrolla y pone en funcionamiento aplicaciones con un mejor contexto de servicio
La gestión de activos de aplicaciones y servicios es fundamental para los equipos de desarrollo de aplicaciones porque los productos digitales modernos dependen de una red de aplicaciones, servicios, entornos, infraestructura y componentes de terceros.
Cuando la información sobre aplicaciones, dependencias, propiedad y sistemas de soporte está dispersa en tickets, consolas en la nube, hojas de cálculo y conocimiento tribal, los equipos tienen menos visibilidad del impacto de los cambios, el riesgo de incidentes y el estado de los servicios.
Esa falta de contexto puede ralentizar la entrega y aumentar la probabilidad de interrupciones o de una resolución de problemas mal orientada.
Las aplicaciones para desarrolladores y la gestión de activos de servicio reúnen este contexto en un modelo compartido y de confianza. Con Service Collection, los equipos pueden hacer un seguimiento de los elementos de configuración de la aplicación y del servicio, conectarlos con la actividad de desarrollo, comprender las relaciones en toda la pila e identificar rápidamente a los propietarios.
Esto ayuda a los equipos de desarrollo de aplicaciones a realizar cambios más seguros, resolver incidentes más rápido, reducir la carga de la coordinación y realizar la compilación y la puesta en marcha de servicios fiables con mayor confianza.
¿Qué es la gestión de activos de aplicaciones y servicios?
La gestión de activos de aplicaciones y servicios consiste en hacer un seguimiento del ciclo de vida, la propiedad y las dependencias de las aplicaciones y los servicios para mejorar la visibilidad operativa. Al conectar aplicaciones a la infraestructura, como bases de datos relacionales, servicios web, microservicios o entornos en la nube, los equipos obtienen el contexto de servicio necesario para reducir el riesgo de incidentes y acelerar las implementaciones.
Combina varias capacidades estrechamente relacionadas:
Gestión de la configuración de los servicios: manteniendo información precisa sobre servicios, aplicaciones, bases de datos, API, recursos en la nube y las relaciones entre ellos.
Seguimiento de activos y configuración: organizando los sistemas y componentes que respaldan la entrega de aplicaciones de software y las operaciones de producción.
Flujos de trabajo de gestión de servicios: aplicando ese contexto a incidentes, cambios, solicitudes, aprobaciones e informes.
Service Collection, Activos proporciona la estructura para estos datos. Activos es tu CMDB que almacena todos los registros de la configuración y sus relaciones a lo largo del tiempo, lo que ayuda a los equipos a entender no solo lo que existe, sino cómo se conectan los componentes.
El Gestor de datos de Activos de Service Collection ayuda a mejorar la calidad de los datos al unificar y conciliar registros de múltiples fuentes antes de que los equipos dependan de ellos a nivel operativo.
Por qué la gestión de activos de aplicaciones y servicios es importante para los desarrolladores
Cuando la información de aplicaciones y componentes está dispersa en hojas de cálculo y sistemas aislados, resulta difícil tener una idea clara de qué aplicaciones ejecuta una empresa, cómo se utilizan y, lo más importante, qué se estropea cuando algo cambia.
Activos de Service Collection te proporciona una CMDB estructurada y apta para consultas que reúne todos los datos de tus aplicaciones y componentes en un solo lugar, reemplazando las hojas de cálculo dispersas por un registro activo y conectado.
Activos de Atlassian centraliza tu catálogo de aplicaciones y servicios en una única CMDB estructurada y con función de búsqueda, sustituyendo las hojas de cálculo dispersas y las herramientas aisladas por registros activos y conectados. Mapea las dependencias entre aplicaciones, componentes e infraestructuras y se vincula directamente con los flujos de trabajo de Jira Service Management, para que los equipos siempre sepan qué tienen, quién es responsable y qué se ve afectado cuando las cosas cambian.
Evalúa el impacto de los cambios más rápido: los equipos pueden saber qué aplicaciones, entornos o servicios dependientes podrían verse afectados antes de implementar un cambio.
Mejora la respuesta ante incidentes: el personal de respuesta puede identificar rápidamente al propietario del servicio, las dependencias ascendentes y descendentes, y la infraestructura probablemente afectada.
Reduce el cambio de contexto: los desarrolladores y operadores pueden acceder al contexto del servicio y del activo directamente en los flujos de trabajo de Jira Service Management.
Fortalece la propiedad del servicio: los equipos pueden hacer que los datos de propiedad, responsabilidad de soporte y dependencia sean más fáciles de encontrar y mantener.
Mejora la confianza en los servicios de la aplicación y los datos operativos: el Gestor de datos de Activos ayuda a conciliar los registros de las herramientas en la nube, las herramientas de detección y los sistemas internos en una fuente de información más clara.
Fomenta una mejor colaboración con los equipos de operaciones: el contexto de configuración compartido ayuda a que ingeniería y operaciones realicen su trabajo en sintonía durante los cambios y los incidentes.
Cómo Service Collection respalda el desarrollo orientado a aplicaciones y servicios
Service Collection ayuda a los equipos de desarrollo y operaciones a llevar los datos de configuración a los flujos de trabajo donde más importan. En lugar de mantener los modelos de servicio separados de la actividad diaria, los equipos pueden conectar aplicaciones, servicios y dependencias directamente a las solicitudes, los incidentes y los cambios.
Generar una CMDB centrada en los servicios con Activos
Activos permite a los equipos definir esquemas de objetos para los componentes que son importantes para la entrega y las operaciones de software y aplicaciones, y luego mapear la infraestructura y las bases de datos relacionales. Eso puede incluir servicios empresariales, aplicaciones, entornos, API, bases de datos, colas, recursos en la nube, repositorios y equipos de soporte.
Dentro de una CMDB, esos elementos de configuración pueden vincularse mediante relaciones que reflejan cómo funcionan realmente los servicios. Por ejemplo, una aplicación orientada al cliente podría depender de una puerta de enlace de API, un clúster de base de datos, infraestructura en la nube y un equipo propietario. Ese modelo conectado resulta útil cuando los equipos necesitan conocer el impacto rápidamente.
Best practice: start with one or two critical application services and the dependencies that matter most for incidents and changes. A lean, service-centric CMDB is usually more useful than a large model nobody maintains.
Usa el Gestor de datos de Activos para mejorar la calidad de los datos
Los datos de las aplicaciones y servicios a menudo provienen de muchos lugares: plataformas en la nube, herramientas de detección, hojas de cálculo, documentación interna y sistemas de ingeniería. Si esas fuentes no coinciden, los equipos pierden la confianza en el modelo.
El Gestor de datos de Activos ayuda a consolidar, limpiar y conciliar datos de múltiples fuentes en un registro operativo más fiable. Esto facilita normalizar las convenciones de nomenclatura, reducir los duplicados e identificar las brechas antes de que afecten a los incidentes, las auditorías o las aprobaciones.
Para los equipos de ingeniería y plataforma, eso significa mayor confianza en la propiedad de los servicios, los registros de entorno y los datos de dependencias.
Mapea los servicios empresariales con los servicios y activos de los servicios para acceder al impacto de los incidentes y los cambios.
Jira Service Management permite a los equipos asociar solicitudes o cambios con objetos de Activos directamente desde la vista del ticket. Eso significa que un incidente puede vincularse a la aplicación o servicio afectado, mientras que un cambio puede hacer referencia al entorno o la infraestructura que afecta.
Una vez vinculados, los responsables de las respuestas y los aprobadores tienen mejor contexto. Pueden ver qué servicio está involucrado, a quién pertenece, qué otros componentes pueden verse afectados y si ya hay alguna actividad relacionada en progreso.
Facilita una resolución de problemas más rápida con el contexto de las relaciones
Un registro de servicio por sí solo es útil. Un registro de servicio conectado a sus dependencias es mucho más potente. Los datos de relaciones ayudan a los equipos a pasar de "algo no funciona" a "esta dependencia específica puede ser la causa" más rápidamente.
Por ejemplo, si una aplicación web está degradada, el equipo puede revisar la base de datos vinculada, el proveedor de autenticación, la cola y el entorno en la nube para acotar la investigación. Esa vista compartida también puede respaldar una estrategia de "enjambre" al proporcionar a los equipos de desarrollo y operaciones un mapa común del servicio.
Aprovecha la automatización para mantener en marcha los flujos de trabajo operativos
La automatización puede ayudar a los equipos a actuar sobre el contexto del servicio y la configuración sin actividad manual adicional. Los equipos pueden desencadenar notificaciones, enrutar tickets, crear tareas de seguimiento o actualizar registros en función de los cambios de estado o de los objetos vinculados.
Entre los ejemplos habituales se incluyen los siguientes:
Enrutamiento de incidentes según el servicio seleccionado o el equipo propietario
Crear tareas de seguimiento cuando cambia una dependencia crítica
Notificar a las partes interesadas cuando los incidentes afectan a servicios de alta prioridad
Asociar comprobaciones operativas estándar con entornos o componentes específicos
Ejemplo de recorrido: del modelo de servicio a una clasificación de incidentes, causa raíz y resolución más rápidas
Aquí tienes un ejemplo práctico de cómo la gestión de activos de aplicaciones y servicios puede funcionar en Service Collection con Jira Service Management y Activos.
Escenario
Un equipo de ingeniería de plataformas da soporte a un portal interno para desarrolladores y a varias aplicaciones orientadas al cliente. La propiedad del servicio está parcialmente documentada, pero la información de dependencias es incoherente y está dispersa entre diagramas, herramientas en la nube y el equipo.
Cuando se producen incidentes, los equipos de respuesta invierten demasiada tiempo en averiguar qué cambió y qué componentes están involucrados.
Paso 1: Define el modelo de servicio
El equipo crea un esquema de Activos para representar elementos de configuración clave en su CMDB, incluidos servicios empresariales, aplicaciones, entornos, bases de datos, API y equipos propietarios. Empiezan con un servicio de aplicación de alto valor y mapean sus dependencias más importantes.
Definen relaciones como:
La aplicación depende del servicio API
El servicio API depende del clúster de base de datos
La aplicación se ejecuta en el entorno de producción
El equipo de plataforma es propietario de la infraestructura de tiempo de ejecución.
Paso 2: Consolida los datos de origen con el Gestor de datos
El equipo usa el Gestor de datos para reunir registros de inventarios en la nube, hojas de cálculo internas y documentación de servicios existente. Los nombres de aplicación duplicados se concilian, se señalan los propietarios que faltan y se eliminan los registros obsoletos antes de publicarlos en el modelo de trabajo.
Outcome: the team now has a cleaner, more trustworthy service model rather than relying on competing versions of the truth.
Paso 3: Conecta el modelo a los flujos de trabajo de Jira Service Management
El equipo añade campos de Activos a los flujos de trabajo de incidentes y cambios para que el personal de ingeniería y operaciones pueda seleccionar el servicio o elemento de configuración afectado. Cuando se crea un nuevo incidente, los equipos de respuesta pueden ver inmediatamente la aplicación vinculada, el propietario, el entorno y las dependencias relacionadas.
Eso reduce el tiempo que se dedica a hacer preguntas básicas de triaje y ayuda a los equipos a involucrar a las personas adecuadas antes.
Paso 4: Usa el modelo durante un incidente
Se ha informado de un incidente debido a errores elevados en una aplicación orientada al cliente. La persona encargada de responder vincula el servicio afectado en Jira Service Management y revisa los elementos de configuración relacionados. Notan que la aplicación depende de una API de autenticación compartida y de un clúster de base de datos.
Un cambio reciente ya está asociado a la API de autenticación. Esa pista ayuda al equipo a acotar la investigación rápidamente e involucrar a los responsables adecuados sin tener que adivinar.
Paso 5: Mejora la planificación de cambios futuros
Después del incidente, el equipo empieza a usar las mismas relaciones de servicio durante las revisiones de cambios. Antes de implementar actualizaciones, pueden saber qué servicios dependientes pueden verse afectados y coordinarse con los equipos adecuados con antelación.
Cómo se aplican estas medidas en la práctica
Fase | Lo que hace el equipo | Valor operativo |
Modela el servicio | Crea objetos de servicio, aplicación, entorno y dependencia en Activos | Crea una CMDB útil para ingeniería y operaciones |
Mejora la calidad de los datos | Usa el Gestor de datos para conciliar datos de múltiples sistemas | Genera más confianza en los datos de propiedad y dependencia |
Conecta los flujos de trabajo | Vincula servicios y elementos de configuración a incidencias y cambios | Ofrece a los equipos contexto donde ya realizan su actividad |
Clasifica más rápido | Usa relaciones de dependencia durante los incidentes | Acorta el tiempo de investigación y derivación |
Planifica mejor los cambios | Revisa los servicios y componentes afectados antes de la implementación | Mejora la concienciación sobre los riesgos y la coordinación |
Cómo abordar la implementación
Si estás creando esta capacidad para equipos de ingeniería o de desarrollo de aplicaciones, una implementación por fases suele funcionar mejor.
Empieza con una aplicación o servicio crítico que aparezca con frecuencia en incidentes o cambios.
Define el conjunto mínimo útil de elementos de configuración y relaciones.
Usa el Gestor de datos para mejorar la calidad de los datos de origen antes de escalar de forma generalizada.
Añade primero el contexto de Activos a los flujos de trabajo de incidentes y cambios, donde crea un valor operativo inmediato.
Amplía la CMDB gradualmente a medida que los equipos demuestren que el modelo es útil y sostenible.
Good first milestone: make it easy for a responder or approver to answer what service is affected, what supports it, who owns it, and what else may be impacted.
Cliente destacado: Lucid Motors
[Activos es una] parte absolutamente crucial de nuestra infraestructura de Jira, y francamente no sé cómo se podría hacer ingeniería de hardware con Jira sin hacer también un seguimiento de tu hardware en el mismo espacio. Porque cuando intentamos hacerlo con herramientas de seguimiento de hardware fragmentadas… no había una trazabilidad inherente en nuestros sistemas. Y si intentaras hacer todo eso en esas otras herramientas, tampoco habría agilidad. Así que realmente hemos encontrado algo que nos funciona.
Felipe Luisi, director sénior de productos, Lucid Motors
Preguntas frecuentes
¿Qué es la gestión de activos de aplicaciones y servicios?
La gestión de recursos de aplicaciones y servicios es la práctica de hacer un seguimiento de las aplicaciones, los servicios, las dependencias, los entornos, los elementos de configuración y la propiedad en un modelo conectado. Proporciona a los equipos de desarrollo y operaciones un contexto fiable para incidentes, cambios, solicitudes y la planificación del servicio.
¿Cómo ayuda Activos a los equipos de desarrollo de aplicaciones?
Activos proporciona una CMDB estructurada para modelar aplicaciones, API, bases de datos, entornos, recursos en la nube y los equipos responsables de todo ello. Los equipos pueden vincular este contexto a los incidentes y cambios de Jira Service Management para evaluar el impacto, canalizar el trabajo y solucionar los problemas más rápido.
¿Cuál es la diferencia entre una CMDB y un inventario de activos?
Un inventario de activos registra lo que existe, mientras que una CMDB también registra cómo los elementos de configuración se relacionan entre sí y respaldan un servicio. La solución Activos puede ofrecer ambas cosas al almacenar registros de aplicación y servicio junto con sus dependencias, propiedad y contexto operativo.
¿Cómo pueden los equipos mejorar la calidad de los datos de aplicaciones y servicios?
Usa el Gestor de datos de Activos para unificar, depurar, normalizar y conciliar registros de múltiples fuentes antes de publicarlos en el modelo de trabajo. Empieza con los datos necesarios para los incidentes y cambios críticos, y luego amplía a medida que el modelo de servicio resulte útil y sostenible.