Objectif
Le but de ce blogue est de fournir des conseils pratiques pour établir et utiliser une base de surveillance afin de donner une visibilité sur la santé et la performance des systèmes informatiques.
Public cible
Ce blogue s’adresse principalement à un public opérationnel TI responsable de fournir un soutien opérationnel continu et une gestion pour un environnement informatique typique, incluant la surveillance et les rapports.
Introduction
« Pourquoi n’avons-nous pas été alertés à l’avance? » Cette question (ou une dérivée) figure facilement parmi les 5 questions que j’ai entendues à plusieurs reprises au cours de ma carrière en consultation et en services gérés. La surveillance et l’alerte semblent constamment représenter un défi important pour la plupart des organisations TI, et plusieurs d’entre elles rencontrent plusieurs défis apparemment contradictoriques, comme obtenir une visibilité de bout en bout versus une visibilité profonde dans certains domaines mais une relative obscurité dans d’autres, la surveillance de l’infrastructure mais une connaissance limitée de l’expérience utilisateur (UX), et souvent avoir beaucoup (peut-être trop?) de métriques/données mais pas de contexte.
Certainement, ce ne sont pas des défis faciles à résoudre, et comme tout en TI, il faut une planification et une conception appropriées pour établir une solution de surveillance solide qui réponde aux besoins de l’organisation. Dans ce blogue, nous fournirons des conseils pratiques sur la façon de relever certains de ces défis en nous basant sur l’expérience de terrain et l’expertise technique. Notez que ce blogue est principalement écrit du point de vue de la surveillance Citrix, bien que les concepts soient applicables à la surveillance de composants/environnements non-Citrix.
Indicateurs qui comptent
Comme pour tout, la première étape est d’identifier les exigences; Dans ce cas-ci, ce que nous appelons les métriques qui comptent. C’est essentiel, car il existe une tonne de métriques à capturer, donc la vraie tâche est d’identifier uniquement celles qui sont vraiment importantes. Nous avons observé qu’une approche courante consiste à demander à chaque secteur TI (par exemple le stockage, le réseau, les services d’annuaire, les bases de données, etc.) de définir sa liste de métriques, puis de combiner toutes les métriques pour offrir une visibilité sur l’environnement global. Cela fonctionne, bien que dans une situation réelle, il arrive souvent qu’un problème affecte les utilisateurs; cependant, les métriques pour chaque zone TI individuelle sont toutes « vertes » (c’est-à-dire que les indicateurs de surveillance ne montrent aucun signe qu’il y a un problème, donc l’informatique n’est pas au courant tant que les utilisateurs ne signalent pas de problèmes).
Pour relever ce défi commun, nous aimons commencer par énumérer les services/fonctions utilisés par la communauté d’utilisateurs (par exemple connectivité, authentification, accès aux applications, etc.), puis identifier les systèmes qui collaborent pour permettre ces fonctions (par exemple pare-feu, WAN, AD, etc.), puis identifier les métriques qui indiquent la santé et la performance de ces systèmes. Un élément clé ici est aussi de surveiller les services et fonctions globaux des utilisateurs finaux, ce qui nécessite généralement un outil de surveillance permettant des transactions synthétiques. Cela est souvent facilité par l’organisation des systèmes en catégories traditionnelles d’infrastructure (IaaS), de plateforme (PaaS) et d’applications ou de services/fonctions pour les utilisateurs finaux (SaaS). Ensuite, pour chaque catégorie (couche de service), identifier les services/fonctions clés consommés par les utilisateurs finaux; notez que typiquement (mais pas toujours) la couche SaaS fournit des services/fonctions aux utilisateurs finaux, et que les couches IaaS et PaaS sous-jacentes fournissent des sous-services à la couche ci-dessus, comme illustré dans le diagramme suivant.
In addition to the abovementioned objective metrics, we also like to capture subjective feedback; one simple method involves surveys. An end-user survey may be distributed to capture end-users’ subjective feedback regarding their experience with using IT systems to do their daily jobs. The survey should be short (<10 questions) and should consist of multiple-choice questions (not freeform) so answers can be captured and stored in (for example) a database, which facilitates repeating the same survey in regular intervals (e.g. semi-annual) and comparing answers to spot trends/patterns (we use a 6-question multiple-choice survey designed for Citrix environments, with multiple-choice A-D answers organized to facilitate being able to easily spot poor, neutral, or positive trends). This is important, as it enables us to marry subjective feedback (end-user perceptions) with objective metrics.
En résumé, deux points clés à retenir de cette section sont :
- Surveillez les services/fonctions globaux pour les utilisateurs finaux, pas seulement les métriques typiques de « feu de circulation » associées aux composants informatiques courants.
- Capturez périodiquement des retours subjectifs et mariez-les à des indicateurs objectifs.
Concevoir une solution
Une fois les indicateurs importants (les exigences) identifiés, une bonne étape suivante est de concevoir la solution de surveillance appropriée. Durant cette phase, de nombreuses organisations ont tendance à inventorier les outils de surveillance internes pour voir quels outils peuvent être utilisés pour surveiller les services/fonctions et indicateurs des utilisateurs finaux identifiés lors de la collecte des exigences. Ensuite, une décision est prise quant à savoir si les exigences de surveillance peuvent être satisfaites uniquement avec des outils de surveillance internes ou si l’organisation doit investir dans un ou plusieurs nouveaux outils de surveillance.
Une fois l’outil ou les outils de surveillance identifiés, une bonne étape suivante consiste à documenter l’outil de surveillance qui sera utilisé pour surveiller chaque service/fonction et métrique de l’utilisateur final. Cela donne souvent lieu à une liste de fonctions et de métriques qui indiquent certaines fonctions/métriques pour lesquelles il n’existe pas d’outil de surveillance; c’est-à-dire des fonctions/métriques qui apparemment ne peuvent pas être surveillées. À ce moment-là, l’organisation peut décider d’accepter le risque ou de déterminer comment surveiller un ou plusieurs indicateurs particuliers, mais l’essentiel est que ce soit une décision consciente plutôt qu’un oubli.
Une fois cette liste documentée, une bonne étape suivante consiste à définir les valeurs des seuils métriques (typiquement, les seuils jaunes et rouges pour les avertissements et les erreurs, respectivement), ainsi que la liste des alertes qui seront déclenchées si ces seuils métriques sont dépassés. Lors de la définition des alertes, il est impératif d’éviter de créer des alertes qui, avec le temps, deviendront considérées comme du bruit blanc; Ainsi, il est généralement utile de les classer comme suit :
- Information – ces alertes informent d’un événement survenu ou d’autres données importantes à connaître, mais ne justifient pas une action immédiate ou de suivi.
- Avertissement – ces alertes avertissent d’un événement survenu qui indique souvent (symptôme) un problème ou un autre événement plus grave sur le point de survenir; Ces alertes méritent une enquête.
- Erreur – ces alertes informent qu’un problème s’est produit, qu’un composant a subi une défaillance de processus ou de service, etc.; Ces alertes justifient des mesures correctives immédiates.
Ce sont toutes des étapes nécessaires, et de nombreuses organisations sortent souvent de la phase de conception à ce stade; cependant, selon notre expérience, c’est aussi un bon moment pour définir comment la solution de surveillance s’intègre dans le processus global de gestion d’événements de l’organisation (du point de vue ITIL). La gestion des événements définit et régit la configuration des outils de surveillance, la création et la gestion des références, la définition et la réponse des alertes, les types et contenus des rapports, l’intégration avec d’autres processus opérationnels, ainsi que les rôles et responsabilités connexes. En l’absence d’un tel processus, suivre seulement quelques étapes clés peut souvent être très bénéfique (pour les organisations qui ont un processus de gestion d’événements mature, ces tâches sont généralement réalisées dans le cadre de la conception de la surveillance), comme suit :
- Lors de la documentation des alertes, documentez également l’action de réponse (c’est-à-dire l’action à prendre si/quand une alerte donnée est déclenchée), l’équipe ou les équipes responsables de l’action, et l’équipe ou les équipes notifiées (ces deux derniers éléments sont du point de vue RACI, afin d’identifier l’équipe responsable, responsable, consulté et informé).
- Déterminez comment les alertes s’intégreront au processus de gestion des incidents de l’organisation. Typiquement, les alertes d’information sont souvent mises en file d’attente dans un dépôt qui peut être référencé pour analyse, etc., mais ce n’est pas nécessaire pour une action immédiate. Les alertes d’alerte et d’erreur s’intègrent généralement au processus de gestion des incidents en étant utilisées pour créer automatiquement un billet d’incident dans le système de gestion des tickets de l’organisation. Typiquement, un tel billet d’incident est par défaut un Sev3 (sur une échelle de Sev1 à 4), est trié (examiné) et reclassifié (si nécessaire) par le Service Desk, puis traité via le processus de gestion des incidents (qui peut s’étendre à la gestion des problèmes, si une ou plusieurs alertes sont liées à un problème).
- Déterminez comment les alertes s’intégreront à la fonction DevOps de l’organisation, dans le but de définir et de mettre en œuvre une réponse automatisée aux événements clés qui déclenchent des alertes (par exemple, une alerte signalant une défaillance de service Windows peut tenter de redémarrer automatiquement le service).
The monitoring design should also define how a baseline will be established, reported against, maintained, and (over time) re-evaluated as necessary. To determine a baseline, one simple technique we have found effective (especially when taking a UX-centric approach) is to set threshold values based on what constitutes a “known good” user experience (UX). This essentially involves marrying objective metrics with subjective user feedback. To do so, based upon answers from end-user surveys, note if the overall trend reflects a poor, fair, or good user experience. Overlay these trends onto objective infrastructure/user-experience metric values, with the goal of organizing objective metric values into category ranges of poor, fair, and good values so that a range of metric values can be used to indicate a poor, fair, or good user experience. For example, a “poor” metric value range may include CPU and memory greater than 95% (>95%), a “fair” range may be 80-94%, and a “good” range may be less than 80% (<80%). Note that this is an overly simplistic example to illustrate the concept; this approach should be used to determine the baseline for all key metrics (e.g. disk queue length) and functions (e.g. user logon duration). This exercise should be repeated whenever a user survey is captured, so the baseline is refreshed and maintained over time, with the goal of being able to use objective metric values as a fairly accurate barometer of the likely user experience. This should be supplemented by running synthetic transactions (scripts) that are regularly initiated/performed by the monitoring tool(s) to perform various end-user tasks to validate that key end-user services are online/available (e.g. launching a Citrix Gateway session to open an application or VDI).
Pour résumer, les tâches clés de cette phase sont :
- Inventez l’outil de surveillance interne pour voir quels outils peuvent être utilisés pour surveiller les services/fonctions et métriques des utilisateurs finaux identifiés lors de la collecte des exigences.
- Documentez le(s) outil(s) de surveillance qui seront utilisés pour surveiller chaque service/fonction et métrique de l’utilisateur final.
- Définir les valeurs de seuil métriques (typiquement, les seuils jaunes et rouges pour les avertissements et les erreurs, respectivement), ainsi que la liste des alertes qui seront déclenchées si ces seuils métriques sont dépassés.
- Déterminez comment les alertes s’intégreront au processus de gestion des incidents de l’organisation.
- Définir comment une référence sera établie, rapportée, maintenue et (au fil du temps) réévaluée au besoin.
De plus, un résumé des principaux résultats de cette phase est le suivant :
- Liste (par exemple, feuille de calcul) des services/fonctions pour les utilisateurs finaux, des métriques, des seuils jaune/rouge, des alertes, de la catégorie d’alerte, de l’action de réponse à l’alerte, des équipes avisées et responsables d’agir si/quand une alerte est déclenchée, ainsi que des outils de surveillance utilisés pour surveiller chaque métrique et service/fonction pour l’utilisateur final.
- Liste d’alertes qui créeront automatiquement des tickets d’incident dans le système de gestion des tickets, et décision concernant la gravité spécifique de l’incident (par exemple, Sev3). Indiquez aussi la file d’attente spécifique dans laquelle ces billets d’incident seront créés (par exemple, une file « Événements » où le gestionnaire d’événements de l’organisation peut enquêter/trier et réattribuer ces billets à la file d’attente de l’équipe concernée).
- Sondage auprès des utilisateurs finaux qui servira à recueillir les retours subjectifs de l’expérience utilisateur final (UX) (idéalement, il s’agirait d’un sondage à choix multiples).
Surveillance de la configuration
Une fois la solution de surveillance correctement conçue, le(s) outil(s) de surveillance peut être configuré en utilisant la conception comme plan. Les tâches clés de cette phase sont de configurer l’outil de surveillance pour surveiller les objets/compteurs (métriques), les seuils de métriques, les alertes, etc. Le résultat de cette phase devrait être une solution de surveillance opérationnelle utilisée pour surveiller la santé et la performance de l’environnement, déclencher des alertes au besoin, et créer automatiquement des tickets d’incident pour les alertes classées comme avertissements et erreurs. Puisque cette phase implique la configuration/mise en œuvre manuelle de la solution de surveillance, elle peut aussi inclure le choix d’un nouvel outil de surveillance si les besoins de surveillance/alerte ne peuvent être satisfaits par les outils internes existants.
Il existe de nombreux outils de surveillance, donc l’outil de surveillance dépend de la capacité de l’outil à répondre aux exigences de la conception de la surveillance. Dans Ferroque Systems, nous utilisons ControlUp, car il s’intègre directement aux technologies Citrix (y compris Citrix Cloud et NetScaler), aux plateformes d’hyperviseurs (VMware, Hyper-V, Nutanix, etc.), aux clouds publics (Azure, AWS) et aux composants d’infrastructure traditionnels. ControlUp dispose également d’une communauté de rechange saine qui a développé une vaste bibliothèque de scripts disponibles pour automatiser de nombreuses tâches et étendre les capacités de surveillance, et qui s’intègre à divers systèmes de billets pour créer automatiquement des tickets d’incident et générer des alertes par courriel.
Les actions/tâches spécifiques requises pour configurer la solution de surveillance varieront selon l’outil ou les outils de surveillance utilisés. La mise en œuvre de l’outil de surveillance doit être documentée afin de maintenir une documentation de configuration telle quelle, car nous avons observé qu’il est souvent tout aussi important que les organisations soient informées de ce qui est surveillé que de savoir ce qui ne l’est pas (pour maintenir un compte précis de l’exposition globale au risque). Idéalement, la documentation inclurait une vue arborescente de tous les systèmes qui montre la ligne de vue entre les services aux utilisateurs finaux et les composants informatiques individuels. Ce n’est pas obligé d’être un diagramme physique massif, mais il devrait au moins indiquer des relations clés 1 :M où, si un composant subit une panne, plusieurs autres composants/services seraient affectés. L’objectif est que l’organisation soit consciente que si (par exemple) un serveur de fichiers est hors ligne, elle puisse « parcourir l’arbre » pour identifier d’autres composants/services (généralement « en montée ») qui pourraient subir une dégradation ou une panne de service. De nombreux outils de surveillance le font automatiquement en tentant de détecter automatiquement les composants dans l’environnement, bien qu’il y ait presque toujours un certain niveau d’ajustement manuel nécessaire pour améliorer la précision.
Un point important ici : pour rendre la solution plus complète, l’objectif ultime devrait être de relier la solution de surveillance aux fonctions clés de l’entreprise. Par exemple, le paragraphe ci-dessus suggère la capacité de « marcher dans l’arbre » pour identifier les services qui subiraient une dégradation ou une panne si un composant de bas niveau venait à être hors ligne; idéalement, ces services devraient inclure des fonctions clés de l’entreprise, telles que la chaîne d’approvisionnement ou les fonctions RH, qui peuvent ensuite être reliées aux propriétaires de fonctions d’entreprise afin que la ou les bonnes personnes puissent être informées d’une possible dégradation ou d’une panne de la ou des fonctions d’entreprise dont elles sont responsables.
Une fois la solution de surveillance configurée, avant que cette phase ne soit considérée comme terminée, la solution doit être testée pour valider les bons composants et services surveillés, les valeurs seuils des métriques sont précises, les alertes s’activent comme prévu, etc. Cela implique souvent des tâches comme mettre hors ligne un serveur, faire échouer un service Windows, mettre hors ligne un site Gateway Citrix, etc., donc il faut planifier cela afin de minimiser le risque de perturbation de l’utilisateur final.
Établir une base de référence
Une fois la solution de surveillance configurée, il est recommandé de la laisser fonctionner pendant 4 à 5 semaines afin que l’organisation ait l’occasion de vérifier que la solution fonctionne comme prévu et de comprendre le niveau d’ajustement fin nécessaire pour minimiser le bruit blanc. Pendant ce temps, le sondage auprès des utilisateurs finaux devrait être distribué, et les commentaires des utilisateurs devraient être recueillis et examinés; Ce type de rétroaction devrait être traité avant ou avant la fin des 4 à 5 premières semaines suivant le déploiement de la solution de surveillance (afin qu’il soit disponible au moment de définir ou d’établir une base de santé et de performance des systèmes).
L’objectif d’une référence de santé et de performance des systèmes est de fournir un point de comparaison permettant aux TI d’avoir une visibilité sur si/combien la performance continue des systèmes peut s’améliorer ou se dégrader au fil du temps, et ce benchmark devrait être directement lié à l’expérience utilisateur finale (UX). Une référence devrait représenter un niveau de performance « connu comme bon », afin de permettre aux TI d’utiliser des valeurs objectives de métriques comme baromètre assez précis de l’expérience utilisateur finale probable, afin que les TI puissent prendre des mesures appropriées (et idéalement, proactives) pour gérer l’environnement afin de maintenir une expérience utilisateur cohérente.
Pour établir la base, le service informatique devrait analyser les retours de l’enquête auprès des utilisateurs finaux et ajuster les seuils jaunes/rouges pour les métriques cibles à la hausse ou à la baisse ou les laisser telles quelles. Dans des situations où les commentaires d’enquête indiquent une mauvaise expérience utilisateur en raison d’une performance lente (un scénario très courant), il n’est pas toujours possible d’ajouter de la capacité pour améliorer la performance. Dans ces situations, une technique que nous avons observée est de réserver 2 à 3 serveurs Citrix (VDA) pour permettre un peu moins d’utilisateurs/serveurs afin de déterminer combien d’utilisateurs peuvent être supportés confortablement avant que les utilisateurs ne commencent à remarquer un impact sur la performance (notez que ces chiffres peuvent varier selon les applications/etc. hébergées). Une fois ce nombre d’utilisateurs/serveur déterminé, capturez les valeurs des métriques surveillées et utilisez ces valeurs comme valeurs de référence. Ensuite, remettez les serveurs en usage normal (ce qui devrait montrer que les valeurs des métriques dépassent la ligne de référence, et continuera jusqu’à ce que de la capacité supplémentaire soit disponible).
À l’avenir, la référence devrait être réévaluée annuellement (par exemple en envoyant le même sondage utilisateur final pour comparer les retours aux avis précédents, et en ajustant les seuils des métriques en conséquence) ou après une mise à niveau importante ou un déploiement de nouveaux systèmes (par exemple, après la mise à niveau du système Windows, car les systèmes d’exploitation plus récents consomment souvent plus de ressources de calcul, donc la perception de la performance par les utilisateurs finaux peut diminuer si la capacité n’est pas également augmentée). Une fois établie, la référence devrait être incluse dans les rapports et, lors de l’examen des métriques pour une analyse historique, afin de fournir un contexte aux valeurs des métriques (en l’absence de ce contexte, il est souvent difficile de déterminer si les valeurs examinées représentent une amélioration, une dégradation ou un statu quo).
Le résultat clé de cette phase est l’établissement d’une base de santé et de performance des systèmes, ainsi que d’un processus de maintenance périodique continue et de réévaluation/ajustement de la référence au fil du temps.
Corrélation et rapport
En plus d’activer l’alerte avancée, l’utilisation principale d’une solution de surveillance est de générer des rapports qui décrivent la santé globale et la performance de l’environnement. Dans les solutions de surveillance populaires (telles que ControlUp, Goliath, SolarWinds, etc.), les différentes possibilités de reporting sont infinies et dépassent le cadre de ce blogue; Au lieu de cela, ce blogue se concentrera sur quelques-unes des techniques de reportage que nous avons observées afin d’apporter des perspectives supplémentaires.
Une technique consiste à exporter des données vers Microsoft Excel, puis à utiliser Excel pour organiser les données de façon à faciliter l’analyse et à fournir des informations rarement accessibles dans les rapports préfabriqués courants. Par exemple, le rapport sur la durée de connexion Citrix est très courant et est le plus souvent représenté sous forme de graphique linéaire, ce qui est certainement utile. Au-delà de cela, nous avons aussi trouvé utile d’utiliser un diagramme de dispersion pour représenter visuellement les valeurs de la durée de connexion individuelle par rapport à la durée moyenne de la connexion, ce qui facilite la vision du pourcentage de sessions ayant connu une durée de connexion plus proche de la durée moyenne que de la durée maximale, et donc quelles valeurs peuvent être considérées comme normales ou anomalies. Par exemple, le graphique linéaire ci-dessous illustre un graphique typique de durée de connexion et montre clairement qu’il y a eu des cas de durée de connexion excessive; Cependant, il n’indique pas combien d’instances de durée excessive de connexion sont survenues, ce qui est mieux indiqué par le diagramme de diffusion qui suit (qui montre clairement plusieurs valeurs aberrantes mais que la grande majorité est regroupée autour de la plage de 50 secondes).
L’organisation des données dans Excel permet aussi de créer des graphiques qui ne seraient pas possibles autrement avec la majorité des outils de rapports par défaut, et permet aussi des techniques telles que le tracé de métriques sur un axe secondaire pour faciliter la représentation des corrélations entre plusieurs ensembles de données, comme illustré dans l’exemple de graphique suivant pour Citrix Gateway.
Une autre technique importante (mais souvent négligée) est de créer des rapports qui parlent le langage de l’entreprise (c’est-à-dire pas seulement des rapports destinés à un public informatique), en adaptant le contenu des rapports pour résonner auprès des responsables fonctionnels de l’entreprise. Par exemple, un rapport de surveillance traditionnel montre un graphique linéaire du processeur, de la mémoire et des valeurs similaires, mais la plupart des dirigeants d’entreprise ne pourront pas tirer de conclusions significatives à partir de tels rapports (pas plus qu’un administrateur TI ne pourrait tirer des conclusions pertinentes d’un rapport d’affaires montrant le coût/widget et combien de widgets par semaine ont été produits). Comme mentionné précédemment, le contexte est essentiel pour créer des rapports convaincants. Ainsi, plutôt que de présenter des graphiques linéaires traditionnels « feu de circulation », ces rapports de surveillance devraient être adaptés pour résonner auprès des dirigeants d’entreprise en incluant, par exemple, du contenu indiquant que la consommation de ressources de calcul sur les serveurs hébergeant des applications de la chaîne d’approvisionnement est stable et peut accueillir deux utilisateurs supplémentaires avant que des fonds supplémentaires ne soient nécessaires pour ajouter un serveur supplémentaire, Et il faut environ deux semaines pour se procurer et mettre en place un nouveau matériel serveur. Désormais, la responsable de la chaîne d’approvisionnement peut se référer à ses prévisions de ventes de produits pour déterminer si elle doit embaucher plus de personnel, et peut informer les TI à l’avance pour s’assurer que la capacité est disponible pour du personnel supplémentaire. C’est un exemple simplifié, mais il illustre le concept de la façon dont de bons rapports peuvent faciliter la capacité des dirigeants d’entreprise à mieux planifier et prendre des décisions.
Une technique supplémentaire consiste à faire inclure les valeurs seuils de référence, jaunes et rouges sur les graphiques, afin de donner du contexte et permettre au public de mieux comprendre si les indicateurs représentent une amélioration, une dégradation ou un statu quo. Par exemple, sur les rapports contenant des graphiques linéaires, la valeur de référence ainsi que les seuils jaunes et rouges pourraient être représentés sous forme de pointillés aux valeurs cibles de l’axe des Y.
Ces deux dernières techniques mettent en lumière un concept important : les rapports de surveillance doivent fournir de l’information, pas seulement des données. Selon ITIL, il y a quatre couches : données, information, connaissance et sagesse (DIKW). Les données ne sont que des données brutes, ce qui est utile mais pas nécessairement éclairant à moins que le public ait déjà une bonne compréhension des données. Mettre en évidence les relations entre données, établir des corrélations et des conclusions, etc., fournit au rapport de l’information. Par exemple, les graphiques de durée de connexion ci-dessus fournissent des données; inclure du contenu correspondant en utilisant un langage qui résonne avec l’entreprise fournit de l’information (comme dans l’exemple simple ci-dessus); et tirer parti de l’expérience sur le terrain pour ajouter du contenu fournissant du leadership d’opinion (des conseils) sur la façon de réduire la durée de connexion pour les cas de durée excessive fournit des connaissances. En règle générale, les rapports devraient au moins fournir de l’information, pas seulement des données, et s’efforcer de fournir des connaissances autant que possible.
En conclusion
Il y a beaucoup de contenu en ligne facilement accessible qui offre un aperçu complet de la façon de mettre en œuvre la surveillance, l’alerte et les rapports de base; Ce blogue suppose une connaissance de base de ces tâches et se concentre plutôt sur plusieurs techniques clés pour améliorer le processus de définition et de mise en œuvre d’une solution de surveillance efficace, établir et maintenir une base de référence directement liée à l’expérience utilisateur finale, et créer des rapports pertinents qui résonnent avec le public cible, dans le but ultime d’obtenir de meilleurs résultats. Nous avons souvent utilisé et utilisons ces mêmes techniques dans Ferroque Systems, et espérons que leur partage ici apportera des informations qui aideront les organisations à améliorer leur solution de surveillance, que ce soit en effectuant une refonte complète de la surveillance ou en cherchant des gains marginaux pour une solution existante.
