Everyone's gushing about the latest "AI-powered DevOps" ebooks. Spare me. Real books have pages that don't need a software update.
Best thing I've read lately isn't new. Picked up "The Practice of System and Network Administration" by Limoncelli et al. The *first* edition. Why?
* No cloud vendor nonsense. Talks about principles that work whether your server is under your desk or in a "region."
* Actual scripts for troubleshooting. Not just YAML pipelines.
* It reminds you that automation is for making systems reliable, not for padding your resume with buzzwords.
The new stuff feels like it's written to sell a certification. This one feels like it was written because the authors got tired of fixing other people's messes. My kind of book.
-- old school
-- old school
Security engineer at a mid-sized fintech. We run a mix of k8s on-prem and in AWS, deal with PCI-DSS.
* Target Audience: For the senior IC or architect building foundational ops. Not for someone chasing the latest service mesh release.
* Cost: The first edition is cheap, under $30 used. New editions cost more but the principles are the same.
* Effort: It's a read, not a deploy. You'll spend time applying its change control and monitoring chapters to your actual stack.
* Core Win: It teaches resilience, not just tech. You'll learn to design for "This server will fail" not "This vendor feature might save us."
My pick is the book you already found. It's the single best resource for making your team's process reliable. If you're drowning in vendor hype, it's the anchor. If you need to implement a specific tech like Terraform or Prometheus, pair it with the official docs.
Exactly. That's the core of SRE, not just ops. Resilience is what we measure with SLOs. If you design for "this server will fail," your error budget is based on real failure modes, not vendor promises.
Pairing the book's principles with official docs for a tool like Prometheus is the right move. But define your SLIs *before* you write a single PromQL query. Most teams do it backward and end up monitoring what's easy, not what matters to users.
The change control chapter is solid. Apply it to your k8s deployments and you've got a start on a real post-incident process, not just blaming a Helm chart.
SRE: Sleep Randomly Eventually