SREcon Conversations Europe/Middle East/Africa, October 27–29, 2020

October 27–29, 2020

Thanks to those who joined us for SREcon Conversations Europe/Middle East/Africa. We hope you enjoyed the event.

SREcon Conversations are short, interactive, online discussions about Site Reliability Engineering, hosted on Zoom. SREcon Conversations maintain and celebrate the values, goals, and culture of SREcon.

Registration Fees

Member Rate
Standard Rate
US$0 US$60

Get the best value: become a USENIX member today and attend SREcon Conversations for free! Plus your membership supports USENIX's mission and our commitment to open access.

Already a member? Log in to the USENIX website and access your discount code.

USENIX Conference Policies

We encourage you to learn more about USENIX's values and how we put them into practice at our conferences.

Refunds and Cancellations

We are unable to offer refunds, cancellations, or substitutions for any registrations for this event. Please contact the Conference Department at with any questions.

Amy Tobey, Equinix Metal

Tuesday, October 27, 2020
13:30-14:15 UTC

Amy has worked in web operations for more than 20 years at companies of every size, touching everything from kernel code to user interfaces. When she's not working she can usually be found around her home in San Jose, caring for her family, making music, or running slowly in the sun.

Emerging from Burnout

As practitioners at the edge of disaster, SREs live with high highs and low lows of emotional engagement with our work. We're also often "swimming upstream" to fight for our users, in organizations that often don't value reliability as much as we do personally. When we combine factors like oncall stress, misalignment of missions, and frustration with the status quo, it can lead to burnout, or cognitive injury. As professionals, we spend a lot of our time talking about important concepts like blameless analysis, inevitability of failure, and practicing towards a perfect that doesn't exist. In order to emerge from burnout, we can take the practices we use to make our socio–technical systems more reliable and turn them inward, to steward our health and build resiliency. This talk is my story of (partial) recovery from serial burnout woven together with SRE, resilience, and mental health concepts the audience can use to both deepen their understanding of our profession, and hopefully, themselves.

Our skills as SREs and people who think about systems can inform how we manage our burnout. What we know about resilience can help us endure troubled times. Burnout is a real and potential issue that impacts SREs and some awareness can hopefully help folks avoid the worst of it and emerge healthier.

Jennifer Petoff and JC van Winkel,
Google Inc.

Tuesday, October 27, 2020
14:15-15:00 UTC

Jennifer Petoff is Google’s Director of SRE Education and is based in Dublin, Ireland. She leads the SRE EDU program globally and is one of the co-editors of the best-selling book, Site Reliability Engineering: How Google Runs Production Systems.

JC has been teaching UNIX and programming languages since 1992, working for AT Computing, a small courseware spin-off of the University of Nijmegen, the Netherlands. JC joined Google's Site Reliability Engineering team in 2010 and is both a founding member and lead educator of the SRE education team, SRE EDU.

SRE Onboarding: From In–Person to Remote in 13 Days

Mitigating a potential onboarding outage
COVID–19 changed work and the workplace as we know it around the world. The need for social distancing meant that onboarding new team members also had to change. Google's SRE EDU team had to react and evolve in the face of rapidly changing conditions, pivoting from an in–person orientation experience for new hires with team members flying from different locations to meet together in a classroom to a fully remote experience. This talk will cover how Google's SRE EDU team delivered a work–from–home onboarding experience in 13 days, avoiding disruptions to training operations by applying SRE principles and best practices. We’ll share lessons learned from our Live → Remote postmortem that are expected to be applicable to organizations of all sizes and recommendations for how to make the most of difficult circumstances to set new hires up for success.

Avery Pennarun, Tailscale

Wednesday, October 28, 2020
13:30-14:15 UTC

Avery is co-founder and CEO of Tailscale, which is the opposite of Internet scale, and it shows. His open source projects include wvdial, netselect, git-subtree, bup, sshuttle, and redo. Once, on vacation, he wrote a visual simulation of wifi beamforming radiation patterns. Nobody knows why.

The Curse of Unreasonably Sized Networks

What does IPv6 have in common with String Theory? How big can an internet get before parasites use it to destroy democracy? When you're building infrastructure, should scale–invariance be the ultimate goal? Can you give people a useful, verifiable identity without building a panopticon? Did you ever notice that Dunbar's Number fits comfortably in a /24? And what does NAT have to do with anything? We'll answer some of these questions!

King'ori Maina, Zappi

Wednesday, October 28, 2020
14:15-15:00 UTC

King'ori (or "King") is a software developer turned Infrastructure/Operations (DevOps) Engineer passionate about unlocking developer productivity by automating their problems away or providing/building the tools for them to work faster, smarter, and more efficiently. He is currently a part of the devops team at Zappi and a huge fan of Kubernetes, Golang, Ruby, open source, and automation.

Pitfalls of Kubernetes Adoption

Kubernetes is an amazing piece of technology certainly not without it’s odd quirks. The team at Zappi got into Kubernetes about 4 years ago and we’ve hit some snags and surprises along the way. This talk lists some of the tissues that stood out along the way that hopefully will give a heads up to anyone looking to get started or even those who’ve been using it for a while.

Alex Hidalgo

Thursday, October 29, 2020
13:30-14:15 UTC

Alex Hidalgo is a Site Reliability Engineer and author of the upcoming Implementing Service Level Objectives (O'Reilly Media, September 2020). During his career he has developed a deep love for sustainable operations, proper observability, and using SLO data to drive discussions and make decisions. Alex's previous jobs have included IT support, network security, restaurant work, t-shirt design, and hosting game shows at bars. When not sharing his passion for technology with others, you can find him scuba diving or watching college basketball. He lives in Brooklyn with his partner Jen and a rescue dog named Taco. Alex has a BA in philosophy from Virginia Commonwealth University.

I Have an SLO. Now What?

It's 2020: There is a plethora of data available about measuring SLIs and setting SLO targets. But, now that you have this data, what are you actually supposed to do with it? The classic example of "Ship features when you have error budget; focus on reliability when you don't" is antiquated, too simple, and ignores all of the amazing discussions and decisions you can have with your SLO data. Let's talk about how you can use SLOs to actually make people happier–from your customers, to your engineers, to your business.

Štěpán Davidovič, Google Inc.

Thursday, October 29, 2020
14:15-15:00 UTC

Štěpán Davidovič is an SRE at Google. He currently works on internal infrastructure for automatic monitoring and alerting. In previous Google roles, he developed Canary Analysis Service, maintained an internal Cron system and was oncall for AdSense. He obtained his bachelor's degree from Czech Technical University in Prague.

Alerting Patterns against Toil

Nobody likes to get paged, and especially not needlessly. But nobody likes to write an incident retrospective due to missing alerts. As we focus more on alerting on user–perceived behavior (that is, SLO alerting), can we take it too far? We'll take a look at patterns and problems in managing our alerting.

Event Sponsorship

Become a Sponsor: Sponsorship exposes your brand to highly qualified attendees, funds our diversity and student grants, supports open access to our conference content, and keeps USENIX conferences affordable. USENIX is a 501(c)(3) non-profit organization that relies on sponsor support to fulfill its mission. To learn more, please contact the Sponsorship Department with the conference name in your subject line.

The acceptance of any organization as a sponsor does not imply explicit or implicit approval by USENIX of the donor organization’s values or actions. In addition, sponsorship does not provide any control over conference program content. Questions? Contact the Sponsorship Department.