J'essaie de conduire de bons comportements au sein d'un programme de transformation DevOps, pour soutenir cela, je cherche à identifier des mesures exploitables autour des disciplines opérationnelles:
- Gestion des problèmes et des incidents
- Gestion de la capacité
- Gestion des modifications et des versions
Pour être tout à fait clair, ce sont des fonctions qui appartenaient à l'organisation des opérations et qui appartiennent maintenant à l'organisation Agile / DevOps. Il existe des indicateurs clés de performance qui conduisent à de mauvais comportements:
- Délai d'analyse de la cause racine terminé:
- Conduit des RCA incomplets juste pour les faire entrer dans le système à temps.
- Durée d'exécution du test:
- Désactive les tests de longue durée, quelle que soit leur valeur commerciale.
- Utilisation moyenne des services cloud:
- Encourage le sur-engagement des ressources de calcul, entraînant des temps de réponse lents
Quels indicateurs de performance clés peuvent être utilisés pour encourager un bon comportement dans un programme DevOps?
Réponses:
Je ne pense pas qu'il existe de KPI DevOps "universels". Par exemple, la vélocité est excellente, à moins qu'elle ne soit pas un moteur clé pour votre entreprise. Amazon se soucie beaucoup de la vitesse car ils ont une opération de vente au détail massive. C'est moins important pour une petite application avec 100 utilisateurs.
Cela soulève la question: comment sélectionnez- vous les meilleurs KPI pertinents pour votre entreprise? Il s'agit d'un processus de recherche et de découverte qui implique l'ensemble de votre entreprise.
De quoi vous souciez-vous?
Qu'est-ce qui empêche les parties prenantes de votre entreprise de dormir la nuit? Qu'est-ce qui détermine si vous gagnez de l'argent ce trimestre ou non? La liste ci-dessus peut inclure certaines de ces choses, ou non. Faites votre liste, puis découvrez comment aligner les incitations dans chaque département pour les atteindre.
Les incitations stimulent le comportement, alors décidez en collaboration des objectifs SMART. Choisissez deux ou trois éléments de votre liste de brainstorming et lancez un cycle de rétroaction de mesure / correction pour chacun. N'en choisissez pas trop à la fois - vous avez plus de chances de réussir en vous concentrant dur sur deux ou trois choses.
la source
DevOps n'a pas de KPI . Ce serait comme demander quels sont les KPI de l'amour. Mais certaines des choses dont vous avez parlé ( problèmes et gestion des incidents , gestion des capacités , le changement et la gestion des versions ) n'ont bon KPI, dont certains sont basés sur la théorie derrière DevOps.
En général, pour tout processus métier, vous pouvez créer une carte de la chaîne de valeur décrivant comment la valeur circule du client , à travers l'entreprise vers le client . La boucle entière doit toujours commencer et se terminer avec le client, mais parfois, pour une organisation de service, le client peut être interne. Le débit de valeur à travers une telle chaîne peut être un bon moyen de concevoir votre KPI d'une manière inviolable. Mesurer n'importe quel indicateur de performance clé dans un maillon individuel de la chaîne de valeur n'a de sens que tant que ce maillon particulier est le goulot d' étranglement du processus et que vous essayez d'exploiter ou d'élever le goulot d'étranglement.
Un problème commun avec KPI est quand il commence à mi-chemin de la chaîne. Par exemple, un processus de modification et de publication commence souvent par les développeurs et se termine par le déploiement. Ce processus a exclu:
Le problème est que la seule mesure d'un temps de cycle peut entraîner deux problèmes majeurs:
Le goulot d'étranglement se trouve dans l'une des parties exclues mentionnées ci-dessus et vos clients ne réalisent pas la valeur et vous ne réalisez pas le revenu proportionnel à la vitesse de votre temps de cycle. Ainsi, même si votre ingénierie est excellente, votre entreprise en souffre.
La déconnexion des clients rendra votre cycle de publication vide - ne produisant aucune valeur, malgré les changements en cours - ou même contrera les besoins de vos clients et le travail effectué pourrait avoir une valeur commerciale négative.
Un autre problème avec l'indicateur de performance clé est que, tout en commençant et en terminant avec un client, il peut ne pas réellement mesurer la valeur pour le client. Un bon exemple serait un processus de réponse aux problèmes et incidents et MTTR (Mean Time To Repair) comme KPI. Le problème affecte-t-il même quelqu'un? Quelle est la valeur pour les clients? Vous pourriez avoir un excellent MTTR de 3 heures sur 100 incidents. Mais si la plupart d'entre eux étaient internes, avec un impact nul ou minime sur les clients et résolus en quelques minutes, alors que le seul gros incident avec un impact client énorme a pris 3 jours à gérer, la valeur commerciale est inférieure à celle d'un MTTR d'une journée, car vous ignorez la plupart des incidents internes, mais vous avez répondu à l'énorme incident d'impact sur les clients en moins d'une heure.
REMARQUE: Pour un client interne, dans le cas du processus métier de l'équipe de support, la valeur dérivée n'est pas la valeur du travail pour le client interne, mais la valeur acquise par l'entreprise en débloquant le client interne dans son propre processus métier. Le déblocage d'une équipe qui est un goulot d'étranglement dans son propre processus a une valeur plus élevée que le déblocage d'une équipe ou d'un individu sans goulot d'étranglement. Tous les KPI d'une telle équipe de support doivent inclure la valeur commerciale dans leur calcul.
la source
Et enfin,
la source
5.DevOpsCulture, which actually can’t be measured=> créez un questionnaire anonyme pour toutes les personnes impliquées, même légèrement, et demandez-leur ce qu'elles pensent de tout cela. Cela vous dira sûrement si vous avez un processus qui est vécu par votre peuple, ou si beaucoup de gens sont en vérité à mi-chemin de la porte ...