The DevOps Wonder @ PHPTour Lyon 2014

1. Le Miracle DevOps Comment accélérer le passage en production 1

2. matts2cant@gmail.com @matts2cant 2

3. • Le besoin de rapidité • Le miracle DevOps : Les faits • Mettre en place DevOps, pas à pas 3

4. Le business nécessite la rapidité 4

5. Le cycle en V est long et risqué … ? 5

6. … 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

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

8. -Machiavel « Divide et impera! » (Diviser pour régner) 8

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

10. Car les features s’entassent et ne passent pas en production DEVS OPS 10

11. Scrum n’est que le début Jeff SutherlandKen Schwaber 11

13. DevOps Résoudre le problème du silo 13

14. Faire travailler en équipe les Devs en les Ops vers des objectifs communs 14

15. La trinité DevOps 15

16. L’eﬃcacité 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, Netﬂix, 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

17. 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 jours 30 - 180 jours 7 - 30 jours 1 - 7 jours Sur demande 17

18. 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 mois 1 - 6 mois 7 - 30 jours 1 - 7 jours < 1 jour < 1 heure 18

19. 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

20. 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 jours Quelques heures Moins d'une heure Quelques minutes 20

21. 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

22. 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

23. 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

25. 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

26. 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

27. Etape 0 : Transformer le bébé dev en dev respectable • Environnement Unix • Contrôle de version (Git) • Workﬂow • Méthodologie agile • Tests unitaires et fonctionnels 27

28. 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

29. 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

30. Etape 3 : Le faire déployer … et comprendre comment ça marche • Script shell ✘ • Capistrano ✔ • Fabric ✔ • Ansible ✔ 30

31. 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

32. Etape 5 : Responsabiliser les devs sur l’intégration continue • Jenkins : Très ﬂexible et complet • Travis-CI : Très facile a mettre en place • CodeShip : Déploiement continu • GitLab-CI : Intégration avec GitLab 32

33. 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

34. 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 simpliﬁe 34

35. Etape 8 : Utiliser le cloud ! • Cloud privé : Openstack • Cloud publique : Amazon EC2 35

36. Etape 9 : Rendre le backup facile • Push to S3/Swift • Ou des solutions comme Idera ServerBackup 36

37. 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+Ops 37

38. 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

39. 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 deﬁnition du DONE • Inclure des solutions de mesure de performances dans le provisioning • Aﬃcher des graphes de performances 39

40. 40

41. 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 Netﬂix • http://techblog.netﬂix.com/ 41

42. DevOps is hard 42

43. Questions ? matts2cant@gmail.com @matts2cant 43

The DevOps Wonder @ PHPTour Lyon 2014

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

The DevOps Wonder @ PHPTour Lyon 2014

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (17)

Similaire à The DevOps Wonder @ PHPTour Lyon 2014 (20)

Plus récents (20)