{"id":297,"date":"2021-08-31T14:40:03","date_gmt":"2021-08-31T14:40:03","guid":{"rendered":"https:\/\/fde.cat\/?p=297"},"modified":"2021-08-31T14:40:03","modified_gmt":"2021-08-31T14:40:03","slug":"sre-weekly-issue-265","status":"publish","type":"post","link":"https:\/\/fde.cat\/index.php\/2021\/08\/31\/sre-weekly-issue-265\/","title":{"rendered":"SRE Weekly Issue #265"},"content":{"rendered":"

View on sreweekly.com<\/a><\/p>\n

\n

A message from our sponsor, StackHawk:<\/h2>\n

Join StackHawk and WhiteSource tomorrow morning to learn about automated security testing in the DevOps pipeline. With automated dynamic testing and software composition analysis, you can be sure you\u2019re shipping secure APIs and applications. Grab your spot:
\nhttp:\/\/sthwk.com\/stackhawk-whitesource<\/a><\/p>\n<\/div>\n

Articles<\/h2>\n
\n
Insights into a Product SRE team at LinkedIn<\/a><\/div>\n
\n

Here\u2019s a great look into how LinkedIn\u2019s embedded SREs work.<\/p>\n

\n

[\u2026] the mission for Product SRE is to \u201cengineer and drive product reliability by influencing architecture, providing tools, and enhancing observability.\u201d<\/p>\n<\/blockquote>\n

Zaina Afoulki and Lakshmi Namboori \u2014 LinkedIn<\/small><\/p>\n<\/div>\n<\/div>\n

\n
DNS propagation does not exist<\/a><\/div>\n
\n

It\u2019s all just other people\u2019s caches.<\/p>\n

Ruurtjan Pul<\/small><\/p>\n<\/div>\n<\/div>\n

\n
Advice for someone moving from SRE to backend engineering<\/a><\/div>\n
\n
\n

Recently there was a Reddit post asking for advice about moving from Site Reliability Engineering to Backend Eng. I started writing a response to it, the response got long, and so I turned it into a blog post.<\/p>\n<\/blockquote>\n

Charles Cary \u2014 Shoreline<\/small><\/p>\n<\/div>\n<\/div>\n

\n
The Mightiest Monolith<\/a><\/div>\n
\n

This is the first in a series about lessons SREs can learn from the space shuttle program. The author likens earlier spacecraft to microservices and the Shuttle to a monolith.<\/p>\n

Robert Barron<\/small><\/p>\n<\/div>\n<\/div>\n

\n
The 5 characteristics of high reliability organizations<\/a><\/div>\n
\n

This article is ostensibly about Emergency Medical Services (EMS), but as is so often the case, it\u2019s directly applicable to SRE. The 5 characteristics are enlightening, and so is the fictitious anecdote about an EMT rattled from a previous incident.<\/p>\n

Ems1<\/small><\/p>\n<\/div>\n<\/div>\n

\n
How we scaled the GitHub API with a sharded, replicated rate limiter in Redis<\/a><\/div>\n
\n

Simple solution meets reality. I like how we get to see what they did when things didn\u2019t quite work out as they were hoping.<\/p>\n

Robert Mosolgo \u2014 GitHub<\/small><\/p>\n<\/div>\n<\/div>\n

\n
GitHub Availability Report: March 2021<\/a><\/div>\n
\n

They did the work to convert a database column to a 64-bit integer before it was too late. Unfortunately, one of their library dependencies didn\u2019t use 64-bit integers.<\/p>\n

Keith Ballinger \u2014 GitHub<\/small><\/p>\n<\/div>\n<\/div>\n

\n
Learning from incidents: getting Sidekiq ready to serve a billion jobs<\/a><\/div>\n
\n
\n

In this post, I\u2019ll walk you through one of our first ever Sidekiq incidents and how we improved our Sidekiq implementation as a result of this incident.<\/p>\n<\/blockquote>\n

Nakul Pathak \u2014 Scribd<\/small><\/p>\n<\/div>\n<\/div>\n

Outages<\/h2>\n