Notes de version de Opérations pour la fiabilité des sites
Historique des versions de Site Reliability Operations sur le ServiceNow Store.
Important :
Pour plus d'informations sur la configuration système requise et la compatibilité des familles, consultez la liste des applications sur le site Web ServiceNow Store.
Historique de version
- Version 14.2.2 - Janvier 2024
- Modifié : accès modifié pour devenir une approbation uniquement afin de décourager d’autres téléchargements et d’encourager les téléchargements de la nouvelle application de l’App Store Gestion de la fiabilité des services.
- Correctifs liés à l’interface utilisateur.
- Version 14.2.1 - Août 2023
- Fixe:
- Problèmes associés au générateur de conditions dans le flux de création de conditions de règle d’alerte.
- Problème lié à la sélection de service sur la page Relations de service.
- Autres corrections mineures.
- Fixe:
- Version 14.2.0 - Novembre 2022
- Nouveau :
- Ajout de la prise en charge de l’affichage des services commerciaux et techniques dédiés dans Opérations pour la fiabilité des sites.
- Ajout de la prise en charge de la localisation.
- Fixe:
- Actualisez la page Dépendance de service lorsqu’un service est supprimé.
- Mettez à jour une table de suivi d’escalade d’astreinte comme Accepté avec les fonctions vocales lorsqu’un utilisateur accepte une affectation via un appel vocal.
- Capturez l’état Accepté dans une table de suivi d’escalade d’astreinte lorsqu’un utilisateur accepte une affectation via un appareil de notification pour les fonctions vocales.
- Arrêtez d’autres rappels lorsque l’affectation d’enregistrement est rejetée par un appareil de notification pour l’e-mail primaire.
- Nouveau :
- Version 14.1.1 - Mai 2022
- Correction : Plusieurs bogues, dont les suivants :
- Correction d’un problème où les services d’application créés par l’utilisateur à partir de Site Reliability Operations (SRO) étaient automatiquement définis sur Non opérationnel après la création.
- Correction d’un problème où l’administrateur ou le gestionnaire SRO ne pouvait pas afficher le calendrier d’astreinte sur SRO.
- Correction : Plusieurs bogues, dont les suivants :
- Version 14.0.2 - Décembre 2021
- Correction : Correction des problèmes de compatibilité avec la planification d’astreinte.
- Version 14.0.0 - Juillet 2021
- Nouveau :
- En plus de permettre aux équipes de gérer les services d’application, Opérations pour la fiabilité des sites (SR Ops) permet désormais aux équipes de gérer les services techniques créés à partir de groupes de CI dynamiques dans Gestion des opérations IT. Cela permet aux équipes de gérer un groupe de CI qui ne sont pas mappés à un service d’application comme s’il s’agissait d’un service. Ces services techniques sont créés par le service informatique central pour le compte de l’équipe SRE. Les services techniques ne peuvent pas être créés ou supprimés directement dans SR Ops.
- Les actions d’intégration sont désormais des règles d’alerte. Les règles d’alerte sont un système plus complet qui permet de créer de nouveaux types de règles sur les services ainsi que sur les éléments de configuration (CI) ayant un impact sur les services. Remarque : pour les options Service + CI et CI, la règle d’alerte se déclenche uniquement si le CI est un enfant direct du service ou du service technique (tout élément de profondeur supérieur à un niveau ne déclenche pas la règle). Par exemple, les groupes dynamiques avec des groupes dynamiques imbriqués ne déclencheront pas la règle.
- Changé:
- SR Ops n’a cessé de passer à une expérience réservée à l’espace de travail. Cette version a terminé cet effort à quelques exceptions près. Les modules d’interface utilisateur classiques pour la gestion des conditions, des actions et des configurations pour les règles d’alerte ont été conservés, car ces formulaires contiennent des champs qui ne sont pas entièrement compatibles avec l’espace de travail. Tous les autres modules de l’interface utilisateur classique ont été supprimés et certaines actions ne sont plus prises en charge dans l’interface utilisateur classique. Par exemple, la création de nouveaux services d’entreprise et d’application ne peut plus être effectuée dans l’interface utilisateur classique.
- Dans une chaîne de règles d’alerte, la première condition de règle d’alerte est évaluée à chaque changement apporté à l’alerte afin qu’elle puisse s’exécuter ultérieurement lorsque cette condition correspond.
- Fixe:
- Une « erreur interne du serveur » s’affiche lorsqu’un utilisateur supprime des services d’application de la carte des relations
- « Erreur interne du serveur » s’affiche si un utilisateur ajoute une relation de service à un service existant avec un nom en double CI impacté L’erreur « Service non disponible » est renvoyée sur la page d’accueil si une équipe compte des milliers de membres
- Un groupe de support est supprimé du service enfant si un utilisateur crée une relation entre deux services existants Impossible de supprimer un service de la carte des relations de service après la suppression d’un service Niveau de service Les enregistrements de règle d’alerte ne sont pas supprimés des tables de règles de gestion des alertes lorsque le service est supprimé
- La fonctionnalité Supprimer de la carte ne fonctionne pas correctement entre les services d’entreprise et les services d’application
- Niveau de service Les règles d’alerte ne sont pas supprimées automatiquement lors de la suppression du service Le responsable SRO n’est pas en mesure de voir les équipes de tous les groupes Divers problèmes d’actualisation
- Mise à niveau : le champ Condition est maintenant obligatoire sur les règles d’alerte. Si vous avez d’anciennes règles d’alerte qui n’ont pas de conditions, elles fonctionneront toujours.
- Désinstallation : règles d’alerte : la désinstallation de Opérations pour la fiabilité des sites ne supprimera pas les règles d’alerte qui ont été créées dans le système.
- Problèmes connus : Connecteurs EM : problème lorsque les clients s’exécutent sur site à l’aide de la base de données Oracle. Les clients s’exécutant sur site avec Oracle DB ne doivent pas utiliser cette version de SR Ops. Solution : aucune (pour l’instant). Si Notification n’est pas configurée correctement, au Québec, les notes de travail d’une alerte peuvent signaler par erreur que des notifications ont été envoyées alors qu’elles ont échoué.
- Nouveau :
- Version 13.0.0 - Avril 2021
- Nouveau :
- Nouvelle expérience utilisateur des actions d’intégration.
- Nouvelle action pour envoyer des notifications d’alertes à un canal Slack existant.
- Nouveau connecteur EM pour Grafana.
- Mes calendriers d’astreinte ajoutés aux listes d’espaces de travail.
- Fixe:
- Le champ d’alerte CI est désormais renseigné lors de l’utilisation du connecteur push Azure Monitor.
- Les utilisateurs seront désormais avertis lorsqu’ils demanderont une équipe en double.
- Correction d’un problème de bouclage lorsqu’aucune astreinte n’est configurée et que l’utilisateur rejette l’alerte/l’incident.
- Correction de problèmes lors de la suppression complète des actions d’intégration.
- Problèmes connus :
- Connecteurs EM : problème lorsque les clients s’exécutent sur site à l’aide de la base de données Oracle.
- Les clients s’exécutant sur site avec Oracle DB ne doivent pas utiliser cette version de SR Ops.
- Nouveau :
- Version 12.0.0 - Mars 2021
- Nouveau :
- SR Ops prend désormais en charge le Québec.
- Mise à jour du mécanisme de suivi de l’escalade d’astreinte.
- Le traitement de l’action d’alerte est basculé en arrière-plan vers la nouvelle application Gestion des règles d’alerte.
- Fixe:
- Le lien Supprimer l’offre de services n’est plus disponible dans le menu de débordement lorsque Gestion des portefeuilles de services (SPM) est activé.
- Les utilisateurs ne seront plus en mesure de supprimer un élément de configuration (CI) si l’élément est utilisé ailleurs dans SR Ops.
- Les utilisateurs ne seront plus en mesure de supprimer un élément de condition si l’élément est utilisé ailleurs dans SR Ops. Lorsqu’un utilisateur clique sur le bouton Nouveau à partir de l’onglet Intégrations du formulaire de service, l’onglet Détails s’affiche.
- Lorsqu’un utilisateur modifie le champ Action sur le formulaire Actions d’intégration, le champ Configuration est alors effacé.
- Lorsque le nombre de changements entrants est élevé, le nombre de cartes Changements ouverts indique alors la valeur correcte.
- Connecteurs EM : problème lorsque les clients s’exécutent sur site à l’aide de la base de données Oracle. Les clients s’exécutant sur site avec Oracle DB ne doivent pas utiliser cette version de SR Ops.Solution de contournement : aucune (pour l’instant).
- Connecteur push Azure : l’élément de configuration (CI) sur l’alerte n’est pas renseigné. Solution : utilisez l’action de service Définir pour définir le champ CI sur l’alerte.
- Nouveau :