Le domaine Gérer les services techniques implique les tables utilisées par Gestion des opérations informatiques les produits (ITOM) telles que Mappage des services et Détection. Il s’agit des instances déployées de produits digitaux et de leurs composants connexes et détectables, ainsi que de la documentation des services qui fournissent et prennent en charge les instances déployées.

Les CI de ce domaine sont des éléments détectés tels que les applications installées, les serveurs et les composants réseau. Le domaine Gérer les services techniques représente également le portefeuille des services techniques utilisés. Ces services sont opérationnels, ce qui signifie que vous pouvez les sélectionner pour ITSM Gestion des incidents, Gestion des problèmes, ou Gestion des changements.

Les utilisateurs typiques sont les propriétaires de services d’application (pour l’application et la plateforme) et les propriétaires de services technologiques (pour l’infrastructure et la distribution). Les consommateurs de technologie peuvent demander des offres de service technique via le catalogue de demandes.

Gérer le domaine des services techniques.

Les tables du domaine Gérer les services techniques représentent la technologie que votre entreprise vend ou consomme dans la vue du fournisseur. Bien que vous ne soyez pas obligé d’utiliser Mappage des services et Détection de remplir les tables, ces produits accélèrent le processus et minimisent les erreurs. Ils vous permettent également de gérer les CI et leurs relations. Le domaine comprend les tables suivantes :

  • Table des services techniques [cmdb_ci_service_technical]
  • Services techniques utilisés Gestion des événements dans la table de groupes de CI dynamiques [cmdb_ci_query_based_service].
  • Demander le catalogue
  • Table des offres de service technique [service_offering]
  • Table de groupe de CI dynamique [cmdb_ci_query_based_service]
  • Table des services d’application mappés [cmdb_ci_service_discovered] (incluse dans le système de base)

Services techniques

Les services techniques sont associés aux propriétaires de services et sont généralement superposés sous un ou plusieurs services d’entreprise ou d’application. Un service technique peut proposer une ou plusieurs offres de service technique.

Les utilisateurs du service technique peuvent afficher et gérer les technologies que vous fournissez à l’entreprise. Gestion des événements vous permet de surveiller les performances de service. Vous pouvez également l’utiliser Gestion des événements pour identifier les problèmes d’intégrité pour les CI d’infrastructure et les services d’application associés.

Les services techniques peuvent être gérés dans le cadre du portefeuille des services dans le domaine Vente/Consommation (c’est-à-dire qu’une hiérarchie de portefeuille de services peut être référencée à partir d’un service technique). Cela permet une hiérarchie et une gestion plus complètes des services techniques et des services d’entreprise au sein de l’espace Gestion des portefeuilles de services de travail et des espaces de travail connexes. Vous pouvez prendre de meilleures décisions lorsque vous savez comment les dépenses consacrées aux services techniques peuvent améliorer les performances et la fiabilité de vos services d’entreprise.

Remarque : Les services d’entreprise et les services techniques se connectent au spm_service_portfolio via le spm_taxonomy_node. Consultez Taxonomie Gestion des portefeuilles de services.

Offres de service technique

Les consommateurs de technologies peuvent demander des offres de service technique (SO) via le catalogue de demandes. Le consommateur peut généralement sélectionner les fonctionnalités et options suivantes :
  • Niveau de performance
  • Emplacement ou géographie
  • Environnement
  • Tarification
  • Graphique des disponibilités
  • Aptitude
  • Groupe de support (pour l’incident)
  • Groupe d’approbation technique (pour le changement)
  • Options d’emballage (engagements)
Les offres de service technique comportent généralement les composants suivants :
Un ou plusieurs engagements de service
Un engagement de service définit les obligations de prestation de service convenues entre le consommateur et le fournisseur. Les engagements de service définissent uniquement le niveau de service en termes de disponibilité, de criticité, de portée, de tarification et d’autres facteurs. Par exemple, une organisation peut offrir deux niveaux de prise en charge pour un service d’application :
  • Prise en charge d’une offre au niveau de la production : fournit un niveau élevé de disponibilité et de criticité pour les instances de production. Comprend une garantie de temps de réponse de 5 minutes 24 heures sur 24, 7 jours sur 7 (24 heures sur 24, sept jours sur sept).
  • Prise en charge d’une offre de non-production : disponibilité et criticité limitées pour les instances de non-production. Comprend une garantie de temps de réponse de 60 minutes entre 8h00 et 17h00, du lundi au vendredi.
Abonnement à une offre de service qui enregistre les utilisateurs qui ont accès à une offre

Les offres de service technique mappées à la table [service_offering] sont classées comme « service technique » et dérivées du service. L’offre de service technique est basée sur la façon dont la société mère répond à un besoin technique spécifique. Chaque service technique opérationnel doit avoir au moins une offre de service technique.

Chaque CI associé par l’intermédiaire d’un groupe de CI dynamique ne peut être associé qu’à un seul service technique ou à une seule offre de service technique. Des conflits peuvent survenir lorsqu’un service inclut plusieurs offres avec des SLA, des OLA, des groupes de support et des engagements différents.

Groupes de CI dynamiques

