Narrative 001: Do you need a reliability strategy?

Let’s be direct:
Do you care about your users? Your business? Continuity, perhaps?
Then long story short is yes, you need a reliability strategy.

I know. It depends. It always does.

But insight into reliability is valuable, especially when you can access it before things break.

Perhaps the cracks are now showing in your service or some of the popular buzzwords are showing up in a roadmap nearby? Either way, it's a good time to talk about reliability strategies.

Where I find this especially relevant:

If you're working with:

• Containers and Kubernetes

• Internal developer platforms

• A team large enough to fight over merge conflicts

• CI/CD pipelines that break more than they build

• [if you're not able to ship your ideas from cradle to grave with ease, add more reasons]

We are also here because in the early days (what do I even know :-p) functionality was a huge priority and while that remains relevant contextually, modern software environments are more complex and expectations are at an all-time high.

So, do any of these sound familiar?

• You're running software critical to your business

• You have customers, or even just one user who matters

• You're on the modern cloud (AWS, GCP, Azure, etc.)

• You're building or scaling a team

• You're dealing with sensitive data

• You're not sure how your system behaves under load—or during failure

If yes to any of the above, then it's worth exploring a reliability strategy.

Making this happen depends on a lot of factors and it doesn't have to be complex.

At any scale, reliability is a everyone's responsibility and I believe an investment in discovering what it takes to start or keep it going is absolutely worth it. I also think reliability (SRE) is greatly misunderstood because we have been reading from the books by Google trying to be Google and when we weren't trying, we didn't experiment enough. btw they are great books and what they started is still a game changer. Shout out to them always.

Making this happen depends on a lot of factors and it doesn't have to be complex.

So what does a strategy look like?

There’s no one-size-fits-all answer.
Strategies come in different shapes and sizes but what matters is that they’re intentional and grounded in reality.

Here are just a few of the questions a good reliability strategy should help you answer:

1. What kind of value do you provide? Who’s depending on it and what breaks or who is affected if they don't get what they need?

2. Where does your software run? How important is location to fulfilling the value you provide? does it even matter where it runs?

3. How many people work on or depend on the system? And how do they collaborate?

4. What are your biggest sources of failure today? (Be honest. And if you know and can share, how much does it cost you?)

5. How do you currently detect problems and how fast can you recover?

The answers won’t give you a complete strategy, but they’re a start.
They give shape to the system you’re working with and show you where to focus your efforts. Btw let’s not forget that a good strategy isn’t just a set of policies or tools as it can involve multiple people and roles. So there's an agenda to drive a shared understanding.

There’s also no shortage of modern techniques and tools that can support your approach, but remember tools complement strategy they don’t replace or complete one.

---

TL;DR

If you care about uptime, trust, and delivering value, you need one.
But it can (and should) reflect your scale, maturity, and architectural constraints.