Kent Beck lays out five values as the basis for Extreme Programming (XP)

• Communication
• Simplicity
• Feedback
• Courage
• Respect

These are not the only values that you may need for your needs, but they make up the values for XP.

Join the discussion of these values Thursday night at 7 pm Eastern live

This week we dive into the first 3 chapters of Extreme Programming Explained by Kent Beck (amazon).

While XP is not the software development methodology that everyone is talking about these days, its practices have become pervasive in our industry. Through reading this book I've started to think that we aim for these practices not for their inherent value but because of the values that lead to them.

I reference the Westrum topology for organizational culture. There are a ton of great resources about these different types of cultures and delivering software.

• DevOps Culture
• Westrum’s Organizational Model in Technology Organizations
• Accelerate

I hope you'll check out the live discussion for these chapters on Twitch Thursday, June, 3rd at 7 pm eastern.

Next week we start our discussion of Extreme Programming Explained by Kent Beck (amazon)

While there are other methodologies that are more popular for creating software, they are all heavily influenced by XP.

Kent Beck is also just an inspiring author. Here are three ideas from the preface to the book that have stuck with me.

• No matter the circumstances you can always improve.
• You can always start improving with yourself.
• You can always start improving today.

You can join in the discussion about Extreme Programming Explained on Twitch starting Thursday, June 3rd at 7 pm eastern by going to bookclub.dev/live

This is the end of season one of Reading Notes. Next season we'll be looking at Extreme Programming Explained by Kent Beck.

Six takeaways from Site Reliability Engineering: How Google Runs Production Systems

• The 4 Golden Signals of Monitoring
• Error Budgets and SLOs
• Eliminate Toil
• Explain why
• Create your own culture
• Assume the best of intentions

This week we look at Chapter 33 - Lessons Learned from Other Industries and Chapter 34 - Conclusion

Join the free companion discussion at 7 pm Eastern by signing up at bookclub.dev/thursday.

We look at 4 themes of SRE across several industries

• Preparedness and Disaster Testing
• Postmortem Culture
• Automation and Reduced Operational Overhead
• Structured and Rational Decision Making

This week we look at Chapter 31 - Communication and Collaboration in SRE and Chapter 32 - The Evolving SRE Engagement Model.

Join the free companion discussion by going to bookclub.dev/thursday.

Production Meeting Agenda

• Upcoming production changes
• Metrics
• Outages
• Paging events
• Nonpaging events
  • Issues that probably should've paged, but didn't
  • An issue that is not pageable but requires attention
  • An issue that is not pageable and does not require attention
• Prior action items

This week we look at Chapter 29 - Dealing with Interrupts and Chapter 30 - Embedding an SRE to Recover from Operational Overload.

We are almost at the end of Site Reliability Engineering: How Google Runs Production Systems and that means it's time to pick a new book. Please send your suggestions to [email protected].

Join the companion discussion Thursday night at 7 PM Eastern for free by signing up at bookclub.dev/thursdays.

Resources

• Flow
• Explain your reasoning

We are almost at the end of Site Reliability Engineering: How Google Runs Production Systems and that means it's time to pick a new book. Please send your suggestions to [email protected].

This week we are discussing Chapter 27 - Reliable Product Launches at Scale and Chapter 28 - Accelerating SREs to On-Call and Beyond.

Join the Thursday night discussions from 7-9 pm Eastern by signing up at bookclub.dev/thursdays.

Resources

• Appendix E
• The Checklist Manifesto
• Wheel of Misfortune Online
• Wheel of Misfortune Template

We look at Chapter 25 - Data Processing Pipelines and Chapter 26 - Data Integrity: What You Read Is What You Wrote.

Join the companion discussion Thursdays from 7-9 PM Eastern by signing up at bookclub.dev/thursdays.

System prevalence

Prevayler Java implementation of system prevalence.

Types of failure that lead to data loss

Root cause

• user action
• operator error
• application bug
• infrastructure defect
• hardware fault
• site disaster

Scope

• wide
• narrow

Rate

• big bang
• slow and steady

Sign up for the Thursday night companion discussions at bookclub.dev/thursdays. Discussions go from 7-9 pm Eastern.

This week we look at chapter 23 Managing Critical State: Distributed Consensus for Reliability and chapter 24 Distributed Periodic Scheduling with Cron from Site Reliability Engineering: How Google Runs Production Systems.

Things to monitor with a distributed consensus system

• The number of members running in each consensus group, and the status of each process (healthy or not healthy)
• Persistently lagging replicas
• Whether or not a leader exists
• Number of leader changes
• Consensus transaction number - in a healthy system, this number will be incremented over time
• Number of proposals seen and number of proposals agreed upon
• Throughput and latency
• Latency distributions for proposal acceptance
• Distributions of network latencies observed between parts of the system in different locations
• The amount of time acceptors spend on durable logging
• Overall bytes accepted per second in the system

Projects mentioned

• Apache ZooKeeper™
• Consul
• etcd

Articles from this week's chapters

• Harvest, Yield, and Scalable Tolerant Systems
• Brewer’s Conjecture and the Feasibility of
  Consistent, Available, Partition-Tolerant Web
  Services
• CAP Twelve Years Later: How the "Rules" Have Changed
• Existential Consistency:
  Measuring and Understanding Consistency at Facebook
• The trouble with timestamps
• F1: A Distributed SQL Database That Scales
• Impossibility of Distributed Consensus With One Faulty Process
• The Part-Time Parliament
• In Search of an Understandable Consensus Algorithm
  (Extended Version)
• Zab: High-performance broadcast for primary-backup systems
• Mencius: Building Efficient Replicated State Machines for WANs
• ZooKeeper Recipes and Solutions
• ZooKeeper: Wait-free coordination for Internet-scale systems
• The Chubby lock service for loosely-coupled distributed systems
• Stumbling over consensus research: Misunderstandings and issues
• Paxos for System Builders: An Overview
• Implementing Fault-Tolerant Services Using the State Machine
  Approach: A Tutorial
• Spanner: Google’s Globally-Distributed Database
• The Google File System
• Bigtable: A Distributed Storage System for Structured Data
• MapReduce: Simplified Data Processing on Large Clusters
• Unreliable Failure Detectors for Reliable Distributed Systems
• Paxos Replicated State Machines as the Basis of a High-Performance Data Store
• Photon: Fault-tolerant and Scalable Joining of Continuous Data Streams
• High-Availability at Massive Scale: Building Google’s Data Infrastructure for Ads
• Paxos Quorum Leases: Fast Reads Without Sacrificing Writes
• Fast Paxos
• Classic Paxos vs. Fast Paxos: Caveat Emptor
• Egalitarian Paxos
• Tuning Paxos for High-Throughput with Batching and Pipelining
• Paxos made live: an engineering perspective
• Practical Byzantine Fault Tolerance
• WHAT TAKES US DOWN?
• Large-scale cluster management at Google with Borg