défi des métriques de déploiement pré-DevOps

TL; DR, comment prouvez- vous que les devops, en particulier l'automatisation du déploiement, améliorent les taux d'échec des changements?

Nous essayons tous de capturer des mesures sur les «échecs de déploiement» en utilisant des moyens actuels (principalement manuels). Malheureusement, un «échec» se produit rarement, non? Parce que quand quelque chose ne va pas, l'équipe se rassemble (généralement avec des héroïques) pour résoudre le problème (généralement les autorisations, les configurations manquées, vous connaissez l'exercice). Alors ... quand nous demandons comment s'est déroulé le déploiement, la réponse est "ça a marché".

Mais, intuitivement, nous savons tous que ce n'est pas bon. Le rapport 2017 sur l'état des devops indique qu'il y a environ 31 à 45% de « taux d'échec du changement » . Bien que cela semble intuitivement correct, sont-ils suivis comme des incidents? Non. Parce qu'ils sont corrigés assez rapidement, généralement lors de la validation. Il est beaucoup plus rare de faire reculer un déploiement.

Il faut donc de la discipline pour signaler avec précision les taux d'échec. Nous ne sommes pas encouragés à faire de tels rapports parce que nous voulons que les choses fonctionnent et que nous faisons ce qu'il faut pour y arriver.

Alors, comment prouver que les devops, en particulier l'automatisation du déploiement, améliorent les taux d'échec des changements?

(PS a essayé de marquer cela avec "# devops-capacity-model")

Une technique que nous avons utilisée dans le passé dans des situations similaires consiste à obtenir un «engagement de gestion» qui impose ces règles à chaque membre de l'équipe:

1. L'accès pour effectuer des mises à jour des zones de déploiement cibles (c'est-à-dire la production) est limité aux systèmes automatisés sélectionnés, qui ont des pistes d'audit appropriées (= journalisation) de tout type de mises à jour des zones qu'ils gèrent.

2. Les mises à jour manuelles des zones de déploiement cibles, pour quelque raison que ce soit, ne sont plus autorisées par les membres typiques de l'équipe (identifiants utilisateur) qui étaient en mesure (autorisés) d'effectuer ces mises à jour. À la place, de nouveaux ID utilisateur (supplémentaires) seront créés, qui disposeront de toutes les autorisations nécessaires pour effectuer (toujours) ces mises à jour manuelles, si nécessaire. Mais pour pouvoir réellement utiliser ces nouveaux ID utilisateur (= effectuer une connexion avec eux), le membre de l'équipe qui souhaite effectuer une connexion avec ce nouvel ID utilisateur devra effectuer "une" étape supplémentaire pour accéder au mot de passe de ce nouvel ID utilisateur. Idéalement, cette étape supplémentaire est également automatisée (utilisez votre propre imagination à quoi cela devrait ressembler), mais si quelque chose échoue: contactez simplement (= eMail, appel, etc.) le gardien du mot de passe requis, y compris "quel problème ils ont se réparer "

3. Mettre en place un tel gardien n'est pas une tâche facile. Et la plus grande résistance viendra de ... les membres de l'équipe (pour toutes sortes de raisons). Par conséquent, une variation de ces nouveaux ID utilisateur (comme à l'étape précédente) est que chaque membre de l'équipe obtient un ID utilisateur supplémentaire (avec le mot de passe qu'ils décident eux-mêmes), mais avec une chaîne supplémentaire qui lui est attachée: ils ne sont autorisés à effectuer connectez-vous avec cet ID utilisateur (supplémentaire) s'ils ont réellement une bonne raison de le faire. Et chaque fois qu'ils effectuent une telle connexion, ils sont tenus de déposer un certain type de rapport sur «le problème qu'ils ont résolu» (similaire à votre question).

Une fois ces procédures en place, il ne reste plus qu'à examiner périodiquement chacun de ces rapports / raisons pour lesquelles il était nécessaire d'utiliser un tel ID utilisateur spécial, et de poser la question " Y a-t-il quelque chose qui puisse être fait pour automatiser davantage cela, pour réduire davantage le besoin d'une telle connexion spéciale? ".

Mise à jour :

Citez votre commentaire supplémentaire sous cette réponse:

Je pense que l'ajout de barrières artificielles pour résoudre un problème de déploiement est contre-productif.

Certes, cela ajoute une barrière supplémentaire, mais je ne suis pas convaincu que c'est "artificiel". Parce que c'est, à ma connaissance, le seul moyen de prendre conscience des choses que les autres membres de l'équipe ne vous diront jamais, pour des raisons telles que:

• la sécurité d'emploi.
• les mauvaises choses / pratiques qu'ils préfèrent garder cachées.
• le pouvoir qu'ils ne veulent pas perdre.

Le rapport 2017 sur l'état des devops indique qu'il y a environ 31 à 45% de «taux d'échec du changement». Bien que cela semble intuitivement correct, sont-ils suivis comme des incidents? Non. Parce qu'ils sont corrigés assez rapidement, généralement lors de la validation.

Un problème qui se résout rapidement est toujours un problème. Si vous ne les signalez pas comme tels, c'est un problème.

Il faut donc de la discipline pour signaler avec précision les taux d'échec. Nous ne sommes pas encouragés à faire de tels rapports parce que nous voulons que les choses fonctionnent et que nous faisons ce qu'il faut pour y arriver.

Si votre objectif est réellement de faire fonctionner les choses, alors vous devez être honnête au sujet des échecs afin de pouvoir les éviter à l'avenir. On dirait que l'équipe ici est couché (peut - être eux - mêmes, sans aucun doute à la gestion) au sujet des échecs parce que leur objectif est d'avoir les choses semblent fonctionner.

Ce sont des choses différentes. Par exemple, prenez la vieille blague selon laquelle QA produit des bugs - "mon code était correct jusqu'à ce que QA s'en empare, puis ils ont fait tous ces bugs!". Les bugs étaient toujours présents, mais le développeur les ignorait. L'objectif d'une équipe d'exploitation doit être la fiabilité réelle , et elle doit être incitée en tant que telle par sa direction. Cela signifie que s'ils mettent en place plus de surveillance qui mène à la découverte de nouveaux problèmes, ils devraient être récompensés, et non pénalisés pour la baisse ultérieure des mesures de fiabilité.

TL; DR, comment prouvez-vous que les devops, en particulier l'automatisation du déploiement, améliorent les taux d'échec des changements?

Si vous essayez de motiver le changement dans votre organisation, vous ne devriez pas essayer de prouver quoi que ce soit, mais fournir des preuves de ce que les autres organisations disent de leurs propres transitions. Si vous essayez de mesurer les processus que vous avez déjà en place et de justifier leur existence continue, vous devez suivre les mesures de fiabilité standard, comme le temps moyen de réparation (MTTR).

Mais les principes devops ne consistent pas seulement à accroître la fiabilité. Même l'ingénierie de la fiabilité du site ne se limite pas à accroître la fiabilité. Au contraire, vous voulez atteindre un niveau de fiabilité approprié - quelque chose qui profite à l'entreprise mais n'entrave pas le développement. Et cela fait apparaître le véritable facteur de motivation dans les devops, qui est de permettre le changement . Vous voulez permettre à l'entreprise de répondre plus rapidement aux stimuli du marché, ce qui se produit en diminuant la friction des développeurs, en augmentant le taux de déploiements, en automatisant les processus manuels, etc. tout en restant dans une limite de fiabilité acceptable. Cela signifie que vous devez mesurer la fiabilité, mais vous devez également mesurer la vitesse, car votre objectif est d'augmenter cette dernière tout en maintenant la première relativement statique.