Advice for Writing Abstracts
The abstract is the primary resource for the PC (program committee) to understand what the talk is about and what it will contain. Writing good abstracts is very important for both the PC and potential speakers.
Be Clear
We are not mind readers; try not to make too many assumptions about prior knowledge in your abstract—e.g. we may or may not have heard of X, and if you submit a talk about it, it’s good to explain (or link to) what it is. Be explicit about what you are going to speak about.
Abstracts are not teasers—if you want a teaser to be published on the conference schedule (perhaps you are unveiling a new project) rather than the abstract you can write so in the abstract and we will try to oblige, but the abstract must contain information about the content of the talk.
Be Focused
A good abstract provides an idea of why this talk provides an added value to the conference and the ongoing dialogue in the field. It is obviously not easy to trim down your talk to a few paragraphs. The following questions can help you focus on what the abstract needs to communicate:
- What is the problem you address? Why is it important now?
- Who is the target audience?
- What type of session is this? (e.g. technical, conceptual, review)
- What are the takeaways from this talk? What is the message?
- What is the format of this talk? (e.g. demo, live coding, structured talk, loose talk, improve, etc.)
And take your time! A good abstract is not written in just a few minutes. Even experienced speakers prefer to go over it several times.
Try to keep the abstract short but don’t skimp on the words if you feel important information might be excluded.
Examples of Selected Proposals from 2016
40-minute Talk
Title: Lessons from Automatic Incident Resolution for a Million Databases
Abstract: In the beginning of Heroku Postgres, low pager volume were a sign of broken monitoring, not a healthy fleet. Running customer databases on AWS, we needed an automated way to resolve routine failures, so a state machine based framework was slowly grown, to handle issues with server and service availability, filled disks, failed backups, failed server boots, stuck EBS volumes and other incidents that would otherwise wake an engineer. A framework emerged as the basis for writing flexible and robust incident resolution automation, and it has grown to now power High Availability and Disaster Recovery for the Heroku Postgres and Heroku Redis services.
This talk will be comprised of:
- An overview of how to run Postgres and Redis in the cloud
- An incomplete survey of what can go wrong in the cloud and how we fix it
- An introduction to state machines
- How to convert playbooks into state machines
- Proper panics and circuit breakers for your automation
- Limits of automation
- Limits of people
- What we would change if we could do it again
- How to continue scaling up and out
Workshop
Title: Staring into the eBPF Abyss
Abstract: eBPF (extended Berkeley Packet Filters) is a modern kernel technology that can be used to introduce dynamic tracing into a system that wasn't prepared or instrumented in any way. The tracing programs run in the kernel, are guaranteed to never crash or hang your system, and can probe every module and function -- from the kernel to user-space frameworks such as Node and Ruby.
In this workshop, you will experiment with Linux dynamic tracing first-hand. First, you will explore BCC, the BPF Compiler Collection, which is a set of tools and libraries for dynamic tracing. Many of your tracing needs will be answered by BCC, and you will experiment with memory leak analysis, generic function tracing, kernel tracepoints, static tracepoints in user-space programs, and the "baked" tools for file I/O, network, and CPU analysis. You'll be able to choose between working on a set of hands-on labs prepared by the instructors, or trying the tools out on your own test system.
Next, you will hack on some of the bleeding edge tools in the BCC toolkit, and build a couple of simple tools of your own. You'll be able to pick from a curated list of GitHub issues for the BCC project, a set of hands-on labs with known "school solutions", and an open-ended list of problems that need tools for effective analysis. At the end of this workshop, you will be equipped with a toolbox for diagnosing issues in the field, as well as a framework for building your own tools when the generic ones do not suffice.
To make the most of this workshop:
- Attendees are expected to bring a laptop with a recent Linux kernel (4.6+) and install a small set of development dependencies (list TBD)
- Attendees should be familiar with one of the following programming languages: Python, C/C++, or Lua
Lightning Talk
Title: What a 17th century samurai taught me about being an SRE
Abstract: Around the year 1645 an aging master samurai climbed a mountain and set down in writing his philosophy learned from a life of least 60 duels to the death. In his treatise on life-long learnings from the Sengoku period of Japanese history you will find concepts that resonate with the SRE ethos of resilience, reliability, and scale. While our job (rarely) requires us to fight to the death, I will present how his philosophies of Earth, Fire, Water, Wind and Void, although from a different age, map naturally into effective reliability engineering and how everything old is new again. Also, he was kind of an arrogant know-it-all.