Growing Next Generation Engineers

The revised Miyagi method. Presented at CfgMgmtCamp.eu Tue 03 Feb 2015.

Transcript

1. MR MIYAGI’s DevOps DOJO
2. MR MIYAGI’s DevOps DOJO
3. Growing the Next Generation of Engineers
4. Session Goals • Examine challenges we all face when trying to build out devops engineering teams ! • Create an actionable list of skills to cultivate so we can grow next gen engineers
5. GEORGE MIRANDA @gmiranda23 gmiranda@chef.io
7. TRAINING !
8. TRAINING PROFESSIONAL SERVICES
9. TRAINING PROFESSIONAL SERVICES Field enablement
10. PREVIOUSLY…
11. NOW…
12. QUICK SURVEY… WHO IS USING CONFIGURATION MANAGEMENT?
13. QUICK SURVEY… WHO CAN USE HELP MANAGING ALL OF THAT CONFIGURATION CODE?
14. QUICK SURVEY… WHO IS HIRING A “DEVOPS ENGINEER” TO MANAGE YOUR INFRASTRUCTURE?
15. QUICK SURVEY… WHO HAS BEEN HIRING A “DEVOPS ENGINEER” FOR AT LEAST ONE MONTH?
16. SURVEY RESULTS… HIRING A “DEVOPS ENGINEER” IS HARD!
17. WAIT, WHAT’S A “DEVOPS ENGINEER?” LET’S ASK GOOGLE! !
18. TWO CATEGORIES
19. TWO CATEGORIES RIDICULOUS REQUIREMENTS
20. TWO CATEGORIES RIDICULOUS REQUIREMENTS RE-LABELED REQUIREMENTS
21. TWO CATEGORIES RIDICULOUS REQUIREMENTS RE-LABELED REQUIREMENTS • 10+ YEARS EXPERIENCE WITH ANSIBLE • EXPERIENCE MANAGING PERL 6 IN PRODUCTION • COMPULSIVELY DESTROYS SILOS REINFORCED BY EVERY FACET OF CORPORATE CULTURE • DETAILED EXPERT LEVEL INSIGHT OF MANAGING AS/400 CONTINUOUS DELIVERY PIPELINES • KNOWS ALL POSSIBLE TAR FLAGS IN CORRECT ORDER
22. TWO CATEGORIES RIDICULOUS REQUIREMENTS RE-LABELED REQUIREMENTS • 10+ YEARS EXPERIENCE WITH ANSIBLE • EXPERIENCE MANAGING PERL 6 IN PRODUCTION • COMPULSIVELY DESTROYS SILOS REINFORCED BY EVERY FACET OF CORPORATE CULTURE • DETAILED EXPERT LEVEL INSIGHT OF MANAGING AS/400 CONTINUOUS DELIVERY PIPELINES • KNOWS ALL POSSIBLE TAR FLAGS IN CORRECT ORDER • SOLID LINUX OS MANAGEMENT EXPERIENCE • UNDERSTANDS IT BEST PRACTICES & ALWAYS-AVAILABLE SERVICES • SHELL SCRIPTING • COMFORTABLE WRITING TECHNICAL DOCUMENTATION • WILLING TO PARTICIPATE IN ON-CALL ROTATION • KNOWS ALL POSSIBLE TAR FLAGS IN CORRECT ORDER
23. WHAT THAT MEANS… I NEED HELP. I DON’T KNOW WHAT I NEED. GET ME HELP NOW!
24. IF WE DON’T KNOW WHAT THAT MEANS… WELL… WHAT *DO* WE KNOW?
25. WHAT IS “DEVOPS”? INSERT NEBULOUS IDEAS HERE
26. DevOps at its core: • Practitioner Driven • Practitioners discussing/sharing/evolving: • State of IT • How to do it better • Working together • Humane Systems • Open Practices Fundamentally rooted in the idea that our business needs to deliver software faster, safer, and more reliably into the hands of users.
27. DevOps at its core: • Practitioner Driven • Practitioners discussing/sharing/evolving: • State of IT • How to do it better • Working together • Humane Systems • Open Practices Fundamentally rooted in the idea that our business needs to deliver software faster, safer, and more reliably into the hands of users.
28. OKAY. HOW DO WE GET THERE? ! !
29. MAYBE VENDORS? WHAT ABOUT THAT“DEVOPS CLOUD MANAGEMENT TOOL SUITE” IN CIO MAGAZINE?
30. E N T E R P R I S E T O O L A D O P T I O N
31. E N T E R P R I S E T O O L A D O P T I O N
32. E N T E R P R I S E T O O L A D O P T I O N
33. MAYBE CERTIFICATIONS?
34. MAYBE CERTIFICATIONS? DEVOPS IS NOT A MULTIPLE CHOICE TEST.
35. SO WHAT’S LEFT? WHERE AM I SUPPOSED TO FIND PEOPLE TO ACCOMPLISH MY GOALS?
36. L E T ’ S TA L K A B O U T…
40. GO FROM HERO TO ZERO JENNIFER DAVIS (@SIGJE) HTTP://VIMEO.COM/104252736 !
41. WE DON’T NEED ROCKSTARS OR UNICORNS OR NINJAS ! WE NEED TO GET THINGS DONE
43. … MAYBE??? … HOW AM I SUPPOSED TO GET THINGS DONE IN THE MEAN TIME?
44. L E T ’ S TA L K A B O U T C O N S U LT I N G …
45. E V E RY O N E O N LY E V E R TA L K S A B O U T T H E K N O C K O U T P U N C H
46. E V E R Y T H I N G I E V E R N E E D E D T O K N O W A B O U T D E V O P S , I L E A R N E D F R O M M R . M I Y A G I
47. A POP-CULTURE PRIMER IN SIXTY SECONDS OR LESS… * FOR THOSE BORN AFTER DINOSAURS ROAMED THE PLANET
48. C O O L N E W K I D I N T O W N
49. C O O L N E W K I D I N T O W N
50. G E T S I N T O T R O U B L E
51. W I T H K A R AT E B U L L I E S
52. A L O T O F T R O U B L E
53. M I YA G I S AV E S D A N I E L
54. T H E Y M A K E A PA C T
55. C H O R E S ? ? ? W T F ? ! ?
56. I N S T I N C T I V E D E F E N S E
57. B E C O M E S A C H A M P I O N
58. S E E ?
59. MR MIYAGI’s DevOps DOJO
60. P R E - R E Q U I S I T E S
61. D A N I E L P L AY E D S O C C E R
62. D A N I E L R O D E H I S B I K E
63. T O O K K A R AT E AT T H E “ Y ”
64. “ F I R S T L E A R N S T A N D , T H E N L E A R N F L Y . N A T U R E R U L E , D A N I E L - S A N , N O T M I N E ”
65. You must be this tall • Use artifact repositories • If no internet access: host your own universe • End-to-end, granular, accurate map of the problem domain • Thorough domain expertise to build/deploy/ manage the *entire* stack • Network access to managed infrastructure • Local Admin rights on workstations • Basic scripting, working with CLIs or APIs • Dedicated resources (no context-switching)
66. DO NOT PASS GO DO NOT COLLECT $200
67. MR MIYAGI’s DevOps DOJO
68. W A X O N , W A X O F F
69. Convergent Infrastructure • Proper use of Configuration Management frameworks • Practice on the whole stack • Converge on a regular interval • Persistent changes must be captured in configuration code • Out-of-band change will be lost • Infrastructure as Code • Use it, don’t disable it
70. P A I N T T H E F E N C E
71. Local Development • Bring Production to your developers • This just in: Ops are developers too! • Disposable Dev Environments • Vagrant • Mad crazy providers! • Test on a reasonable facsimile of Production
72. P A I N T T H E H O U S E
73. Collaborative SCM • Open repositories • Fork anyone’s code • Contribute back to anyone’s code • Curate contributions to your own code • Comment, fix, improve submissions • Share commit rights • Encourage a culture of openness
74. “YOU CAN’T DIRECTLY CHANGE CULTURE. BUT YOU CAN CHANGE BEHAVIOR, AND BEHAVIOR BECOMES CULTURE” – LLOYD TAYLOR VP INFRASTRUCTURE, NGMOCO
75. “YOU CAN’T DIRECTLY CHANGE CULTURE. BUT YOU CAN CHANGE BEHAVIOR, AND BEHAVIOR BECOMES CULTURE” – LLOYD TAYLOR VP INFRASTRUCTURE, NGMOCO “… SOME TOOLS ENFORCE BEHAVIOR!” - ME
76. S A N D T H E F L O O R
77. Build Pipelines • SDLC Practices apply to Infrastructure Code • No one gets to push changes by hand • Set up rules for Code Review • Develop changes locally • Test (more later) • Check-in and submit for code review • CI jobs push (build) the change • You will feel like Daniel-san sanding the floor
78. L E A R N T O S T R I K E
79. Provisioning • Mr Gorbachev, tear down this server! • "Cloud" reduces the amount of blood, sweat, and tears required to get new infrastructure • Containers also reduce this effort • Roll out new systems often • Replace Production often • Make provisioning trivial • Can we be fully immutable?
80. “THIS IS WHAT I CALL DISPOSABLE COMPUTING. THROW AWAY A BROKEN PROCESS RATHER THAN TRYING TO FIX IT. MACHINES CAN BE MADE EXPENDABLE AS LONG AS THE TOTAL SOFTWARE IS DESIGNED FOR IT. NOT MUCH OF IT IS TODAY, BUT WE ARE GETTING THERE. NATURE SHOWS THAT THIS IS A GOOD WAY OF SCALING SERVICES.” – MARK BURGESS AUTHOR OF CFENGINE
81. L E A R N B A L A N C E
82. Metrics & Analytics • Monitor Everything • Log Everything • Graph Everything • Then DISPLAY it! • Give access to see the data freely • Get the data before you argue • Argue about what the data means
83. Blameless Culture • Failures will always happen • Mistakes, errors, slips, lapses: all opportunities to learn • Presume good intentions • Remove fear of punishment • Blameless Post-Mortems • Structured Incident Response • Produce actionable items to prevent the same thing in the future
84. “ Y O U R E M E M B E R L E S S O N A B O U T B A L A N C E ? L E S S O N N O T J U S T K A R A T E O N L Y ; L E S S O N F O R W H O L E L I F E . W H O L E L I F E H A V E A B A L A N C E , E V E R Y T H I N G B E B E T T E R . U N D E R S T A N D ? ”
85. 1 S T L E V E L M A S T E R E D
86. B U T N O W . . . Y O U ’ R E D A N G E R O U S !
87. T H E D R U M T E C H N I Q U E
88. Test Driven Infrastructure • Test your infrastructure like you test your applications: it’s ALL code! • Regression test during development (guards) • Unit test local development before commit • e.g. Kitchen.CI • Test on commit via CI, before code review • Test after code review passes at 1st integration point • Canary test Production • Test Test Test Test Test Test Test Test Test
89. “ K A R A T E I S T R A I N I N G T O F I G H T . ” “ T H A T W H A T Y O U T H I N K ? ” “ N O . ” “ T H E N W H Y T R A I N ? ” “ S O I W O N ' T H A V E T O F I G H T . ” “ M I Y A G I H A V E H O P E F O R Y O U . ”
90. C O N T I N U O U S D E L I V E R Y
91. . . . M O R E L I K E T H I S ?
92. SO TO RECAP…
93. • GET IN SHAPE! • CONFIGURATION MANAGEMENT • LOCAL DEVELOPMENT • COLLABORATIVE SOURCE CONTROL • BUILD PIPELINES • METRICS & ANALYTICS • BLAMELESS CULTURE • CONSTANT PROVISIONING • TEST DRIVEN INFRASTRUCTURE
94. • GET IN SHAPE! • CONFIGURATION MANAGEMENT • LOCAL DEVELOPMENT • COLLABORATIVE SOURCE CONTROL • BUILD PIPELINES • METRICS & ANALYTICS • BLAMELESS CULTURE • CONSTANT PROVISIONING • TEST DRIVEN INFRASTRUCTURE … ALL STARTABLE TODAY!
95. • GET IN SHAPE! • CONFIGURATION MANAGEMENT • LOCAL DEVELOPMENT • COLLABORATIVE SOURCE CONTROL • BUILD PIPELINES • METRICS & ANALYTICS • BLAMELESS CULTURE • CONSTANT PROVISIONING • TEST DRIVEN INFRASTRUCTURE … THEN LET’S TALK ABOUT KNOCKOUTS
96. A N D , R E M E M B E R …
99. QUESTIONS? GMIRANDA@CHEF.IO @gmiranda23