Team Guide to Software Operability
Minimum price
Suggested price

Team Guide to Software Operability

Proven techniques for making software work well

About the Book

Learn how a focus on software operability helps to increase system reliability, reduce problems in Production, and reduce total cost of ownership (TCO).

Software operability is the measure of how well a software system works when operating 'live' in production, whether that is the public cloud, a co-located datacentre, an embedded system, or a remote sensor forming part of an Internet of Things (IoT) network. We say that a software system with good operability works well and is operable. A highly operable software system is one that minimizes the time and effort needed for unplanned interventions (whether manual or automated) in order to keep the system running.

The ‘Team Guide’ collection is designed to help teams building and running software systems to be as effective as possible. Guides are curated by experienced practitioners and emphasise the need for collaboration and learning, with the team at the centre.

  • Share this book

  • Categories

    • Software
    • Agile
    • Testing
    • Systems Engineering
  • Installments completed

    6 / 9

  • Feedback

    Email the Author(s)

About the Authors

Matthew Skelton
Matthew Skelton

Matthew Skelton is co-author of Team Topologies: organizing business and technology teams for fast flow. Recognised by TechBeacon in 2018, 2019, and 2020 as one of the top 100 people to follow in DevOps, Matthew curates the well-known DevOps team topologies patterns at He is Head of Consulting at Conflux and specialises in Continuous Delivery, operability, and organisation dynamics for modern software systems.

Rob Thatcher
Rob Thatcher

Rob Thatcher has worked on technology deployment, management and support projects in the financial services industry for over 15 years, with technologies including Solaris, Linux, Microsoft, Cisco and Juniper networking.

Prior to that he spent time working in a range of IT roles from task scheduling to teaching and mentoring IT skills in the workplace.

He has built and led successful matrix teams, combining IT staff across multiple disciplines, for managing electronic trading platforms, technical infrastructure, remote offices, VPN services, virtual machines, and storage platforms. He has co-built four trading floors in the City of London along with associated data-centre and Direct Market Access components.

Bundles that include this book

Bought separately
Bundle Price
Bought separately
Bundle Price

About the Contributors

Manuel Pais
Manuel Pais

Manuel Pais is an independent DevOps and Delivery Consultant, focused on teams and flow.

With a diverse experience including development, build management, testing and QA, Manuel has helped large organizations in finance, legal, and manufacturing adopt test automation and continuous delivery, as well as understand DevOps from both technical and human perspectives.

Manuel is co-author of the Team Guide to Software Releasability book and lead editor for the remaining books in the Team Guide series.

