Feedback des ressources, du métier et du business

Description

Dans une perspective DevOps, le retour d'information et la mesure sont une nécessité, et ils sont ancrés dans les valeurs fondamentales de la pratique :

• C'est le "M" de "CALMR" de SAFe [SAFe 2021-43] ou le "CALMS" bien connu de Jez Humble [Buchanan 2021].
• Gene Kim, Jez Humble et Patrick Debois (le "père" de DevOps [DevOps Cafe 2010]) ont également écrit quelques principes DevOps sur le retour d'information.
• Le point de vue de Google sur le DevOps nommé "Site Reliability Engineering" (SRE) a également une forte préoccupation pour le retour d'information et les alertes [Beyer 2016].

La liste pourrait être étendue à un ensemble encore plus grand de références qui diraient la même chose, parce que l'essentiel est que le retour d'information synthétisé avec des métriques est obligatoire ; et il ne s'agit pas seulement de tests mais d'activités sur le produit. Ce retour d'information fait partie de l'approche Shift Right Testing (SRT) qui fournit un "apprentissage en double boucle" [Argyris 1977] sur plusieurs éléments tels que les ressources, les attentes du domaine et les activités/revenus.

En ce qui concerne les ressources, les moyens techniques tels que les unités centrales, le réseau, le stockage et la mémoire doivent être surveillés pendant leur utilisation. Cela permet d'éviter une interruption de service due aux demandes régulières de l'entreprise. Lorsqu'il s'agit de demandes de service irrégulières telles que des attaques DoS, des alertes doivent être lancées pour gérer ces questions de sécurité et, par extension, la détection d'une utilisation suspecte des ressources, notamment grâce à des outils tels que les moyens de détection DDoS ou les pots de miel. Cette question dite "OPSEC" soulève le besoin de traiter toute exigence non fonctionnelle (NFR) qui serait significative sur le produit, comme les temps de réponse moyens, la version de l'API utilisée pour surveiller les problèmes de compatibilité, ou même le retour du client sur les fonctionnalités mises en œuvre.

Lorsqu'il s'agit du domaine, l'approche Lean Startup [Ries 2012] ou les descriptions épiques de SAFe [SAFe 2021-34] impliquent des "indicateurs avancés". Ces retours d'expérience dans le domaine fournissent des indices pour aider à prédire l'hypothèse de résultat de l'activité [SAFe 2021-44].

Enfin et surtout, le retour d'information de l'entreprise est également attendu pour garantir les revenus et atteindre le bon équilibre entre les revenus, les besoins du domaine et les ressources. Des outils tels que l'APM aident à traduire les métriques informatiques en valeurs commerciales. Pour illustrer cela, il apparaît que le temps de réponse d'une transaction HTML a un impact énorme sur les géants du web tels qu'Amazon, Google, Yahoo ou Bing ; par exemple, un retard de 100 ms entraîne une baisse de 1% des revenus d'Amazon, soit environ 2 milliards de dollars [Moustier 2019-1] !

Impact sur la maturité des tests

Obtenir un retour d'information des ressources, du domaine et de l'entreprise est très utile pour éviter les interruptions de service ou le mécontentement dû à de mauvaises hypothèses. Si ce feedback est fourni rapidement, tout problème peut alors être traité rapidement et les impacts négatifs sont alors limités à quelques incidents. Bien entendu, cela n'est possible que si le processus de livraison est suffisamment rapide et stable pour permettre une stratégie "échouer vite, beaucoup et souvent"Cette stratégie est conforme à l'approche DevOps, car elle vous amène à automatiser tout ce que vous pouvez.

Toujours dans une optique de limitation de l'impact, cette approche peut être mélangée avec Canary Releasing pour combiner un faible impact et un retour d'information rapide.

Les réactions du domaine sont également utilisées dans les tests A/B pour déterminer quelle option est réellement préférée par les utilisateurs finaux.

En fin de compte, le retour d'information est également utilisé pour contrôler la satisfaction du client et respecter tout accord de niveau de service avec une certaine marge, avec des objectifs de niveau de serviceappropriés et la gestion du budget d'erreur qui devrait aller de pair avec la politique de traitement des anomalies comme Andon.

Le point de vue d'Agilitest sur cette pratique

Agilitest est essentiellement un outil conçu pour les tests de décalage à gauche; toutefois, l'outil peut facilement être transformé en un automate de vérification de l'intégrité qui peut être lancé régulièrement pour s'assurer que l'ensemble du système fonctionne correctement. Cette séquence de tests en fumée peut simplement être scriptée sur les fonctionnalités les plus importantes afin de s'assurer que les parties sous-jacentes (par exemple, les services web, les bases de données) sont toujours opérationnelles. Comme l'outil ne nécessite aucune connaissance en matière de codage, il peut être utilisé et maintenu par les personnes d'un service d'assistance.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