Devops

• Devops comes from the lived experience of the practitioner
• Making it, in all cases, unique to the practitioner
• We had a lot of overlapping experiences though
• Relationship to failure
• High trust, high interaction relationships with each other
• A penchant for automation
• A tendency towards self reliance
• Obsession with metrics and graphs
• A focus on revenue and availability

Devops and the struggle for definition

• I think the struggle to define devops comes from this nature
• You can look at an individual, and see the 'school' they came from
• If you look at the 10 people I worked with longest, they way they 'do devops' is very, very similar to mine
• Its not surprise - our experiences are very similar
• The further you go from there, the more small differences there are
• In general, the macro trend holds - you can see us all under one umbrella, with many small differences

Gōngfu (功夫)

• 功 (gōng) meaning "work", "achievement", or "merit"
• 夫 (fū) often treated as being a word for "man"

The excellence achieved through long practice in one's skills

• Originally, it did not mean just to practice martial arts
• It referred to the process of ones training - the refinement of body and mind, the learning and perfection of your skills

Wushu (武术)

Many styles of Wushu

• Hundreds of different schools
• They vary widely on what they emphasize
• But the broad methods are the same
• Basics - the fundamental internal/external foundation
• Forms - a series of predetermined behaviors that can combine to a continuous way of acting
• Applications - using your Kung fu in the field, and adapting the basics and forms to your situational awareness Source - http://en.wikipedia.org/wiki/Kung_fu_%28term%29

• When you see someone doing it, and you are broadly ignorant, you know its different than boxing
• When you are someone who knows it well, you can tell the differences right away
• Its because the basics and forms are different
• Both are obviously fighters, but only one is Wushu
• You can have strong kung fu at both boxing and wushu
• Sound familiar?

• There is a deep well of practical philosophy
• There is a broad base of experience, unique to each individual
• We are recognizably similar
• There is a way to teach people how to do it
• It starts with the basics, and everyone must master them
• It moves to Forms - predetermined behaviors that can be combined into continuous sets of actions
• It ends in Application - actually doing your Kung fu in the field, using what you have learned
• TMTOWTDI is true and honest and important
• However - if you don't know how to do it, you could probably skip the 15+ year journey of difficulty
• And practice the basics, learn the forms, and apply them in your life

We can and often do argue about what it means

• Those arguments might change what overall makes a form
• But they don't change its nature
• We have a common language and palette for expression of our ideas

• CEOs and Executives
• Managers (Cyclops)
• Systems Administrators (Beast)
• Software Developers (Storm)
• Network Administrators (Kitty Pryde)
• Security Professionals (Wolverine)
• Sales Reps (Cannonball)
• Product Managers (Forge)
• All of these roles (and more) should practice our Kung fu

Chef Style DevOps Kung fu

This is my Devops Kung fu

• I call it "Chef Style"
• It comes from my experience
• As a systems administrator
• As a software developer
• As an entrepreneur
• As an executive
• As a human being dedicating my adult life to the internet
• As a father

• It draws on many important influences

• This talk is my foundational document of that Kung fu
• Once you have watched it, you can join my school
• We can develop the basics, our forms, and help on application
• Talib Kweli explained to me that artists amplify the movement they see in the world
• Marvin Gaye didn't write What's Goin On and
• then
• the movement happened
• The movement happened, and Marvin had to respond to, and amplify it, with his art
• That is my intent here - I will use my platform to raise up the voices of those who are doing the work
• And we can then leverage it as a platform to help each other
• And to further our aims of having our workplace be a better place

• The principles we aspire to (How you recognize DevOps when you see it)
• Wushu calls this the 'basics', but it involves a lot of pushups, and there isn't a lot of pushups in devops
• This includes a definition of DevOps
• The forms we use - the actual things we practice, that try and re-enforce and bolster our principles
• The application - the use of those forms in our actual situation
• These three things are the evolutionary arc of your practice - in the beginning, you learn from others
• As you grow, you will use the forms others have used to learn about the deeper meaning and philosophy
• The more you apply them in practice, the less reliant on the forms you will be - it all just becomes the natural flow
• Leading you, and anyone else, to be where those of us with already strong Kung Fu are - uniquely suited to our task
• (It's not about whether you are good at it - it's about the soul of our kung fu)

