Introduction à la philosophie DevOps devops

Publié le : 10 Janvier 2020 07:39

Qu'est ce que DevOps ?

DevOps est un terme issu de la contraction des mots anglais development (développement) et operations (exploitation). C'est une philosophie ou au moins une méthode de travail pronant la fusion des métiers issue du développement et de l'exploitation.

Oui, mais, Qu'est ce qu'un dev ?

Un dév ou plus officiellement un développeur logiciel est un personne qui conçoit un logiciel, généralement dans cette conception, il suit le cycle suivant :

dev.png

Cycle de conception logicielle

Donc si on fait tout, Qu'est ce qu'un ops ?

Un ops ou plus généralement un administrateur (système, réseaux, application, base de données...) est une personne en charge de faire fonctionner un système. Quand il reçoit un logiciel, il l'intègre jusqu'à la fameuse Mise en Production puis il en suit son bon fonctionnement

ops.png

Cycle de gestion des logiciels en production

C'est toujours pas clair, mais on m'a dit de mettre ça sur mon CV

On vous à bien conseiller car c'est une philosophie en vogue notamment si on cherche l'évolution des recherches sur Google de ce terme

evol.png

Évolution des recherches du terme DevOps sur Google

Avons-nous une définition de DevOps

En fait oui , c'est une méthodologie…

  • Un ensemble de bonnes pratiques
  • Pour créer une osmose entre les équipes de développement et d’exploitation

dans l’esprit des méthodes agiles…

  • Même enjeu : améliorer la réactivité de l’entreprise face aux mouvements du marché pour réduire son « time-to-market »

qui vise à raccourcir les délais de mise en production

  • Un nouveau cadre de travail
  • Pour améliorer les synergies entre les équipes de développement et d’exploitation
  • Livrer le plus rapidement possible avec la qualité escomptée

Le DevOps dans l'agilité

C'est une approche complémentaire des méthodes agiles

Née de la nécessité de mettre en production des projets de développement Agile (livraison plus petite mais plus fréquente)

Impossibilité d'absorption par la production de cette fréquence de mise à jour

agile.png

Cycle agile

Un peu d'histoire

Mainframe

  • Equipe intégrée DevOps dans l’esprit
  • Facile à faire car maîtrise complète de toute l’infrastructure informatique

Client-Serveur

  • Augmentation du nombre d’intervenants
  • Création de silos

Applications distribuées

  • Augmentation significative des composants d’infrastructure
  • Arrivée des API de management facile à utiliser
devops history

L'histoire de la méthodologie

Quand mettre en œuvre la démarche DevOps ?

Les symptômes

Détection tardive des défauts de conception

  • Coûts de correction élevés induits par le développement classique en V (« en cascade »)
  • Défauts majoritairement détectés lors de l’utilisation par l’utilisateur final

Temps d’exécution des actions trop important

  • Levée d’alerte, récupération de logs, analyse, identification des défaillances…
  • Mise en production de correctif

Mise à disposition tardive de ressources

  • Impact sur les plannings
  • Manque d’implication des exploitants au démarrage des projets
  • Infrastructures nécessaires pas toujours livrées à temps

Environnements de développement peu conformes à l’environnement cible de production

  • Pas de contraintes d’un environnement dit « de production » (plusieurs serveurs, gestion de flux réseaux complexes, configurations différentes, systèmes d’exploitation différents…)
  • Un développeur installe son propre serveur web avec sa configuration habituelle, sa base de donnée habituelle sur son système d’exploitation préféré…
  • Conséquence : une détection tardive des problèmes d’intégration

Manque de confiance entre le développement et l’exploitation

  • Frilosité de l’équipe d’exploitation à tester certaines livraisons

Manque de dialogue entre l’équipe de développement et l’équipe d’exploitation

Comment puis-je évaluer mon équipe DevOps ?

Niveau de maturité de mon équipe DevOps

Une définition de 5 niveaux de maturité a été défini :

  • Initial
  • Managé
  • Défini
  • Mesuré
  • Optimisé
mature.png

Niveau de maturité du DevOps

matdesc.png

Tableau de maturité

Ça passe toujours mieux avec un petit Comics

dev1.png

Entraide

dev2.png

Empathie

Principes et obstacles

Les quatre piliers du DevOps « C.A.M.S. »

