SRE - Enterprise Roadmap and the UNIX Philosophy

Hello, I'm incompetent.
It was a delightful day, like a beggar, after having the best lunch – all-you-can-eat soup, drinks, and salad – which I learned about from my senior colleagues and older folks at the company. When you have soup with your meal, your life's happiness level goes up by about 5. Huh? What percentage is 5? Well, that's up to each person's discretion...

Useful URL Links to Start With

with The Grateful Dead - Darkstar
A famous song used for early Slackware hostnames

Introduction

I read the SRE Enterprise Roadmap once a month ago, and today I read it a second time.
It's also available for a fee from O'Reilly, but I've read about half of the first part, which is also publicly available for free at the preceding URL.
The first time I read it, I just tried to get the words into my head, and then I read it a second time. That's all there is to it...

It is Generic/Versatile

The content of the SRE roadmap does not use actual product names, but rather discusses the principles of thinking, why they are necessary, and positional aspects.
Especially the awareness of working in a team and the idea that human workload should not be increased. The latter exists as a UNIX philosophy

Automate everything
To efficiently build a third system

Does this point apply?
It's interesting that it states that distributed engineering, or whatever you want to call it, should not involve taking on a hard workload at first glance, and I think this is a topic about what the ideal form is.
Furthermore, regarding the content, it also touches upon not only the versatility of systems but also human versatility in having an open mind to welcome diverse people into the team, especially concerning the point that existing teams should become SREs.

Both Offense and Defense

It should be an organization that combines conservative operational and construction thinking with innovative development-side thinking.
I felt that the points where it should be subservient and where it should not be were clearly explained.
As explained in Building a Culture of Security and Reliability, if an organization leans too much towards 'no', it will stagnate, and decisions must be made to take risks where appropriate. Humanly speaking, in a culture of negativity, even good ideas risk becoming nothing.
Even in casual conversation, for example, if you consider SNS to be useless, the chances of gaining information from it will decrease accordingly. This applies to all means of gathering information; while it's said that 'watching too much TV makes you stupid,' conversely, you'll lose the ability to catch what information is being broadcast on TV.
However, it's not realistic for one person to catch everything, but I believe human communication can overcome this.
Even now, it's fun to discover new things about friends even after talking to them and being together for several years.

I've strayed a bit from the topic, but ultimately, if asked whether it's engineering that eliminates waste in terms of mechanisms, I would say no. Rather, is it (site) reliability engineering that is created by finding added value in what might seem wasteful and building systems to eliminate that waste?

Small is Beautiful

I believe that in many cases, systems inevitably grow large, and that's unavoidable. It's a legacy from the past, and I feel it's synonymous with the continuous issuance of fiat currency backed by government bonds, moving away from the gold standard.
In that sense, the currency issued by government bonds eventually becoming a liability, doesn't that overlap with technical debt?
No matter how much you try to keep a system small, if a country grows, it will eventually gradually expand.
This is also why, historically, actions must be taken after something has grown large, and I believe most things operate on this principle.
As explained in Simplicity, what developers who adhere to other UNIX philosophies value more is that less code increases readability and also improves maintainability.

Look to the future. The future comes faster than you think.

Conclusion

In reality, I broke it down and read it section by section as my interest arose, and I feel it's a technical book that can be enjoyed within a readable range.
I like reading interview articles, so the content, which describes what actual engineers think and what they've done, feels realistic and is easy to grasp.
It's great that this is available for free.
Well then. See you again.