• Focused on how we build and operate - it encompasses the details of how we build things, and the details of how we operate them
• High velocity organizations - because we aren't very good at operating slow moving organizations; we were built to go fast
• Born from the experiences of it's practitioners - many of whom were the web innovators - because they were the first ones that had to go fast
• 'Do not be timid about the scope or the influence - we are re-inventing the way we run businesses"

• Focused on how we build and operate - it encompasses the details of how we build things, and the details of how we operate them
• High velocity organizations - because we aren't very good at operating slow moving organizations; we were built to go fast
• Born from the experiences of it's practitioners - many of whom were the web innovators - because they were the first ones that had to go fast
• 'Do not be timid about the scope or the influence - we are re-inventing the way we run businesses"

• High velocity organizations - because we aren't very good at operating slow moving organizations; we were built to go fast
• Born from the experiences of it's practitioners - many of whom were the web innovators - because they were the first ones that had to go fast
• 'Do not be timid about the scope or the influence - we are re-inventing the way we run businesses"

• Born from the experiences of it's practitioners - many of whom were the web innovators - because they were the first ones that had to go fast
• 'Do not be timid about the scope or the influence - we are re-inventing the way we run businesses"

• 'Do not be timid about the scope or the influence - we are re-inventing the way we run businesses"

Design for the safety, contentment, knowledge and freedom of both your peers and your customers.

• Design is fundamental
• Each choice you make needs to make life better for the humans involved
• That also leads to better business outcomes, as we'll learn later
• Ultimately, the most scalable, fastest systems are also the ones that are best for the humans involved, most of the time

• Imagine you were early days at twitter
• The system wasn't human safety critical, in your mind
• Until it became a source of human safety and communication during countless revolutions

• Happiness is fleeting
• If you are in trouble, contentment helps you make better decisions
• Think about a brutal on call week - if the systems that support you are good, you survive

• The right knowledge, at the right time
• Think about PaaS - it's awesome you just git push
• Until you are Rap Genius and heroku changes the router and everything sucks and you don't know why
• Which doesn't make PaaS awful - at a different level of criticality, who cares?

• The Big Web got this right
• Empower individuals to work as they see fit
• Trust them to do the right things
• Build systems that increase the trust needed to allow more freedom

People -> Product -> Company

• Both the producer and the consumer
• When you do the right thing for the people, the right things happen for the product and the company

• Failure is a learning opportunity
• a status quo event
• not an anomaly

Ubiquitous Workflow Automation

• Makes the easy path flow with our principles
• Make Conway's law work for you
• organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

• is good, both in thought, opinion, experience, and background
• this is sweeping kung fu - you need help
• Voices, stupidity, similarity
• You want harmony, thinking in different ways, bringing their skills to bear
• Good D+D parites are diverse
• We are not generalists - we are highly diverse specialists with high empathy and connection

• There are probably more, but these are core to Chef Style
• There are many, so we are going to go fast

• Need a sense of clearly defined purpose thats bigger than the task at hand
• Sources of engagement
• Gallup Q12
• Write it down publicly
• Always refer back to it in every internal communication
• Shoot for one sentence
• Include the people you are trying to help
• Include your product
• Include the change the people you are helping will see "The most enduring and transformative companies use Chef to become fast, efficient, and innovative software driven organizations" (Contentment, Knowledge, Freedom) (People over Product over Company) (Lean Product Development)

• Remember to use active voice
• Its okay to not be perfect! Nobody is!

• Empowerment
• Permission to act
• Context to make good decisions
• Access to help, guidance, and more context
• Find leaders who
• Care about your purpose
• Align with your beliefs
• Have leadership as a talent
• Holding of context and caring for your subordinates
• Be available for context and caring at any time - up to senior leaders, down to individuals

