The Wide Range of DevOps

DevOps is a cultural and professional movement. Practicing DevOps in your organization doesn't need to require massive change! DevOps is a wide range, and this talk presents how to move your organization towards the DevOps culture.

Transcript

1. The wide range of DevOps
2. Mitchell Hashimoto @mitchellh
3. Vagrant
6. — DevOps
7. — Memes W ARNING!
8. I got into DevOps by accident. (But I love it!)
9. Confession: I’m new to this.
10. No experience with Rack & Stack.
11. I am the Cloud generation.
12. More specifically... I am the bridge.
13. I practice DevOps!
14. But my devs don’t do ops...
15. Is this still DevOps?
16. DevOps: A range.
17. Based on my experience transitioning to DevOps...
18. Vagrant
20. 2 people to 200 people
21. Ops is a black box. Devs do all ops
22. Ops is a black box. Devs do all ops The Range Requires More than Ops
23. Ops is a black box. Devs do all ops Road to... increased stability. Road to... faster feedback. Road to... cheaper iteration.
24. Metrics, metrics, everywhere.
25. What does my code do?
26. What is the system -wide effect of this change?
27. Why is my service slow?
28. Ops knows.
32. Developers should know, too.
34. It should be easy
35. Remember, we’re right here now.
36. How do we make this easy?
38. Graphite + Statsite = —
39. That was easy.
42. Insight into... performance Insight into... system-wide effect Insight into... ops!
43. Document your infrastructure
45. “Its easy!”
46. “Its easy!” Your request comes in. IPTables lets it pass through because its global traffic on a load balancer. It then hits an SSL terminator which proxies the request back to a level 7 load balancer, which round robins the request to an app server. If its a static file request its served directly off disk otherwise it goes to the actual application process. Now your code is executed. Got it? Ready to learn about service orchestration, response caching, and how the site stays running?
48. 1. Document your ops.
50. Topics... Deploy process Lifecycle of a request How do new servers come online? Coding guidelines for Cookbooks Failures and resolutions (automated or not) Tools guides (htop, lsof, ps, netcat, strace) Development VM internals (Vagrant)
51. Remove the Black Box
52. 2. Company Tech Talks
53. Bi-weekly. Short (15 minutes). Deep dives.
54. Topics... HAProxy Vagrant Configuration management philosophy On-Call Practices Infrastructure testing and verification
55. Deeper understanding of technologies in use
57. Insight into... architecture Insight into... scalability Insight into... how code is executed Insight into... ops!
58. Production-mirror Dev Environments
59. Vagrant
60. Duplicate efforts for production vs. development?
61. Use production ops for development
62. Extra effort involved. Big gain.
63. Small effect on developer workflow.
65. Insight into... provisioning Insight into... server evolution Insight into... architecture Insight into... ops!
66. DevOps Office Hours
67. Ops can be scary to those new to it.
68. What was that?!
69. Luckily, we’re friendly.
70. Ops office hours. Dev office hours.
71. A comfortable environment to ask and learn anything.
73. Office hour activities... Architecture explanation Fast Chef tutorial Help with cookbook bugs Teaching how current cookbooks work Code review!
74. My Office Hours: Mondays 3 - 5 PM
76. Insight into... anything Provides a safe, comfortable learning environment.
77. Automated Infrastructure Tests
78. Warning: This field is still under heavy development
79. Honestly: I don’t trust devs to do ops, right now.
80. But... I don’t need to.
82. Test that Chef runs complete successfully.
83. Run integration tests on top of that.
84. My Opinion: “Unit tests” for ops is still too new and doesn’t excite me yet.
85. Test at high level... Do the new changes apply cleanly? Can I still load the website? Is it still secure? Do all the interactions with the site still work?
86. Can we do better?
87. Can we do better? I think so. We need tools.
88. Also: Code Review
89. Ops engineers verify any non-ops contributions
91. Developers are now safe to make their own ops changes.* * Ops supervision still important
92. Devs: Go Crazy.
93. A strong foundation.
94. Powerful insight via metrics.
95. Powerful insight via metrics. In-depth documentation.
96. Powerful insight via metrics. In-depth documentation. Production-mirror development.
97. Powerful insight via metrics. In-depth documentation. Production-mirror development. A safe learning environment.
98. Powerful insight via metrics. In-depth documentation. Production-mirror development. A safe learning environment. Infrastructure verification.
99. Powerful insight via metrics. In-depth documentation. Production-mirror development. A safe learning environment. Infrastructure verification. Devs doing Ops.
100. Powerful insight via metrics. In-depth documentation. Production-mirror development. A safe learning environment. Infrastructure verification. But: This is all DevOps.
101. Ops is a black box. Devs do all ops
102. WAIT! The most important question of all...
103. Who wears the pager?
104. On-call rotation for everybody.
105. Problem/Solution not in the Wiki? Call in the ops engineer.
106. Can’t fix the problem in 5 minutes or less? Call in the ops engineer.
107. I only care about the site or services going down.
108. Nagios [almost] never wakes me up.
110. People aren’t overworked. Everyone shares responsibility.
111. THANK YOU I — DevOps Questions?