Culture

  • Le capital humain est la composante essentielle de la méthode.
  • Encourager la communication
  • Avoir une vision commune

Automatisation

  • Automatiser les différentes tâches du cycle de développement et mise en production d’un système
  • Réduire les interventions manuelles
  • Aller vers le « continuous operations »
  • « Infrastructure as code »

Mesure

  • Instaurer un système de métriques qui permette de mesurer en continu et en temps réel le système
  • Donner de la visibilité sur ces métriques au plus grand nombre à travers des tableaux de bord partagés

Partage (« sharing »)

  • Le partage et la collaboration sont au cœur du processus DevOps.
  • Il faut partager aussi bien les succès que les échecs !
  • Travail en équipe intégrée et collaborative

Obstacles

Culturel

  • Les équipes de développement et d’exploitation travaillent souvent de façon cloisonnée.

Organisationnel

  • Les processus IT sont historiquement structurés de manière verticale et favorisent le travail en silo.
  • Les bonnes pratiques utilisées dans les DSI (notamment ITIL) favorisent la segmentation.

Objectifs divergents

  • Fournir de nouvelles fonctionnalités vs garantir la haute disponibilité du système
wall.png

Le mur entre les dev et la prod

Les pratiques contre productive

Anti-pattern n°1 : l’outil magique

Ne pas confondre DevOps et automatisation

  • Il n’existe pas d’outil magique fluidifiant comme par magie le processus de mise en production.
  • Si l’idée de cet outil provient des équipes de développement, les opérationnels penseront qu’on veut les remplacer. Au contraire, si l’idée vient des opérationnels, les développeurs se sentiront peu (voir pas du tout) impliqués.
  • Le plus important n’est pas l’outil mais bien la culture de l’échange et de la communication entre les équipes.

Construire une vraie culture de la qualité est bien plus complexe que d’installer un outil mais il s’agit de la seule façon efficace d’améliorer la chaine de valeur et d’obtenir les bénéfices escomptés par l’application des pratiques DevOps.

Anti-pattern n°2 : l’équipe merveilleuse

Ne pas croire qu’une équipe dédiée DevOps est la bonne solution

  • Quasiment aussi courant que l’anti-pattern « j’impose un outil », voici l’anti-pattern « l’équipe merveilleuse », qui consiste tout simplement à créer une équipe dédiée à la mise en place d’une démarche DevOps au sein de l’entreprise.
  • Une des raisons principales du DevOps est de faciliter le passage du logiciel de l’équipe de développement à la mise en production et de pouvoir livrer des fonctionnalités rapidement. Ajouter une nouvelle équipe n’est pas la bonne façon de faire, sauf à imaginer que cette nouvelle équipe soit en charge de l’amélioration des pratiques et de la transformation des autres équipes.

Le but de DevOps est de supprimer les silos, et non pas d’en créer un nouveau : il faut faciliter le passage du livrable d’une couche à une autre.

Anti-pattern n°3 : l’histoire sans fin

Définir précisément les attendus

  • Nécessite l’implication mutuelle de chaque équipe dès le début du projet
  • Choix de la « Definition of Done » dans un contexte Agile
    • Ne pas trop la réduire
    • Focus sur la valeur ajoutée au client et non seulement sur le commit du code ou encore l’acceptation du product owner
    • Inclure les Ops

Il est capital de se mettre à la place de l’autre, celui qui reçoit une livraison ou doit utiliser un script de déploiement.

Anti-pattern n°4 : ça marche chez moi

Veiller à impliquer l’ensemble des acteurs

  • Développeurs et opérationnels : même combat !
  • Partager les différents indicateurs de santé de la plateforme
  • Notifier les développeurs en même temps que les opérationnels en cas de problème sur la plateforme
  • Mettre en place des tests de performance en continu sur un environnement de pré-production toujours dans le but de partager des métriques communes entre les équipes opérationnelles et de développement

De manière plus générale, chaque personne de l’équipe doit se sentir responsable des fonctionnalités livrées à l’utilisateur. Problèmes de code ou problèmes d’infrastructure doivent avoir le même résultat : chacun doit se sentir concerné.

Anti-pattern n°5 : nous sommes uniques

