非SREが読んだら特に9章がグッと来た SREの知識地図 について
こんにちは。ダイの大冒険エンジョイ勢のbun913と申します。
私はSDET（Software Development Engineer in Test）という職種で働いており、テスト自動化コードの実行だけでなく「こういうテストをできる仕組みが欲しい〜！」を叶えるのも私の仕事だと思っています。
そのため今でもAWSやGCPなどの学習を行っているのですが、以下の書籍 "SREの知識地図 基礎知識から現場での実践まで" を読んでみました。「QAグループに属するものとして、SREが何をしているか知らないと信頼性を築けないよな」という思いで購入し、まさに「SREとは何か」や「どのように組織構造でSREを配置するか」といった内容まで教えてくれた素敵な本でした。
あまり詳細に書き過ぎてネタバレをしないように気をつけつつ、特にグッと来た箇所や章を簡単に紹介させていただきます。
章立ては以下のようになっています。
- 第1章 SREとは
- 第2章 信頼性を定義して組織で運用する
- 第3章 システムの状態を観測する
- 第4章 障害を学びにつなげる
- 第5章 障害対応のプロセスや体制を作る
- 第6章 手作業を自動化し効率化する
- 第7章 サービスのリリースを事前にレビューする
- 第8章 SREの組織構造
- 第9章 SREの実践
第1章 SRE とは
以前AWSエンジニアとして働いていたのですが、私自身はSREとして特定のプロダクトや組織に在籍したことがなく「SREって何をどういう気持ちでする人たちなんだろう」となんとなく思い続けていました。
実際組織の状況や立場によって結構バラバラな考えがあると思っていて、シンプルにインフラ屋さんに近い方から、バックエンドエンジニアからクラウドやインフラの知識を携えてプロダクトコードも分かった上でより広範な働き方をする人まで多岐に及ぶと思っています。
この章では「サイトリライアビリティのサイトって何？」や「なぜSREチームが重要なの？」という疑問まで参考文献を交えながら考え方を紹介してくれていました。
なお、「知識地図」という名前通り、この章に限らず随所で参考文献やWebサイトの紹介をしてくれており、本気で全てを読もうと思うと相当なボリュームになるので私はまず本書籍の読了に集中し、特に興味があるタイトルのコンテンツの場所に付箋を貼っていきました。
こちらはさらに他書籍からの引用してくださっていた言葉ですが以下のSREの定義がとても素敵だなと思いました。
SREとは、ソフトウェアエンジニアに運用チームの設計を依頼した時にできあがるものです。
私も SDET(Software Development Engineer in Test) として、開発やAWSエンジニアの経験と心を持った人がQAグループ側にいる状態を常々意識しています。
専門知識を持った人がさらに越境して、より異なる領域でプロダクトやサービスに向き合って開発者を支える。という意味でもSDETもSREに似ているかもしれないなと、一人でニヤニヤしながら本章を読了していました。
第2章 信頼性を定義して組織で運用する ~ 第3章 システムの状態を観測する
2章では今後の話にも繋がってくるような、じゃあ信頼性ってどうやって測るの？うちのサービスではどの状態であれば信頼性を保っている状態と言えるの？といったことを定義して運用する方法について記載してくれています。
よく聞くSLAやSLO・SLIといった言葉の説明だけでなく、どのようなステップを踏んでそれらを導入していくかということも記載されています。
第3章に入ると「システムの状態を観測する」ということで、よりシステム側にたったモニタリングの時の指標などについて説明してくれています。その際、 The Four Golden Signals や USE メソッド などの適用する範囲やそれぞれが重視している指標について解説してくれています。
あるあるかもしれませんが、かつて2章にあたる信頼性の定義などは特にせずに雰囲気でそれらの指標を適用していく作業をやっていました。信頼性って何？という定義をした上で臨むべき取り組みだったのかもしれませんが、逆に言えば「色々システムにおいてこれらはみておいた方が良さそう」という偉大な先人たちが形にしてくれていたものだったので、単に適用するだけでも一定の効果や適用への一定の説得力になってくれていたのだろうな。と思いを馳せていました。
第4章 障害を学びにつなげる ~ 第5章 障害対応のプロセスや体制を作る
障害が起きた後のポストモーテムの意義ややり方、5章では障害発生時のオンコールなどについて詳しく述べてくれています。
個人的に一番驚いたのが第6章の「手作業を自動化し効率化する」の章よりも物理的に厚かったことです。
イメージなのですが、SRE人口を増やそうと思ったら第6章の事例を集めたり、手厚くしようと私なら考えてしまいそうです。
この書籍では「リアルにSREとして障害とちゃんと向き合う。そのために組織側の体制や場合によっては勤務ルールもちゃんと考えないといけない」ということへのメッセージを勝手に受け取っていました。（実際はわかりません）
ちなみにその中でも個人的にグッと来たのが、ポストモーテムについて書かれていた第4章の中の以下の箇所です。
ポストモーテムは、障害が発生したときにのみ実施するものではありません。小さなインシデントや「ヒヤリハット」（重大な事故にはいたらなかったものの、その可能性があった出来事）についても、ポストモーテムを行うことで潜在的な課題を発見し、障害の予防につなげることができます。
私の知るチームの限りでは、開発者やSREチームなどを中心に障害が発生してしまった時などに批判なきポストモーテムをおこなってくれています。一方で、どのチームにも「スーパーバックエンドエンジニア」「このプロダクトは俺の子」といった超人が（経験的に）いるもので、その方たちがヒヤリハットを未然や即座に鎮火してくれることが多いと思います。
そのような時にはポストモーテムなどは開かれず（開くのにもパワーと時間が必要ですし）、ある意味、学びのポイントを失おうとしているかもしれないなということを尊敬するエンジニアの一人がおっしゃっていました。
まさに、ポストモーテムといった形に限らず、このようなヒヤリハットも組織の学びとして使える軽量な仕組みがあると良さそうだなと感じました。
ちなみに第5章のオンコールの話では、リアルに組織としてオンコールに対応するべく手法のヒントや注意点などが書いてあり、必読だと思いました。
第6章 手作業を自動化し効率化する ~ 第7章 サービスのリリースを事前にレビューする
第6章はみんな大好きトイル（の減少）について書かれており、個人的に特にあまり知らなかったことがなかったため割愛いたします。（興味のある関連コンテンツがあったので、あとでそれらは拝見します）
第7章ではお恥ずかしながら、言葉を知らなかったPRP（プロダクトレディネスレビュー）について書かれていました。こちらは重要な変更を本番にリリースする前に、その変更が本番運用の条件を満たしているか確認するプロセスの一つのようです。
QAチームの立場としては、プロダクトの品質や機能網羅性などをチェックするリリース判定のようなことを行っていましたが、PRPではより信頼性や技術的な観点から評価をするプロセスだそうです。
こちらについては知らないことが多かったので、時間がある時に以下書籍に目を通そうと思います。
第8章 SREの組織構造 ~ 第9章 SREの実践
第8章では、いよいよSREを組織的にどのようにチーム化したり配置するかという手法について書かれていました。
いわゆる、チームトポロジーの4つのチームタイプから考えるSREチームの位置づけやそこから考えられる以下のパターンについて説明されています。
- プロダクト専任パターン
- プロダクト横断パターン
- 会社横断パターン
それら説明から第9章では、実際に組織規模が拡大していったとある組織におけるSREチームの変遷や実践へと繋がります。
この記事のタイトルにもなっていますが、9章は特に私の価値観や考えにあうことが多く書かれていました。
著者がSREとしての活動を各プロダクトチームで展開するとき、最も重視していることは、チームメンバーにSREチームの価値をすぐに実感してもらうことです。
次のポイントは、SREプラクティスを一方的に推進するのではなく、チームが直面している具体的な課題にまず寄り添うことです
このあたりの記述だけで頷き過ぎて、寝転がりながら読んでいたのですが「それなんですよ！」などといって立ち上がってしまいました。
個人的な話にはなりますが、私も組織内でも（当時は特に）珍しかったSDETとしてQAグループに所属するなかで、一番大事だと考えるようになったのは「私の理想的なシフトレフト」を推進することではなく、「このチームの役に立たないとな」という思いでした。
最近私は「ずっとやりたかった、非同期的なテストをするための仕組みづくり」や「AIを活用していい感じに開発者の役に立てないかなぁ」といった施策をやらせてもらえるようになったのは、ちゃんとマニュアルテストの威力を勉強しつつ実際にバグを発見して開発者の役に立てるように取り計らってくれた先輩QAのデリバリーのおかげだと強く感じています。
なにか大きなものを持ってくる、導入しようとするにしても「こいつなら大丈夫だろう」「あれ解決してくれたしなぁ」という信頼貯金がお互いに必要であるため、「まず現場の役にたつ」というプラクティスをSREの立場で明言してくれていたのが非常に推せるポイントでした。素敵です。
まとめ
- SREの知識地図 を読了しました
- 知識地図 のとおり、技術的なプラクティスの説明だけでなく、組織的な観点や必要であればより詳細が書かれているコンテンツへのリンクなどを貼ってくれていました
- 個人的にとても9章に共感を感じ非常によかったです
私もSREではない立場でしたが、SREという方々が何を思いながら日々の業務をしているか考えるきっかけになってくれたので、本書にはとても感謝しています。ありがとうございました。
興味があればぜひご覧ください！
Discussion