監訳者である、 @ymotongpoo さんを通じて、オライリー社からご恵贈頂いた「SREの探求」を読んだ。この本は33章を632ページで書かれており、技術書としてはかなり厚い部類に入るので、手に取ることをためらう方も多いのではないかと思う。読んでみて僕自身が思ったのは、僕のためになることもとても多くあるし、今の僕には必要のない情報も書かれている本でもあるということだ。よって、おすすめの読み方は目次なり、各章の頭の方を読んでみて、興味が持てるならば読む、興味を持てなければ見出しだけ読んで、脳内に、こんなこと扱ってる章があったなとインデックスだけ残して進むことをおすすめする。
書籍の内容としては主にアメリカのBigTechと呼ばれるような組織に所属する主に、エンジニアが、まるでリレーのように各章を様々なトピックで書きつないでいる。例えば、SREをどのように組織に導入するか、日々の仕事をどのように進めるのか、トレーニングはどのようにするべきかなど、多岐に渡る。故に、先に述べたように今の自分に必要なことも、未来で必要なことも、あるいはすでに自分が通ってきた道に関することも書かれている。
僕は今回は自分がすぐに取り組みたいと思ったことや、これは僕たちの組織に今、必要なことだと思ったことにラインを引いて、付箋を貼るような読み進め方をした。書籍の購入を迷っている方のために、 どういった内容なのかを知ってもらう目的で、自分がラインを引いた箇所をいくつか書籍より引用する。
「人々が漫然と運用業務を行っているわけではなく、適切な意思決定を行うためのコンテキストが欠如しているだけだ」という原則を出発点とすることです
SREの探求 初版 1章SREにおけるコンテキストとコントロール 5ページ
この章を読んで、僕自身が過去に人の判断、感じ方を不思議に思ったことは、仕事、日常の暮らし問わずにあるが、振り返ると自分は人に対して意思決定ができるほど十分にコンテキストを共有しているのだろうかと思った。なぜならば、僕はこうして文章を書くときはある程度、まとまった情報を書くのだが、一方で普段のテキストコミュニケーションだと反射神経が8割位を締めているので、かなり情報の出し方が下手なのだと思う。そういう自分を振り返る瞬間がここ章にはあった。
検出時間(Time to Detect = TTD)
SREの探求 初版 4章SREにおけるインシデントのメトリクスを用いたSREの大規模な改善
普段、あまり気にしてないメトリクスだったなと感じてラインを引いていた。この値は、障害影響の発生から運用者がインシデントを把握するまでの時間なのだが、例えば暫定的に自動収束の実装がされていない、手動での復旧が必要なインシデントであれば、このTTDがかなり復旧時間にとって大きな影響を与える。僕の所属している組織ではまだまだそういったインシデントが多くあるので、組織として一つのメトリクスとして検討してもいいだろうと思った。
部分的に、あるいは全体として、チームがコントロールできる範囲から外れているトイルは特に危険です。こうしたトイルは、あらゆるエンジニアリング作業が締め出されてしまう破産の瀬戸際までチームを追い詰めることになりかねません。これはシステム管理者のチームから「SREチーム」へと看板だけ掛け替えたものの、エンジニアリングが欠如していることから新しい名前にふさわしい変革が阻害されるというアンチパターンの共通の原因です。
SREの探求 初版 10章大企業でSRE導入の道を開く方法
引用元のコンテキストをもう少し補足すると、大企業において部門をまたぐようなトイルがある場合、その境界を超えてそのトイルを解決することは一筋縄ではいかないということを起点に、サイロに立ち向かう方法や、トイルの削減、行動するためのプロセスなどをわかりやすく解説されている。これは割と僕たちの今の組織に適用できそうな内容に感じたので、ラインを引いた。
ここまで紹介したもので全体のラインを引いたものの4分の1くらいだが、こうして振り返っているとついつい前後まで読んでしまって筆が進まないのでこれくらいにする。
最後に、僕自身が昨今、人々をどうエンパワーメントして、組織でエンジニアリングしていくかということに、どのようにアプローチしていくのかということを課題に感じているので、タイミングが良く多大に影響を受けたし、これからどう実践していこうかと考えをまとめているところです。 SREについての文化、働き方、あり方、組織について興味がある方に、ぜひおすすめの一冊です。