Table of Contents

  • Team Guides for Software
  • Foreword
  • Introduction
    • What is software operability and why should we care?
    • Where can operability techniques be used?
    • How to use this book
    • What is covered in this book
    • Why we wrote this book
    • Feedback and suggestions
  • 1. What does good operability look like?
    • 1.1 Use operability checklists to assess core operability
    • 1.2 Assess operability with real people regularly
    • 1.3 Provide a good User Experience for all agents and all users, external and internal
    • 1.4 Treat operational aspects as product features: viable, configurable, deployable, diagnosable, reliable, well-performing, securable, observable, recoverable
    • 1.5 Good operability does not necessarily mean good safety or ethics
    • 1.6 Summary
  • 2. Core practices for good software operability
    • 2.1 Logging and metrics are the first features to implement
    • 2.2 Enumerate all likely failure modes of the software
    • 2.3 Use well-defined, meaningful event identifiers
    • 2.4 Define and track at least one KPI or SLI per service
    • 2.5 Include operational hooks as first-class features
    • 2.6 ‘DONE’ means working correctly in Production
    • 2.7 Treat Operations as a high-skill activity
    • 2.8 The software development team writes a draft Run Book
    • 2.9 Avoid a separate ‘Production-ization’ or ‘Hardening’ phase
    • 2.10 Avoid Production-specific tools
    • 2.11 Talk about ‘operational features’, not ‘non-functional requirements’
    • 2.12 Developers and Product Owners should be on-call
    • 2.13 Make operational problems visible
    • 2.14 Test for operability in a deployment pipeline
    • 2.15 Summary
  • 3. Use Run Book collaboration to increase operability and prevent operational issues
    • 3.1 Operational aspects are very similar across many software systems
    • 3.2 Use a Run Book template as a common baseline for operational aspects
    • 3.3 Use a Run Book Dialogue Sheet to facilitate discovery and avoid ‘documentation fallacy’
    • 3.4 Assess operability on a regular basis: every sprint, iteration, or week
    • 3.5 Summary
  • 4. Use modern log aggregation and metrics for deep operational insights
    • 4.1 Use logging to help design and understand distributed systems
    • 4.2 Collect and aggregate logs and metrics centrally using standard tools & software
    • 4.3 Focus on collaboration, design decisions, and team experience
    • 4.4 Identify 2 or 3 key application metrics and test these early on
    • 4.5 Run log aggregation and metrics locally on development workstations
    • 4.6 Hide sensitive information at the point of logging
    • 4.7 Use Structured Logging for greater meaning
    • 4.8 Use Event IDs for visibility of application behaviour
    • 4.9 Collaborate on Event IDs to enhance operability
    • 4.10 Test your logging and metrics
    • 4.11 Trace operations across system boundaries with correlation IDs
    • 4.12 Adapt your logging and metrics techniques to the technology characteristics
    • 4.13 Summary
  • 5. Use well-defined readiness checks to increase operational confidence
    • 5.1 Introduction
    • 5.2 Define readiness checks so we know when a service is ‘ready’
    • 5.3 Use Deployment Verification Tests (DVTs) to increase confidence in infrastructure
    • 5.4 Expose Endpoint Healthchecks for persistent services to detect problems early
    • 5.5 Provide custom diagnostic hooks to expose additional operational information
    • 5.6 Run operational checks within a deployment pipeline to gain rapid feedback
    • 5.7 Define a set of Service Readiness criteria to establish operational viability
    • 5.8 Summary
  • 6. Use information radiators and dashboards to drive effective behaviour and good psychological responses
    • 6.1 Introduction
    • 6.2 Invest time an effort in good dashboard design and information radiators
    • 6.3 Avoid information overload - be selective about information on screen
    • 6.4 Consider common psychological responses
    • 6.5 Use dashboards to promote inter-team collaboration
    • 6.6 Example: Using Dashboard visualisation in Formula 1
    • 6.7 Be aware of typical mistakes with dashboard design
    • 6.8 Summary
  • 7. Make operability part of the software product
    • 7.1 Overview: why we need a focus on operability
    • 7.2 Use rich, time-series logging and metrics to drive product decisions
    • 7.3 Go beyond the Agile “User Story” to address operability as a first-class concern
    • 7.4 Use secondary User Personas to address operability aspects
    • 7.5 Use a single backlog for visible features and operational features
    • 7.6 Make operational aspects part of the team’s regular work
    • 7.7 Address operational aspects from the very start and then throughout the delivery phase
    • 7.8 Raise an alert if a team is spending less than ~30% of their time / effort / budget on operational aspects
    • 7.9 Product Owners should be responsible for the operational success of the software
    • 7.10 Developers, Testers, and Product Owners should be “on call” for operational problems
    • 7.11 Understand the business case for operability
    • 7.12 Encourage a culture of operability
    • 7.13 Summary (?)
  • Appendix
    • Adapt your logging techniques to the technology characteristics
    • Understand how the complexity of modern distributed systems drives a need for a focus on operability
  • Terminology
  • References and further reading
    • Introduction
    • Chapter 1 - What does good operability look like?
    • Chapter 2 - Core Operability Practices
    • Chapter 3 - Use Run Book collaboration to increase operability and prevent operational issues
    • Chapter 4 - Use modern log aggregation for deep operational and insights
    • Chapter 5 - Use Deployment Verification Tests and Endpoint Healthchecks for rapid feedback on environments
    • Chapter 6 - Run operational checks within a deployment pipeline to gain rapid feedback and increased collaboration
    • Chapter 7 - Use information radiators and dashboards to drive effective behaviour and good psychological responses
    • Chapter 8 - Use operability as a differentiating aspect of your software
    • Appendix
  • Run Book template
    • Service or system overview
    • System characteristics
    • Required resources
    • Security and access control
    • System configuration
    • System backup and restore
    • Monitoring and alerting
    • Operational tasks
    • Maintenance tasks
    • Failover and Recovery procedures
  • Index
  • About the authors
    • Matthew Skelton
    • Alex Moore
    • Rob Thatcher
  • Conflux Books
  • Notes

About the Publisher

This book is published on Leanpub by Conflux Books

Conflux Books publishes books for the global technology community from experienced practitioners.

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

80% Royalties. Earn $16 on a $20 book.

We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub