Rendered at 19:03:36 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
corvad 4 hours ago [-]
Started reading the book recently and one thing stood out:
> Blameless postmortems are one aspect of a blameless culture. Creating a safe environment and fostering a culture of learning requires understanding blame and acknowledging cognitive biases. Blame can be a way to discharge discomfort, as Brené Brown suggests. It’s crucial to recognize cognitive biases such as the fundamental attribution error (where we attribute others’ actions to internal traits and our own to external circumstances) and hindsight bias (the tendency to see past events as predictable).
> Blamelessness shifts the focus of responsibility from people to systems and processes after an incident. Finger-pointing leads to risk aversion, fear, and a tendency to hide mistakes, which reduces situational awareness, increases the risk of problems accumulating, and limits the organization’s ability to be proactive—stunting the ability to innovate and improve. A blameless culture instead focuses on identifying and improving the systems and processes that allowed the incident to occur. It assumes that individuals act in good faith and make decisions based on the best information available.
This is probably the most important thing in my opinion in a lot of scenarios and cannot be emphasized further.
solatic 7 hours ago [-]
Eagerly awaited, particularly the sections on AI infrastructure.
Stuff that was lacking from the first edition, that it doesn't seem like it will make it into the second edition:
Financial justification and cost optimization, in particular for observability: it's easy to extoll the virtues of collecting metrics, logs, traces, and profiles, but it gets very expensive, very quickly. Conversations about observability quickly throw out the baby with the bath water, rather than laying out clear best practice approaches on when, along the lifecycle of system maturity, additional return on investment can be proven. But FinOps perspectives in general are lacking as well.
Security-focused SRE: rolling out secrets management, permissions management, certificate management, firewall/network management, adapting SIEMs, whether or not traditional SOC work should be integrated with SRE roles and given the same "solve toil like a software engineer" treatment.
I don't know if I'm really suggesting that the book should be twice as long; perhaps there should be multiple volumes: uptime reliability engineering, financial reliability engineering, security reliability engineering, for lack of better phrasing off the top of my head.
so-cal-schemer 10 hours ago [-]
I've taken a cursory look at the 1st edition. It looked like an excellent book -- definitely on my 'To Read' list. In fact, I'll put in an order for a copy now.
dangets 9 hours ago [-]
FYI the first edition is readable online for free.
> Blameless postmortems are one aspect of a blameless culture. Creating a safe environment and fostering a culture of learning requires understanding blame and acknowledging cognitive biases. Blame can be a way to discharge discomfort, as Brené Brown suggests. It’s crucial to recognize cognitive biases such as the fundamental attribution error (where we attribute others’ actions to internal traits and our own to external circumstances) and hindsight bias (the tendency to see past events as predictable).
> Blamelessness shifts the focus of responsibility from people to systems and processes after an incident. Finger-pointing leads to risk aversion, fear, and a tendency to hide mistakes, which reduces situational awareness, increases the risk of problems accumulating, and limits the organization’s ability to be proactive—stunting the ability to innovate and improve. A blameless culture instead focuses on identifying and improving the systems and processes that allowed the incident to occur. It assumes that individuals act in good faith and make decisions based on the best information available.
This is probably the most important thing in my opinion in a lot of scenarios and cannot be emphasized further.
Stuff that was lacking from the first edition, that it doesn't seem like it will make it into the second edition:
Financial justification and cost optimization, in particular for observability: it's easy to extoll the virtues of collecting metrics, logs, traces, and profiles, but it gets very expensive, very quickly. Conversations about observability quickly throw out the baby with the bath water, rather than laying out clear best practice approaches on when, along the lifecycle of system maturity, additional return on investment can be proven. But FinOps perspectives in general are lacking as well.
Security-focused SRE: rolling out secrets management, permissions management, certificate management, firewall/network management, adapting SIEMs, whether or not traditional SOC work should be integrated with SRE roles and given the same "solve toil like a software engineer" treatment.
I don't know if I'm really suggesting that the book should be twice as long; perhaps there should be multiple volumes: uptime reliability engineering, financial reliability engineering, security reliability engineering, for lack of better phrasing off the top of my head.
https://sre.google/sre-book/table-of-contents/
I would also mention "The Datacenter as a Computer: designing warehouse-scale machines". https://research.google/pubs/the-datacenter-as-a-computer-de...