Return on investment
Dans notre précédent billet, nous vous avions présenté le modèle de travail DevOps. 
Penchons-nous à présent sur son ROI: quelle performance doit-on observer ?
Décider d’enclencher une dynamique DevOps au sein de votre organisation impose de bien définir la trajectoire et de mesurer le chemin parcouru afin d’évaluer son gain.
A ce titre, il est recommandé de « start small and iterate » pour constater rapidement du bénéfice et pour garder de l’enthousiasme.
Mesurez le ROI, oui mais comment ?
Rappelons les grands objectifs du développement (le build) et des opérations (le run) afin de dégager les métriques pertinents.
Pour le build, votre objectif est principalement d’être « time to market ».
C’est à dire votre capacité à délivrer des fonctionnalités pour l’utilisateur final au moment attendu.
Par exemple, proposer une option supplémentaire payante lors d’un évènement sportif, etc.
Dans le run, vous vous attachez, à minima, à respecter les SLA et donc de maintenir le taux de disponibilité. Vous souhaitez également renforcer votre QoS.
Pour votre business unit, l’objectif est concentré sur le cycle de déploiement continu (plan, code, build, test, release, deploy, operate) lequel est, au regard de la logique de concurrence, de plus en plus fréquent et de plus en plus rapide. Prenez par exemple la technique du A/B testing qui exige de réagir rapidement face aux comportements des utilisateurs.
Alors comment mesurer l’impact de DevOps, son ROI en somme, vis à vis de ces objectifs ?
A – Effectuez l’inventaire des métriques pertinents disponibles:
Le Run:
nombre d’incident ventilé par niveau de criticité
délai de la mise en ligne des correctifs et délai moyen
volume des alertes de supervision
durée des interruptions par service
coût moyen des interruptions par service
durée cumulée des interruptions de service
coût total des interruptions de service
taux de disponibilité des services
consommation des ressources hardware des plateformes
Le Build:
nombre d’itération du code par mois par projet
nombre de patch générés
nombre de bug déclarés vs nombre de bug résolus
nombre de features livrées en production
L’Organisation:
nombre de jour homme consommé pour le build
nombre de jour homme consommé pour le run
nombre de jour homme consommé pour le DevOps
investissement dans l’automatisation
% des revenus générés par service
DevOps:
nombre de rencontre (coffee break, déjeuné, réunion, conf call, babyfoot, etc.)
outil de partage mis en place: oui / non
niveau d’utilisation de l’outil de partage (nombre de post, wiki, pertinence, etc.)
enclenchement de la boucle de rétro action
niveau de collaboration (synergie)
niveau d’autonomie
indicateurs de stress
adoption d’outils agile
B – Générer et actualiser les métriques périodiquement
C – Grapher, superposer les courbes et mettez en évidence les deltas
Voici un exemple simple de graphique sur le nombre d’incident ventilé par niveau de criticité :
En voici un autre exemple sur le délai de la mise en ligne des correctifs:
Ici un exemple représentant visuellement la QoS des services :
D – Mesurer, observer, comparer, communiquer
D’une manière générale, vous devriez consommer moins de temps sur le run et plus sur le build.
Itération après itération, voici les ROI que vous devriez observer:
Le Run :
diminution du temps de cycle via le nombre de jour homme consommé pour les opérations ventilées par service
raccourcissement des délais de mise en ligne
réduction des coûts de livraison et des erreurs via l’automatisation (packaging, déploiement)
autre ? réduction des achats de licence produit ?
Les Ventes :
augmentation du CA et ou amélioration des marges.
Pour conclure sur cette note, vous l’aurez compris, le ROI de DevOps se retrouve in fine, dans 2 pentes de vos courbes :
->L’amélioration de vos revenus grâce à l’automatisation, l’implication de vos équipes et une plus grande agilité dans le cycle de déploiement.
->La réduction des coûts d’exploitation par le biais d’un meilleur partage des connaissances et d’outillage commun.
Phi. D.
