Notes de cours sur DevOps (Automne 2024)

Partie 2: Principes de DevOps Organiser et Mesurer DevOps Responsabilité collective, mesurer ce qui importe, métriques exploitables Wiem TOUNSI...

Partie 2: Principes de DevOps Organiser et Mesurer DevOps Responsabilité collective, mesurer ce qui importe, métriques exploitables Wiem TOUNSI Automne 2024  A la fin de cette séance, vous devriez Organiser pour DevOps Comprendre que DevOps est un état d'esprit adopté par l'ensemble de l'organisation. Être conscient que des actions sans conséquences peuvent mener à l'apathie et que permettre aux équipes de ressentir l'effet de leurs actions favorise l'empathie et le travail de meilleure qualité. Mesurer pour DevOps Expliquer l'importance de mesurer ce que vous souhaitez améliorer, d'identifier la valeur des indicateurs sociaux et DevOps, Reconnaître que le DevOps change votre approche de la résolution des problèmes. Décrire la valeur des mesures exploitables et de répertorier des exemples de mesures exploitables. W. Touns i 2 DevOps - Changement culturel Penser différemment Travailler différemment Organiser différemment Codage social (social coding) Taylorisme et Travail L'organisation impacte la en Silos conception des produits Exécution en petits lots pour (logiciels) fabriqués réduire les pertes Infrastructure as code / Containerisation Création de produits minimaux viables Mesurer différemment Intégration continue Dév piloté par les Tests / Dév Mesurer ce qui importe. piloté par les comportements Livraison continue / Déploiement continu Vous aurez ce que vous Microservices natifs du Cloud mesurez ! Concevoir pour l'échec W. Touns i 3 Organiser DevOps L'impact Organisationnel sur DevOps Il n'y a pas d'équipe DevOps (ou DevSecOps) Le succès est la responsabilité de tous W. Touns i 4 Organiser DevOps Il n'y a pas d'équipe DevOps 5 Il n'y a pas d'équipe DevOps (ou DevSecOps) Différents points de vue sur le DevOps Dev DevOps Ops Larges entreprises (Souvent) DevOps est ce que Ops fait Dev Ops Dév. Et Ops traditionnels W. Touns i 6 Il n'y a pas d'équipe DevOps (ou DevSecOps) Différents points de vue sur le DevOps Dev DevOps Ops Startups (Souvent, Cloud native) Larges entreprises (Souvent) DevOps est ce que Ops fait DevOps Dev Ops Dev DevOps Ops DevOps une culture d'organisation DevOps est ce que Dev fait Dév. et Ops traditionnels Dev et Ops travaillent ensemble : - avec le même état d'esprit, Dev DevOps Ops - de préférence au sein de la même équipe, - en utilisant les mêmes objectifs et mesures DevOps est une équipe 7 séparée W. Touns i Il n'y a pas d'équipe DevOps (ou DevSecOps) « Le mouvement DevOps s'attaque au dysfonctionnement qui résulte des organisations composées de silos fonctionnels. Ainsi, créer un autre silo fonctionnel entre les équipes de développement et d'exploitation est clairement une mauvaise façon (ironique) de résoudre ces problèmes. » Jez Humble, The DevOps Handbook W. Touns i 8  Il n'y a pas d'équipe DevOps (ou DevSecOps) W. Touns i 9 Source photo: Andrew Clay Shafer, Senior Director of Technology of Pivotal  Il n'y a pas d'équipe DevOps (ou DevSecOps) Un autre Silo, qui sépare davantage les équipes Dev et Ops ! W. Touns i 10 Source photo: IBM Developer  Il n'y a pas d'équipe DevOps (ou DevSecOps) DevOps n'est pas un titre de poste Ce n'est pas une tâche qu'une personne ou une équipe fait ! DevOps est (Rappel) : Une transformation culturelle à l'échelle de l'organisation la pratique selon laquelle : Ingénieurs de dév. et d'Ops travaillent ensemble durant tout le SDLC + en suivant les principes Lean et Agile Cela commence par travailler et s'organiser différemment : + de préférence au sein de la même équipe, + des équipes interfonctionnelles dont les piliers sont l'ouverture, la transparence et la confiance. W. Touns i 11 Organiser DevOps Le succès est la responsabilité de tous 12 Le succès est la responsabilité de tous Mauvais comportement « Bad behavior arises when you abstract people away from the consequences of their actions » Jez Humble, Continuous Delivery « Un mauvais comportement survient lorsque vous éloignez les gens des conséquences de leurs actes » W. Touns i 13  Le succès est la responsabilité de tous - Exemple Les silos fonctionnels engendrent le mauvais comportement Exemple Entreprise avec une série le dév. estimait qu'il n'était de problèmes de qualité plus chargé de tester son code. avec ses logiciels. --> il s'efforce de finir le code le plus Cité par Jez humble rapidement possible. "c'est le travail de l'équipe d'assurance qualité de se soucier de la qualité !" Développeur Assurance Opérationnel L'organisation a soustrait l'équipe de Lest tests de Qualité dév. aux conséquences de l'écriture d'un code bogué ou non sécurisé. securité se situent où ici ? Surprise ! Volume de tests Qualité de code La qualité a diminué ! W. Touns i 14 Iconfinder de Ivan Sokolyanskiy  Le succès est la responsabilité de tous Les actions ont des conséquences - Créer des équipes interfonctionnelles : tout le monde a affaire à des coéquipiers plutôt qu'à des files d'attente. Pas possible de créer des équipes interfonctionnelles? demander aux Dév. d'effectuer une rotation entre les Ops : comprendre ce que Ops font au quotidien pour assurer le fonctionnement de leurs applications. Et demander aux Ops de rejoindre les stands des développeurs ou des responsables de la Sécurité (DevSecOps) Un dév. se met dans la rotation des astreintes un Ops ou Dév dans une équipe de réponse à (un dimanche ou deux) incidents de sécurité... Si vous les élognez des - Rendre les personnes responsables de leurs actions conséquences de leurs actions, ils deviendront apathiques. W. Touns i 15  Le succès est la responsabilité de tous Objectif organisationnel - Atteindre une conscience partagée tout le monde a une idée globale de votre objectif et de ce que vous espérez accomplir, - Donner le contrôle local sur la manière d'y permet aux personnes de faire de leur mieux au lieu d'attendre des commandes venant d'en haut. parvenir Dev ou Ops ou Sec : Chacun a la responsabilité d'apporter de la valeur au client, mais l'organisation doit leur donner les moyens de le faire. W. Touns i 16 Exercices Sélectionnez l’énoncé qui explique comment un mauvais comportement survient lorsque vous éloignez les personnes des conséquences de leurs actes. 1. Lorsque les gens travaillent en silos, ils ne voient ni ressentent les effets de leur mauvais travail. 2. Inclure les développeurs dans la rotation d'astreinte les amène à se comporter mal. 3. Les files d’attente pour les tickets incitent les gens à se comporter de manière plus responsable. 4. Toutes les équipes ont besoin d’une assurance qualité (AQ) pour détecter leurs erreurs. W. Touns i 17 Exercices Sélectionner la mauvaise réponse : 1. DevOps est un état d’esprit qu'une seule équipe de l’organisation adopte. 2. DevOps résout les problèmes causés par les équipes cloisonnées. 3. Permettre aux équipes de ressentir l’effet de leurs actions favorise l’empathie, ce qui se traduit par un travail de meilleure qualité. 4. Des actions sans conséquences peuvent conduire à l’apathie. W. Touns i 18 DevOps - Changement culturel Penser différemment Travailler différemment Organiser différemment Codage social (social coding) Taylorisme et Travail L'organisation impacte la en Silos conception des produits Exécution en petits lots pour (logiciels) fabriqués réduire les pertes Infrastructure as code / Containerisation Création de produits minimaux viables Mesurer différemment Intégration continue Dév piloté par les Tests / Dév Mesurer ce qui importe. piloté par les comportements Livraison continue / Déploiement continu Vous aurez ce que vous Microservices natifs du Cloud mesurez ! Concevoir pour l'échec W. Touns i 19 Mesurer DevOps Mesurer ce qui importe Métriques exploitables Mesurer sa culture W. Touns i 20 Mesurer DevOps Mesurer ce qui importe 21 Mesurer DevOps – Mesurer ce qui importe Si vous mesurez des lignes de Vous aurez plusieurs lignes de code code Si vous mesurez les co-équipiers Vous obtiendrez un comportement A en les classant les uns par rapport antisocial aux autres Si vous mesurez les intéractions Codeurs sociaux B sociales (partage code et connaissances) Vous ne pouvez pas mesurer pour A et espérer obtenir B. Cela n'arrivera pas parce que vous obtenez ce que vous mesurez. Alors, mesurez ce qui compte ! W. Touns i 22 Quelles sont les métriques que vous utiliserez pour avoir des codeurs sociaux? W. Touns i 23 Mesurer DevOps – Mesurer ce qui importe - Métriques sociales Créez-vous du code que le reste de l'entreprise (ou de la communauté open source juge utile 1. Qui utilise le code que vous créez pour être réutilisé dans leurs solutions ? Cela incitera les dév à réfléchir à la manière dont ils peuvent rendre leur code utile aux autres. Est-ce que vous gaspillez tous mes dollars de 2. Quel code utilisez-vous ? développement en réinventant les roues ? ou Utilisez-vous les roues existantes pour ne construire que des pièces sur mesure qui n'existent pas ? Ces deux indicateurs sont nécessaires car ils incitent les deux parties à partager et à réutiliser le code de l'autre. Vous obtenez ce que vous mesurez ! pour avoir Besoin d'une métrique sociale comportement social. W. Touns i 24 Mesurer DevOps – Amélioration continue -1 Savoir d'où vous venez pour savoir si vous allez dans la bonne direction. 1.Etablir une base de référence Qu'est- ce que tu souhaites 6 membres de l'équipe qui améliorer ? font 10 heures pour déployer une version de votre produit. Cela coûte X dollars pour chaque sortie. 2. Créer un objectif Les objectifs métriques vous permettent de raisonner à partir de ces chiffres et de juger du succès de vos progrès un seuil d'amélioration réduire le temps de déploiement de 10 heures à 2 heures. multiplié par cinq pour atteindre 2 h. passer de 6 membres d'équipe à 2 membres de l'équipe réduire le nombre de défauts détectés lors de la production travailler sur un objectif à la fois ! W. Touns i 25 Mesurer DevOps – Amélioration continue -2 Savoir d'où vous venez pour savoir si vous allez dans la bonne direction. 3. Evaluer le succès de votre processus Êtes-vous passé de 10 heures à 2 heures ? NON ? Essayez différemment jusqu'à ce que vous obteniez cette mesure. Ensuite : travailler sur le prochain objectif. W. Touns i 26 Mesurer DevOps – Amélioration continue -3 1.Etablir une base de référence : le temps moyen de remédiation des vulnérabilités critiques est de 60 jours (Mean Time to Remediate) Réduire le temps moyen de remédiation des 2.Etablir un objectif : vulnérabilités critiques de 60 jours à 40 jours - Augmenter le personnel - Analyser et reprioriser les vulnérabilités - S’assurer de son parc d’actif (produits logiciels, matériel) 3. Evaluer le succès de votre processus Même principe pour (Temps moyen d’identifier les vuln. , temps moyen de répondre à un incident) W. Touns i 27 Mesurer DevOps Métriques exploitables 28 Mesurer DevOps – Métriques futiles Méfiez vous des indicateurs futiles (de vanité) ! Les indicateurs de vanité sont bons pour se sentir bien, mais mauvais pour passer à l'action. Exemple Considérez la métrique des « visites » sur un site Web. « C'est génial, notre site Web a été consulté 10 000 fois ! » Que représente un clic ? Une personne a-t-elle cliqué 10000 10000 personnes ont cliqué fois avec nervosité ? une fois et sont parties ? Vous ne savez pas quelle action ​a incité les visiteurs à visiter votre site Web et vous ne savez donc pas quelle ​action prendre ensuite. Le nombre de clics à lui seul n'est pas un indicateur exploitable. W. Tounsi 29 Mesurer DevOps – Métriques Exploitables Imaginez que vous ajoutiez une nouvelle fonctionnalité à votre site Web Vous introduisez la fonctionnalité à l'aide de tests A/B : 50 % des clients voient la nouvelle fonctionnalité Revenu par consommateur Le groupe B enregistre un chiffre d'affaires par Déployer cette fonctionnalité au client supérieur de 20 % Cause près de 100 % de vos clients Effet Le pouvoir des indicateurs exploitables ! W. Tounsi 30 Mesurer DevOps – Métriques Exploitables - exemples Lors de la conférence de 2017 : « Tools Won't Fix Your Broken DevOps » Nicole Forsgren a identifié ce qu'elle considère comme les quatre principaux indicateurs exploitables : Combien de temps faut-il pour qu'une idée passe en production ? le délai moyen de livraison À partir du moment où votre client demande la nouvelle fonctionnalité, ou d'exécution (Mean Lead Time) combien de temps lui faut-il pour qu'elle soit disponible ? À quelle vitesse pouvez-vous Aussi vite que nécessaire et pas plus tôt. Ne pas être dérangé par un concurrent et mettre du temps à réagir. publier des objets ? S'assurer que, même si vous pouvez publier plus rapidement, les Le taux d'échec suite modifications n'échouent pas lors du déploiement. aux modifications La vitesse n'a aucun sens si elle déstabilise le système. (Change Failure Rate) Délai moyen de reprise Au lieu de vous préoccuper du délai moyen avant une panne (MTTF Mean Time to Recovery (MTTR) : Mean Time to Failure) --> faire preuve de résilience et vous remettre rapidement en place lorsque cela se produit W. Tounsi 31 Mesurer DevOps Mesurer sa culture 32 Mesurer DevOps – Tout à fait d'accord ou Pas d'accord Une série de déclarations élaborées par le Dr Nicole Forsgren lorsqu'elle était PDG et scientifique en chef de DevOps Research and Assessment (DORA). Déclarations culturelles pour mesurer les équipes sur une échelle de 7 à 1 W. Tounsi 33  Mesurer DevOps – Tout à fait d'accord ou Pas d'accord Dans mon équipe, les échecs sont des opportunités d'apprentissage et les messagers ne sont pas punis. Entendu l'expression « ne tirez pas sur le messager » ? Les gens ne seront pas honnêtes à signaler ce qui se passe réellement s'ils pensent être punis. Il est essentiel d'inculquer à votre équipe l'idée que « chaque échec est une opportunité d'apprentissage » --> favoriser une culture d'expérimentation Amélioration continue Personne ne vient au travail pour réduire la production (sauf s'il ya une mauvaise intention) Qu'aurait-on pu faire pour donner à cette personne une meilleure info --> Ce n'est pas la personne qui a échoué, ou une meilleure formation ou pour mais plutôt le système qui l'a fait échouer corriger ​les erreurs du système ? Blameless culture ! Série de déclarations élaborées par le Dr Nicole Forsgren W. Tounsi 34  Mesurer DevOps – Tout à fait d'accord ou Pas d'accord Dans mon équipe, les responsabilités sont partagées C'est mesurer le sentiment que nous sommes tous dans le même bateau. Lorsque les choses explosent, tout le monde intervient pour résoudre le problème ou se remettre du désordre. Série de déclarations élaborées par le Dr Nicole Forsgren W. Tounsi 35  Mesurer DevOps – Tout à fait d'accord ou Pas d'accord Dans mon équipe, la collaboration interfonctionnelle est encouragée et récompensée. Cela revient au système de mesure. Les personnes sont elles évaluées en fonction du fait qu’elles sont des collaborateurs ou sont-ils récompensés pour avoir contribué seuls ? N'oubliez pas que vous obtenez ce que vous mesurez. Série de déclarations élaborées par le Dr Nicole Forsgren W. Tounsi 36  Mesurer DevOps – Tout à fait d'accord ou Pas d'accord Dans mon équipe, les nouvelles idées sont les bienvenues. Cela est essentiel pour que les idées circulent librement. Est-ce q'on a le sentiment que les commentaires et les idées sont écoutés, ou sont-ils abandonnés ? Vous pouvez en dire long sur la santé de la dynamique de votre équipe... Série de déclarations élaborées par le Dr Nicole Forsgren W. Tounsi 37 Mesurer DevOps – Mesurer sa culture “You can’t directly change culture, but you can change behavior, and behavior becomes culture.” — Lloyd Taylor, VP Infrastructure, Ngmoco W. Tounsi 38  Quelle est l'information la plus importante que vous avez apprise aujourd'hui ? En fonction de ce que vous avez entendu, vu, fait pendant la séance, quelle question demeure... ? 39 Au prochain cours Partie 3 DevSecOps Faits marquants, problématique, Techniques, Durcissement des Conteneurs et Orchestrateurs, Pipeline DevSecOps Wiem TOUNSI Automne 2024