Optimize for Happiness

The other day I was talking backups with a client. They had a solid custom script that compressed customer data into one large file and pushed it to object storage. One big compressed object is usually much faster to upload than thousands of small ones, so the backup finished sooner. That felt like a win.

Then I asked the obvious next question: what does the restore look like?

With the single large file, you download everything, decompress everything, and only then start putting customers back online. Everyone stays unhappy for a long time, then suddenly everyone is happy again.

If you instead back up each customer’s data as separate objects, the restore changes shape. The moment the process starts, the first customers come back online. Every minute after that, more customers become happy. Some unlucky ones at the end still wait longer than they would have under the big-file approach, but overall happiness rises earlier.

That small shift in perspective matters more than most backup metrics. The backup job itself runs unattended at night. Nobody is watching the progress bar. What actually counts is how quickly customers stop being unhappy when something goes wrong.

This is the lens SRE work should use more often: customer happiness, not the internal numbers we find convenient to measure.

Google’s four golden signals — Latency, Errors, Traffic, and Saturation — are useful precisely because they are close proxies for that experience. What good is an online store that returns a 503 quickly, or one that eventually works but takes thirty seconds to respond to every click? Both destroy the customer’s sense that the service is reliable.

Not long ago, most monitoring was far cruder: a simple ping, an SSL certificate check, or a request that expected a 200. Those checks answered the basic up/down question and were already more than many organizations had. Today we can go much further. Synthetic tests can walk a full user journey: login, browse, add to cart, checkout — and measure not only success but how long each step takes. We can then set alerts on those timings.

This is where Service Level Objectives come in. Inside the company, we agree on targets that are stricter than the external SLA. The SLOs keep us honest and give us an early warning before customers feel the pain.

None of this works if the SRE organization still sees itself as a separate technical tribe that simply “keeps the servers running.” We have to understand how the systems we build, operate, and recover actually affect the people who pay the bills. Everything we do — capacity planning, incident response, backup design, on-call rotation — should be judged by one practical question: does this make customers happier, or does it only make our dashboards look better?

If your team is trying to shift from internal metrics to real customer outcomes and could use an experienced outside perspective, feel free to reach out.