Detailed and specific description of impact? Check. In-depth root cause analysis? Check. Clearly defined and easy to follow resolution? Check. Postmortems present an incredible learning opportunity, despite the inherent cost of time and effort. They ensure an incident is documented, that all contributing factors are understood, and that effective preventative actions have been put in place to reduce the likelihood or impact of recurrence.

In response to recent events, many organizations are implementing social distancing programs such as remote work. Successfully transitioning to remote work does come with challenges, but the right practices and attitudes can make it much less painful (and safer for you than heading into the office). We like to think of incidents as “unplanned investments,” and a sudden switch to remote work could be considered an unplanned investment of its own.

With remote work becoming more common, and distributed teams the norm, incident response has become even trickier. Years ago, everyone would gather in a war room and sort through the issue together, boots on the ground. Now, things have shifted. Remote work is only projected to increase, and teams need to be able to adapt in order to resolve incidents quickly and efficiently, even if team members are a thousand miles away. But how can we make great incident response a reality?

When someone asks what type of “shop” your organization is, can you answer confidently that it’s ITIL, DevOps, or SRE? Maybe some people can, but if you’re a large enterprise, the answer is likely a combination of several of these operating models, especially since SRE has become a key implementation of DevOps. ITIL can work effectively alongside DevOps and SRE principles, though at first glance they appear to be different species.

The first keynote speaker, he is a senior director of engineering at Google. You might know him as they guy who founded and leads the customer reliability engineering function at Google. CRE, this is a team that teaches the world SRE principles and practices. Now I want to tell you a bit more about him, because I think he has a very unique view and perspective. He is deeply compassionate and intuitive as a teacher, not just a lecturer.

Today, the number of possible failure modes in cloud and microservices applications are exploding, making it increasingly difficult to gain true observability and take the right action across IT environments. According to Lightstep’s Global Microservices Trends report, 91% of teams are using or have plans to use microservices, but 73% report it is harder to troubleshoot application performance problems due to greater complexity.

In the fast-moving world of software development, as your product and organization grow and evolve, there are almost always competing priorities. Zeroing in on what is most important to your business in order to take it to the next level can at times seem like a non-stop process of trial and error. Oftentimes the customer who screams the loudest becomes a priority and gets the most focus.

At Blameless, we drink our own champagne, and aim to adopt a mindset of continuous learning to foster resilience. We believe that the adoption of SRE practices is one of the best ways to get there. Like most organizations, our early efforts to implement SRE were imperfect. However, through hard work, teamwork, and investing in what we believe is the most important feature (reliability), we have made significant changes to how we do SRE. And we’re getting better at it every day.

How well positioned is your team to ship reliable software? What are the different roles in engineering that impact reliability, and how do you optimize the ratio of software engineers to SREs to DevOps within teams? These questions can be hard to answer in a quantifiable way, but projecting different scenarios using systems thinking can help. Will Larson’s blog post Modeling Reliability does just that, and serves as inspiration for this article.

For many SREs, networking prompts a similar response as going to the dentist. You know you should do it, but you don’t really want to. But networking is much less like a root canal and more like a regular teeth cleaning; you may not want to go, but once you’re there, it’s not so bad. In fact, you may walk away feeling good knowing that you’ve done something that helps future you.