Planification de la remédiation
Une plateforme APM permet aux administrateurs cloud d’identifier les problèmes, mais elle ne résout pas ces problèmes à leur place. Par exemple, si vous savez qu’un appel distant à une base de données prend 10 fois plus de temps que ce qu’il devrait, que se passe-t-il ensuite ? Guidez-vous vos collègues du développement logiciel vers une solution, ou ouvrez-vous un ticket de réclamation et comptez-vous sur le fait qu’ils vont y travailler d’eux-mêmes ?
La planification de la remédiation est le processus par lequel vous définissez la façon dont les problèmes découverts par la supervision sont atténués et résolus. La remédiation peut être réactive, auquel cas elle est déclenchée par des événements exposés par une APM, ou elle peut être proactive, auquel cas l’objectif est d’apporter continuellement des améliorations à un système même en l’absence d’erreurs d’autres événements critiques. Dans un nombre croissant d’entreprises, la remédiation n’est plus simplement une réponse à un problème. Il n’est pas nécessaire quelque chose fonctionne mal pour l’améliorer.
Gestion des problèmes via des tickets
Le cycle de travail de nombreux services informatiques s’articule autour de tickets. Il s’agit d’un système qui automatise la distribution des demandes adressées au service informatique : un administrateur peut ainsi surveiller les réponses apportées à toutes les demandes conformément aux priorités, aux nécessités et aux ressources disponibles. De nombreuses organisations investissent dans un système de gestion de tickets qui standardise ce processus, souvent appelé ITOM (IT Operations Management, Gestion des opérations informatiques). Une telle suite comprend souvent des fonctionnalités permettant de répondre aux alertes au fur et à mesure qu’elles sont générées, en particulier par une plateforme APM. Dans certains cas, une APM peut déclencher la génération de tickets de problème.
Un des problèmes avec les plateformes qui activent les alertes et les notifications est comment intégrer au mieux le processus de notification au cycle de travail de l’administrateur. Tout l’enjeu après la notification d’un problème est de déclencher une action corrective. Dans l’idéal, un système d’alerte déclenche une réaction automatisée qui applique une stratégie - c’est-à-dire la réponse appropriée déterminée à l’avance - à la solution. Une telle stratégie peut déterminer si un problème détecté justifie un ticket de problème : certains systèmes automatisés peuvent en générer un automatiquement.
La gestion par tickets est utile pour appliquer autant d’automatisation que possible et autant de surveillance que nécessaire, pour répondre aux problèmes survenant dans des applications, dans le réseau ou dans l’infrastructure, au fur et à mesure qu’ils se produisent. Paradoxalement, la gestion par tickets peut finir par installer l’idée que toutes les opérations informatiques sont axées sur la résolution de problèmes et consistent à attendre que quelque chose se passe mal.
Plus récemment, les fournisseurs et les partisans des outils et des plateformes APM ont développé un contre-argument, qui revient à éloigner les opérations informatiques de la simple gestion des problèmes pour les orienter vers des objectifs. L’argument se présente comme suit : L’objectif final des APM est de représenter les performances des systèmes informatiques de l’entreprise relativement à son impact sur les objectifs métier. Quand le dirigeant surveillant une division ou le responsable d’un secteur d’une ligne de produits constate dans quelle mesure les performances sont liées au chiffre d’affaires ou à la production, il est plus susceptible d’encourager les travaux et les dépenses pour maintenir des niveaux de performances durables.
Un administrateur peut se voir lui-même expliquer à un responsable pourquoi une partie d’un système doit être redéveloppée ou améliorée, en des termes que cette personne pourra comprendre. Cette partie du travail est souvent appelée « alignement » des métriques de performances avec les objectifs métier : des conférences entières sont consacrées à ce sujet. Cependant, avant que l’alignement puisse se faire, le processus de supervision doit révéler de manière quantifiable la dynamique de la solution cloud.
Indicateurs de performance clés
Les fournisseurs d’APM conseillent souvent à leurs clients d’adopter quelques indicateurs de performance clés (KPI). Il s’agit de métriques individuelles généralement conçues pour déclencher des avertissements ou des alertes quand leurs valeurs se situent au-dessus ou au-dessous de niveaux prédéterminés. L’objectif des indicateurs de performance clés est de permettre à un tableau de bord personnalisé de communiquer rapidement un message indiquant que quelque chose se passe mal ou risque de mal se passer.
De nombreuses plateformes APM utilisent des métriques qu’elles appellent « indicateurs de performance clés », mais qui sont en fait seulement des métriques du point de vue de l’opérateur informatique. Pour les entreprises qui l’utilisent dans la supervision des performances, un indicateur de performance clé est une valeur quantifiable1 qui représente un aspect des performances, car il appartient à au moins deux de ces catégories :
Intégrité du système
Progression relative dans la satisfaction des objectifs métier
Satisfaction de l’utilisateur final quant au système
Efficacité du service informatique dans la résolution des problèmes
Les responsables d’entreprise peuvent s’attendre à ce qu’un indicateur de performance clé prenne en compte des facteurs externe à l’informatique, notamment des données liées aux opérations métier. Voici quelques exemples d’indicateurs de performance clés applicables à la supervision des performances :
Temps consommé lors de la saisie de données dans un formulaire : une fois que les temps de traitement des transactions et des demandes sont éliminés, ce qui reste est le temps passé par les utilisateurs individuels à comprendre la signification du formulaire (ou à trouver cela ennuyeux et à commencer par sortir boire une tasse de café)
Pourcentage d’examens du catalogue aboutissant à des commandes, qui révèle l’efficacité d’un système de e-commerce pour la vente de ses produits et services
Temps moyen de détection (MTTD, Mean Time to Detection) : intervalle de temps entre le moment où une erreur ou un autre problème du système s’est produit et le moment elle a été détectée
Temps moyen de résolution (MTTR, Mean Time to Resolution) : intervalle de temps entre le moment où un problème a été détecté et le moment où il a été résolu
Pourcentage des modifications apportées dans le système bloquées par d’autres problèmes : un indicateur de la façon dont les problèmes de performances peuvent affecter d’autres services, et dans quelle mesure des projets plus étendus et plus complets pour diminuer les problèmes doivent être pris en compte.
Notez que les véritables indicateurs de performance clés ont tendance à être davantage centrés sur le comportement de l’utilisateur que sur le comportement du système. Ceci en conduit beaucoup à penser qu’une analyse du système d’information ne doit pas jouer un rôle dans la détermination des indicateurs de performance clés. Ceci ignore cependant le fait que le comportement du système détermine le comportement de l’utilisateur.
Conception de nouveaux indicateurs de performance clés
Certains analystes ont défendu le fait que les APM centrées sur l’informatique tendent à se concentrer sur des métriques différentes de celles sur lesquelles les véritables indicateurs de performance clés seraient basés. Sur cette base, ces analystes ont recommandé certains packages de gestion d’indicateurs de performance clés à leurs clients. Leur argument est que les métriques de performances réseau traitent le workflow du point de vue de l’infrastructure, qui peut ou non s’aligner avec le point de vue de l’utilisateur final.
Un autre point de vue est que l’organisation elle-même est la meilleure source de bon sens pour déterminer les indicateurs de performance clés sont les plus applicables à son activité, car ses dirigeants, et non pas ses logiciels, sont responsables de la définition des objectifs de l’entreprise. À cette fin, un processus émerge dans toute organisation pour développer des indicateurs de performance clés pour sa propre utilisation interne :
Rassembler les équipes disparates. La tâche de définition des priorités et des objectifs ne doit être déléguée à une équipe sans consulter les autres équipes.
Définir collectivement les priorités de l’entreprise. Les « temps de chargement des pages web très rapides » sont un objectif constant pour les systèmes informatiques, mais ce sera toujours le cas. Quels sont les objectifs les plus pertinents de l’organisation pour lesquels son système d’information joue un rôle directement contributeur ?
Quantifier les paramètres des objectifs de l’entreprise. Déterminez lesquelles parmi ces priorités peuvent être supervisées et mesurées numériquement, de façon vérifiable.
Établir des objectifs pour l’entreprise. Écrivez les formules pour les relations entre des facteurs mesurables et observables, et les valeurs optimales pour ces formules, d’une manière simple et mathématique, que toutes les parties prenantes peuvent comprendre.
Intégrez le système de gestion via des tickets ou d’autres fonctions automatisées impliquées dans la résolution des problèmes, afin que les projets d’amélioration du système pour les objectifs de l’entreprise puissent coexister avec les problèmes de performances et les problèmes des logiciels.
Dédiez la plateforme de supervision des performances à la tâche de collecte des métriques pertinentes relatives aux objectifs d’entreprise qui ont été établis. Là où c’est applicable, faites en sorte que des tableaux de bord remontent continuellement ces métriques sous des formes simples et graphiques.
Dans un environnement de travail où les applications de stratégie et la génération de tickets peuvent être automatiques, l’objectif du tableau de bord de la plateforme APM change. Il devient un résumé de l’état actif du système de remédiation et une jauge de la vitesse à laquelle le système peut récupérer suite à un problème de performances.
Remédiation quotidienne
La doctrine fondamentale d’une planification de la remédiation moderne en informatique est que l’état de l’infrastructure, des services et des applications de l’organisation peut être continuellement amélioré dans le cadre d’un processus connu sous le nom de remédiation quotidienne ou remédiation continue. Un certain nombre de principes découlent de cette doctrine :
Plus rien n’est « normal ». De la même façon que les gens deviennent en bonne santé et le restent en s’occupant tous les jours de leur propre bien-être, il n’y a ici plus de zone permanente de normalité définissant le comportement d’un réseau comme si ce réseau ne devait jamais changer. L’objectif des niveaux de service devient une cible mouvante. Dans la nature, ce concept est appelé « évolution ».
Les bouleversements massifs peuvent être évités si de petits changements sont apportés en permanence. Les environnements intermédiaires des applications cloud prennent place sur des réseaux définis par voie logicielle. Leurs plateformes hôtes peuvent effectuer ou suggérer des ajustements à apporter à ces réseaux pour améliorer leurs performances. Les données des plateformes APM donnent aux administrateurs des conseils quant aux améliorations susceptibles d’être apportées aux communications et aux interactions entre les services.
Une connaissance pratique du système est plus enracinée dans l’esprit de tous ceux qui sont affectés à son entretien. De nombreuses APM permettent à leurs opérateurs d’examiner les rapports de base des événements système, et d’explorer leurs causes et leurs effets sous-jacents. Si les personnes comprennent mieux ces interdépendances avant de se lancer dans la recherche des causes racines des défaillances, ils auront une meilleure idée de ce qu’il faut rechercher et de l’endroit où les rechercher quand des défaillances se produisent.
L’équipe de sécurité et l’équipe des opérations doivent travailler ensemble de façon permanente. Les problèmes de performances sont, à certains niveaux, des problèmes de sécurité, en particulier dans la mesure où ils peuvent être exploités. Une approche de remédiation pour les performances est comme une approche de résilience pour la sécurité : Les deux sont proactives et non pas réactives, et toutes deux impliquent des améliorations continues d’une solution.
Un avantage final de la remédiation quotidienne est que les dirigeants et les responsables extérieurs au service informatique sont plus susceptibles d’y adhérer. Les personnes en responsabilité apprécient quand le personnel qu’ils gèrent prennent soin de ce qui les intéressent eux-mêmes. Dans de nombreuses organisations, les personnes occupant ces positions sont celles qui sont chargées de créer des plans conduisant au succès ; les professionnels de l’informatique sont ceux dont on attend qu’ils répondent aux défaillances. Les conférences pour professionnels promeuvent des exposés sur l’« alignement des objectifs de l’entreprise ». La remédiation quotidienne offre la possibilité de le réaliser.
Références
- De nombreuses organisations utilisent également le concept d’indicateur de performance clé pour effectuer des mesures objectives de la progression de l’entreprise et de l’efficacité des employés, qui se trouvent en dehors du domaine des APM.