ゆるテク紹介
こんにちは、ソフトウェアエンジニアの三田です。
こんにちは、エンジニアの博崎です。
ゆるテクは、三田と博崎が、ゆる区技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、というわけで、26回目、始めていこうかなと思います。
さっき冒頭に、ゆるテクって、ゆる区技術の話をするポッドキャストです、みたいな話をしたじゃないですか。
たまにこのゆるさが疑われるやつですね。
そうそう。疑われるやつもですけど、ちょっと振り返ってみると、ここ最近、あんま技術の話してないような気もしたんですよ。
なんてことだ。確かにしてない。
たぶんこの間は、心理的安全性の話をしたり、とか、その前は多分、キャリアどう考えてますかね、とかって話したり、
そのもっと前は、なんならスクラムマスターがどうこうって話を。
そっち系ちょっと多めですね。組織とか、アジャイルとかね。
全然、技術な話はしてないなって思いつつも、
今日も残念ながらなんか用意したネタが、しっかり技術かって言われると、また概念的なものっぽくて、大変恐縮なんですけれども。
DevOpsとSREの違い
いや、これは大丈夫です。技術ですよ。
大丈夫ですかね。
今日私ホストで用意してきたのが、
DevOpsとSREとプラットフォームエンジニアリングに対して個人の見解を書いた記事を、
先週、先々週あたりに読んだので、ここで博崎さんと共有したいなと思って持ってきましたと。
それぞれの比較みたいな記事なんですかね。
そうですね。中身で言うと、その方が思うDevOpsってこうだよね、SREってこうだよね、
プラットフォームエンジニアリングってこうだよねっていうのを述べられてるんで、
そこで述べられてる内容に対して、我々って今までどういう感じだったのかなとか、
逆に私たちはここはそう思わないねっていうのをこれでディスカッションできるといいなと思ってます。
先にこの記事の中身で書かれてたことを一部ピックアップしてくると、
この方すごく簡潔に書いてくださっていて、
まずDevOpsっていうところの大前提としては、私も同じ見解ではあるんですけど、
DevOpsってまず文化だよねって話をされてます。
ちょっと待ってくださいね、まず記事を全部は読んでないんでザーッと見ると、
まずこれ2021年8月の話ですよね。
そうなんですよ。ちょっと古いんですよ。
でもそのタイミングでもうプラットフォームエンジニアリングって言われてたんですね。
そうなんです。それがちょっと驚いたというか、国内でここ1年ぐらいない印象ですね、私は。
盛り上がってるのはそのぐらいの印象ですね。
この方が言うには、DevOpsって基本的に文化だから、
具体的なプラクティス動向をやってたらDevOpsって話じゃなくて、あくまで文化なんですって話をされてて、
そこに関して私も全面的に同意なんですけれども、
ちょっと面白かったのが、DevOpsとSREってでも結構違うよねっていうのがこの方の見解です。
なぜ面白いなって思ったのかっていうと、私の記憶違いじゃなければ、
SREのすごく分厚いドンキみたいなオラエリーの本。
SREと言えばまずあれですよね。
俗にSRE本と言われるやつだと思うんですけど、
確かの文章の中でもクラスSREインプリメントDevOpsみたいな表現があって、
DevOpsっていう概念とか文化があって、それを実装していくのがSREなんだみたいな表現があったんですよね。
その表現から察するに、DevOpsとSREって厳密にめちゃめちゃ違うものかっていうとそんなことないかなってずっと思ってた矢先に、
この方のこの表現、DevOpsとSREってちょっと違うよねって表現してるのが面白いなって思いました。
ちょっと細かいことはこの方のブログの記事に書いてるんで、
ポッドキャスト出すときにまたブログのURLとかは載せるんで、興味ある方読んでいただければってところなんですけれども、
一部極端なSREとDevOpsのカテゴライズを抜粋すると、
この方曰くSREっていうのは基本的に本番環境の信頼性にフォーカスする人たちなんだ。
それはそうですね。
DevOpsっていうのは主にCICDであったりとか、
ディベロッパーがどうやればより生産性高く、あと開発速度速くなって、
デリバリーできるのかっていうところに重点を置くものなんだっていう表現をされてて。
なんかちょっと面白いじゃないですか。
そうですね。
本番環境か開発環境かっていうところで分けてるんですね。
開発環境ないしは本番環境に届くまでで分けてるかなって印象です。
だいぶ極端な、特にDevOpsの方が極端な切り方をしているなという気がして、
そのまま名前からするとDevOpsのOpsが入ってるので運用が入ってるはずな。
そうそう。
ですけど、だいぶあれですね。
本当に主眼にしているところだけを切ったらという感じですかね。
私もそう思ってます。
この表現だけだとOpsどこ行ったみたいな感じにはなってしまうんで。
どっちかというとこの表現でいくとちょっとXPっぽいなとも思ったんですよね。
確かにそうですね。
過去に自分が読んだ本とかも少し振り返って考えてみたんですけど、
ちょっとフォーカスしたのがDevOpsって言われると、
昨今だとリーンとDevOpsの科学っていう本とかがフォーカスされるんですけど、
確かそれよりももうちょっと前にDevOpsハンドブックっていうのが発売されていて、
私最初DevOpsの色々読んだのってそっちなんですよね。
私これ読んだことないですね。
そうなんですよ。
今となっては多分リーンとDevOpsの科学の方が色々分かりやすい気もしなくもないんですけども。
この表紙見覚えあるな。
そうですか。黄色い。
これ三長さんから勧められたから覚えがあるだけかもしれない。
一周回って自分に帰ってきた感じですかね。
そうかもしれない。
そこに立ち戻って目次見て省打てとかを見てたんですけど、
確かにリスク低くリリースするアーキテクチャーとかの話までをすごく細かくしてるんですよね。
意外とその先のインフラ環境をどう監視するかとかって話ってほとんど書かれてなくて、
そういうところから見ても最初の方ってこの方の簡潔に述べた場合で言うと
CICDとかの速度に重点を置いたっていうのは間違ってもいなそうだなっていう印象を受けました。
なるほど。
とはいえOpsの部分どこいったよって話を考えると、
そもそもDevOpsってデベロッパーっていうのっていう捉え方をすると、
なるべく自分たちが作ったプロダクトをいち早く市場に届けたい人たちじゃないですか。
なのでさっさと出しちゃいたい人たちに対して、
Opsやってる人たちはどちらかというとなるべく本番環境に対してリスクになりそうな行動を取ってほしくないであったりとか、
そもそも取らないでほしいみたいな。
両者のモチベーションというか大事にしてるとか全然違うから、
もちろん対立構造できちゃうねっていうのはわかるんですよ。
なんとなく本番環境にリスクになるような変更っていうのが、
今までだと私の過去の経験だと基本CICDとかがなかったので、
手作業でデリバリーすると。
もちろん人間なので間違えることはあり得ると。
その時点でどんなに手順が正しかろうが危ないですよねって思われてたのかなって思うんですよ。
今言ってるのはリリースのタイミングの話ですね。
そうですね。
そこに対してじゃあ人の手を返さずに、この場で言うとCDか、
CDを使ってオートメーションするんで、
本番に対するリスクも減るよね。
だから安心じゃない。
だからDevTops仲良くできるんじゃないみたいな感じが、
最初の頃のDevOpsの始まりなのかなって勝手に今、
この方の記事も読んで思ったんですけど、
博崎さんそのあたりどう思われます?
そうですね。
自分がDevTopsの対立があるっていうのはもちろん、
そこを今三沢さんがおっしゃったような話だというのは認識してるんですけど、
DevOpsだと、
自分がその対立構造の解決をやる文脈として、
強く思ってるのはSREの方かなと思ってて、
エラープジェットがあるじゃないですか。
ありますね。
あれは今言ったような対立構造、
変化を起こす人と防ぎたい人の調整をするためのツールというか、
ものだと思ってますね。
確かに確かに。
DevOpsはどちらかというとそういうモチベーションの違いというよりも、
組織的に分離されているところをフォーカスした話だったと記憶はしていましたね。
なるほどなるほど。
これ見てDevOpsの時代からそんなこと言われてたんだって思いました。
なるほどね。
自分が最初にDevOpsという話を知った時は、
大企業とかでDevの部署とOpsの部署が違っているから、
速度のある動き方ができなくてみたいな話が出てきたもんだと思っていたので、
こういうモチベーションの違いも既にあったんだなというのは、
今初めて認識した気がします。
なるほど。
DevとOpsの対立の部分を緩和させるというか解決するのがSREの文脈というのがすごく、
今の博多家さんの表現、私もしっくりきたんですけど、
その時点でやっぱりあれですよね、
DevOpsと変な話、SREってやっぱりくっきり分けられないじゃないですか。
そうですね、かなりかぶっているところはありますよね。
ただ、この方も述べている単純な2つのカテゴライズって、
やっぱりとはいえSREがより重点を置いているのは、
本番環境に対する信頼性で、みたいな温度感なんですかね。
そうですかね。
DevOpsとSREの関係
きっとSREだって別にCICDやらないわけじゃないし、みたいな。
でもそれ以外にもやることは、重点を置く場所がいっぱいあるから、
この頃からのDevOpsとSREって実は結構交わってるんだけど、
交わってなさそうなとこもあるよっていう感じなんですかね。
あんまりあれですもんね、この人が言っているかわからないですけど、
SREが開発生産性を気にしているっていうのはあんまりイメージないですもんね。
Cって言えば、提供しているプラットフォームが原因で何か低下してたら気にはするぐらいですよね。
そうですね。SRE広いからそこまで考えるかもしれないけど、
開発生産性のほうまであんまりそんなに気にしてない感じはするな。
確かにそう言われてみるとってとこですね。
DevOpsはその辺が結構主観ですもんね。
LeanとDevOpsの科学とかでも出てくるように、4keysとかも指標として提示されてますしね。
ですね。
っていう、わりとDevOpsとSREに対してアグレッシブな分け方をされてる方だなっていうのが、
まず最初の面白かったところです。
そういう文化があって、SREとDevOpsをこうやって分けてますっていうところの次の項目として、
じゃあSREって結局どういうことやってんねんっていうところもすごく面白かったんですけど、
このブログの内容だと基本的に本番環境にフォーカスするんですっていう話ではあるものの、
とはいえその本番環境にフォーカスするって何すんのじゃないですか。
確かに確かに。
その中で紹介されてたのが、ロードっていう指標。
ロード。
はい、私初めて見たんですけど、レスポンスオブザーバビリティです。
オブザーバビリティ、アベイラビリティ、デリバリーの頭文字を取って、
私が勝手にロードって読んでるだけかもしれないんですけども、ロードっていう指標を提案してると。
R-O-A-Dですね。
この指標を見た時に、確かに自分たち、私が今所得している組織ってSREチームがいるんですけれども、
自分たちの組織がやってきたSRE業って、その当時は別にロードっていう指標を全く意識してたわけじゃないんですけど、
こういうことやってきたなって振り返ってて思って。
例えばそのロードのDのデリバリーですよね。
デリバリーの部分で言えば最初の頃って、もちろんそういう自動的なデリバリーの仕組みなんて全くなかったので、
まずCICD入れたりとか、あとは自分たちのインフラ環境に再現性を持たせるためにIAC入れたりとかっていうので、
確かにデリバリーやったなと。
それが育ってくると、自分たちが本番環境にデリバリーした後、どうやって信頼性を担保しようかっていうと、
やっぱりアベラビリティを測れないといけないから、SLOとかSLI始めましょうであったり。
それを始めましょうになると、今度オブザバビリティがある程度ないとどうしようもないので、
データドックとかニューレリック系のオブザバビリティツール入れたりとか。
最後にレスポンスっていうところで言うと、何か障害が起こったときになるべくスピードに対応する仕組みを作ったりっていうのをやってきたので、
その順番が必ずしも最適解ではないと思うんですけど、
なんか近しいことは確かにやってきたなって思ったんですよ。
素晴らしい。
ロード指標の紹介
ね。
確かにそうですね。
てかさっきスッと流しちゃったけど、Rはリライアビリティじゃなくてレスポンスなんですね。
そうですそうです。
なるほどなるほど。
レスポンス、何か障害が何か問題が起こったときの対応の速さみたいなところですかね。
確かにな。
最近よくインシデントレスポンスなんたらっていうのは見る気がするな。
確かに。
確かに言われてみるとそうですよね。
で、なんかこの辺別にSREだからってあんま関係ないかなとも思うんですけど、
なんか博多家さんこれまでいろんな現場経験されてきたと思うんですけど、
こういうの確かにやったなみたいな事例というかエピソードとかってあります?
本当に何もないところにいれた経験は1回か2回ぐらいしかないですけど、
やっぱり最初はデリバリーから入りますよね。
やっぱそうですよね。
その次はここで言うとオブザーバビリティに入ることが多いかもしれないですね。
障害が起きたことがそもそも検知できないことが多いというか。
はいはいはい。
なのでそこと、でも自分はSLOを策定したことはないので。
なるほどなるほど。
アビリラビリティ&リライアビリティのところはやったことがないかもしれない。
あとレスポンスもインシデントレスポンスに型を形を作ってこれで運用しましょうみたいな声かけをしたこともないですね。
インシデントが起きたらまずコマンダーがとかってやり方あるじゃないですか。
ありますねありますね。
ああいうのをみんなでやりましょうみたいな感じにしたことはないですね。
なるほど。
このロードで言うとRとAは既に運用されているものを改善していったことはありますけど導入はないかな。
今話を聞いてて思ったんですけど、特にAのところ、アビリラビリティのSLOとかSLIのところですけど、
これSREの文脈じゃないとなかなか出てこなそうなキーワードじゃないですか。
SLOはそうですね。
というかですねSLOの前にやることがめちゃめちゃあるんですよね。
確かに。
なんかいろいろできてないとSLOをそもそも運用できない問題があって。
そこにたどり着くまでが長いですよねきっとね。
長いですね。
ただなかなか1個流しに着実に近づいていくかっていうと割と並行しながら進めないと結局たどり着かないなって感じしません。
しますします。
デリバリーとかは独立してできそうだなっていう感じもするんですけど、
アビリラビリティとかって正直オブザバビリティないとそもそもどうしようもなくねとかって思ったりもするんですよね。
依存関係というかそれぞれの中でこっちがちょっとはできてないとこっちもできないし、
こっちがちょっとでき始めたらまたさらにもっと高度なこっちが必要だしとかっていう順番というかそういうのありそうですよね。
なんでどこかが異常に低いと結局面として成り立たないからある程度均等に伸ばしていかないと機能しない感じがしますよね。
プラットフォームエンジニアリングとSRE
しますね。
ロードっていう指標が面白かったのでちょっとここで紹介したかったんですけど、
もしかするとねどっかの本に実はもう載ってて読み落としてんだよとかなると後で恥ずかしいやつですけど。
指標ってことは何らか成熟度モデルみたいなのがあったりするんですかね。
私が読んだ限りだと見つけられなかったかな。
なんかそういうのがあったら嬉しいですけどね。
このぐらいできてたらレベル1でみたいなとかね。
なんかそういうのどっかで見たことある気もしますね。
そしたらね追っていきますよねやっていくときにね。
追っていきますね。
確か私そういうの見たことあるのは大体何かのオフィシャル、可観測性ツールとかが公式が提供してる成熟度みたいなのがありますね。
あるかも。
成熟度が5段階ぐらいあって4に行くにはこういうものが必要で、弊社のこれ入れるとここら辺がカバーできるぜみたいなパターンの紹介。
そういう面があるから成熟度モデルっていうのはそういうベンダーのホームページとかでよく見るやつなのかな。
な気がしますよねなんとなく。
SREの定義でロードって書いてるからSRE版に書いてたのかな。
ちょっと読み直してみようかな。
えーあったかな。前すぎて。
もう思い出せない。
そうですね。
どっちかというとあれですよ。
ロードのレスポンスとか大枠の名前よりMTTRとかそういう用語の方がすごい頭に残っちゃってるんで。
数値にしやすいやつですよね。
そうですそうです。
ちょっとこの辺は見直してみよう。
っていうのがあって何でしょうね結構いろんな組織のその状態によって入れる順番というか育てていく順番は変わりそうだなと思いつつ
一定レベルになってくるときっともうカオスな感じでちょっとずつお互いがレベルアップしていくみたいな伸ばし方なんだろうなと思いますよね。
このブログだとあとプラットフォームエンジニアリングも書いてあるんですかね。
そうですねプラットフォームエンジニアリング割と最近国内だと最近ホットな気がするんで私たちもそんななんかこうだっていう表現はできないんですけどこの記事だとそれを踏まえてプラットフォームエンジニアリングってデブとオプスとSREの観点から全ての観点から効率的に使える
プラットフォーム作ろうねってことにフォーカスしてますと。
まああれですよねSREだけがすごく使いやすいで他の人たち全然使えないとかデブだけがすごく使いやすくて他の人たちが全然使えないみたいなことじゃなくてある程度全ての立場というか職能から効率化できるエコシステム提供しようねそれがプラットフォームエンジニアリングだよって
すごく雑に要約すると書いてるように捉えました。
ただとはいえ思ったのはでもこのプラットフォームエンジニアリングやる実践するのってなんだかんだでもSREなんじゃないかなと思うんですよね。
なんかそれそうですね他にそこをやれるロールがないからなんですかね。
インフラとかをいじったりとかつまりプラットフォームを作る時に動ける人がSREくらいしか今ないからとか。
それもあるでしょうし確かもともとSREって2種類分けられるみたいな話が書かれてたと思ってて本だったかなんだったか忘れちゃったんですけど
SREとプラットフォームエンジニアリング
なんだっけチームに入り込んでエンベッドするスタイルのSREとプラットフォームを突き詰めていくSREみたいな。
なのでそれで言うとあれなんですかねそのプラットフォームエンジニアリングするのって割とプラットフォームを突き詰める側の人がやるのかなって。
確かにエンベッドのSREってあれですもんねSREのプラクティスをそのなんかデブのチームとかデブオフスチームかもしれないですけどそっちに普及させるのが目的とかでしたもんね確か。
そうですね。
それで言うとデブオフスチームも一応プラットフォームを作ってもいいんだけどまあでもそうかやるのはプラットフォームの方のSRE今の話で言うと。
なのでなんかこうSREプラットフォームとかが出てくる前のそのSREの労働が成熟してくるともしかするとそのSREチームの中からさらにこうプラットフォームエンジニアリングチームみたいなものが生まれてきてその人たちが専門性を持ってそこにフォーカスして取り組んでいくのかなって感じもします。
どんどん細分化していきますね。
今日のそのねポッドキャストのこれ何て言うんですかねこれ原稿ではないですね私たちが普段使っているこのネタ帳みたいなやつネタ帳にも書いてるんですけどなんか詰まるところ専門性が全部高くなってきてかつ領域広すぎるからちょっと分けてみんなで手分けして頑張ろうってことなんだろうなと思いますよね。
そうですね何でもそうですね職業新しく生まれたやつって最初はこう割といろんな広いところをやらなきゃいけなくてその中の仕事が高度になっていけば専門性高くなっていって片手間では全部はできなくなって分けられていくんですよね。
そうなんですよね特にね私たちの業界だとそんな歴史が長いわけでもないのでこれからまだまだ細分化をされかついろいろできる人も生まれって感じになりそうですよね。
そうですね。
なんかこうなってくると昔って言うとあれ変な話ですけどフルスタックエンジニアって表現あるじゃないですか。
ありましたね。
あれがもしあの言葉がずっと残るなら何者になるんだろうって感じしません。
フルスタックな。
自分の覚えているフルスタックエンジニアのって要するにあれでしたよねバックエンドとフロントエンドとインフラのエンジニアを全部足したものみたいな認識だったはずなんですよね。
そうですよねそうですよね。
でもなんか昔とか言っちゃうけどその概念でのバックエンドエンジニアフロントエンドエンジニアインフラエンジニアはどれも今ここで言うとこのSREとかの領域をやってなかった気もするんですよね。
確かにそれはありそうですね。
この辺はオブザバビリティとかっていうのはちょっと昔のインフラエンジニアとかがやってたよりも高度な多分可観測性についてやってるでしょうから。
デリバリーのためデリバリーを主に仕事としているエンジニアも多分いなかったはずですし。
確かに。
フルスタックよりさらに広いいろんなことが今あるはずなんですよね。
そうですよね。
例えばフロントエンドだけ取っても専門性高い人ってめちゃめちゃ高いじゃないですか。
その人を前に例えばちょっと書くぐらいならできますよって自分がもしなったとしてもフルスタックとは言えないなって。
そうですね。
均等にできる人がフルスタックでって名乗るんでしょうね。
確かにバランスがいいというかデネラリストみたいな感じですかね。
そうですね。
大抵の人ってグラデーションがもう三浦さんも書いてますけど、
グラデーションがあってフロントエンドしか完全にできない人多分あんまりいなくて。
そうですね。
バックエンドもちょこっとは書けるよとかっていう人がほとんどじゃないですか。
バックエンドの人もバックエンドしか完全にできないはなくて、
JavaScriptもちょっとなら書けるよっていう人が多分ほとんどですし。
だからフルスタックな完全に死後ですね。
なんかそんな感じしてきますよね。
ベンズの各エンジニア領域のベンズを書いて重なるところって絶対あるじゃないですか。
その重なっているところ全部できますよみたいな人がフルスタックなんですかね。
そういうことか。
なんとなく。
でも使われなくなりそうな気はしますよね。
そうですね。
そのもともと指している意味でのフルスタックは無理そうな気もしますしね。
全部に対して、その例えばフロントエンドのリードクラスの人がいるとして、
その人とバックエンドのリードとインフラのリードと同等のスキルレベルを持っている人、
多分存在し得ない気がするんだよな。
時間が足りない感じになりますよね。少なくとも。
ほんと。一部のスーパーマンしかそんなことは。
今日2人で話していて、フルスタックってまだ使えるのかなっていうのは考えた方がいいかもしれないですね。
使わないでいきましょう。
自分たちは使わないでいきましょう。
フルスタックね。
決してフルスタックをディスってるとかではなく、
ディスってませんよ。
ディスってるんじゃなくて、専門性高くなってきたから、
フルスタックっていうよりはもしかするとどっかの専門性が強くて、
他のもちょっとできるぐらいの表現の方がいいんじゃないかなっていう2人の話でした。
すごい上手い言い方だった。
そうですかね。
はい、というとこで一旦オチもついたので、
今回のユルテックはですね、紹介した記事のタイトルとも同じなんですけれども、
DevOpsとSREプラットフォームエンジニアリングについてお話をしました。
今回感想等あれば、ハッシュタグユルテックをつけてポストお願いします。
Googleフォームからも感想コメント等をくれますのでよろしくお願いします。
今日はありがとうございました。
ありがとうございました。
