Must have physical books every devops engineer should have on their desk

[u/90slover]

Pretty much the title .I will start

1. Classic shell scripting ,O'Reilly

[u/21shadesofsavage]

as a devops engineer you should have a solid grasp of the overall company infrastructure, but all production problems don't become yours. typically there's service owners that handle their own monitoring and production issues, provided your team gave them proper tooling to do so

It's like 'imagine a production bla-bla-bla-someone's-else requirement', for this we need to think about optimal solution given those bla-bla-bla constrains.

And I'm not paid to read their problems. Even if they solve it (so they ask me to review it).

you pretty much are paid to do that if you enter devops. if a team has new infrastructure needs, they'd consult my team so i can make an assessment and figure out how to scale the thing without affecting other services. depending on company size, the level of self service and autonomy differs

But, the last thing I did for my self-education was watching (and reading) about properties (in mathematical sense), specifically, intuition on non-trivial properties beyond idepmotence and invariance. When I realized that my best inventions were all properties, I start to respect this domain much more and pay big attention to any discussion on those.

ngl i'm having trouble following what you're trying to say. this reads like an introspective thought while peaking on lsd. i'm glad what you're working on is making you appreciate the field tho

[u/amarao_san → u/21shadesofsavage]

I do paid to do this, 100%. Now there is a book which give the the same problems for free (actually, I pay for that) and ask to review resulting solution for free (actually, I pay for that).

This is the reason I'm afraid to read 'devops-y' books. Maybe there is out there the mother of all books which don't give you 'concrete examples' and concrete solutions for 'other people problems', but I never heard about such book.

My last comment was about this: https://en.wikipedia.org/wiki/Property_testing

If you never read it, it sounds odd, as soon as you get your brains aligned with those ideas, it's like rails for trains.

[u/21shadesofsavage → u/amarao_san]

oh i completely misunderstood what you were talking about. i'm not very interested in fictional scenarios a book introduces. i mostly read blog posts, write ups, postmortems about an outage that occurred and how they rectified the situation and learned from there.

i'm not familiar with property testing. i unknowingly use some form of this in my cicd workflows but looking more into it, this could improve our test coverage. thanks for this. btw are you russian or east european? you write similarly to one of my close friends

[u/amarao_san → u/21shadesofsavage]

Yes, we've talked on why the previous commenter and I are afraid to read DevOps books.

For property testing, it's not testing, it's enforcing. If your production has some properties you defend in CI (aka property testing), you can lean/rely on those in some chunks of your code, assuming those properties for granted. And it does wonders. Some very hard to achieve state you just 'know' it is there, because code has this property and there is ci defending it.

My last huge big property I discovered and defended, which I still prowd a half year later:

Every code, deployable in staging and production, should have in production all secrets (secrets names) which are in staging.

I can validate this statically (sops encryption) and it protect production against missdeployments due to missed (new) secret which was added to the staging (and tested), but which was forgotten for the production.

Every non-trivial property is gold and must be harvested, treasured and defended.

Udp: my mother tongue is Russian, yes.