Five NEINs of availability

We’ve all been there: it’s 3 AM, the system is down, everything is on fire and it’s up to us to make it better. We do some digging, deploy a fix and draft a post-mortem. We might even identify some things we could have done differently, or suggest a process to avoid such problems in the future. Everyone sits down for the ceremonial presentation of the post-mortem and nods sagely, going back to their work secure that valuable lessons had been learned… right up until the next time the system crashes and we go through the motions again. In this session we’ll consider not what could be done differently, but what shouldn’t be done at all: common engineering antipatterns that, if we fail to avoid, will degrade our system and hurt its availability.



Tomer Gabel

A programming junkie and computer history aficionado, Tomer’s been around the block a few times before settling in at WeWork. Over the years he’s built any number of (predominantly ...