Presentation: Failure at Netflix Velocity

The majority of our time is focused on education, training, and follow up with other teams. We help them with instrumentation, metrics, actionable alerts, and best practices. The focus is really education and preparation.

When things do go wrong, we have a team of trained specialists that help coordinate efforts, manage communication, and keep the people involved on task and pointed toward the goal of stabilizing our service so our customers are happy and pressing their play buttons.

Netflix has learned a lot about how not to plan for and not successfully manage incidents. We like to share those things so others don’t have to learn the hard way about what we’ve found that does work.

Developers, engineers, managers, architects who build critical systems and want to sleep through the night.

The patterns and practices we apply for resiliency, incident management, and sanity.

The little, seemingly, inconsequential things. We found most engineers and organizations do well in the big things -- planning architectures, fork-lifting to new systems, and launching new products; most people wouldn’t dream of launching a new service or making a large code change on a Friday 11PM. However, pushing out a canary to a small portion of production traffic or changing a feature flag on quiet code path feel like no big deal, they’re small things. However, at our size and velocity, even a fraction of one percent of production traffic represents a lot of customers. It’s that numbness to what we perceive as small numbers or small changes that reduced our rigor and impede our ability to correctly reason about those changes. And, those, seemingly small or inconsequential changes that lead to customer or systems impact.