• Take people to lunch, or have meetings, outside your specialty
• Ask them what they do, and try and understand
• You need to talk to:
• Legal (Ask them what the role of a lawyer is, and how you can help make any interactions you have smooth)
• Finance (Ask them what the role of a finance is, what key metrics they watch, and how you can help)
• Sales (Ask them what their quota is, what do they struggle with at customers, and how can you help them make their number)
• Marketing (Ask them what message is resonating, why, and how they see the market evolving)
• Business Development (Ask them what partners are moving the needle, how they think about those arrangements, and whats on the horizon)
• Software Development (Ask them what they are building, and why it matters, and what they are excited about in the future)
• Systems Administrators (Ask them about availability, what do they think is the biggest limit to your organizational efficiency)
• Security Professionals (Ask them how they evaluate your business and technology in terms of risk, how you can help)
• Product (Ask them what they think the gaps in your product are, and to talk about the last 5 customers they've met)

• Before you try and do a major decision, make sure you know the answer going in
• Have a written down plan, and why you think its important
• Talk to all the key stakeholders, preferably 1:1
• Get their criticism and feedback
• Update your plan, incorporating their feedback and criticism (Make It Theirs)
• Present plan to the group
• Get it done

Strong value propositions

• Pain Killers, not vitamins
• Make something people ♡
• Needs not wants (one customer wants a feature; many customers need a feature)

Make products that have strong value propositions

• Product/Pain Relievers/Gain Creators
• Map to Customer Jobs, Customer Pains, and Customer Gains
• Pain Killers not vitamins
• Make something people LOVE
• Needs not wants (customer wants a feature, customer(s) need features)
• How to identify the opportunities
• Call out customer pain through engagement
• Interview customers to learn about their problems
• Solve the pain you experience yourself
• Write down your ideas for products What is it? (product) Who is it for? (target customers) What problem does it solves and why does it matter? (problem & pain) How does it work? (pain relievers & gain creators) What is unique about it? (uniqueness) What is the value proposition? (value) How do we make money? (cost & revenue)

• Lead with vision
• Align with customer feedback
• Balance innovation with customer needs
• Group them into themes
• Define the outcomes for the themes
• Distill those into features, and validate with customers
• Iterate on features according to vision and feedback
• Put it on a grid
• Focus on themes
• The power of the parenthetical
• Keep it alive through iteration
• Your THEMES should hold - your OUTCOMES might hold, and your FEATURES should shift all the time

Always have delighters

Always have delighters

• (The Creating Delight slide)

Awesome analogy from Jeff Patton

• You don't have debt if nobody is using it
• Don't mistake "doing it right" for doing it "incrementally"
• It's not iterating if you only do it once
• That means deploying these features! It's all connected!

• You are building for high velocity
• So small batches, with near term hypothesis
• Shipping the smallest and simplest thing possible to help Get closer to our objectives Get feedback learn validate De-risk
• Experiments and validation with customers
• You introduce near-term volatility to gain decreased long-term failure
• Stylistic difference - there wasn't a way to be declarative about stylistic choices
• There is no reason you have to act drunk when doing drunk boxing

• Theory is fun for yak shaving
• Reality is complex
• Execution is all that matters

• Helps you focus on ITERATIVE vs INCREMENTAL (hard to demo one arm of the mona lisa)
• Teams that aren't demo-ing are probably being INCREMENTAL

Choose languages and tools that fit the job

• Use source code control
• You must have lightweight feature branches

• Write one test at a timeS

• Avoid using words like
• Production
• Staging
• QA
• Those are activities and locations all rolled in to one
• They happen ALL OVER The workflow

Practice incident response

• Conway's Law “Interpersonal variability, that is the capability and behavior differences between programmers using the same language, tends to account for more differences between programs than a change of the programming language.”
• Make a component as simple as it can be, but no more
• Design for re-use when you can
• CERN and the LXC - one framework for four experiments
• The number is 3 - you don't need a hundred re-use points
• Can you get 1 less than the number of actors
• Make extensible system
• There is a loop that gets you here
• Complicated
• Break down
• Simple

• Those are the forms we practice - the components of our DevOps Kung Fu
• Now we need to talk about what it means to take our Kung Fu into the world

• When you use your core principles, and you use your discernment, you are in the right place
• The process by which we do things is what matters
• It is training and the situation and experience that brings you to the right value

• The next step is application - actually doing all of these things in your organization
• Given a long enough application, you will develop your own style - what works, what doesn't

• Before you go off and fight the whole school
• We have a way for you to practice the application of your forms in a safe way
• Which also happens to be the right way to start bringing devops in to your organization

• Take a business problem
• Bring together all the stakeholders
• Practice your Kung Fu together for 8 weeks, on that problem
• Lets you feel what its like, increases your bonds to each other, is specific to your problem
• Lets you build consensus together
• It ends - so there is low risk. The time box matters.