We have published the first chapter of our Team Guide to Software Operability as a free chapter on Leanpub – download it now from the book website. In this first chapter we explain how to use what we call Run Book collaboration to increase operability and prevent operational issues.
Future chapters will cover additional material including:
- Deployment Verification Tests and Endpoint Healthchecks for rapid feedback on environments
- Run operational checks within a deployment pipeline to gain rapid feedback and increased collaboration
- Modern log aggregation and metrics for deep operational and product feature insights
- Information radiators and dashboards to drive effective behaviour and good psychological responses
Download the free sample chapter of Team Guide to Software Operability now.
— Matthew Skelton (@matthewpskelton) & Rob Thatcher (@robtthatcher)
We’re pleased to announce that an early version of our book Software Operability: how to make software work well in Production will be published soon via our LeanPub site at operabilitybook.com
We are busy adding significant new chapters and practical examples based on our recent work with organisations in the UK and Germany. Oh, and we have a nice new cover for the book too. Follow us on Twitter for updates: @Operability.
Matthew Skelton & Rob Thatcher, authors, ‘Software Operability’
The book Patterns for Performance and Operability by Ford et al is one of the few publications which addresses directly the operability of business software (which is partly why I am writing Software Operability: A Guide for Software Teams). Patterns for Performance and Operability (‘PPO’) is an excellent volume, containing many valuable insights into the ways we can improve the operability of software systems; this blog post explores a few of the key themes and ideas found in the book.
The book 97 Things Every Software Architect Should Know is a useful collection of personal recommendations from experienced software practitioners around the world, and it contains some excellent advice for any thinking person engaged in software systems engineering.
However, it’s clear that even as recently as 2009 (when the book was published), there was very little focus amongst those who identify as software architects on making sure the software we design and built is operable by the operations teams on the “front line”. In fact, the only contributors who directly touch on software operabililty (aside from Michael Nygard, naturally) are Rebecca Parsons, Mncedisi Kasper, and Dave Anderson; four contributions out of 97.
The book Release It! by Michael Nygard (@mtnygard) is essential reading for anyone concerned with the operability of software. “What about the tl;dr version?”, you ask. There is no tl;dr version of Release It! – it’s all hugely valuable, so if you’re serious about software operability, read the whole book.
Once you’ve done that, here are some page numbers for quick reference which relate to software operability:
- p.212 – Multiple NICs and multiple IP addresses
- p.240 – Keeping configuration out of the application and in version control
- p.252 – The importance of human eyeballs on monitoring systems
- p.261 – Recovery-Oriented Computing (and by implication MTTR)
- p.263 – Sensing changes in the application
- p.267 – The importance of data trends
- p.274-281 – Logging, including logging levels, log message formats, and log message semantics
- p.318-322 – The architecture of the organisation, and how this affects operability
Arguably the most important theme of Release It! in terms of software operability is that we should treat logging and metrics as first-class cross-functional aspects of our applications. We can write all the fancy circuit-breaker or exponential backoff code we like, but if the system operators do not know what is happening, the system as a whole is not operable.