Justifier la GPA en entreprise
Comme ceux qui ont travaillé dans un service informatique en entreprise le savent, les bons outils sont trop souvent gaspillés. Parfois, l'outil ne correspond pas aux attentes ou aux exigences ; parfois, le porteur de l'outil quitte l'organisation ; parfois encore, la technologie devient obsolète juste après que le vendeur soit racheté ou que le produit soit mis au rebut. C'est également vrai pour les outils appartenant à l'écosystème des GPAs. Il n'y a aucune solution toute faite à ce problème, mais si votre métier est l'acquisition d'outils de GPA, il existe certaines étapes à suivre pour rendre moins probable que votre logiciel reste sur une étagère. Voici quelques-unes des leçons que j'ai apprises au cours de ma carrière d'architecte chargé de la surveillance et d'acheteur de GPA.
1. Documenter ce qui fait mal
Personne n'acceptera de dépenser de l'argent pour acquérir un outil, sauf s'il existe un problème dommageable au métier (par exemple, perte de revenus, impact sur laa productivité, satisfaction client). Si vous voulez justifier une acquisition, il faut trouver un problème tangible et le répertorier. Il devra s'agir de manière préférentielle d'une application critique pour le métier, comme une plate-forme de commerce électronique, une application de courtage en-ligne, une passerelle de paiement, un moteur de calcul de risques, un système de règlement, etc.
Trouvez une application ou un service qui impacte le métier de manière significative à cause de performance exécrable et/ou de période d'indisponibilité et documentez les éléments suivants :
- Nombre d'incidents et niveau de gravité
- Durée Moyenne De Réparation (DMDR - généralement le temps écoulé entre l'impact initial et la résolution du problème)
- Mesure quantifiable de l'impact métier (par exemple, dollars perdus par minute, clients potentiels perdus, transactions perdues par minute)
- Nombre moyen d'employés impliqués dans la résolution de chaque incident
- Cause mère de chaque incident
Vous pourrez utiliser ces données dans votre document d'évaluation et votre justification métier plus tard.
2. Faites l'inventaire
Beaucoup d'organisations informatiques ont des douzaines d'outils en leur possession qu'elles utilisent rarement, voire jamais. Si vous ne l'avez pas encore fait, vous devez faire l'inventaire des logiciels que vous possédez et documentez vos découvertes. Vous pourrez utiliser ces informations pour les années à venir tant que vous les gardez à jour. Votre inventaire doit comporter :
- Quels outils existent et à quelle catégorie appartiennent-ils ? (p.e. Surveillance de Base de Données, Réseau, de Système d'Exploitation, Bureautique)
- Combien de licences avons nous et sont-elles en cours ?
- Pour quoi sont-elles adaptées ?
- Pour quoi ne sont-elles pas adaptées ?
- Qu'est-ce qui serait catégorisé comme outil de GPA ?
- Si vous utilisez déjà un outil de GPA, pourquoi n'est-il pas utilisé correctement ?
Étiquetez vos outils existants et comprenez ce qu'ils font. Cela vous aidera à identifier où se trouvent réellement vos faiblesses, et si vous avez des outils en votre possession qui ne sont pas pleinement utilisés.
3. Découvrez vos Angles Morts
Maintenant que le paysage général de votre écosystème de surveillance est en place, vous avez besoin de voir s'il existe des trous béants. Une manière de réaliser ceci est de comparer votre boîte à outils existante avec un modèle de ce qu'une application de solution de gestion de la performance devrait inclure, comme les 5 dimensions de GPA du Gartner. Ce modèle comprend les cinq éléments suivants pour qu'une solution de GAP soit "complète" :
- Surveillance de l'Expérience de l'Utilisateur Final : Mesurer le temps de réponse de votre application tout le long jusqu'à l'utilisateur final. Comprendre uniquement la rapidité de votre application à l'intérieur des limites de votre (vos) centre(s) de données n'est pas suffisant.
- Cartographie de la Topologie Applicative : Détection automatique et affichage de tous les composants associés dans la distribution de votre application. Vous devez connaître les composants applicatifs utilisés à un instant T, mais surtout lorsqu'il se produit un problème qui impacte vos utilisateurs.
- Profilage des Transactions Métier : Détecter l'activité des tous les composants applicatifs initiée par une unique requête utilisateur et mesurer son temps de réponse. Ce n'est pas la même chose que de mesurer le temps de réponse d'une page web !
- Diagnostique Poussé d'Application : Détecter l'exécution de code dans les conteneurs d'applications et mesurer le temps d'exécution. Si votre solution actuelle ou potentielle ne s'intègre pas dans votre conteneur d'applications, vous ne disposerez PAS de cette capacité importante.
- Capacités d'Analyse : Intelligence appliquée aux données qui vous procurent des informations exploitables. Il ne s'agit pas de la même chose que des rapports, et les capacités d'analyse peuvent (et doivent) être un facteur clé de différentiation entre les solutions concurrentes.
Le modèle du Gartner devrait vous donner une idée de ce que vous attendez d'une solution de GPA. La plupart des logiciels n'incorporent pas les cinq aspects de la GPA ; de fait, beaucoup d'organisations utilisent une combinaison d'outils pour disposer de la vision complète dont elles ont besoin. Jetez un coup d'oeil aux outils présents dans votre inventaire pour connaître les lacunes dans votre stratégie de GPA.
Une fois que vous avez justifié et établit une démarche de GPA dans votre organisation, voire même acquis un tel outil, il devient crucial de commencer à mesurer l'efficacité de votre programme de GPA, et d'identifier les axes d'amélioration. C'est là que le modèle de maturité de GPA contribue à l'évaluation et à l'analyse.
Un nouveau modèle de maturité pour la GPA
Les modèles de maturité échouent souvent parce qu'ils sont trop théoriques. Les fournisseurs poussent les modèles de maturité à leurs clients dans une tentative de la dernière chance d'améliorer les taux d'adoption et de rétention, mais le client est tout simplement trop occupé à résoudre les problèmes pour s'en soucier. C'est la raison pour laquelle je propose mon propre modèle de maturité de GPA, basée sur une expérience concrète d'interventions d'urgence et d'utilisation d'outils de GPA plutôt que sur des théories sur la manière d'utiliser celle-ci. Dans cette section, je présenterais mon nouveau modèle de maturité et je fournirais quelques questions illustrant ce qu'un acquéreur de GPA pourrait poser à chaque étape.
Quelles Questions Posez Vous ?
Le meilleur indicateur d'où vous vous trouvez dans le modèle de maturité est déterminé par les types de questions et d'affirmations qui apparaissent dans votre organisation. Par exemple, quand mon enfant demande d'où viennent les bébés, je sais où celui-ci appartient dans le Modèle de Maturité de la Vie - et un autre enfant qui pose la même question en est probablement au même stade quelque soit son âge. Pour vous aider à identifier où sont votre statut et celui de votre organisation, j'ai organisé mon modèle de maturité par types de questions que vous pourriez vous poser à chaque étape du processus.
Modèle de Maturité de GPA de Hirsch
Niveau 0 - Qu'est ce qui vient de se passer ?
- Nous venons de recevoir un tas d'appels téléphoniques sur le fait que l'application/le site web est lent. Vraiment ?
- La CPU, la mémoire, le disque et le réseau ont tous l'air OK. Pourquoi est-ce toujours aussi lent ?
- Vous commencez à téléphoner ou à rejoindre une conférence téléphonique et demandez :
- Avez-vous changé quelque chose ?
- Vous voyez quelque chose dans les fichiers de log ?
- Avons-nous des problèmes réseaux ?
- Quelqu'un peut joindre l'administrateur de base de données ? Ça doit être la base de données !
- Ça à recommencer à fonctionner. Quelqu'un a t'il changé quelque chose ?
- C'est résolu ?
- Appel téléphonique du service d'assistance à 3h du matin... C'est de nouveau inutilisable. Flûte !
- Quel est le lien entre une transaction métier et l'infrastructure informatique ? #### Niveau 1 - Trop d'information !
- Notre nouvel outil de surveillance procure effectivement beaucoup de données. Regardons tous ces graphiques pour passer des heures à fouiller dedans.
- Ça a pris du temps pour mettre en place tous ces seuils d'alerte mais je parie que ça en vaut la peine.
- Pourquoi tant d'alertes ? Est-ce que tout s'est planté au même moment ?
- Est-ce qu'il y a quelque chose de vraiment erroné ? Je ne sais pas, va tester le site/l'application pour le savoir.
- Ça fonctionnait bien dans l'environnement de développement/de test/d'Assurance Qualité. Qu'est-ce qu'il y a de différent dans l'environnement de production ?
- Nous avons profilé notre code en développement et il est toujours ralenti en production. Pourquoi ?
- C'est toujours lent pour nos clients ? Ça a l'air correct depuis le bureau.
- Notre outil de GPA est OK pour tester mais nous n'oserions pas l'utiliser en production.
- Quelqu'un sait-il quelles dépendances existent entre nos applications ?
- J'ai entendu parler de quelque chose appelé DevOps. Une idée de ce que c'est ? #### Niveau 2 - Ouf, ça va mieux !
- Nous recevons toujours beaucoup d'alertes mais maintenant nous savons si les applications sont lentes ou inutilisables.
- Nous ne créons pas de seuils d'alerte très souvent ; notre outillage nous alerte de manière automatisée quand des métriques importantes dévient de leur valeur standard.
- Il semble que certaines des fonctionnalités de notre application soient toujours lentes. Concentrons nous sur l'optimisation de celles qui sont le plus utilisées ou qui sont les plus importantes.
- Nous avons construit un tableau de bord pour notre application qui affiche lorsqu'elle devient lente ou est indisponible.
- Nous pouvons voir tout ce qui se passe en test et en production et connaissons les différences entre les environnements.
- Nous savons si n'importe lequel de nos utilisateurs finaux sont impactés car nous surveillons chaque transaction métier.
- Oui, le problème est à la ligne 45 de la méthode DoSomething.
- Nous déployons automatiquement la surveillance avec nos applications. Ça fait partie de notre processus de construction/livraison.
- Nos applications et leurs dépendances sont automatiquement reliées par nos outils. Pas besoin de deviner ce qui va échouer si nous réalisons une modification.
- Est-ce que ça ne serait pas cool si nous pouvions réagir automatiquement à ce pic de charge de manière à ce que notre site ne ralentisse ni ne plante ?
- Je me demande si le métier a ressenti un impact par rapport à ce problème ? #### Niveau 3 - Star de la GPA
- Nous avons réalisé un tableau de bord métier ET technique de telle sorte que tout le monde puisse voir n'importe quand s'il existe un impact.
- Tous nos outils de surveillance sont intégrés et procurent une vision holistique de la santé de chacun des composants aussi bien que de l'application dans son ensemble.
- Lorsqu'il se produit un ralentissement applicatif dû à des pics dans l'activité utilisateur (ou lorsqu'un tel ralentissement est prévu), notre outillage s'adapte automatiquement et lance de nouvelles instances jusqu'à la fin de ce pic.
- Lorsqu'un de nos noeuds applicatifs ne fonctionne pas de manière nominale, notre outillage supprime le noeud incriminé et le remplace avec un nouveau noeud fonctionnel.
- Les données provenant de notre outillage de GPA sont utilisées par plusieurs groupes différents dans l'organisation, à la fois techniques et métier.
En regardant les questions et affirmations précédentes, vous pouvez probablement identifier le niveau du modèle de maturité où vous et votre organisation vous situez. Encore plus important, vous pouvez avoir une idée de comment progresser sur le chemin de la maturité en regardant ce que vous aurez accompli avec le prochain niveau du modèle. Evidemment, l'utilisation d'un logiciel de GPA est un élément essentiel pour atteindre les niveaux les plus élevés de maturité de GPA, mais des processus adaptés et des ressources correctement formées font partie des composants clés du succès. L'unique moyen pour devenir une star de la GPA est via un équilibre délicat de trois composants : les gens, les processus et la technologie.
A propos de l'auteur
Jim Hirschauer est Evangéliste Technologique à AppDynamics. Avant de rejoindre AppDynamics, Jim a passé des années à résoudre de problèmes GPA côté utilisateur , à faire le pompier, et à convaincre tous ses fournisseurs de GPA qu'ils peuvent (et doivent) faire mieux. Le point de vue de Jim résulte d'un travail dans un environnement de Services Financiers avec une pression importante, mais ses méthodes et son approche s'appliquent à toute organisation informatique qui aspire à la grandeur.