While I was working as a sysadmin engineer, there were a lot of repetitive tasks, routine tasks—toil—that could be automated and customer impact could be minimized. As I was digging into this idea, I discovered the [Google] SRE book, which was basically my first encounter with SRE as a craft. It was mind blowing. I changed my way of thinking about how to architect systems and how to instrument observability to gather actionable data and react in time and prevent any potential incidents and outages. I was excited about the idea and started applying to SRE positions.
That the only “good” way of doing SRE is to focus on SLOs. For a small or medium company to put too much focus on SLOs, it’s often at the expense of being able to deliver new features faster, which is essential at that scale. A small company still needs to position themselves in the market and prioritize velocity. So what works at Google—a massive company that is already known and trusted—doesn’t directly apply.
Anything that requires manual labor or precision, like placing a server on a rack. Handling expensive stuff that could break, or the work of a surgeon where you need to be very precise and the cost of error is high. I like that software is more abstract, and uses the brain rather than the hands.
Thinking Fast and Slow by Daniel Kahneman.
It would depend on the scale of the epidemic of zombies, but if they came here to Copenhagen then I'm doomed. I don't think I would last more than a day.
.png)
.png){kind=icon}
.png){kind=icon}
