« Quatre Indicateurs Clés Accelerate » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 65 : | Ligne 65 : | ||
<br/> | <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/> | 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) === | |||
Répond à : "Combien de temps nous faut-il pour rétablir la situation après une panne en production ?<br/> | |||
<br/> | |||
Les pannes sont inévitables. Qu'il s'agisse des conséquences imprévues des changements, qui peuvent entraîner une défaillance partielle ou totale des services, de problèmes de capacité, de menaces malveillantes ou accidentelles, de certificats arrivant à expiration ou, comme d'habitude, de pannes DNS, pannes de système font partie de la vie quotidienne.<br/> | |||
<br/> | |||
Plus les changements peuvent être annulés rapidement, ou les systèmes adaptés manuellement ou automatiquement pour restaurer les services, plus les performances de l'équipe sont élevées et plus l'expérience client et la valeur fournie sont bonnes. Pour améliorer le temps moyen de restauration, il faut réduire la taille des lots de changements, construire et utiliser des systèmes plus résilients et distribués, permettre des défaillances graduelles des composants grâce à un découplage et à une mise en file d'attente appropriés, ainsi qu'à une surveillance et à des alertes efficaces.<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é. | |||
