SRE Weekly Issue #540

A message from our sponsor, Dragonfly:

Redis runs one core per process. Your server has 64. Dragonfly is a Redis/Valkey-compatible data store, rebuilt multi-threaded by an ex-AWS ElastiCache engineer:

  • 6M ops/sec on one node, no cluster
  • Drop-in: same clients, same commands
  • Instacart migrated and cut latency by 50% using 70% fewer nodes

Read how

Events like the recent compromise of CA signing keys are discussed out in the open, on Mozilla’s Bugzilla. Right now, you can watch the post-incident analysis as it unfolds.

  Mozilla

This article gives a really easy-to-follow explanation of the consistency issues you get when writing across two systems and how to solve them with an outbox pattern.

   Rahul Tewari — DZone

An explanation of why a service catalog is so important, especially during incidents.

Twenty minutes in, you haven’t started diagnosing anything. You’ve been doing archaeology.

Bonus: part two on keeping your service catalog up-to-date.

  Bill Duncan

The Firebase SDK caused app-side crashes due to a server-side data change. This article focuses on Google’s response, and I also recommend reading the writeup on the Firebase blog that Gergely links to.

  Gergely Orosz — The Pragmatic Engineer

LLM agents behave fundamentally differently from deterministic programs, and we can’t just expect them to work like a natural language programming language.

  Uwe Friedrichsen

This one delves into the design choices involved in running tons of little databases at the edge efficiently.

  David Laban and Lambros Petrou — Cloudflare

A seasoned emergency responder and computer incident management engineer shares a rare perspective on the similarities and differences between the two fields.

  Brent Chapman

Now I start a chat session with an AI model, give him a personality, most often it is an old and grumpy but well-mannered distinguished engineer…

  Hrvoje Rancic — ShiftMag

SRE Weekly Issue #539

A message from our sponsor, Incident.io:

AI made shipping code faster. Now reliability is the bottleneck.

Hear how Netflix and OpenAI handle that challenge at SEV0, the reliability conference in SF and London.

Free for SREWeekly readers with code SREWEEKLY.

Claim your free pass →

Today, I learned that “hot take” does not mean what I thought it meant. Specifically, it does not mean “telling it like it is and not holding back”. My deepest apologies for last week’s issue, Alex.

  Alex Ewerlöf

Grey failure, feedback loops, retry storms, and a mis-aligned safeguard, complexity, plus more — there’s a lot to dig into in this incident.

  Lorin Hochstein

They tested using Jev for SRE tasks paired only with a deterministic scaffolding, not an LLM.

  Yiming Su, Saad Mohammad Rafid Pial, Jackson Clark, and Tianyin Xu — SREGym

A case that AI doesn’t quietly swap out human work one-for-one, it reshuffles our roles into something harder. I see a strong thread of the Ironies of Automation throughout this one.

  John Allspaw — Adaptive Capacity Labs

A short interview with a seasoned incident commander. My favorite part was question 3.

  Simona Ursan — Uptime Labs

We’re going to do this via a metric that nobody’s ever heard of before, called “Mean Time to Stop Sucking” (MTSS). Just like in last week’s post, I’m going to argue that, despite the name, this is a real metric that you ought to be tracking in your autoscaler, and then explain why nobody does.

  drmorr — ACRL

How we capture real production database traffic at Airbnb and replay it offline to load-test, plan capacity, and de-risk upgrades.

  Zuofei Wang

Alert on what matters to your customers, not what you have easy metrics for. Reading this reminds me that I should set up a weekly review of on-call alerts to see which ones were actionable.

  Brent Chapman

SRE Weekly Issue #538

A message from our sponsor, Antithesis:

Author and CTO community leader Peter Bell offers engineering leaders a clear, pragmatic framework for adopting and scaling AI across the entire software development lifecycle.

Read now: Scaling AI Adoption in Engineering (Early Release)

This is rare: an article from an AI SRE solution vendor that speaks to the risk we take in adopting this kind of tool. They share quite a bit of detail on what they are doing to try to understand and improve their tool’s accuracy.

  Martha Lambert — incident.io

This was a fascinating incident! I love how Lorin shares his process for trying to understand Telstra’s incident report.

  Lorin Hochstein

No summary from me, I don’t want to ruin it. Well worth a read.

  Lorin Hochstein

Alex tells it like it is, and I loved it.

AI can explain it to you but it cannot understand it for you. That understanding is a key aspect of ownership.

The original version of this issue incorrectly used the term “hot take”.

  Alex Ewerlöf

