The following talk was given at DevOps Days Ohio 2015. It is an ignite style talk — 20 slides, 15 seconds per slide and the slides auto-advance. Video will soon follow, but putting this up to share. For this talk, all the slides were hand drawn and lettered.
Greetings! My name is Matt Williams and I’ll be speaking about the three ‘R’s of DevOps. The slides today are something of a blast from the past meant to evoke chalkboard drawings like you’d see in school.
<sing> School Days, School Days, Good old golden rule days. Reading and Writing and Rithmatic…. </sing> Sorry, just had to be done. Like the 3 ‘R’s of school, the 3 R’s of DevOps form the foundation upon which everything is built.
Reading and company are abilities which form the foundation of success. It’s no coincidence that the 3 ‘R’s of DevOps are also abilities:
It all starts with repeatability. There’s an old practice of sys admins – do a thing a time or three so that you understand it, then automate. However, if it isn’t repeatable…. automation is an exercise in futility.
Repeatability begins with everyone’s favorite topic – documentation. Without docs we have tribal rumour and legend. As people move on, the myths and stories are lost.
Going hand in hand with documentation are processes – clearly defined (and documented!!!) processes.
Repeatable processes lead to repeatable builds and deployments.
Tests are important, but it isn’t enough to do them; they need to be repeatable as well.
Once we have repeatability, we can then proceed to our second ability: reproducibility.
Reproducibility includes being able to reproduce bugs.
One of the best effects of reproducibility is having known outcomes – 2 + 2 = 4, for all values of two.
Reproducibility puts paid to the claim…. “But it worked in Dev”. If it doesn’t work in QA or Prod, then it couldn’t have worked in Dev.
Infrastructure as code enables reproducible servers, networks, and services. Version control ensures repeatability and reproducibility.
Everyone, please repeat after me: No Snowflakes!
Measure all the things. Without metrics, you can’t say if a system is reliable.
For those times when something actually happens, monitoring and alerting will let you know – before the Hyena comes!
Calls in the night persist in memory long after the problem is fixed. Reliable systems have few calls.
It’s not an ‘R’, but an ability… being flexible is an outcome of the three R’s.
Just like Maslow’s Hierarchy, Repeatability leads to Reproducibility and finally to Reliability. Thank you and I hope you remember the 3 R’s of DevOps.