LISA’11: Tech Sessions – Wednesday Keynote DevOps

Print Friendly, PDF & Email

Delivered by Ben Rockwood, super human, good amongst men, with big trousers.

So what on earth is DevOps? It’s nothing really very new about to us, but there’s a catalyst. What is it? Its basically a “cultural and professional movement” (Adam Jacob). Not a tool or a thing, there’s no product. Not a person or a title. Just something we do.

It’s not just dev & ops. John Willis said it’s “culture, automation measurement, sharing”. Ben sees it as a “banner of change”, like a knight on a horse leading an army into battle. Re-envisioning the IT world.

“We are the music makers, we are the dreamers of dreams”. Arthur O’Shaughnessy.

The world is changeable, we must accept this and have the confidence to embrace this. IT is really a machine of Continuous Improvement. DevOps is about the journey not the destination.

The core components break down to

  • collaboration of people
  • convergence of the the rules
  • measuring the results

simon sinek’s golden circle:

why -> motivation -> quality is motivation -> to improve efficiency of infrastructure

how -> method -> process & tools -> build process around automation

what -> product -> build services -> automate with configuration management

“Why is the only true source of power, without it you are powerless”.

Working out why we want something is the key.


Synthesis -Ackoff’s 5 contents of the mind

+ ——–> architect -> wisdom -> isight

Analysis -> systems engineers -> understanding -> why

+———> jr SA(support) – > knowledge -how

+———> infomation -> who, what, when where,

+———-> data


Systems Thinking is an interaction of the parts to form a whole. Systems Dynamics are feedback loops between the parts a system can not understand itself. DevOps should be like Yin & Yan, but the way we work is really just silos, but in the realworld the practice is more like a stream from software development striving to “get it out on time”, with no defects. Operations strive to get it up, keep it up, and make it cheap (  but a bunch of Non-Functional Requirements tend to creep in). But who is responsible for quality? If you look all the definitions are “awful”:

iso-9000 “The degree to which a set of inherent characteristics fulfills requirements

“fitness for use”

It’s what the customer grows to expect even if it’s bad, e.g. Big Mac.

So what is quality software? It does what it’s supposed to do. It needs to be intuitive, responsive, observable (what is it doing?). And a quality service is pretty much the same plus availability and self service!

“efficiency is doing things right, and effectiveness is doing the right things!”

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

So what did we do to try to solve it? ITSM! Argh! Cobit, CMMI, ITIL …. making sense of how it all fits together is a nightmare. What are the problems with IT Service Management? It’s compliance driven, highly security focused, complex, complicated, bureaucratic, pushed from top to already burdened staff, consultant heavy, hard to grok, mostly second hand knowledge.

So what about ITIL? From a quick show of hands the people who like it are the ones who have read all the books. Ben believes it’s fantastic. It’s the most complete & respected pattern, a source for change, incident, problem mgt etc. Provides common terminology, chock full of good ideas. He recommends getting the visible ops book, as have others here at the conference, as the best interpretation of ITIL for what we do in Operations. Really though ITIL is like Dungeons & Dragons, the rules don’t make the RPGs fun.. the Dungeon Master does. ;-)

When assessing the rules consider that:

  • no idea should be rejected without consideration
  • don’t view them as “all in” or “all out”
  • educate yourself on them…

He likened it to Art for Arts sake, agile and ITSM are both good sources, but they don’t change the game.

So what happens when we put the cloud into the mix? At first it was all about consolidation – then it went to self service and automation. All of a sudden HPC becomes less interesting. The role of the OS has changed- silly arguments for which is best are now irrelevant. A broad platform standardisation becomes realistic.

Development experiences a paradigm shift – some problem risks emerge:

  • Developers can bypass IT
  • Developers have more experience with the APIs that cloud use than sysadmins
  • The cloud becomes a leveler, anyone can be a player
  • It has all the methodologies, scrum, ci, etc which massively sped up deployment

As a result rifts have formed or increased in web ops. Tools evolve and rise to the challenge, like pagerduty and vagrant. A switch towards “ops as code” happens. But from our point of view the Cloud is great AND it’s going to demand more SAs not lessen them.

Operations Management is being injected in various places. It describes a hierarchical association between executives and the standard 3 pronged elements of business; finance, operations and marketing. Historically Operations Management came about a lot due to common sense. Ben then gave us a short run through history of how this came to be and the main players involved.

  • Fred Winslow Taylor – efficiency of work.
  • Henry Ford – father of mass production
  • Alfred Sloan – did for big mgt that ford did
  • Sakichi Toyoda – loom works invented jidoka autonomous automation and fault mgt, 5 whys
  • W.A. Shewhart – invented PDSA continuous improvement cycle “plan do study act”
  • W. Edwards Deming – student shewhart, deming cycle was actually the shewhart cycle. father of quality movement.
  • Taiichi Ohno – father of toyota production system, just-in-time.
  • Shigeo Shingo – tps, smed, mistake proofing -> zero quality mgt
  • Peter Drucker – modern mgt
  • Bertalanffy – systems theory
  • Russel ackoff – ops research OR systems theory – search youtube
  • Armand Feigenbaum – total quality control
  • US decline – nobody cared until the oil crisis in 1973. japan stop producing cars due to kanban
  • Eliyahu Goldrat  – theory of constraints, wrote a fiction book instead “the goal”. good book read it.
  • James Womack – the machine that change the world  – coined “lean”

There’s a chain of ideas throughout the 20 century, we can follow on from there. “Lean” will push us into what we do now, we need to understand where it fits in and what we do is just a progression of this. Ben suggests that if we read any book from the ones he suggests we should read “Lean IT” or it’s counterpart the “Lean Startup”.

“Those who cannot remember the past are doomed to repeat it”.

There are 3 aspects of devops. dev>ops, dev<ops, and dev<>ops

  • dev>ops (dev in the ops)
    • infrastructure in the code. serious of metrics, consider scrum, kanban, agile
  • dev<ops (ops into dev)
    • continuous dep, embeds metrics
  • dev<>ops
    • full colab between teams, boundaries blur, both teams are accountable, dev access to prod env, joy.

Ben encourages us to help this start by letting developers into the production environment (“but please don’t give them root”). He instructs us to bring the 2 groups together and work on projects do it from the start.

  • The most powerful tool in devops is beer!
  • Suggests trying a weekly open forum for discussion, which I have tried! Perhaps we could start it again.
  • Adopt the “no asshole rule”.
  • make it fun! take pride in what you do.
  • measure everything, have a systems rule, learn from others and the past, encourage pride in work.