SREの基本概念と入門書としての位置づけ
こんにちは、エンジニアの博崎です。
こんにちは、エンジニアの三田です。
ゆるテクは、三田と博崎が、ゆるーく技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
ここの時点で、お聞きの方は気づくと思うんですけど、三田さんの声が鼻声でございます。
そうですね、すごく調子は良くないです。
はい、お大事にという感じですね。
元々は、先週、この今日のテーマで収録しようって話を二人でしてたんですけど、
ちょっと僕の声も全く出なくてですね、今日にずらしてもらいましたっていう裏話があったりはしますね。
はい、全然良いんですよ。こんなんもやりたいときにやりましょう。
ありがとうございます。
はい、今ちょっと話触れましたけど、今日のトピックは前から言ってたやつで、本読みました系ですね、またね。
はい、今日の本はSREの知識地図という本です。
新しいですね、比較的に。
そうですね、リンク貼ってるんで。
いつでしたっけ?
9月10日ですね。
これ撮ってるのが10月頭ですが。
多分二人とも出て一週間ぐらいで読んだはず。
そうですね、読んでから結構時間が空いてしまって、ちょっと不安ではあるんですが。
そうですね、ただ一応ポツポツとした感想とかメモ書いてるんで、ちょっと見ながらいきましょうかね。
はい、いきましょう。
どっから行こうかな。なんか気になったところとか言ってみます?
もう大事だし、一旦あれですかね、あんまり知らない人に向けてどんな本なのかを軽く紹介しておいた方が良かったりします?
確かに。では、はじめに書いてある本書はSREの基本概念からプラクティス実践の鍵、組織構造まで幅広いトピックをカバーし、読者がSREについて理解し実践できるようになることを目的としていますという感じですね。
はい、なのでSREちょっと知りたいよな、でもGoogleさんが書いてるわけじゃないか、オラエリーが出てるようなめっちゃドンキみたいな本、初っ端に読むのつらいなっていう時はめちゃめちゃ多分入門書として良さそうですよね。
はい、もうこの本の自分の大まかな感想はそれですね。
すごいよくまとまってて、オラエリーのSREよりもちろん新しいこともあって、最近の話とかね、プラットフォームエンジニアリングとかも入ってるし、あれ以降の話もちゃんと入ってる最新のSREについて広く周辺知識まで披露かと思ったらこの本がいいんじゃないかなという感じですね。
SREの組織的サポートと標準化
と言いつつですね、自分もメモに書いたんですけど、これ知らんかったわっていう単語があって、SREセンターオブプラクティスっていう単語、そんな表現があるんやと思ったんですけど。
SREの組織構造のところとかですよね。
そうですね、第8章で出てきました。
これ確かに博多くさんに言われてみると、僕もそういう表現自体あんまり聞いたことないなと思ったんですけど、いわゆるって言ってもあれかもしれないけど、セントラルSREみたいな話のことなのかなって思ったんですが、違うんですかね。
あれですよね、つまりやりたいこと自体は組織合団的にSREのノウハウを集中して集める。
うんうんうん。
一箇所に集めるということで、SRE以外の職種というか分野でも社内のノウハウというか、そういうナレッジを一箇所に集めるみたいなのって多分やられてると思うんで、ああいう系のことっていう、ちょっと自分は理解をしました。
一箇所に集めた上で、僕的には会社横断で広めていく、サポートしていくみたいなことだと思ったけど、でもあれか、集める、センターオブプラクティスって表現からするとあくまで集めることが目的だったりするんだろうか。
でも標準化されてることが多分大事という側面はありそう。
確かに確かに。
それぞれのチームごとに違ったやり方をしちゃってるとか、そういうのを標準化するっていうところが大事みたいなことも書いてあったような気がする。
実際あれですよね。チームごとに違ったやり方をするっていうところも、実際SREの形も、どうしてもその時そのチームが直面してる課題ともちゃんと寄り添った上で、SREイングしていかなきゃいけないっていう風になるから、全てのチームにおいて、せーのこれやりましょうみたいな感じにはできないですもんね。
そうですね。ただ同じような課題を別々の解き方、別々に調査して別々の解き方しちゃうみたいな無駄はこれで防げるよねみたいな話かな、多分。
再開発とかもしたくないですもんね。
同じでいいものはもう同じでいいわけですからね。
確かに確かに。確かにそれは結構あんまり効かないのは効かないですよね。
あとは、僕もそこの章で結構刺さるというか、大事なんだなって思ったのが、多分8章の冒頭の方で組織的なサポートをちゃんとSREチームが受けないと、効果的なSREの進め方できないよねみたいな表現があったと思ってて。
多分、SREやりたいぜって言って、SREプラクティスをひたすら独断で爆心していくよりも、ちゃんとそこって組織の人と説明責任を果たした上でどういうふうにサポートしてもらうかを合意した上で進めないとこういう取り組みって基本進みにくいんだろうなってすごく読んでて感じましたね。
そうですね。自分の経験というか実感ともよく合う、ボトムアップだけでは絶対うまくいかない。
ボトムアップだけではうまくいかないし、おそらくトップダウンだったとしても、トップダウンになった場合にどういう部分は協力をもらって、どういう部分は自分たちでやるかっていうその責任範囲の明確さとか。
冒頭にちゃんと話しておかないと結構大変だろうなって思いますよね。
そうですね。地面というかその役割だけを説明してしまうとすごい期待が高まりますからね、SREって。
SREの実践と価値の実感
そうそう。何とかしてくれるだろうみたいな。
なっちゃうからな。そのSREへの認識というかあれで言うと、どこだっけ、最初の方だった気がする。
第一章で、SREって言ったらサイトリリアビリティエンジニアですけど、とにかく信頼性を高める。
開発者にとってゲートキーパーというか門番のようなブロッカーだという認識をされている。
最近そうでもないかもしれないですけど、そういう認識の存在になりがちだなとはちょっと思っていて。
SREというのを全く知らない人はそういう存在なんでしょっていう認識をされがちな気がしているけど、そうじゃないんだよというのがちゃんと書いてあってよかったなと思いましたね。
そうですね。それは確かにそうだなって思ってて。
ただそれを書いてるだけじゃなくて、これちょっと第一章だったかどうか忘れちゃったんですけど、とはいえその信頼性に対する過剰な投資もやるべきじゃないよねみたいな話もあったと思ってて。
たぶんそこのバランスが上手に保てないと、さっき博多家さんがおっしゃってくれたように開発者にとってスピードを阻害する要因で囚われちゃうんだろうなって思いますよね。
そうですよね。いい感じに信頼性を保ちつつ一番速を出せるソフトウェアエンジニアリングをやる存在ですからねSREは。
それ大事ですね。
インフラの人と思われがちなんですよね。
本当そう。インフラの問題が起こったらSREに聞いてみるみたいなケースって結構あったりしますからね。
領域はインフラなんだがみたいな解決策は今までのインフラエンジニアと言われる人たちがやってきたこととはちょっと違うという感じなんですけどね。
本当そうですね。
広かったからな。
あとはそうですね、なんか僕は結構しっかりとか全体的には読んだんですけどやっぱり後半の僕は8章9章の組織部分とか。
とはいえ実際実践ってどうしていくねんみたいなところが一番染みたなって思ってて。
確か9章で書かれていたSREチームがプロダクトチームにSREを展開していくってなったときに、
なるべくSREチームの価値をすぐ実感してもらうことが大事なんだみたいな表現が確かあって。
価値を実感してもらうってどういう感じなんだろうなっていうのは結構考えちゃったかもしれないですね。
そうですね9章は事例の話だから実際どうやったか書かれてたんですけど、
実際にそれ以外の自分たちがやっていく中でどういうことをやれば価値を実感してもらえるんだろうっていうのはなかなか難しいですよね。
SREが提供するソフトウェアエンジニアリングによって何かプロダクトチームが明らかにコストが減るようになったりっていう話だったりするのか、
あるいは普段の問題解決をするにあたっての時間短縮とかを一緒に入り込んでやったら測れましたとか、
そういった部分の価値だったりするのかっていろいろ一言に価値と言っても難しいなって思いましたね。
そうですねよくやるというか、ネット上とかでもよく見るのは長いCIを短くするとかですかね。
10分の1にしてやったぜとかね。
そうそうよく見るやつね。
確かにそのプロダクトとかのコンテキストがちゃんとわかってなくても手をつけやすいところだし、実際数字で出やすいところだし、
開発者が一番ストレスを感じてそうなところではありますからね。
そうですね確かに。そういう問題を解決する場合ってどうなんですかね。
実際遠別としては近くで一緒にやらないことにはなかなかそこまでの着手って結構距離感あるなって思ったりはするんですけど、
たぶん通りすがれてちょっと解決していくわけでもないでしょうし。
そうですね。
でもそれこそさっきのセントラルの話じゃないですけど、
共通のやり方とかでやって、まずいやり方で遅くなってるとか。
はいはいはい。
前者的にテストを並列で流す、言語とかでちょっと異なるから今のはいい例じゃないかもしれないですけど、
標準化された手法でこれ適用したら簡単に何分か早くなるよみたいなパターンもあるかもしれないですね。
そういった意味だともうあれですよね、ある意味他のところの成功事例に対する情報を
ちゃんと集約された上で他のところにも提供していけるような感じですよね。
うん、ですねですね。
そうなってくるとなんか、ちょっとこの本とかに書かれてなかったと思うんですけど、
逆にそういう部分ってうまく情報集約してそれこそ最近のAIとかに任せていったら
割と解決策が標準化されてたりするんですかね。
なんかアドバイスぐらい、アドバイスできるなら実際プルリクまで作ってくれるか、やってくれるかもしれないですね。
やってくれそうですよね。
逆にそこであれか、そういうのを仮にAIが解決するとしてもそのAIが解決できるような基盤作りというか
ソフトウェアエンジニアリングでちゃんと準備できるかどうかっていうのも結構役割として入ってくるんですかね、今後は。
そうですね、渡すコンテキストの標準化とかはできると良さそうな気はするな。
なるほどな。
SREの基本概念
ちなみに自分は9章まである中で、この章いいなと思ったのは5章でした。
5章は障害とかでしたっけ。
確かにトレーニングとか、オンコール手当とかそういうのも全部書いてましたよね。
書いてました。すごいなと思って。これは良いと思いましたね。
やっぱりオンコールの心理的プレッシャーとかをしっかり理解した上で書いてる感が伝わってきますよね。
ちゃんとオンコールのトレーニング、あとランブックとプレイブックの違いとか、これは自分は意識してなかったんで、なるほどねと思ったし
燃え尽きとかね、オンコール語る上では欠かせないですね。燃え尽きとか、それぞれのケアをどうするかとかですね。
ちゃんと書いてあった。
まじで燃え尽きは、いつぞやのDevOpsレポートとかにもありましたよね、燃え尽き。
そうですね、あの時のレポートにはとにかくBurnoutがめっちゃ強調されてましたね。
Burnoutからのそのまま離脱っていうのも結構あったんでしょうね。
自分はそのあんまり大企業とかにいたことがないんで、大企業というか、だからオンコール対応する人が豊富にいる組織にあんまりいなかったんで、
つまりオンコールが少数の人に負荷が偏りがちというのをよく見てきたんで、すごいわかりみが深いって思って読んでました。
それは確かにわかるな。そんなオンコールローテーションをすごく余裕があるローテを組んで回せるほどの規模感、僕もあまりいたことはないので、
割と1,2週したらすぐ自分のターンが来るとか。
そうですね。
その前の4章もポストモーティブで1つの章なんですよ。
ポストモーティブ、学びを試算化していくのってめちゃめちゃ大事だと思うから、これでちゃんと1章儲けてるのって僕すごい良いと思ってて。
すごい良い。
よくポストモーティブで書かれる障害の振り返りとかが学びのためじゃなくて、とにかく上に報告するための報告書になっちゃうとすごいもったいないなって思う時ありません?
そうですね。自分たちのためじゃない感じになってるやつですよね。
僕もそんなにポストモーティブ、ポストモーティブって表現だとちょっとあれか、障害の振り返りをする場ってたくさんの現場を経験してきたわけじゃないので、
一概にどういうのが良くてどういうのが良くないかってあんまり判断はつかないんですけど、ちょっと分かんないのが、とはいえポストモーティブで失敗から学ぶってなった場合に、
結構僕はなるべくその時のインシデントに対応した関係者はなるべくみんなで参加して振り返りながら発見を探していくやり方が良いのではと思っているんですけど、
これまで見てきた別のケースとかだと割と誰か一人がいわゆるポストモーティブの振り返り書、報告書みたいなのを作って、その後で他の人たちに展開していくみたいなパターンも何回か見たことがあって、
実際周りの組織とか会社さんとかどういう風にその辺やってるんだろうなっていうのはちょっと気になってですね。
そうですね。ただあれ書こうと思っても、やっぱり一人が書かざるを得ないというか、対応した人がやはり個室はその人しか分かってないと思うんで、ただそこからどうだったかとかっていうのは複数人でも書けると思うけど、
それやろうと思ったら、ちゃんとインシデントコマンダーを立ててとか、ああいう運用をちゃんとやらなきゃできないですね。
インシデントコマンダー立てて、多分インシデント時のそれこそ何分ぐらい経ったらそろそろどうしようかとかを整えていかなきゃって感じありますよね。
そうですね。インシデントコマンダーいた職場もほぼないな。
いや、わかる。圧が強い偉い人が後ろで腕を組んでることはあったけど、コマンダーではなかったなみたいな。
あるなあ。
一つあるのは、僕は結構コマンダーいたらいいんだろうなと思ってるのは、一定障害対応してる時って停滞しちゃう時とか、次どうしようかってなっちゃうタイミングがあるので、
そこをやっぱ全体の流れ見た上で、各参加者の役割を明確にして、誰が関係者に報告してとか、誰が深掘り担当してみたいなことを役割分担する人がいるっていうのは結構僕は大事だなって思ってるんですね。
特に下手するといいことなのかもしれないんですけど、本当にみんな集まってくる時あるじゃないですか。
そうですね、わらわらと。
本当にそのレベルで集まらなきゃいけないやばい時もあるかもしれないし、こんなにたくさんの人集まらなくていいよってケースも往々にしてあったりするので、そこを整えるっていう役割でもコマンダーは必要だろうなって思いますよね。
そうですね。難しいんだよな。だいたいコマンダーって集まってきた人の中で誰がやるとか決まるもんじゃないですか結構。
ですね。
誰がやるってなるの難しいんだよな。適当に決めるとなると全員ができないといけないから。
まあ、おのずとっていうのありますよね。
この人がなるみたいなね。
そうそうそう。だいたいそういう時って人が少ないチーム間とかだと、コマンダーできる人が実は一番調査もできるから、結局その人一人に集中して燃え尽きていくみたいなことになりますからね。
少なくともコマンダーじゃないにしろ、対応している人と別に連絡とかそういうのをやる人が絶対いた方がいいから、そこは分けたいんだが、なかなかなかなかねっていう感じですね。
そうなんですよ。
みたいなことが、今のは対応の話でしたけど、ポストモテもちゃんと書いてあってよかったですね。
確かに。ちょっと脱線しちゃいましたね。
今気になったとこだけ話しちゃったけど、ちゃんとね、SREとはなんぞやみたいなのをしっかり書いてあったし、当たり前のこと、今スルーしちゃいましたけど、われわれ1章2章とかね。
結構1章2章いいですよね。
いいですいいです。
そこからちゃんと3章がオクザバビリティの話だし。
流れもいいんだけど、2章から7章は純不動で読んでも大丈夫って書いてありましたね。
1章でざっくりSREとはなんぞやを改めてインプットして、2章から7章は自分の一番興味のある分野というか領域に対して読み進めるっていうのが全然いいかなって思いますよね。
そうですね。いい本だった。
本当にいい本でしたよね。
では、この辺にしておきますか。
はい。
では、今回はSREの自色地図について話しました。
オンコールとその課題
感想などは、ハッシュユルテクをつけて投稿するかNexie2のコミュニティまでお願いします。
今日はありがとうございました。
ありがとうございました。
