Gestion des actifs d'application et de service pour les équipes de développement
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
Développer et exploiter des applications avec un meilleur contexte de service
La gestion des actifs des applications et des services est essentielle pour les équipes de développement d'applications, car les produits numériques modernes dépendent d'un réseau d'applications, de services, d'environnements, d'infrastructures et de composants tiers.
Lorsque les informations sur les applications, les dépendances, la propriété et les systèmes de support sont dispersées dans des tickets, des consoles cloud, des feuilles de calcul et des connaissances tribales, les équipes ont moins de visibilité sur l'impact des changements, les risques d'incident et la santé des services.
Ce manque de contexte peut ralentir la livraison et augmenter le risque de pannes ou de dépannage mal orienté.
Les applications pour développeurs et la gestion des actifs de service réunissent ce contexte dans un modèle partagé et de confiance. Avec Service Collection, les équipes peuvent suivre les éléments de configuration d'application et de service, les associer aux tickets de développement, comprendre les relations dans l'ensemble de la pile et identifier rapidement les propriétaires.
Cela aide les équipes de développement d'applications à apporter des modifications plus sûres, à résoudre les incidents plus rapidement, à réduire la charge de coordination et à élaborer et exploiter des services fiables avec une plus grande confiance.
Qu'est-ce que la gestion des actifs d'application et de service ?
La gestion des actifs d'applications et de services est la pratique qui consiste à suivre le cycle de vie, la propriété et les dépendances des applications et des services afin d'améliorer la visibilité opérationnelle. En connectant les applications à une infrastructure telle que des bases de données relationnelles, des services web, des microservices ou des environnements cloud, les équipes obtiennent le contexte de service nécessaire pour réduire le risque d'incident et accélérer les déploiements.
Il combine plusieurs capacités étroitement liées :
Gestion des configurations des services : maintenir des informations précises sur les services, les applications, les bases de données, les API, les ressources cloud et les relations entre eux.
Suivi des ressources et des configurations : organisation des systèmes et des composants qui prennent en charge la livraison des applications logicielles et les opérations de production.
Workflows de gestion des services : application de ce contexte aux incidents, aux changements, aux demandes, aux approbations et à la création de rapports.
Dans Service Collection, la fonctionnalité Actifs fournit la structure de ces données. Actifs constitue votre CMDB qui stocke tous les enregistrements de configuration et leurs relations au fil des dates, aidant les équipes à comprendre non seulement ce qui existe, mais aussi comment les composants se connectent.
Le Gestionnaire des données d'actifs de Service Collection aide ensuite à améliorer la qualité des données en consolidant et en rapprochant les enregistrements de plusieurs sources avant que les équipes ne les utilisent de manière opérationnelle.
Pourquoi la gestion des actifs des applications et des services est importante pour les développeurs
Lorsque les informations sur les applications et les composants sont dispersées dans des feuilles de calcul et des systèmes en silo, il devient difficile d'avoir une idée précise des applications qu'une entreprise utilise, de la façon dont elles sont utilisées et, surtout, de ce qui tombe en panne lorsque quelque chose change.
La fonctionnalité Actifs dans Service Collection vous offre une CMDB structurée et interrogeable qui rassemble toutes les données de vos applications et composants en un seul endroit, remplaçant ainsi les feuilles de calcul éparses par un registre dynamique et connecté.
La fonctionnalité Actifs d'Atlassian centralise votre catalogue d'applications et de services dans une CMDB unique, structurée et interrogeable, remplaçant les feuilles de calcul éparpillées et les outils en silo par des enregistrements dynamiques et connectés. Elle cartographie les dépendances entre les applications, les composants et l'infrastructure et s'intègre directement aux workflows Jira Service Management, afin que les équipes sachent toujours ce qu'elles possèdent, qui en est responsable et ce qui est impacté en cas de changement.
Évaluez plus rapidement l'impact des changements : les équipes peuvent comprendre quelles applications, quels environnements ou services dépendants peuvent être affectés avant de déployer un changement.
Améliorez la réponse aux incidents : les intervenants peuvent rapidement identifier le service owner, les dépendances en amont et en aval, et l'infrastructure susceptible d'être affectée.
Réduisez les changements de contexte : les développeurs et les opérateurs peuvent accéder au contexte des services et des actifs directement dans les workflows Jira Service Management.
Renforcez la responsabilité des services : les équipes peuvent ainsi retrouver et maintenir plus facilement les informations de propriété, les périmètres de support et les données de dépendance.
Renforcez la confiance dans les services d'application et les données opérationnelles : le Gestionnaire des données d'actifs permet de rapprocher les enregistrements provenant des outils cloud, des outils de découverte et des systèmes internes pour obtenir une source de référence plus propre.
Favorisez une meilleure collaboration avec les équipes opérationnelles : le contexte de configuration partagé aide les équipes ingénierie et opérationnelles à travailler avec la même compréhension lors des changements et des incidents.
Comment Service Collection prend en charge le développement axé sur les applications et les services
Service Collection aide les équipes de développement et opérationnelles à intégrer les données de configuration dans les workflows là où elles sont nécessaires. Au lieu de séparer les modèles de service des tickets quotidiens, les équipes peuvent connecter les applications, les services et les dépendances directement aux demandes, aux incidents et aux changements.
Générer une CMDB centrée sur les services avec Actifs
La fonctionnalité Actifs permet aux équipes de définir des schémas d'objet pour les composants essentiels à la livraison et aux opérations de logiciels et d'applications, puis de cartographier l'infrastructure et les bases de données relationnelles. Cela peut inclure des services métier, des applications, des environnements, des API, des bases de données, des files d'attente, des ressources cloud, des dépôts et des équipes de support.
Dans une CMDB, ces éléments de configuration peuvent être liés par des relations qui reflètent la façon dont les services fonctionnent réellement. Par exemple, une application orientée client peut dépendre d'une passerelle d'API, d'un cluster de base de données, d'une infrastructure cloud et d'une équipe propriétaire. Ce modèle connecté devient utile lorsque les équipes doivent comprendre rapidement l'impact.
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.
Utiliser le Gestionnaire des données d'actifs pour améliorer la qualité des données
Les données d'application et de service proviennent souvent de nombreuses sources : plateformes cloud, outils de découverte, feuilles de calcul, documentation interne et systèmes d'ingénierie. Si ces sources ne concordent pas, les équipes perdent confiance dans le modèle.
Le Gestionnaire des données d'actifs permet de consolider, de nettoyer et de rapprocher les données provenant de plusieurs sources en un enregistrement opérationnel plus fiable. Cela permet de normaliser plus facilement les conventions de nommage, de réduire les doublons et d'identifier les écarts avant qu'elles n'affectent les incidents, les audits ou les approbations.
Pour les équipes d'ingénierie et de plateforme, cela signifie une plus grande confiance dans la propriété des services, les enregistrements d'environnement et les données de dépendance.
Associer les services métier aux services d'application et aux actifs pour évaluer l'impact des incidents et des changements.
Jira Service Management permet aux équipes d'associer des demandes ou des changements à des objets Actifs directement depuis la vue du ticket. Cela signifie qu'un incident peut être lié à l'application ou au service concerné, tandis qu'un changement peut faire référence à l'environnement ou à l'infrastructure qu'il touche.
Une fois reliés, les intervenants et les approbateurs disposent d'un meilleur contexte. Ils peuvent voir quel service est impliqué, qui en est responsable, quels autres composants pourraient être affectés et si un ticket associé est déjà en cours d'avancement.
Accélérer le dépannage grâce au contexte des relations
Un enregistrement de service à lui seul est utile. Un enregistrement de service connecté à ses dépendances est beaucoup plus puissant. Les données de relation aident les équipes à passer plus rapidement de « quelque chose ne fonctionne pas » à « cette dépendance spécifique pourrait en être la cause ».
Par exemple, si une application web est dégradée, l'équipe peut examiner la base de données, le fournisseur d'authentification, la file d'attente et l'environnement cloud associés pour affiner l'investigation. Cette vue partagée peut également servir de support au swarming d'incidents en fournissant aux équipes de développement et d'exploitation une carte commune du service.
Utiliser l'automatisation pour faire avancer les workflows opérationnels
L'automatisation peut aider les équipes à agir sur le contexte de service et de configuration sans ticket manuel supplémentaire. Les équipes peuvent déclencher des notifications, acheminer des tickets, créer des tâches de suivi ou mettre à jour des enregistrements en fonction des changements d'état ou des objets liés.
Voici quelques exemples courants :
Routage des incidents en fonction du service sélectionné ou de l'équipe propriétaire
Création de tâches de suivi lorsqu'une dépendance critique est modifiée
Notification des parties prenantes lorsque des incidents affectent des services de haute priorité
Association de contrôles opérationnels standards à des environnements ou des composants spécifiques
Exemple de présentation : du modèle de service à un tri des incidents, une cause racine et une résolution plus rapides
Voici un exemple pratique de la façon dont la gestion des actifs d'application et de service peut fonctionner dans Service Collection avec Jira Service Management et Actifs.
Scénario
Une équipe d'ingénierie de plateforme prend en charge un portail interne pour les développeurs et plusieurs applications destinées aux clients. La propriété des services est partiellement documentée, mais les informations sur les dépendances sont incohérentes et réparties entre les diagrammes, les outils cloud et les connaissances de l'équipe.
En cas d'incident, les intervenants passent trop de temps à déterminer ce qui a changé et quels composants sont impliqués.
Étape 1 : Définir le modèle de service
L'équipe crée un schéma Actifs pour représenter les éléments de configuration clés dans sa CMDB, notamment les services métier, les applications, les environnements, les bases de données, les API et les équipes propriétaires. Elle commence par un service d'application à forte valeur ajoutée et cartographie ses dépendances les plus importantes.
Elle définit des relations telles que :
L'application dépend du service API
Le service API dépend du cluster de base de données
L'application s'exécute en environnement de production
L'équipe de plateforme est responsable de l'infrastructure d'exécution
Étape 2 : Consolider les données sources avec le Gestionnaire de données
L'équipe utilise le Gestionnaire de données pour regrouper les enregistrements provenant des inventaires cloud, des feuilles de calcul internes et de la documentation de service existante. Les noms d'application en double sont rapprochés, les propriétaires manquants sont signalés et les enregistrements obsolètes sont nettoyés avant la publication dans le modèle de travail.
Outcome: the team now has a cleaner, more trustworthy service model rather than relying on competing versions of the truth.
Étape 3 : Connecter le modèle aux workflows Jira Service Management
L'équipe ajoute des champs Actifs aux workflows d'incident et de changement afin que les ingénieurs et les opérateurs puissent sélectionner le service ou la tâche de configuration concerné. Lorsqu'un nouvel incident est créé, les intervenants peuvent immédiatement voir l'application liée, le propriétaire, l'environnement et les dépendances associées.
Cela réduit le temps passé à poser des questions de triage de base et aide les équipes à impliquer les bonnes personnes plus tôt.
Étape 4 : Utiliser le modèle lors d'un incident
Un incident a été signalé, dû à un nombre élevé d'erreurs dans une application destinée aux clients. L'intervenant associe le service concerné dans Jira Service Management et examine les éléments de configuration associés. Il voit que l'application dépend d'une API d'authentification partagée et d'un cluster de base de données.
Une modification récente est déjà associée à l'API d'authentification. Cet indice aide l'équipe à cibler rapidement l'enquête et à mobiliser les bons responsables sans tâtonner.
Étape 5 : Améliorer la planification des futurs changements
Après l'incident, l'équipe commence à utiliser les mêmes relations de service lors des revues de changement. Avant de déployer des mises à jour, ils peuvent voir quels services dépendants pourraient être affectés et se coordonner avec les bonnes équipes à l'avance .
Et en pratique ?
Étape | Ce que fait l'équipe | Valeur opérationnelle |
Modéliser le service | Crée des objets service, application, environnement et dépendance dans Actifs | Crée une CMDB utilisable pour l'ingénierie et les opérations |
Améliorer la qualité des données | Utilise le Gestionnaire de données pour réconcilier les données de plusieurs systèmes | Renforce la confiance dans les données de propriété et de dépendance |
Connecter des workflows | Lie les services et les éléments de configuration aux incidents et aux changements | Apporte le contexte aux équipes là où elles travaillent déjà |
Trier plus rapidement | Utilise les relations de dépendance lors des incidents | Réduit la date d'investigation et de remontée |
Mieux planifier les changements | Examine les services et composants concernés avant l'implémentation | Améliore la sensibilisation aux risques et la coordination |
Comment aborder l'implémentation
Si vous créez cette fonctionnalité pour les équipes d'ingénierie ou de développement d'applications, un déploiement progressif est généralement préférable.
Commencez par une application ou un service critique qui apparaît fréquemment dans les incidents ou les changements.
Définissez l'ensemble minimal utile d'éléments de configuration et de relations.
Utilisez le Gestionnaire de données pour améliorer la qualité des données sources avant un déploiement à grande échelle.
Ajoutez d'abord le contexte des Actifs aux workflows d'incident et de changement, là où cela crée une valeur opérationnelle immédiate.
Développez la CMDB progressivement à mesure que les équipes démontrent que le modèle est utile et maintenable.
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.
Pleins feux sur un client : Lucid Motors
[Actifs est une] partie absolument cruciale de notre infrastructure Jira, et je ne sais franchement pas comment l'on pourrait faire de l'ingénierie matérielle avec Jira, sans également suivre notre matériel dans le même espace. Parce que lorsque nous avons essayé de le faire avec des outils de suivi de matériel cloisonnés… il n'y avait aucune traçabilité inhérente à nos systèmes. Et si l'on essayait de tout faire dans ces autres outils, il n'y aurait aucune agilité non plus. On a donc vraiment trouvé une solution qui nous correspond.
Felipe Luisi, Senior Product Manager, Lucid Motors
Questions fréquentes
Qu'est-ce que la gestion des actifs d'application et de service ?
La gestion des actifs d'application et de service est la pratique consistant à suivre les applications, les services, les dépendances, les environnements, les éléments de configuration et la propriété dans un modèle connecté. Il fournit aux équipes de développement et d'opérations un contexte fiable pour les incidents, les changements, les demandes et la planification de service.
Comment Actifs aide-t-il les équipes de développement d'applications ?
Actifs fournit une CMDB structurée pour modéliser les applications, les API, les bases de données, les environnements, les ressources cloud et les équipes qui en sont propriétaires. Les équipes peuvent associer ce contexte aux incidents et aux changements Jira Service Management pour évaluer l'impact, acheminer le travail et résoudre les problèmes plus rapidement.
Quelle est la différence entre une CMDB et un inventaire des actifs ?
Un inventaire des actifs enregistre ce qui existe, tandis qu'une CMDB recense également la manière dont les éléments de configuration sont liés les uns aux autres et assurent le support d'un service. La fonctionnalité Actifs peut remplir ces deux rôles en stockant les enregistrements d'application et de service ainsi que leurs dépendances, leurs propriétaires et leur contexte opérationnel.
Comment les équipes peuvent-elles améliorer la qualité des données d'application et de service ?
Utilisez le Gestionnaire de données de la fonctionnalité Actifs pour consolider, nettoyer, normaliser et réconcilier les enregistrements provenant de plusieurs sources avant de les publier dans le modèle de travail. Commencez par les données nécessaires aux incidents critiques et aux changements, puis développez-les à mesure que le modèle de service s'avère utile et facile à maintenir.