Operability can Improve if Developers Write a Draft Run Book

Matthew Skelton (@matthewskelton)'s avatarSoftware Operability

The run book (or system operation manual) is traditionally written by the IT operations (Ops) team after software development is considered complete. However, this typically leads to operability problems being discovered with the software, operational concerns having been ignored, forgotten, or not fully addressed by the development (Dev) team. If the software development team writes a draft run book or draft operation manual, many of the operational problems typically found during pre-live system readiness testing can be caught and corrected much earlier. Because the development team needs to collaborate with the operations team in order to define and complete the various draft run book details, the operations team also gains early insight into the new software. Channels of communication, trust, and collaboration are established between the traditionally siloed Dev and Ops teams, which can help to establish and strengthen a DevOps approach to building and running software systems.

I…

View original post 1,295 more words

Summary of DevOps Summit London 2013

Here is a video interview I gave summarizing some of the main themes and discussions which came out of the DevOps Summit on May 23rd in London: a shared goal for development and operations; anti-fragility as a way for DevOps and ITIL to complement each other; surface the quality of the software for all to see; tools can produce a step change in behavior for the better; and use the theory of constraints to focus improvements.

Continue reading Summary of DevOps Summit London 2013

The Business Case for DevOps – DevOps Summit May 2013, London

I chaired the May 2013 DevOps Summit in London, whose theme was Enabling DevOps. I gave a talk on The Business Case for DevOps (blog post), and the slides are on SlideShare:

(Thanks to all those credited on the final slide, and to Unicom for organising the event)

The Business Case for DevOps

[At the Unicom DevOps Summit on 23rd May 2013 in London I gave a talk on The Business Case for DevOps; here is a summary of the talk, along with the slides. Update: now with video too.]

With an increasing number of organisations turning to DevOps to try to improve their software systems, it is becoming necessary to provide the business case for introducing DevOps, especially in organisations which perceive their main focus to be something other than software systems.

For me, building the business case for DevOps has three strands:

  1. Using appropriate terminology
  2. Recognising the huge technology shift which has occurred over the last few years
  3. Emphasising the importance of operability in our software systems

Continue reading The Business Case for DevOps

Questions to ask when applying for DevOps jobs

Here are some criteria which should be useful when trying to cut through the tangled mess of “DevOps”  job titles in order to work out if a prospective role will actually lead to working within a DevOps culture, or whether you’ll be stuck in an old-school IT silo with a fancy “DevOps” name tag and the same crappy us-and-them mentality.

Continue reading Questions to ask when applying for DevOps jobs