The First Ever Devopsdays

I've been reviewing old articles on Agile Sysadmin, as I dust it down and polish it up, ready for more writing. It's fascinating to see the things that have changed, the things that are still problems, and to get, can you believe it, 9 years of perspective on this thing we call Devops!

Here's my overview of the first day of the very first Devopsdays, back in 2009!

Devopsdays is a day old. I can honestly say that it's been one of the most engaging and enriching conferences I've ever been to, and we're only half way through. In addition to excellent talks by Rachel Davies on non-fuctional requirements, Lindsay Holmwood on Cucumber-Nagios, and a thrilling new 'submarine project' on rethinking monitoring for the cloud, and Teyo Tyree from (the artist formerly known as....) Reductive Labs on Building Agile Infrastructures with Puppet, we had a super 'Open Spaces' session.

I've probably got about a month's worth of blog ideas from the conversations and talks we had yesterday - it's been absolutely thrilling to be surrounded by brilliant, intelligent and innovative people - people who get operations, and who get that the historic divide or even animosity between developers and sysadmins is damaging, misguided, and conquerable.

The Holy Grail

The conference opened with a hilarious video created by Patrick Debois. With subtitles over excerpts from Monty Python's Holy Grail, it wittily presented a world in which admins and developers were pitted against each other, but inspired by the principles of the Agile Manifesto, started to believe that there might exist a brighter future in which they worked together, and had more fun.

Non-functional Requirements

It was a tough act to follow, but Rachel Davies stepped up to the front and delivered a top performance, discussing the possible use of user stories as a way to capture Non-Functional Requirements.

Non-functional requirements are essentially the often unspoken desires of a product owner or user about how a piece of software works, rather than what it does. We don't really mean how the software itself behaves, as this can still be captured in behaviour-driven design and acceptance tests; rather we mean aspects of its behaviour over the lifecycle of the application:

  • How fast should it be?
  • What should happen if it crashes?
  • How long, and how will we manage it over time?

These sorts of requirements are sometimes called -ilities - we're talking about its reliability, availability, usability and so forth.

The problem is these sorts of requirements are often never explicitly discussed, or it's simply assumed that the systems or infrastructure team knows what they are and how to deliver them. Rachel had some high level advice for tackling the problem:

  • There's no magic bullet - no 'new' agile method for dealing with this challenge
  • The whole team must work together - business and technical - to understand what these requirements are
  • NFR's won't arrive in a lump, ready formed and understood, and if they did, we should be wary of them anyway
  • Equally, the technical team aren't telepathic - it's unreasonable to expect them to know the expectations of the business
  • Talk about the lifecycle of the product - how long will it be around, what sort of usage patterns are expected? What sort of promotion will it receive? What sort of audience?
  • Use the YAGNI principle, but cautiously
  • Trade carefully between now and later - we do need to plan for scalability and reliability, but we should try to defer any engineering decisions or implementations to the last responsible moment
  • Educate the product owner and help them to understand the choices that are being made
  • Make it about money - talk about site reliability in terms of risk, and cost of downtime - this helps to focus the mind, and brings home the point that time and money may need to be spent on getting it right
  • Don't rely on the product owner to know what the NFRs will be
  • Make sure planning meetings include technical stakeholders, and people with hands-on operations experience
  • Make sure the development team includes sysadmin experience
  • Share knowledge by encouraging pairing with and between sysadmins
  • Consider using XP-style story cards, either with a traditional "As a... I can... so that..." format, or with some other clearly defined "definition of done"
  • In the iteraction cycle, come up with ways to include tasks which will tackle non-functional requirements - some people use coloured cards to denote "classes of service", others impose a kind of "Quality Tax" to ensure that technical debt or spikes are being carried out throughout the lifecycle of the project

As always with Rachel, it was full of excellent advice, and anecdotal experience, presented in a relaxed and engaging way. You can read more of her wisdom in her blog.

Don't go away...

In our next thrilling installment, we learn about how to think about monitoring - believe me, we frequently get it entirely wrong; a strategy for automating infrastructures and doing operations in an agile way; and we'll talk about open spaces, and run through some more of the fascinating takeaways from the rest of the day.

Show Comments