DOES16 San Francisco - David Blank-Edelman - Lessons Learned from a Parallel Universe
Download as PPTX, PDF0 likes661 views
The document outlines essential practices and insights for Site Reliability Engineering (SRE), emphasizing the importance of hiring coders, maintaining service level agreements (SLAs), and using error budgets. It discusses staffing recommendations, on-call team structures, and the necessity of conducting blameless post-mortems for operational events. Additionally, it highlights the role of production engineers at companies like Facebook and the need for management support in developing effective SRE teams.
DOES16 San Francisco - David Blank-Edelman - Lessons Learned from a Parallel Universe
- 1. Lessons Learned from a Parallel Universe David N. Blank-Edelman @otterbook photo: Will Langenberg
- 2. SRE for DevOps David N. Blank-Edelman @otterbook
- 16. What Makes SRE, SRE (dramatic recreation) • hire only coders • have an SLA for your service • measure and report performance against SLA • Use Error Budgets and gate launches on them • Common staffing pool for SRE and DEV • Excess Ops work overflows to DEV team • Cap SRE operational load at 50% • Share 5% of ops work with DEV team • Oncall teams at least 8 people, or 6x2 • Maximum of 2 events per oncall shift • Post mortem for every event • Post mortems are blameless and focus on process and technology, not people
- 17. What Makes SRE, SRE (dramatic recreation) • hire only coders • have an SLA for your service • measure and report performance against SLA • Use Error Budgets and gate launches on them • Common staffing pool for SRE and DEV • Excess Ops work overflows to DEV team • Cap SRE operational load at 50% • Share 5% of ops work with DEV team • Oncall teams at least 8 people, or 6x2 • Maximum of 2 events per oncall shift • Post mortem for every event • Post mortems are blameless and focus on process and technology, not people
- 19. What Makes SRE, SRE (dramatic recreation) • hire only coders • have an SLA for your service • measure and report performance against SLA • Use Error Budgets and gate launches on them • Common staffing pool for SRE and DEV • Excess Ops work overflows to DEV team • Cap SRE operational load at 50% • Share 5% of ops work with DEV team • Oncall teams at least 8 people, or 6x2 • Maximum of 2 events per oncall shift • Post mortem for every event • Post mortems are blameless and focus on process and technology, not people
- 20. What Makes SRE, SRE (dramatic recreation) • hire only coders • have an SLA for your service • measure and report performance against SLA • Use Error Budgets and gate launches on them • Common staffing pool for SRE and DEV • Excess Ops work overflows to DEV team • Cap SRE operational load at 50% • Share 5% of ops work with DEV team • Oncall teams at least 8 people, or 6x2 • Maximum of 2 events per oncall shift • Post mortem for every event • Post mortems are blameless and focus on process and technology, not people
- 21. Observation #1: Create virtuous and reinforcing feedback loops
- 22. What Makes SRE, SRE (dramatic recreation) • hire only coders • have an SLA for your service • measure and report performance against SLA • Use Error Budgets and gate launches on them • Common staffing pool for SRE and DEV • Excess Ops work overflows to DEV team • Cap SRE operational load at 50% • Share 5% of ops work with DEV team • Oncall teams at least 8 people, or 6x2 • Maximum of 2 events per oncall shift • Post mortem for every event • Post mortems are blameless and focus on process and technology, not people
- 23. What Makes SRE, SRE (dramatic recreation) • hire only coders • have an SLA for your service • measure and report performance against SLA • Use Error Budgets and gate launches on them • Common staffing pool for SRE and DEV • Excess Ops work overflows to DEV team • Cap SRE operational load at 50% • Share 5% of ops work with DEV team • Oncall teams at least 8 people, or 6x2 • Maximum of 2 events per oncall shift • Post mortem for every event • Post mortems blameless and focus on process and technology, not people
- 24. Observation #2: You can’t fire your way to reliable.
- 26. • Airbnb • Amazon • Apple • Baidu • Dropbox • Etsy • Facebook • GitHub • LinkedIn •Microsoft •Netflix •Pinterest •Spotify •Stack Exchange •Twitter •Uber •Yahoo! •Yelp
- 27. • Airbnb • Amazon • Apple • Baidu • Dropbox • Etsy • Facebook • GitHub • LinkedIn •Microsoft •Netflix •Pinterest •Spotify •Stack Exchange •Twitter •Uber •Yahoo! •Yelp
- 29. Facebook has Production Engineers
- 31. Facebook has Production Engineers “Production Engineers at Facebook are hybrid software/systems engineers who ensure that Facebook's services run smoothly and have the capacity for future growth. They are embedded in every one of Facebook's product and infrastructure teams, and are core participants in every significant engineering effort underway in the company.”
- 32. Facebook has Production Engineers “Production Engineers at Facebook are hybrid software/systems engineers who ensure that Facebook's services run smoothly and have the capacity for future growth. They are embedded in every one of Facebook's product and infrastructure teams, and are core participants in every significant engineering effort underway in the company.”
- 33. Facebook has Production Engineers “Production Engineers at Facebook are hybrid software/systems engineers who ensure that Facebook's services run smoothly and have the capacity for future growth. They are embedded in every one of Facebook's product and infrastructure teams, and are core participants in every significant engineering effort underway in the company.”
- 34. Observation #3: There is no one right way to build an SRE team. But there are wrong ways.
- 35. Facebook has Production Engineers •~1-10 ratio •18, 24, 36 months with a service (not a S.W.A.T. team or ops monkeys) •Also do Bootcamp •Lead reports to Facebook head of engineering (same person responsible for Ops and Eng)
- 36. Observation #4: SRE requires management support at the highest levels.
- 37. Production Engineering Maturity Model •maturity of SW/PE team’s work •maturity of level of service •relationship status of PE/SWE teams •stages: • bootstrap/build out • scale/initial deployment • awesomize