The Wide Range of DevOps

Transcript

1. The wide range of DevOps

2. Mitchell Hashimoto @mitchellh

3. Vagrant

4. None
5. None

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

19. None

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.

29. None
30. None
31. None

32. Developers should know, too.

33. None

34. It should be easy

35. Remember, we’re right here now.

36. How do we make this easy?

37. None

38. Graphite + Statsite = —

39. That was easy.

40. None
41. None

42. Insight into... performance Insight into... system-wide effect Insight into... ops!

43. Document your infrastructure

44. None

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?
47. None

48. 1. Document your ops.

49. None

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

56. None

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.

64. None

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.

72. None

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

75. None

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.

81. None

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

90. None

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.

109. None

110. People aren’t overworked. Everyone shares responsibility.

111. THANK YOU I — DevOps Questions?