Ne pas croire que notre entreprise est tellement particulière que ces nouvelles techniques ne fonctionneront pas.

  • Oui, mais c’est le cas de tout le monde !
  • La mise en place des principes DevOps prend du temps et se fait par incrément.
    • Commencer petit pour apporter confiance et crédibilité
    • Puis mettre en place des métriques représentatives
      • Mesurer est un principe essentiel de DevOps.
      • Appuyer son histoire DevOps sur des données chiffrées est toujours plus convaincant et objectif que de l’appuyer sur des sentiments.
    • Attirer les personnes curieuses
  • Promouvoir l’amélioration continue
    • Apprendre de ces problèmes
    • Retirer (ou automatiser) les étapes ne créant pas de valeurs suivant une démarche typiquement Lean

Facteurs de succès

Une autre façon de penser l’architecture

L’architecture doit être pensée pour du DevOps Virtualisation & Cloudification

  • Des rajouts de capacité doivent devenir des « non évènements »

Mise à disposition d’API par les équipes de production

  • Ouvertes, disponibles, maitrisées
  • Changement de champ de responsabilités

Penser en amont résilience, performance, sécurité

  • Cadrage d’architecture fort en amont

Remonter des contraintes de run au niveau du build Accroitre la surface des « backlogs » aux utilisateurs « au sens large » du système

  • Sécurité
  • Exploitation
  • Fournisseurs…
qualite.png

Éxigences

Le nouveau rôle des développeurs

Objectif permanent de qualité

  • Adapter les processus de test pour les rendre automatiques
  • Ecrire les tests d’intégration (si possible automatisés) avant le développement
    • « Test Driven Development »
  • Adopter une approche pilotée par les tests métier
    • « Acceptance Test Driven Development » : on substitue les spécifications détaillées par des tests d’acceptation à valider
    • Les tests métier sont définis par un product owner (dans un contexte Agile)
    • Et sont implémentés par les développeurs

Le nouveau rôle des exploitants

Déploiement

  • Pas seulement un rôle d’exécutant
  • Implication dans la conception du déploiement
  • Les opérations de packaging des binaires, de configuration des serveurs et de déploiement des binaires font partie d’un processus outillé et automatisé.

Surveillance

  • Les notions de monitoring et le logging deviennent fondamentalement liées à la notion de qualité.
  • On ne doit plus se limiter à avoir des métriques destinées aux seuls exploitants, mais aussi des métriques applicatives destinées aux métiers et aux développeurs.

L'usine logicielle

Des profils mixtes dev/prod/admin rassemblés

  • Release Manager
  • Test Automation
  • SysAdmin

Co-localisation des acteurs

Infrastructure as Code

Que veux dire ce barbarisme ?

  • Une approche qui définit l’infrastructure matérielle et réseau comme du code source et qui peut donc être traité comme n’importe quel système logiciel.
  • Pourquoi l’adopter ?
  • Contrôle de source

Auditabilité et reproductibilité

  • Adapté aux pratiques de test automatisé
  • Permet de gérer de petits changements plutôt que de gros ensemble d’un coup
periodtable.png

Classification périodique « DevOps »

Politique technique

Nécessité d’avoir une politique technique forte et largement diffusée

  • Définition d’un référentiel commun et partagé d’outils

Exemple

  • Aide aux choix de technologies vis-à-vis de problèmes répertoriés
  • Notion de conformité
  • Déviation par rapport à la politique technique possible mais responsabilité engagée et justification exigée

Continuous Opération

Association de 5 principes:

  • Développement continu
  • Intégration continue
  • Tests en continu
  • Packaging en continu
  • Déploiement continu
continuous.png

Cycle de production continu

En résumé !

Les facteurs clés du succès de la mise en place d'une démarche DevOps sont :

Gestion de l’humain

  • L'évolution des compétences individuelles
  • La définition d'indicateurs communs pour les Dev et Ops
  • La mise en place d’une culture commune entre les Devs et Ops qui favorise les cérémonies communes
  • La communication vers les équipes IT opérationnelles
  • Le support du management
  • La conduite du changement

Outillage

  • Ne pas imposer un outil sans s’assurer qu’il corresponde aux besoins
  • Prendre en compte le temps de mise en place des outils et de la montée en compétence de leurs utilisateurs
  • Ne pas avoir un héros, seul à maîtriser le système
  • Tester avant de déployer
 Retour