Le Miracle DevOpsComment accélérer le passage en production

1

matts2cant@gmail.com

@matts2cant

2

• Le besoin de rapidité

• Le miracle DevOps : Les faits

• Mettre en place DevOps, pas à pas

3

Le business nécessite la rapidité

4

Le cycle en V est long et risqué …

?

5

… bien plus long et risqué que prévu

• Une étude de 2 professeurs d’Oxford sur 1471 projets IT d’envergure montre :

• 1 projet sur 6 coute en moyenne 3x plus que prévu

• Exemple :

• Faillite de FoxMeyer Drugs après être passé brutalement à SAP

Oxford study: http://eureka.bodleian.ox.ac.uk/897/1/WP_2011_08_15.pdf Fox-Meyer bankruptcy: http://fr.slideshare.net/jmramireza/the-foxmeyer-drugs-bankruptcy-was-it-a-failure-of-erp-2332065 6

Nos cerveaux estiment très mal la probabilité des évènements rares

7

-Machiavel

« Divide et impera! »(Diviser pour régner)

8

Le développement agile : Une série de « fausses » iterations

9

Car les features s’entassent et ne passent pas en production

DEVS OPS10

Scrum n’est que le début

Jeff SutherlandKen Schwaber

11

• Le besoin de rapidité

• Le miracle DevOps : Les faits

• Mettre en place DevOps, pas à pas

12

DevOpsRésoudre le problème du silo

13

Faire travailler en

équipe les Devs en les Ops vers des

objectifs communs

14

La trinité DevOps

15

L’efficacité du DevOps est largement documentée sur le web

• Rapport de productivité sur 620 ingénieur (RebelLabs, 2013)

• Rapport « State of DevOps » sur 4000 ops et devs (PuppetLabs, 2013)

• And all the testimonials from web leaders like Amazon, Netflix, Etsy, Flickr, etc. (at Velocity Conference, DevopsDays, etc.)

State of DevOps by puppet labs: https://puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-devops-report.pdf RebelLabs productivity report: http://pages.zeroturnaround.com/RebelLabs-AllReportLanders_DevopsProductivityReport.html 16

Les DevOps délivrent 30% plus fréquemment

• 7% des non-DevOps déploient sur demande contre 27% pour les devOps

• 35% des non-DevOps déploient moins d’une fois par mois contre 13% pour les DevOps

Temps moyen entre déploiements

0

25

50

75

100

Non DevOps DevOps > 1 an

> 180 jours30 - 180 jours7 - 30 jours1 - 7 joursSur demande

17

Les DevOps délivrent 8000x plus vite !

• 7% des non-DevOps déploient en moins d’une heure contre 23% pour les devOps

• 25% des non-DevOps nécessitent plus d’un mois a déployer !

Temps moyen d’un déploiement

0

25

50

75

100

Non DevOps DevOps > 1 an

> 6 mois1 - 6 mois7 - 30 jours1 - 7 jours< 1 jour< 1 heure

18

Les DevOps ont 50% d’erreurs en moins

• Les équipes qui échouent plus d’un déploiement sur dix passent de 40% à 23% avec DevOps

Temps moyen entre déploiements

0

25

50

75

100

Non DevOps DevOps > 1 an

> 50%30 - 50%10 - 30%5 -10%< 5%

19

Les DevOps ont 50% d’erreurs en moins

• 47% des équipes DevOps résolvent leurs erreurs de déploiement en quelques minutes seulement

Temps moyen de résolution

0

25

50

75

100

Non DevOps DevOps > 1 an

Plusieurs joursQuelques heuresMoins d'une heureQuelques minutes

20

Amazon déploie en moyenne 300 fois par heure

• Fondé en 1994, 75 Milliard $ en 2013

• Temps moyen entre les déploiements : 11.6s

• Nombre max de déploiements en une heure : 1079

• Nombre moyen de machines hôtes : 10000

http://assets.en.oreilly.com/1/event/60/Velocity%20Culture%20Presentation.pdf http://en.wikipedia.org/wiki/Amazon.com 21

Chez Etsy, chaque ingénieur déploie le jour de son arrivée

• Fondé en 2005, 1 Milliard $ de transactions en 2013

• 250+ contributeurs, chaque personne déploie

• 30+ déploiements par jour

• Chacun déploie le jour de son arrivée

http://codeascraft.com/2012/03/13/making-it-virtually-easy-to-deploy-on-day-one/ https://speakerdeck.com/astanway/bring-the-noise-continuously-deploying-under-a-hailstorm-of-metrics http://gigaom.com/2013/08/23/meet-the-man-behind-new-yorks-other-billion-dollar-internet-company-this-one-makes-money/ 22

