achiang

I was a sysadmin (at uni, in the early 2000s) and I am an SRE today (at Google).

The two jobs are nothing alike, at all, whatsoever.

Sysadmins are support roles. Their functional role is to provide a healthy substrate to run the application layer on top of.

SREs work at the application layer itself. If the system can't scale due to internal architecture, an SRE would be expected to propose a new, scalable design. That would be in addition to maintaining the substrate.

To be clear, there is also nothing inferior about performing a support role. No org can succeed without support.

But the two roles are not the same, and if a job's set of responsibilities don't include shared ownership over application layer architecture, then it can be a great job but it's not an SRE role.

It has been 10 years since I left Canonical (on good terms), but what popey describes (hi popey) about the intentional lack of human review in the Snap store sounds very Canonical to me.

I agree with all the recommendations - add human gates. Yes, it's expensive, but still far cheaper than the unbounded reputational damage that just occurred around the untrustworthiness of the store (hi Amazon).

Full body scans are a common preventative measure in Taiwan.

My parents (expats, living in the US for over 50 years) flew back and got routine scans (MRI, PET, CT) in February for about $1000 USD total.

Similar to this story, they found a tumor on my dad's pancreas. A biopsy confirmed it, and he had surgery in August. They caught it at stage I. We're very lucky.

The latency from February til August was entirely convincing the US medical system to take his Taiwanese images seriously. They finally gave up and went back to Taiwan to get the procedure done.

I'm getting older myself and will absolutely be paying for any sort of imaging available.

This should be more broadly available to everyone. I'd be happy for more of my tax dollars to go to preventative care rather than rear guard action.

Real world usage is you only get to use ~70% of the stated range on a road trip, so we're really talking about 350 miles of range, which is, as you say, what most people actually want.

Why 70%? You obviously don't run the battery to zero, 10% is a common amount of buffer to leave. And then when you DC fast charge, the rate of charging drops dramatically around 80%, so people don't charge to full.

These are for ideal conditions, add in any sort of weather and the range drops again as you run a heater, etc.

Living in the Bay Area, driving to Tahoe in the winter without a mandatory recharge should be the gold standard.

It's not an unusual use case, "only" about 180 miles, and yet there aren't any EVs that can do it confidently because going uphill in the cold with aerodynamic-destroying ski rack is really hard.

A car with 500 miles of fair-weather range could probably do it?

You need to use the fully loaded cost of an employee when estimating opex savings, which includes health care costs, retirement funding, etc.

Rule of thumb is that fully loaded cost for US employees is approximately 2x yearly salary (although people who've actually run a company can correct my potentially stale or incorrect understanding).

Google SRE here.

Point of clarification on "losing skills" by not being oncall enough.

Google designs its SRE teams to scale sublinearly to the service, which means we're often responsible for entire portfolios, not just a single service.

It's common for individuals to be SMEs on a subset of the portfolio, as the focus of their coding projects.

Obviously the rest of the portfolio is also undergoing continuous change, and so to remain a broadly effective oncaller across the entire portfolio, you need regular production exposure to the parts you interact with less frequently.

Those are the specific bits that get rusty with disuse.

I haven't seen anyone recommend net/http yet, but that is the library that was recommended to me to read to get a sense for modern, idiomatic go.

As mentioned elsewhere, the worse bug was in upstream, unpatched gdm.

It's been a very long time since I worked on a distro (former Canonical employee here) but every distro carries patches of some sort.

The semantic tagging is nice, I might start incorporating that into my notes.

On the overall topic of meeting notes, I picked this up as a new skill in the past year and it's been immensely valuable for myself and the people I meet with.

Specifically, I learned how to take realtime notes during the meeting while also listening and paying attention. It took practice but was achievable.

One key to success here is to explicitly ask for a helper to take notes while I speak. I've found this helps make the note taking seem like a whole team effort.

Colleagues have noticed and valued the notes and they do seem to lead to better meetings.

The politics is exactly the point of my comment.

The professional way to write a blog post like this is from your own perspective. Identify the proximate cause (the peer), name names if you must, talk about how awesome your own systems are, show some of your monitoring if you like, and talk about what you'll do in the future to be even more resilient to this class of problems.

That's all to the good and much of Cloudflare's blog was exactly that. Would've been fine if they left it like that.

Acknowledging there is no postmortem (yet) but then pointlessly speculating about what it might contain is what I have a problem with.

I don't speak for Google but if I found out we had written a post like this, I would speak up and advocate to change it.

Google networking SRE here (my team runs ns[1-4].google.com among other services).

Regardless of original intent, the blog doesn't land well with me. It could have provided the background on flowspec, using their own past outage as a case study, without any of the speculation or blameyness that came across here. The #hugops at the end reads quite disingenuously.

We see other networks break all the time and we often have pretty good guesses as to why. But I personally would never sign off on a public blog speculating on a WAG of why someone else's network went down. That's uncouth.

The design you propose is stateful, and if you read the chapter closely, you can see we spend a lot of effort to make things stateless.

The main thing I wanted to respond to in this thread about a single bad server destroying your yearly SLO is described in the first paragraph in the section on load balancing at the virtual IP address.