Error budgets are about understanding and managing risk, and the risk equation is changing with LLMs.

if a material change depends on concentrated knowledge, single points of failure, or solely on AI models, that change is riskier than a similar change the team can explain and operate without them.

  Paul LaPosta — LeadDev

How do you measure kubernetes cluster utilization?

But I once had an economics professor who would respond whenever you mentioned a rate like productivity, efficiency, or utilization with a simple question: “Of what?” This was a polite way of saying: “Tell me the damn numerator and denominator, and do it right now.”

  Ian O’Gorman — ACRL

A code change was deployed before the schema change it depended on.

  Angelo Saraceno — Railway

Key business logic lived in the database as Groovy scripts, and analysts changed it live constantly. Why set up version control and CI/CD when everything worked fine? How they made the case is an interesting story.

  Dmitry Moskalyuk

SRE Weekly Issue #537

A message from our sponsor, WarpBuild:

WarpBuild runs your GitHub Actions jobs on runners that are 2x faster at half the cost. Change one line in your workflow file and keep everything else. Get $50 in free credits to try it now

Try WarpBuild free

When an Anthropic engineer says they’re seeing problems when using Claude for incident response, it’s well worth a read. The story seems to be improving, but it’s worth reading both this talk summary and The Register’s summary of a previous talk.

  Sylvain Kalache, summarizing talks by Alex Palcuie (Anthropic)

Another excellent story of shaving bytes at scale, with a fun coda: how do you safely change the hashing scheme in your massively distributed cache at scale without invalidating the whole thing?

  Kevin Guthrie, Mariia Iurchenko, Zaidoon Abd Al Hadi, and Ivan Babrou — Cloudflare

I can’t even count how many times I’ve pulled up the Wikipedia article with the nines chart. Maybe I’ll bookmark this interactive tool instead.

  fivenines

I’m impressed by the guardrails and safeguards they built into this system, and the automated fallback.

  Violetta Pidvolotska and Naveen Mareddy — Netflix

As the first in a series, this article sets the stage, going into why we autoscale and the autoscaling dimensions available in Kubernetes. I like the emphasis on the balance between cost and reliability.

  drmorr — Applied Computing Research Labs

Third-party SDKs speed up development, but they also introduce performance, security, reliability, and maintenance risks that teams must actively manage.

   Satyam Nikhra — DZone

This one’s worth paying attention to if you might need to scale up any time soon.

  Gergely Orosz

Here’s Lorin’s take on an incident I linked here a couple weeks back. I love this way of framing it:

The report attributes the incident to two errors:

  1. correctly following an incorrect procedure
  2. incorrectly following a correct procedure

  Lorin Hochstein

SRE Weekly Issue #536

A message from our sponsor, Planetscale:

PlanetScale is headed to SREcon26 in Dublin this October. Swing by our booth to grab some merch, catch a live demo, and chat with the team behind the world’s fastest databases. We can’t wait to see you there.

→ If you’re not at SREcon but still want to learn how PlanetScale can reliably scale your databases, get in touch.

Common threads seen across incident write-ups from many companies.

  Lorin Hochstein

How we built a production architecture handling 1,900+ messages per second and tens of thousands of concurrent connections with Kafka, Redis Pub/Sub, .NET Channels, and SSE.

  Mohsen Rajabi — ITNEXT

This is a thorough tour of the design decisions that separate a background job system that works in development from one that survives production.

  Shreshtha Saha — Techgenyz

This question kicked off a great comment section:

Has anyone gotten an automated RCA setup to actually nail root cause without a person doing the final synthesis, or is that still mostly aspirational marketing from vendors?

  u/Acrobatic_Refuse8100 and many others — reddit

Do you have a way to slow down traffic to your database during an incident? This one has a great explanation of why you need one.

  Lorin Hochstein

Through a fictitious case study, this article shows how to go about building a reliable service with an agentic component.

FYI the last ~quarter or so is a sales pitch, but the preceding majority of the article isn’t.

  Arpio

Rollback sounds great in theory, but it doesn’t always work. The CircleCI example really hits hard.

This reminds me of a classic article from the now-defunct company Skyliner, You Can’t Have a Rollback Button.

  Balu Kambala

Yes, this is a walkthrough of a vendor’s product, but the architecture is genuinely interesting and it reads like an engineering explainer rather than a sales pitch. I especially liked the wrinkle where one shard has to be designated authoritative so that custom type OIDs stay consistent across the whole cluster.

  Harshit Gangal — PlanetScale

  This article is published by this issue’s sponsor, but their sponsorship did not influence its inclusion in the newsletter.