10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
âą
1,010 gefĂ€llt mirâą1,021,652 views
Communications and cooperation between development and operations isn't optional, it's mandatory. Flickr takes the idea of "release early, release often" to an extreme - on a normal day there are 10 full deployments of the site to our servers. This session discusses why this rate of change works so well, and the culture and technology needed to make it possible.
Empfohlen
Empfohlen
Weitere Àhnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ăhnlich wie 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
Ăhnlich wie 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr (20)
Mehr von John Allspaw
Mehr von John Allspaw (15)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (20)
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
- 1. 10 deploys per day Dev & ops cooperation at Flickr John Allspaw & Paul Hammond Velocity 2009
- 2. 3 billion photos 40,000 photos per second http://ïŹickr.com/photos/jimmyroq/415506736/
- 4. âItâs not my machines, itâs your code!â
- 5. âItâs not my code, itâs your machines!â
- 6. Spock Scotty Little bit weird Pulls levers & turns knobs Sits closer to the boss Easily excited Thinks too hard Yells a lot in emergencies
- 8. Says âNoâ all the time Afraid that new fangled things will break the site Fingerpointy
- 9. Ops stereotype Because the site breaks unexpectedly Because no one tells them anything Because They say âNOâ all the time
- 10. http://www.ïŹickr.com/photos/stewart/461099066/ Traditional thinking Devâs job is to add new features Opsâ job is to keep the site stable and fast
- 11. Opsâ job is NOT to keep the site stable and fast
- 12. Opsâ job is to enable the business (this is devâs job too)
- 13. The business requires change
- 14. But change is the root cause of most outages!
- 15. Discourage change in the interests of stability or Allow change to happen as often as it needs to
- 16. Lowering risk of change through tools and culture
- 17. Dev and Ops
- 18. Ops who think like devs Devs who think like ops
- 20. You can always think more like them
- 21. Tools
- 22. 1. Automated infrastructure If there is only one thing you doâŠ
- 23. CFengine Chef BCfg2 FAI 1. Automated infrastructure If there is only one thing you do⊠System Imager Puppet Cobbler
- 25. 2. Shared version control
- 26. Everyone knows where to look http://www.ïŹickr.com/photos/thunderchild5/1330744559/
- 27. 3. One step build
- 29. 3. One step build and deploy
- 32. [2009-06-22 16:03:57] [harmes] site deployed (changes...) Who? When? What?
- 34. Small frequent changes http://www.ïŹickr.com/photos/mauren/2429240906/
- 35. 4. Feature ïŹags (aka branching in code)
- 36. 1.0.1 1.0.2 1.0 1.1 1.2 1.1.1 Desktop software
- 37. r2301 r2302 r2306 Web software
- 39. Everyone knows exactly where to look http://www.ïŹickr.com/photos/thunderchild5/1330744559/
- 40. Feature ïŹags #php if ($cfg['enable_feature_video']){ ⊠} {* smarty *} {if $cfg.enable_feature_beehive} ⊠{/if}
- 41. http://www.ïŹickr.com/photos/healthserviceglasses/3522809727/ Private betas
- 43. http://www.ïŹickr.com/photos/jking89/3031204314/ Dark launches
- 44. Free contingency switches http://www.ïŹickr.com/photos/ïŹattop341/260207875/
- 49. Adaptive feedback loops RU ok? App System Metrics maybe?
- 51. 6. IRC and IM robots
- 52. Dev, Ops, and Robots Having a conversation build deploy logs logs alerts monitors IRC search engine
- 53. Culture
- 54. 1. Respect If there is only one thing you doâŠ
- 55. Donât stereotype (not all developers are lazy) http://www.ïŹickr.com/photos/aaronjacobs/64368770/
- 56. http://www.ïŹickr.com/photos/chrisdag/2286198568/ Respect other peopleâs expertise, opinions and responsibilities
- 57. http://www.ïŹickr.com/photos/jwheare/2580631103/ Donât just say âNoâ
- 58. http://www.ïŹickr.com/photos/alancleaver/2661424637/ Donât hide things
- 59. Developers: Talk to ops about the impact of your code: âą what metrics will change, and how? âą what are the risks? âą what are the signs that something is going wrong? âą what are the contingencies? This means you need to work this out before talking to ops
- 60. 2. Trust
- 61. Ops needs to trust dev to involve them on feature discussions Dev needs to trust ops to discuss infrastructure changes Everyone needs to trust that everyone else is doing their best for the business http://www.ïŹickr.com/photos/85128884@N00/2650981813/
- 62. http://www.ïŹickr.com/photos/ïŹattop341/224176602/ Shared runbooks & escalation plans
- 63. http://www.ïŹickr.com/photos/telstar/2861103147/ Provide knobs and levers
- 64. http://www.ïŹickr.com/photos/williamhook/3468484351/ Ops: Be transparent, give devs access to systems
- 65. 3. Healthy attitude about failure
- 67. If you think you can prevent failure then you arenât developing your ability to respond http://www.ïŹickr.com/photos/toms/2323779363/
- 72. Fingerpointyness problem!!! argggh! ïŹxed. freaking out, blaming, whining, ïŹguring it ïŹxing things not talking, covering hiding. out ïŹnding fault ass hurt egos time
- 73. Being productive problem!!! argggh! ïŹxed. ïŹguring it ïŹxing things feeling move out guilty on with life time
- 74. Developers: Remember that someone else will probably get woken up when your code breaks http://www.ïŹickr.com/photos/alex-s/353218851/
- 75. http://www.ïŹickr.com/photos/allspaw/2819774755/ Ops: provide constructive feedback on current aches and pains
- 76. 1. Automated infrastructure 2. Shared version control 3. One step build and deploy 4. Feature ïŹags 5. Shared metrics 6. IRC and IM robots 1. Respect 2. Trust 3. Healthy attitude about failure 4. Avoiding Blame
- 77. This is not easy You could just carry on shouting at each otherâŠ
- 78. (Thank you)