タイトルは「お前が書け」という話です。

97 Things Every SRE Should Know

Site reliability engineering (SRE) is more relevant than ever. Knowing how to keep systems reliable has become a critical skill. With this practical book, newcomers and old hats alike will … - Selection from 97 Things Every SRE Should Know [Book]

https://learning.oreilly.com/library/view/97-things-every/9781492081487/

『97 Things Every SRE Should Know』を読んだ。言うまでもなく「97のこと」シリーズのSRE版にあたる。

Amazonでレビューを見ると、かなり漠然としていて哲学的だ、という理由で☆1つになっている投稿があった。他の「97のこと」シリーズを読んでいれば予想はできると思うが、この本もまた、確かにある種漠然としたエッセイ集であり、具体的な実践Tipsではない。自分としては、ことSREに関してはむしろ積極的にエッセイが読みたい。『SREの探求』に書かれている、この一節が象徴的だと思う。

私の経験では、SREのような分野は、その分野の人々（すなわち現実の実務担当者）が互いに話し合うことで最も望ましく成長していきます。人々が集うことで、話し合い、議論し、笑い合い、自らの経験（成功と失敗）と未解決の問題を共有するようにするのです。会話が織りなす、賢く、親切で、多様性に富み、インクルーシブで、敬意に基づくコミュニティには、ある分野を他の何物にも代えがたい方法で進化させる効果があります。

『97 Things ...』のなかでも、「93. SRE in Crisis」において近しいことが書かれている。現状のSREは『SRE book』を参考としているものの、この本もまたあくまでGoogleにおける実践、プラクティスであり、科学的に何か裏打ちされているわけではない。例えば、なぜトイルの比率は50％以下がよいのか。別の比率ではダメなのか。Googleのプラクティスをそのまま真似をする必要はないし、むしろあれほどの規模の組織で、あれだけ優秀なエンジニアを抱えたSREチームを真似できるわけがない。

だから、SREは探求が必要であり、各企業やチームの状況に合わせて、SREをどのように「インストール」したのかが重要になる。それは必ずしも客観的な根拠に基づいたものではないかもしれないし、仮説を立てて、実践検証して、また別の仮説を立てていく、常に発展途上なものでもある。そういった試行錯誤している実践や、そこから得られた教訓や、各々の「SRE観」をまとめていけば、自ずと「エッセイ」と呼ばれる、ある種漠然としたものにはなっていくだろう。それで全然いいので読みたい。SREはエッセイを書くべきだな、というのを、本書を読んで強く感じた。千差万別な実践をそれぞれに言語化していくことで、初めてGoogleに寄らない、SREというロールの抽象化ができる。Google1社による実践の手を離れ、多くの企業での具体的実践を通過することで、SREについてはさらに次の論理が生まれていくんじゃないか。日本だと主観的なエンジニアの記事に対して、「ポエム」という表現が半ば揶揄を交えつつ使われることがあるが、あれは詩ではないし、「エッセイ」と呼んだら抵抗なくなるんじゃないかと思うが、どうだろうか ¹ 。

以下、印象に残った章をいくつかピックアップしておく。

2. Do We Know Why We Really Want Reliability?

信頼性というものがそう簡単に割り切れるものではないことがよくわかる一節。拡大する市場で勝負を仕掛けているのであれば、信頼性の欠落により失う顧客よりも獲得顧客のほうが多く見込め、機能開発に対するインセンティブが強く働く。このように、常に信頼性が至上命題ではないなかで、どう向き合うか。

22. SRE, at Any Size, Is Cultural

タイトルだけですべてを言い表しているし、とても同意する。 State of SRE Report 2022 でも、 "SRE is a cultural change" と書かれている。

34. Storytelling Is a Superpower

SREの行っていることは "mystical" に見えがちであり、他のチームに対するストーリーテリングをすること、そういったスキルも重要であると説かれている。技術一辺倒の技術職ではないよな、というのは自分も感じている。

76. The SRE as a Diplomat

いわゆるEmbedded SREのようなプラクティスについて書かれている。ここではDiplomat、すなわち外交官に例えられており、ロールとしては "forward-deployed SREs (fdSREs)" と呼び表されている。

87. Important but Not Urgent: Roadmaps for SREs

重要だが緊急ではない。アイゼンハワー・マトリックスにおいては、最も多くの時間をここに費やせとされているが、「緊急ではない」タスクは積まれがちであり、なかなか消化されていかないジレンマ。信頼性がひどく劣化していたりしない限りは、どのSREチームでも「重要だが緊急ではない」タスクばかりが溜まっていそうであり、それに着手できていないとすれば、トイルの比率を考え直したほうがいいのかもしれない。

92. Risk and Rot in Sociotechnical Systems

組織というのはリスクを過小評価して、信頼性への投資を怠りがちである。SREはこれを避けるように組織を仕向けていかねばならない。

93. SRE in Crisis

先に言及した通り。