Team Guide to Software Operability
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.
Bundles that include this book
About the Contributors
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.
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 $12 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