Le gouvernement Anglais a adopté DevOps de manière de manière radicale en

moins d’un an

• gov.uk est le site de tous les départements et agences publiques

• Version alpha en 2011 avec 4 devs

• Site live en octobre 2012

• 15-20 déploiement par jour

• Principal argument commercial : plus rapide que tous les autres prestataires

http://vimeo.com/album/2384821/video/66622266 https://github.com/philandstuff/devopsdaysparis#kushal-pisavadia-kushalp-how-we-ship-software-at-govuk https://www.gov.uk/service-manual 23

• Le besoin de rapidité

• Le miracle DevOps : Les faits

• Mettre en place DevOps, pas à pas

24

Créer un esprit d’équipe entre les devs et les ops

• 1. Eduquer les devs sur les contraintes opérationnelles

• 2. Inciter les ops a déléguer du pouvoir aux devs

• 3. Mélanger les équipes de devs et d’ops

25

Le background « classique » d’un développeur

• A appris Java en école/a l’université

• Utilise Windows (Jeux !)

• A installé Linux car il est curieux

• A réalisé plusieurs sites pour son école ou ses amis

• Déploie avec FileZilla

26

Etape 0 : Transformer le bébé dev en dev respectable

• Environnement Unix

• Contrôle de version (Git)

• Workflow

• Méthodologie agile

• Tests unitaires et fonctionnels

27

Etape 1 : Lui donner un serveur pour s’amuser

• Donner une instance micro a tout le monde

• Libre de faire ce qu’on veut, quand on veut dessus

• … tout en restant légal :)

28

Etape 2 : Lui faire installer un serveur … au moins deux fois

• Beaucoup de devs juniors n’ont jamais installé de serveurs

• Deux fois : pour comprendre l’intérêt du provisioning automatique

29

Etape 3 : Le faire déployer … et comprendre comment ça marche

• Script shell ✘• Capistrano ✔• Fabric ✔• Ansible ✔

30

Etape 4 : Faire du monitoring une étape évidente

• Le monitoring est devenu facile (NewRelic, AppDynamic, ELK)

• Facilite de debug (StackTraces, Requêtes SQL, Page performances, HealthCheck)

31

Etape 5 : Responsabiliser les devs sur l’intégration continue

• Jenkins : Très flexible et complet

• Travis-CI : Très facile a mettre en place

• CodeShip : Déploiement continu

• GitLab-CI : Intégration avec GitLab

32

Etape 6 : Normaliser les environnements avec Vagrant

• Limite les effets de bord (32/64 bits, Configuration, OS, etc.)

• Différents providers (VirtualBox, Openstack, EC2, Docker, etc.)

• vagrant package : share boxes between devs

33

Etape 7 : utiliser Vagrant avec un provisioning automatique

• Apprendre puppet et chef est une étape douloureuse pour un dev … mais moins que le provisioning manuel

• Pour créer le script:• Un Ops expérimenté crée un template• Un Dev expérimenté challenge et simplifie

34

Etape 8 : Utiliser le cloud !

• Cloud privé : Openstack

• Cloud publique : Amazon EC2

35

Etape 9 : Rendre le backup facile

• Push to S3/Swift

• Ou des solutions comme Idera ServerBackup

36

Etape 10 : Créer une plateforme de test de charge

• Créer un serveur facile d’accès (VNC) avec une grande bande passante

• Les Ops expliquent aux Devs ce qu’est un bon test de charge

• Tester les performances régulièrement avec Devs+Ops37

Etape 11 : Inciter au « pair-devopsing »

• Les devs ont un problème avec Puppet/Chef ?• Les tests de charge montrent un problème de performances ?• Les Ops voient des erreurs dans les logs ?

!

-> Pair devopsing

38

Etape 12 : Utiliser la management visuel pour aligner les intérêts

Comment amener les devs a s’intéresser aux performances :• L’inclure dans la definition du DONE• Inclure des solutions de mesure de performances dans le

provisioning• Afficher des graphes de performances

39

40

Prochaines étapes :

• Velocity conferences• http://lanyrd.com/2013/velocity/coverage/• http://lanyrd.com/2012/velocity/coverage/

• “Top 11 things you need to know” - Gene Kim• http://www.thinkhdi.com/~/media/HDICorp/Files/White-Papers/

whtppr-1112-devops-kim.pdf

• Blog Etsy• http://codeascraft.com/

• Blog Netflix• http://techblog.netflix.com/

41

DevOps is hard

42

Questions ?matts2cant@gmail.com

@matts2cant

43