Velocity Conference - Notes & Takeaways, pt.2

Here is part two of my notes from this year's Velocity conference!

Blame, Language, Learning: Tips for Learning from Incidents (Lindsay Holmwood)

Good and helpful talk on maximising learning and minimising blame when dealing with incidents. Lindsay has also made an article version of the talk available. 

TL;DR: The language we use and views we hold when talking about failure, shape the outcome of that discussion, and what we learn for the future. Note in particular that both “Why...?” and “How...?” questions tend to limit the scope of our inquiry into incidents. Instead, “What...?” questions are a much better device for building empathy, and also help to focus the analysis on foresight, rather than it’s less constructive counterpart hindsight, which more easily falls prey to various cognitive bias and to blameful thinking. 

Another point stressed was to always assume local rationality: “people make what they consider to be the best decision given the information available to them at the time.” - there isn't really a just culture that doesn't revolve around this premise.

Alert Overload: Adopting a Microservices Architecture without being Overwhelmed with Noise (Sarah Wells) 

No huge surprises, but a good summary on how to set up useful alerts - some key points discussed were:

Focus on business functionality! - Look at your architecture and decide which parts or relationships are crucial to your core functionalities, and decide what it is that you care about for each - speed? errors? Throughput? 

Focus on End-to-End! - Ideally you only want an alert where you actually need to take action.

Make alerts useful, and build them with support in mind! - Ensure readability when setting up alerting (eg. use spaces rather than camel casing etc.), if possible make your alerts include links to more information or useful look-ups, and provide clear and helpful messages. And importantly, if you get to a point where most people filter out most of the email alerts they are getting, you should probably fix your alert system!

Finally, have radiators everywhere (things like dashing.io are great for dashboards), make sure you would know it if your alert system went down (!), and accept that alerts need continuous cultivation - they are never “finished”. As part of this, it is key to treat setting up an alert as part of fixing any new major issue that you weren’t previously able to detect.

WebPageTest using real mobile apps (Steve Souders)

The open source performance testing tool WebPageTest.org now offer a few “Real Mobile Networks” test locations - only a handful for the time being, but if they extend this it could be a really interesting tool for testing client web apps from different locations! To use the new service, go to webpagetest.org > enter web page URL > select one of the “Real Mobile Networks” options. 

The full talk was less than 7min (!), so if you are interested in some more detail, context and caveats, you can watch it here at minimal time investment.