Track: Chaos and Resilience: Architecting for Success

10:35am - 11:25am

Better Resilience Adoption through UX

Too often, attempts to bring resilience engineering to an organization fall flat. Perhaps there’s some initial interest, but that wavers under the crushing weight of JIRA queues and sprint reviews. The tools are there but no one’s using them.

This session will go over three case studies where teams achieved success (and a few that didn't!) by focusing on the human element of engineering tooling. In each one, we’ll look at a specific UX technique that team employed to put their company on a path to resilience.

11:50am - 12:40pm

Preparing for the Unexpected

Convincing engineers to be on-call isn’t always straightforward. In 2019 the Customer Products group at the Financial Times set out to make their out of hours support process more sustainable after losing a number of people from their on-call team.

In this talk you’ll discover how to continuously learn from past incidents by applying your team’s most recent operational experience, increase the confidence of your team in handling live incidents away from the pressures of production, and convince them that, actually, joining the on-call team is a great idea!

Hear how the Financial Times is using incident workshops to prepare for the unexpected and make incident management a more consistent process by sharing the group’s wide range of operational knowledge and architectural insights.

1:40pm - 2:30pm

How Many Is Too Much? Exploring Costs of Coordination During Outages

Service outages can attract a lot of attention from a wide range of participants - particularly when the service is for a business critical function. These ‘stakeholders’ represent multiple roles with different experience, responsibilities, expertise and knowledge about how the system functions - be they users, management, engineers from other dependent services or the incident responders paged in to help with the response. Each stakeholder brings important contributions that are necessary for maintaining reliable operations but smoothly and effectively integrating their contributions or sufficiently meeting their needs for updates, for task delegation or for decisions requires elaborate coordination often under extreme time pressure.  Prior research has shown these coordinative efforts represent a significant cognitive cost (Klein et al, 2005; Klinger & Klein, 1999; Klein, 2006) and require a distinct set of skills (Woods, 2017) to manage in concert with the demands of diagnosing and resolving the incident itself.

Presenting findings from her doctoral research and her experience working with site reliability engineers responsible for critical digital infrastructure (CDI), Laura will uncover the hidden costs of coordination, highlight how the challenges of modern IT infrastructure will continue to impede hitting four 9’s service reliability and show how resilient performance is directly tied to coordination. Along the way, she will examine problematic elements of an Incident Command System, use case study examples to describe helpful and harmful patterns of coordination and offer some promising directions for how to control the costs of coordination in your incident response practices. You will never look at incident response the same way!

2:55pm - 3:45pm

Growing Resilience: Serving Half a Billion Users Monthly at Condé Nast

4:10pm - 5:00pm

Rethinking How the Industry Approaches Chaos Engineering:

In order to determine and envision how to achieve reliability and resilience that drive our businesses forward, organizations must be able to look back at past blunders unobscured by hindsight bias. Resilient organizations don’t take past successes as a reason for confidence. Instead, they use them as an opportunity to dig deeper, find underlying risks, and refine mental models of how our systems succeed and fail.  

There are key components of Chaos Engineering beyond building tools for experimenting in production and running game days. Understanding the concerns, ideas, and mental models of how the system is structured for each individual and learning where your organization excels in technical and human resilience are things that can’t be automated away by code. This talk will address the three different phases of Chaos Engineering and the hidden goals within each phase that might be the greatest benefit of all: using Chaos Engineering as a way to distill expertise.    

The chronically under-invested phases of Chaos Engineering in our industry are the Before and After phases -- and these tend to fall on a single individual to complete, usually a facilitator. This is someone who can act as a third party during the experiment, but prior to that will educate themselves on what the team is going through, their systems, and how it all works. If we only optimize for finding issues before they become incidents, we miss out on getting the most out of the point of Chaos Engineering, which is refining the mental models of our systems and distilling expertise.  

In this talk we focus on the Before and After phases of developing Chaos Engineering experiments (whether they be gamedays or driven by software) and develop important questions to ask with each of these phases. We will also dig into some of the Ironies of Automation present with Chaos Engineering today.