Catégories
Start-up et applications

Gestion des performances des applications et gestion de la stabilité des applications

La gestion traditionnelle des performances des applications a été conçue dès le départ pour les opérations d'infrastructure et les équipes DevOps émergentes. Ils n'ont pas été conçus pour les équipes produit et ingénierie.

Mais si vous êtes développeur et que vous écrivez du code à livrer à vos clients sous la forme d'une application ou d'un service, vous voudrez probablement savoir après l'avoir livré qu'il fonctionne comme vous le souhaitiez.

CONTENU CONNEXE:
Observabilité: tout dépend des données
Surveillance des applications dans les architectures logicielles modernes

Cette vision axée sur l'ingénierie de la gestion des performances a pris le nom de «gestion de la stabilité des applications». James Smith, cofondateur du fournisseur de solutions ASM Bugsnag, a déclaré que sa société et une autre, Sentry, étaient les deux premières à hausser la bannière de la stabilité des applications.

Alors, quelle est la vraie différence entre APM et ASM? Smith a expliqué: «Il y a ce grand écart dans l'espace APM – déterminer quand promouvoir les builds des données à la production, déterminer quand déployer un test A / B de 5% à 100%. Vous devez savoir quand vous effectuez ces changements itératifs rapides: «Les changements que nous proposons fonctionnent-ils réellement?» Et ce n'est tout simplement pas quelque chose auquel les fournisseurs d'APM réfléchissent. C'est une réflexion après coup pour eux. "

C’est cette concentration sur ce personnel d’équipes de produits et d’ingénierie qui fait la différence. Smith a déclaré que lorsqu'il était utilisé avec une solution APM traditionnelle, sa société a constaté que moins de 5% des ingénieurs se connectaient à l'APM, tandis que 70% de l'équipe d'ingénierie se connectait à Bugsnag sur une base hebdomadaire. "Cela signifie que nous avons construit ce qui est essentiellement un tableau de bord quotidien pour les équipes d'ingénierie et de produits", a déclaré Smith, "au lieu d'attendre de l'équipe de surveillance pour dire à l'ingénieur logiciel qu'il a foiré et qu'il doit le réparer. C’est un outil que ces gens utilisent tous les jours pour affiner leur métier et devenir meilleur ingénieur logiciel. »

Les grandes entreprises se rendent compte aujourd'hui que leur impression de marque provient davantage des expériences Web et mobiles que de leurs magasins ou bureaux. En se concentrant donc d'abord sur l'expérience client, Smith a déclaré que la surveillance côté client – JavaScript et la surveillance mobile – est l'endroit où «le caoutchouc rencontre la route quand il s'agit de clients touchant votre logiciel».

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *