« Quatre Indicateurs Clés Accelerate » : différence entre les versions

De Wiki Agile
Aucun résumé des modifications
Ligne 66 : Ligne 66 :
C'est l'un des indicateurs les plus faciles à mesurer, car les déploiements sont généralement bien enregistrés, quels que soient les méthodes ou les systèmes utilisés. Veillez toutefois à définir un déploiement de manière appropriée : dans votre contexte, une modification d'une seule ligne de code est-elle considérée comme un déploiement ? Une modification de plusieurs lignes de code est-elle prise en compte si elle concerne un système qui reçoit très peu de trafic ?<br/>
C'est l'un des indicateurs les plus faciles à mesurer, car les déploiements sont généralement bien enregistrés, quels que soient les méthodes ou les systèmes utilisés. Veillez toutefois à définir un déploiement de manière appropriée : dans votre contexte, une modification d'une seule ligne de code est-elle considérée comme un déploiement ? Une modification de plusieurs lignes de code est-elle prise en compte si elle concerne un système qui reçoit très peu de trafic ?<br/>


==Indicateur : Temps moyen de rétablissement (MTTR) ===
==Indicateur : Temps moyen de rétablissement (MTTR)==
Répond à : "Combien de temps nous faut-il pour rétablir la situation après une panne en production ?<br/>
Répond à : "Combien de temps nous faut-il pour rétablir la situation après une panne en production ?<br/>
<br/>
<br/>
Ligne 74 : Ligne 74 :
<br/>
<br/>
En termes de mesure, vous devez savoir quand l'incident s'est produit (et pas seulement quand il a été observé ou enregistré pour la première fois) et quand il a été résolu. Veillez à définir ce que signifie "résolu" : "résolu" peut-il signifier que le système fonctionne dans un état dégradé mais qu'il est disponible, ou existe-t-il un état optimal "souhaité" du système ? Dans ce dernier cas, vous aurez probablement besoin d'indicateurs de niveau de service (SLI) pour vous assurer que tout le monde est d'accord sur l'état souhaité.
En termes de mesure, vous devez savoir quand l'incident s'est produit (et pas seulement quand il a été observé ou enregistré pour la première fois) et quand il a été résolu. Veillez à définir ce que signifie "résolu" : "résolu" peut-il signifier que le système fonctionne dans un état dégradé mais qu'il est disponible, ou existe-t-il un état optimal "souhaité" du système ? Dans ce dernier cas, vous aurez probablement besoin d'indicateurs de niveau de service (SLI) pour vous assurer que tout le monde est d'accord sur l'état souhaité.
==Indicateur : Taux d'échec des changements (CFR)==
Répond à : "À quelle fréquence nos déploiements entraînent-ils une défaillance en production ?"<br/>
<br/>
Différentes estimations ont été faites pour montrer combien de changements dans la production entraînent des défaillances du système, et elles vont de 5% à plus de 50%. Les défaillances résultant des changements ont un impact sur l'expérience du client et obligent l'équipe à passer de la livraison de la valeur planifiée à un travail de lutte contre les incendies non planifié. Le travail non planifié a toujours la priorité sur le travail planifié.<br/>
<br/>
Les risques de défaillance augmentent avec les systèmes complexes et de grande envergure dont les composants sont étroitement liés. De même, si les processus de développement n'incluent pas de tests unitaires ou d'intégration appropriés ni d'analyse statique du code, et si les pratiques de l'équipe de développement n'incluent pas le pair programming ou la peer review, les risques d'échec sont plus élevés. Pour réduire le taux d'échec des modifications, il faut renforcer la capacité à intégrer la qualité plus tôt dans le cycle de développement des logiciels.<br/>
<br/>
Pour mesurer cela, nous devons connaître le volume de déploiements et le volume d'incidents. Nous devrions également être en mesure d'établir un lien et de démontrer la causalité entre le déploiement et l'incident, qui peut n'être évident que quelque temps après le fait, et peut se produire des semaines ou des mois après le changement initial.<br/>