Un groupe de CI dynamique est composé de CI qui résultent d’une CMDB requête de groupes. Par exemple, vous pouvez créer un groupe de CI dynamique en fonction de l’emplacement : « tous les serveurs Web à Detroit » ou « toutes les bases de données Oracle à Mumbai ».
Remarque : Les groupes de CI dynamiques contiennent uniquement des CI et ne peuvent pas contenir d’autres groupes de CI.
Les groupes de CI dynamiques sont mappés à la table [cmdb_ci_query_based_service] et sont classés comme service d’application ou service technique, selon le cas. Vous pouvez utiliser des groupes de CI dynamiques dans les situations suivantes :
Service d’application basé sur des requêtes
Vous n’avez Mappage des services pas encore activé, mais vous disposez de 12 serveurs et de trois instances de base de données dans MyAppServiceProd. Vous pouvez remplacer vos feuilles de calcul par un groupe de CI dynamique en tant que service d’application.
Groupe géré de CI d’infrastructure
Les serveurs Web de Détroit sont gérés par l’offre de service technique DetroitRockCity. Au lieu de créer manuellement des relations entre les offres de services techniques et les CI d’infrastructure, utilisez un groupe de CI dynamique. Une relation unique entre votre CI d’offre de service technique (DetroitRockCity) et votre groupe de CI dynamique (serveurs Web à Détroit) vous donne la visibilité dont vous avez besoin.
Un moyen de gérer les correctifs pour vos CI
Dans Gestion des changements, vous pouvez sélectionner le groupe de CI dynamique correspondant aux CI que vous devez mettre à jour et utiliser une règle métier pour renseigner automatiquement le champ CI affecté .

Reportez-vous à la section Créer un groupe de CI dynamique pour obtenir des instructions.

Services d'application

Un service d’application est une représentation logique d’un système déployé ou d’une pile d’applications. À l’aide des services d’application, vous pouvez afficher les cartes et l’historique des changements des services. Par exemple, l’application peut surveiller les Gestion des événements performances de service et identifier les problèmes d’intégrité des services d’application.

Les services d’application peuvent être internes, comme le système de messagerie d’une entreprise, ou destinés aux clients, comme le site Web d’une organisation. Par exemple, la création de rapports financiers via une application Web nécessite un ordinateur, un serveur Web, un serveur d'applications, des bases de données, des logiciels intermédiaires et une infrastructure réseau. Les applications et les hôtes sont configurés pour offrir le service de génération de rapports financiers. Un service d’application représente une instance de ce type d’application ou système d’entreprise dans l’environnement de développement, de test ou de production.

Les services d’application sont les points d’entrée de la Mappage des services fonctionnalité. Les services d’application sous-tendent un service technique ou d’entreprise et sont mappés à la table Service d’application [cmdb_ci_service_auto] pour la CMDB génération de rapports communs.

Les services d’application sont des entités de relation clés pour Gestion des services informatiques (ITSM), Gestion des opérations informatiques (ITOM), Strategic Portfolio Management (SPM) et Gestion du service clientèle (CSM).

Les services d’application incluent les relations entre les applications d’entreprise, les services aux entreprises, les services techniques, les applications et les CI d’infrastructure. Vous pouvez exposer un service d’application à l’aide de l’offre de service technique ou d’entreprise connexe.

La table à laquelle un service d’application est mappé dépend de la méthode utilisée pour le créer :
Tableau 1. Méthodes mappées à des tables
Méthode utilisée pour créer le service d’application Mappé vers la table
Détection descendante (Service Mapping) cmdb_ci_service_discovered
Groupe de CI dynamique (basé sur une requête) cmdb_ci_query_based_service
Balises cmdb_ci_service_tags
Manuel (à l’aide du formulaire Créer un service d’application) cmdb_ci_service_discovered

Applications

Une application est un programme ou un module qui définit un comportement et exécute une fonction spécifique. Les applications sont généralement des instances détectables et fournissent un ensemble spécifique de fonctions pour un ou plusieurs services.

  • La table d’application et les tables étendues contiennent des instances de code détectées de façon unique en cours d’utilisation sur l’hôte.
  • Les applications sont considérées comme des CI d’infrastructure.
  • L’instance est limitée aux applications sur un seul hôte. Cette limitation garantit que les applications sont identifiées de façon unique lors de la détection.
  • Il existe une relation un-à-plusieurs (et non un-à-un) entre l’application et le service d’application. Une seule application installée, telle qu’une instance de base de données, peut prendre en charge plusieurs services d’application en fonction de la configuration et de l’utilisation des applications.
Remarque : La table d’applications [cmdb_ci_appl] n’est pas un inventaire ou un portefeuille de vos applications. Ne faites pas l’erreur de stocker les détails de l’application gérée dans la table des applications. Ces détails (objets d’inventaire ou de portefeuille des applications) appartiennent à la table des applications d’entreprise (comme documenté à la section Domaine de conception du CSDM cadre de travail).

CI d’infrastructure

Les CI d’infrastructure sont des composants physiques et logiques gérés. Un CI peut être un module unique, tel qu’un serveur, une base de données, un routeur, ou un système complet tel qu’un serveur Web, une base de données ou une infrastructure.

Les composants d’infrastructure ou CI sous-jacents peuvent être compliqués. La complexité augmente à mesure que les structures de données sont superposées aux CI physiques. C’est pourquoi vous devriez travailler avec un Business Relationship Manager ou un architecte d’entreprise pour définir vos options d’entreprise et vos applications d’entreprise.

Vidéos CSDM dans le ServiceNow Community

Liste de lecture de toutes les vidéos