待望のゲストとの再会
Yosuke Asai
London Tech Talkのリスナーの皆様、こんにちは。Kazです。
ken
Kenさん、今日もよろしくお願いします。 はい、よろしくお願いします。
今日はですね、リスナーの皆さん、待望のゲストですよね。 待望ですね。僕もめっちゃ待望。
Kazunari Okuda
はい、私ももう待ちわびてました。 本日のゲストはですね、Asaiさんです。Asaiさん、よろしくお願いします。
Yosuke Asai
よろしくお願いします。 待望って言われるとちょっと緊張するんですけど、はい、すごい僕も楽しみにしてました。
Kazunari Okuda
ずっと話したかった。 そうですね、Asaiさんはちょっと経緯を話すと、もともとホストをやっていただいていたんですけど、
卒業ということでホストを辞めて、もうしばらくゲストと、それからゲストとしても出演はされてなかったので、そういう意味でいろいろなお話が聞けるという意味で、待望のゲストということですね。
ken
いや、久しぶりに出ると嬉しいです。ありがとうございます。 いや、積もる話がたくさんありすぎてない。
Kazunari Okuda
そうですね。
Yosuke Asai
まずは、ちょっといつものパターンなんですけど、天気どうですか? 天気は、
はい、スイスの天気は。 最近午前中が雨で、午後がちょっと晴れるみたいな感じの天気になってきて、
まあなんかヨーロッパの冬っていう感じなんですかね。 パッとしない天気ですね。
Kazunari Okuda
そちらは同じですか? いや、ベルニンはめっちゃ晴れてますよ。
これは普通じゃないっていうぐらい、もうずーっと先週からずっと晴れてるんですよね。 えー、いいな。
で、暖かかったんです。今日はちょっと、 ちょっと気温は下がったんですけど、それでも晴れてるんですよね。
気温何度くらいですか、今。 今が、
暖かくて13度とかで、
最低気温が7度ぐらいだったんです。 昨日が、最低が12度で最高が16度とか言って、結構暖かくて。
Yosuke Asai
いいですね。 でもじゃあ気温も同じくらいかもしれないですね、もしかしたら。
天気、はい。 ベルニンと。
ken
夏がやっぱ恋しくなります。夏は毎日晴れてたんで。 そうですよね。
ロンドンはどうですか? ロンドン、多分中間ぐらい。
そんなに晴れてるわけじゃないけど、そんなに寒いわけでもない。 っていう。
Yosuke Asai
まあよくあるヨーロッパのね、感じで。
ken
いやなんかこう、天気の話面白いなと思った。 結構いろんな国とかいろんな都市から参加してくれる人が多いから、
なんか意外と。そうそう、広がる。 広がるね。
Yosuke Asai
朝めちゃくちゃ、今一番暗いですよね。だからそれが辛いですね。朝7時に起きてもまだ真っ暗みたいな。
わかる。 テリアイズセービングやってるから。
来週から変わるんですよね。 あ、そうですね。1時間遅くなるかな。
ken
まあそれでちょっと明るくなるんですけど。 確かに確かに。7時半ぐらいだと。
Kazunari Okuda
私も6時に起きるんですけども、 これまだ夜なんじゃないかって思うぐらい真っ暗ですよね。
ken
ヨーロッパあるある。
ビタミンDとか取ったりします?2人とも。 サプリでってこと?
Kazunari Okuda
はい、サプリメントで。 なるほど。
Yosuke Asai
妻が撮ってる時もあるし、僕も落ち込んだギター取る時もあるし、
あとなんかビタミンDを取るためにそのライトを買って照射させるみたいなやつを一応持ってますね。
Kazunari Okuda
持ってますか、そういうの。 ありますあります。持ってます。
Yosuke Asai
効果あれあるんですかね。ちょっとわかんないですけど、一応あると思って使ってるんですけど。
なんかドイツだと保険で降りるんですよ。 一応効果がパブリックのヘルスインシュランスでサポートされるっていうことは多分効果あるんだろうなと思ってます。
ken
何が降りる?サプリが降りるの?それともライトが降りるの?
ライトが降ります。
Kazunari Okuda
マジか。すごいな。
ビタミンDはよく言われるんですよ。
Yosuke Asai
ロンドンはわかんないんですけど、やっぱり冬の間とかめっちゃ暗くて日照時間が短いから、日を浴びて人はビタミンDを生成して、なんて言うんでしょう。
Kazunari Okuda
落ち込まないようになるんですけど、その日照時間が短いからビタミンDを自ら摂取するっていうことを。
ドイツでは推奨されてますね、冬は特に。
ken
なんか似たような話だと、オランダに住んでいる同僚が医師の処方箋が出て、地中海の方に旅行に行きなさいって言われたみたいな。
どこまで本当にどこまで上だかわかんないんだけど、でも日照時間を伸ばして太陽を浴びなさいみたいなことを医師の処方箋出されたって言ってました。
Yosuke Asai
旅行に行けって言われるんですか。
ken
審議のことはわからないですけど。
Kazunari Okuda
それ会社に提出したら休みとかもらえたりするのかな。
ken
いや医者が旅行しろって言ってるんで、僕はイタリアに行かなきゃいけませんって言って。
Yosuke Asai
いいですね。
ken
まあでも効果があるというかね。
うん。
あるんでしょうね、きっとね。
Kazunari Okuda
そうですね。
SREの役割と経験
Kazunari Okuda
ってな感じでちょっと本編に行きましょうか。
今回本編は浅井さんの働いている会社とそこでのSREを経験してきて、改めてSRE、浅井さんが今働いている現職でどういうことをやっているのかっていうことをお話ししていただける感じですよね。
Yosuke Asai
はい。なんかきっかけとしては確か、和さんと篠さんが話しているときにSREってなんだっけみたいになったっていう話を聞いたと思うんですけど、
はい。
Kazunari Okuda
Discordで。
Yosuke Asai
はい。
それで僕も一応SREの収録を昔していて、けんさんと一緒に。
そのときにやっていた僕のSREは全然今やっているのと全然違うので、改めてもう一回喋りたいなっていうふうに思ったという感じですかね。
今自分がやっていることとか。
ken
そうですね。興味ある、すごい聞きたい。
はい。
Yosuke Asai
よかったです。ということで、じゃあまず自分の仕事から何か説明すればいいですかね。
Kazunari Okuda
そうですね。
はい。
Yosuke Asai
自分は今スイスでSonaっていう会社で働いていて、SonaCubeっていうのが多分一番有名なんですけど、SonaCubeっていうコードの解析ツールを作っている会社にいます。
SREとしては何をするかっていうと、Observabilityっていう、何だろう、過観測性でしたっけ日本語で。
過観測。何だっけ。いいですね。
観測するシステムを観測することができるようにするための取り組みをしていて、
そのために何をするかっていうと、例えばサービスのメトリクスをもとにダッシュボードを作ったり、アラームを設置して何か問題が起きたら対応できるようにしたり、
あとはSLIとかSLOっていうサービスレベルオブジェクティブとかインディケーターっていうのがあって、
そういうオブジェクティブを作って、オブジェクティブ目的、目標に達成しているかみたいな、
サービスのスピードとかエラー率とかそういうのが目標通りに達成しているかみたいなことを監視するような仕事を主にしていて、
それを日々改善していくっていうのが主な仕事になります。
で、僕の会社では主にAWSを使っているんで、そのAWSのCDKっていうのをPythonで書いてアラームとか全部管理するような、
ISC的なことをして管理してますね。
ken
クラウドデベロップメントキットみたいな、
そうですね、クラウドデベロップメントキット。
テラフォーム的なやつですよね。
はい、まさにそれです。
コードでインフラを表現するみたいなやつですよね。
だからGitHubとかGitとかで差分を出してプルリクでインフラの差分を見てマージしたらデプロイされるみたいな。
Yosuke Asai
まさにそれですね。
一応この書き方でいうと、AWSのクラウドフォーメーションっていうのがあって、
それがテラフォーム的なAWSのツールなんですけど、
それのラッパーみたいな感じでコードで書けるっていうのがCDKですね。
Kazunari Okuda
これってこのCDKって最近テラフォームあれじゃないですか、
ライセンス変えてオープントーフっていうのにオープンソースで出たじゃないですか、
それを元にされて作ってるんですか、CDKって。
ちょっと興味があるんですか。
Yosuke Asai
テラフォームとCDKは全く依存してなくて、
CDKっていうのはAWSのクラウドフォーメーションが別にあって、
それを使って構築していくもので全く別のものになります。
CDKのいいところを挙げるとすれば、やっぱりPythonみたいなプログラミング言語は、
AWSおよびインフラ管理
Yosuke Asai
元はJSとか使ってるんですけど、JSとかPythonとか何でもプログラミング言語で書けるんで、
Kazunari Okuda
エンジニアフレンドリーな感じがテラフォームよりあるかなっていうところがありますね。
Yosuke Asai
難しいところを言うと、クラウドフォーメーションに依存してるんで、
クラウドフォーメーション周りで問題が起きるとちょっと厄介みたいなのもありますね。
Kazunari Okuda
最近私もこんな感じのことやってるんで。
SREじゃないんですけど、SL5とかアラームの設定でアラームをこう、
アラームって一回設置したらそれで終わりじゃないじゃないですか。
そのアラームが本当に正しいかどうかっていうのまで、
ちゃんと見直してあげないといけないんですよね。
ダッシュボードも作成、それで各チームごとに作成したりとか、
あとテラフォームとか触ってて、
SREじゃないんですけどSREみたいなことしてますね。
Yosuke Asai
SREじゃないけどしてるんですね。
開発者としてやってると。
Kazunari Okuda
そうですね。
そういうチームにプラットフォームチームっていうのにいて、
私が専業でやってるわけじゃないんですけど、
時々そういうタスクをやってたりしてますね。
面白い。
ken
聞いてみたいのが、
アサイさんがオブザーバビリティのことをメインでやってるのか、
アサイさんの所属チームとしてオブザーバビリティをメインでやってるんですか。
例えばSREって結構チームとか会社によってやってること全然違っていて、
大きい会社だとオブザーバビリティ専門のチームがSREと別にいて、
オブザーバビリティプラットフォームとかがそういうのやってたりするんですよね。
アサイさんのSREというチームの中の位置作業としてオブザーバビリティがあって、
それをアサイさんがやってるのか、
アサイさんの所属しているSREチームのメインの仕事がオブザーバビリティなのかというと、
どっちですか。
Yosuke Asai
いい質問ですね。
これは回答がちょっと難しいんですけど、
組織改変があって、その話も後でしようと思ったんですけど、
組織改変をする前、僕が入ったタイミングだとSREチームっていうのがあって、
主にこのオブザーバビリティの対応をするチームがありました。
そのチームのメンバー、チームがありつつも他に開発のチームがあるんで、
そこにそれぞれ縦軸、横軸みたいな感じで、
そこにも入っていってオブザーバビリティやるみたいなそんな感じでやってましたね。
ken
なるほど、分かりました雰囲気。
組織改変があったので、じゃあちょっとね、後で聞けるということで。
Yosuke Asai
はい、またちょっと話しますね。
もう一個の仕事がオンコールですね。
これはけんさんとかもかなりやられていると思うんですけど、
僕、これはまたちょっと最近変わったんですけど、
インシデント対応のオンコールをするっていうのが平日の日中のみ。
だから自分が働く9時から4時の間だけオンコール対応して、
SREの進化
Yosuke Asai
4時以降はアメリカに引き継いでみたいなことをしていました。
で、さっきカズさんがおっしゃったようなアラームが起きたら、
それを見て対応するっていうのをやってますと。
で、それが最近ちょっと変わって、
SREだけじゃなくて全エンジニアでそれを見ようみたいな話になって、
しかもそれを24時間、7日間247でやろうってなったので、
だいぶそれが今変わっているっていう感じですね。
Kazunari Okuda
大きな変化ですね。
全エンジニアっていうのはSREじゃなくても?
Yosuke Asai
そうですね。
クラウドサービスに関わっている全エンジニアがSREじゃなくてもやるっていう。
フロントエンド、バックエンド問わずみんなやるみたいな。
Kazunari Okuda
それは私の会社と同じですね。
本当ですか?
Yosuke Asai
はい。
これは色々賛否両論ありそうですけど、
とりあえず今はこの方法で、本当に10月から始まりましたね。
だからSREの仕事としてのオンコールっていうのはなくなりました、最近。
Kazunari Okuda
なるほど。
ken
だからこのオンコールに1メンバーとして入ってるみたいな感じですか?
Yosuke Asai
まさにそうですね。
結局でもまだやっぱりみんなオンコールとかやったことないんで、
まだ僕がこれ始まってから大きなやつ起きてないですけど、
起きたら多分SREもどこかに必要になる気がするんで、
結局今のところはそんなに大きく変わんないというか、
まだみんな準備できてないっていうところはありそうですね。
なるほど。
Kazunari Okuda
っていうことはアサイさん的には特にオンコールに入る頻度は減ったけど、
Yosuke Asai
特にあまり変化はないっていう感じですか?
心構え的には似たような感じですかね。
Kazunari Okuda
オンコールに入る頻度確かに減ったんでありがたいんですけど。
なるほど。
オンコールどうですか?お2人に聞いてみたいんですけど、
私はオンコールあんまり好きじゃないんですよね。
それはSREになりたくない1つの理由はオンコールをやりたくないからなんですよ。
例えば週末とかですね、先のプランが決まっちゃうというか、
仮に週末にやらないといけないとしたらですね。
お2人はSREとして仕事の一部としてやってると思うんですけど、
Yosuke Asai
オンコールどうですか?
僕はない方がありがたいですね。
やっぱり週末とかの予定がブロックされるので、
それに見合った収入というか手当とかあればいいんですけど、
それによってそれ次第なところもありますかね。
けんさんはどうですか?
ken
僕はオンコール嫌いです。
僕がSREをやってる理由は、
オンコールではなくスケーラビリティとかパフォーマンスエンジニアリングとか
アーキテクチャ全体に関わられるっていうアップサイドが
オンコールに入るダウンサイドより大きいと思ってるからなので、
オンコールは嫌です。
Kazunari Okuda
なんで嫌なんですか?
ken
あさひさん先どうぞ。
Yosuke Asai
僕はそうですね。
本当に僕はインシデント対応自体は嫌いじゃないですけど、
嫌いじゃないですが、
オンコールとして週末とか夜とか緊張して寝なきゃいけないし、
あんまり予定立てられないしみたいなところがあるのはやっぱり嫌ですね。
ken
同じですね。
僕は平日日中のオンコールは全くいいんですけど、
週末ですね基本的には。
週末がなかったら多分最高なんですけど、
やっぱり今フェーズ的にも家族というか子供といる時間を増やしたい時期なので、
2ヶ月に1,2回とはいえ週末丸24時間っていうのがちょっと合わないかな。
平日やる分には全く問題ないです。
Kazunari Okuda
わかります。そうですね。週末ですよね。私も同じ感じですね。
平日やる分には全然いいんですけど。
ken
代わりに休み取れるんですけどね。
日曜日オンコールだったら次の月曜日休みいいですよってなるんだけど、
Yosuke Asai
月曜日休んでも子供いないし。
そうですよね。
Yosuke Asai
めっちゃわかります。
だからあんまりオンコールは評判良くないですね。
それは僕の会社でも。
Yosuke Asai
そうですね。
オンコールでインシデントマネージャーがいるんですか?
そうですね。別にインシデントマネージャーというのがいて、
オンコールの詳しい話をすると、
インシデントマネージャーというインシデントのインシデント解決する調査とか以外の
いろいろポストモーティングしたりとか、
インシデントのチャンネルを作ったりとかそういうのを全部管理してくれる人がいて、
そういうのはすごいありがたいなと思いますね。
周りのことを全部やってくれるんで。
ken
その人はどうやって決まるんですか?
そこにSREの誰かからラウンドロビンで入る?
Yosuke Asai
それはもうインシデントマネージャーという役職があって、
その人がいますね。
ken
珍しい。
Yosuke Asai
確かに珍しいかもしれないですね。
それはめちゃくちゃありがたいです。
集中できるというか、オンコールにインシデントに。
Kazunari Okuda
なるほどですね。
私の会社ではオンコールの人がインシデントマネージャーと同じことをやるというか、
新しくチャットを作って、
ポストモーターもフォローアップとかもオンコールの人がやるみたいな感じなので、
なるほどインシデントマネージャーというのは新しいですね。
インシデントマネージャーの役割
Yosuke Asai
全然関係ない話をするんですけど、
この前インシデントがあって、
マーケティング関連の人がたまたま入ったんですね。
その人はイギリス人で、
ポストモーティングやるぞってなったんですけど、
ポストモーティングという言葉を聞いてすごいびっくりしたらしくて、
もともとその意味が死体を切り刻むみたいな意味らしくて、
それを奥さんに話したら奥さんもすごいびっくりしたみたいなことを聞いて、
ポストモーティングって普通に言ってるけど、
ネイティブの人からしたら結構、
ぎょっとする言葉なんだなっていうのを改めて思い知りました。
Kazunari Okuda
そうですね。
そういう業界用語みたいなのが結構ITというかソフトウェアエンジニアリング業界に入ってきますよね。
あれって誰が導入するんでしょうね。
で、どうやって広がっていくのか確かに結構興味あるな。
ken
なんか検視作業みたいな意味でしょうね。
Yosuke Asai
そうかもしれないですね。
ken
なんかその、よく話題にというかジョークになりますね。
エンジニア用語はなんかこう、バイオレントな言葉が多い。
例えばプロセスをキルするとかね。
確かに。
ちょっとドキドキ冗談になったりしますけど。
Kazunari Okuda
そう、なんか子プロセスっていうか、
チャイルドをキルするとかなんかそのチャットだけを見ると、
こいつら何言ってんだみたいな。
ken
子供をね、子プロセスを殺せみたいな。
いやいや怖いでしょみたいな。
Kazunari Okuda
ありますよね。
話を戻るんですけど、
インシデントマネージャーがいると
オンコールを全エンジニアに導入するのはやりやすいかもしれないですね。
ちょっと思ったのは。
Yosuke Asai
そうですね、確かに。
それはそうですね。間違いないです。
Kazunari Okuda
プレッシャーがないというか、
ポストモーターもやらないといけない。
あとはインシデントハンドリングの方に
フォーカスできるっていうのが。
Yosuke Asai
それは間違いないですね。
それはすごい良いですね。
Kazunari Okuda
はい。
逆にインシデントがなくなれば
インシデントマネージャーはいらなくなる。
なくなるってことはないんですけど。
Yosuke Asai
そうですね。
それが理想の世界ですね。
Kazunari Okuda
彼らが忙しくないというのが。
Yosuke Asai
そうですね。
あとは仕様設計とか、
新しい仕様を作るときに参加したりするときもあるんですけども、
特に多分レイテンシーとかベラビリティが
大丈夫かみたいな観点で。
この辺はまだ僕はあんまり自信がないところですね。
こういうのってケンさんもやってるんですかね。
新しいサービス作るときに
実際に仕様設計参加するとか。
ken
入るときありますね。
呼ばれるときもあるし、
自分たちから事前に
察していくときもありますね。
クラウドプラットフォームとの関係
ken
はいはい。
Yosuke Asai
必要だなって。
ken
個人的にはこれ結構好きですね。
こういう設計に関われて、
ここでパフォーマンスエンジニアリングの観点とかで
いろいろ口出したりできる、
考えることができるのは面白いかなと思いますね。
Yosuke Asai
ですよね。
この辺は話の元でもさせてください。
ぜひぜひ。
あとで出そうと思って。
あとはクラウドプラットフォームの構築があって、
これは別のクラウドプラットフォームエンジニアっていうのがいるんで、
たまにSREとは別れてるんですけど、
その人が忙しいときに手伝ったりみたいな感じですかね。
SREはオブザバビリティに集中するけど、
たまにそういうクラウドプラットフォーム関連、
あとはCICDとかそういうとこもちょっとやりますって感じですかね。
Kazunari Okuda
ということはこのクラウドプラットフォーム、
例えばアラームがきました、
例えばサービスがデグレードしてます。
そのときに例えばスケールアップとか、
そういう判断はSREがやるんですか。
それともこのクラウドプラットフォームの方がやるんですか。
Yosuke Asai
そうです。インシデントのときはSREが主にやりますね。
インシデントのコールとか電話があって、
その中にクラウドプラットフォームとか呼ばれたりして、
そこで一緒に決断してSREが対応するって感じになります。
Kazunari Okuda
じゃあ例えばインシデントじゃないアラームが来た場合はどうなるんですか。
例えばインシデントになりそうじゃないけど、
前の段階のアラームとかもオブザビリティとかで
我々は管理すると思うんですよね。
ここまで来たらちょっと、
もちろんオートメディティってしてるかもしれないんですけど、
そこの判断とか、
インフラをスケールさせようみたいなっていうのはSREじゃなくて、
多分クラウドプラットフォームの方々がやる。
Yosuke Asai
そうですね、まさにそうだと思います。
その辺を議論しながらクラウドプラットフォームの人が
Kazunari Okuda
主導権を握ってやっていく感じになります。
やってることはこんな感じですかね。
これって昔お話ししたSREとの大きな違いってあります?
Yosuke Asai
これはそうですね、ぶっちゃけて言うと、
僕が昔やってた、喋った時にやった仕事はSREではなかったっていうことになるんですけど、
オブザビリティとかちょっとアラーム作ってるくらいやってましたけど、
全然やってなくて、
その時はどっちかというと僕はクラウドプラットフォームエンジニア的な
働きをしてたのかなって思いますね。
もっとクラウドプラットフォームの構築であるとかしてたんで、
定義した仕方次第ですけど、今やってるものとは全く違いますね。
SREの役割
Yosuke Asai
もう少し会社も小さかったんで、
クラウドIWS全体的に見るみたいなことをしてたと思うんですけど、
今はもっと特化してるような感じだと思います。
Kazunari Okuda
そんな印象がありますよね。
会社の大きさによってインフラというか、
インフラ関係を全てオブザビリティもやったり、
クラウドプラットフォームみたいなこともやったりっていうのが一つのSREという名前で、
小さい会社とかにはそういう役職があって、
でももっと大きくなると大きくなるほど、
Yosuke Asai
やること、ロールが再分化されていくみたいな感じの印象がありますよね。
ken
確かに。
聞いてみていいですか。2つ経験されたじゃないですか。
Yosuke Asai
最初はぶっちゃけどっち好きですか。
どっちのやり方ですか。
ken
クラウドプラットフォームエンジニアリング的な仕事か、
今やっているよりレジリエンシー、リライブリティエンジニアリング的な仕事。
Yosuke Asai
僕は今の仕事結構好きですね。
両方好きですけど、
あんまりクラウド知識をクラウド依存させたくないみたいなところもあって、
今の仕事もクラウド依存ではあるんですけど、
クラウド構築とかになると完全にクラウド依存じゃないですか。
でもレイテンシーとかそういうアベラビリティとかだったら、
もう少し全般的な知識でできるみたいなのもあって、
そういう方が今後も役に立つといいなっていうのもありますね。
ken
なるほど。キャリアの汎用性というか、
そうですね。
メタ的なスキルが求められるからっていうことですね。
Yosuke Asai
そうですね。
ケンさんはどうですか、ちなみに。
ken
僕も一緒ですね。
ガリガリプラットフォームエンジニアリングをコード変えて作るよりは、
もうちょっとメタ的な観点でシステムに切り込んでいくっていう方が好きです。
Kazunari Okuda
うん。
Yosuke Asai
と思ってます。
Kazunari Okuda
分かります。
ken
いいですね、いろんなSREとは言っても本当に会社によっては違うので、
実体DevOpsとか実体プラットフォームエンジニアリングなんてよくあるので、
Yosuke Asai
そうですよね。
ちょっとそういう話もしたいんですけど、
さっき言った組織改編があって、
気になる。
組織改編前はさっき言ったようにSREチームっていうのがあったけど、
今はなくなって、完全に僕はビリングチームっていう決済関連、
サブスクリプションとかのサービスを作っているチームの専属のSREになったみたいな。
完全にチームにアサインされたんですけど、
その後のときにチームへの貢献の仕方が結構分からなくなって、
っていうのもさっき言ったような仕様設計とかに参加するっていうのは
僕はやったことはなくて、
あんまりバックエンドの人とどこで何が問題が起きるかみたいな、
全然会社のそもそもクラウドの仕組みもそんなに分かってなかったし、
みたいなのもあって、難しいなって思って、
あまり議論に参加できないというか、いう状態になったりとか、
あと他にチームにSREがいないんで、どうやってやっていくのかみたいな、
ロールモデルがいなくて、
全然他のチームの人を見ると全然違うことをしてるなみたいなのがあって、
結構迷ってたんですよね。
かつ、その疎外感というか、バックエンドとかフロントエンドとか、
めちゃくちゃ議論してるじゃないですか、
仕様どうするみたいな。
でもSREってプロダクションに出るまではあんまりやることないって正直なくて、
あるっちゃあるんですけどあんまりなくて、
だからその辺がすごい悩みみたいな感じであったんですけど、
そういう悩みをけんさんとか、
もしかしてかずさんも持たれたりしたことはありますかっていうのを聞いてみたい話でしたね。
Kazunari Okuda
SREって何なんだろうみたいなことを思ったんですけど。
けんさん。
ken
いいの、僕最初で。
まずそのビリングチームの専属プロダクトSREになった時に、
自分の希望はあったんですか。
全然ないです。
Yosuke Asai
もう完全に適当に配属された。
適当っていうかあれですけども、配属は上書きみたいな感じで。
なるほどね。
ken
で、その専属プロダクトSREになってから、
他の元々の同僚とかと定期的にワンオンワンとかコーヒーチャットとかはできてるんですか。
そうですね、できてます。
そこでお互いの各プロダクトチームのやってるSREの取り組みというのは、
意識的に取るようにしている。
Yosuke Asai
そうですね、その辺はコミュニケーションは取ってますね。
難しいなと思ったのが、
例えば評価的な話になると、チームごとの評価になるじゃないですか。
で、ビリングチームのマネージャーがいて、その人とかが主に評価する。
僕がもうちょっとプラットフォームSRE的な仕事をしようとなった時に、
その価値をあんまり分かってないとは言えないけど、
自分のチームと関係ないことだから、ちょっと違うじゃないですか。
だからそういう評価的な意味でも、
ちょっと評価されてない感があったんで、
それはマネージャーに一回言ったんですよね。
なんか全然疎外感を感じますみたいな。
ちょっと評価されてない感があるよみたいな話をしたら、
それは分かってくれた感じがあって。
だから一応専属SREだけど、他にもやることがあるんで、
その辺を分かってもらえる努力は自分でしてみたつもりではあります。
ken
多分プロダクトSREってめちゃくちゃ高度だと思います。
かなりすごい気持ちが分かるというか、
まずビリングチーム、ビリングじゃなくても何でもいいんですけど、
プロダクトのゴールってあると思うんですよね。
ビリングだったらなるべく早く確実に決済をするなのか、
新しいビリングのペイメントを導入するのか、
いろいろあると思うんですけど、
そこにレジリエンシーのゴールを一緒に合わせて組み込んでいかなきゃいけないんですよ。
ゴール設計のタイミングから。
しかもそれを自分のマネージャーに分からせなきゃいけないのでかなり難しいし、
基本その障害が発生しなくて難報なので、
低量化するのが時として難しいというか、
うまくやってるほど低量化するのが難しいんですよ。
だって障害はゼロだからみたいな。
でも実は裏でいろいろなプレベンティブなアプローチをしていて、
例えば設計の早いタイミングでアサヒさんがめちゃくちゃくし出すことによって、
本来障害になる予定であった、
例えばデータ量が増加するに従って発生する予定であったアウトブメモリーとか、
データストレージのサチュレーションみたいなのを消すことができましたって証明できないじゃないですか、基本的には。
なのでかなり難易度の高いことを求められてるっていうのは本当にその通りだと思います。
Yosuke Asai
確かに。
本当にかなり先を見ないといけないというか、
実際に開発してテストしてリリースしてみたいな、
チームの課題
Yosuke Asai
その期間が長ければ長いほど先を見なきゃいけないんで、
リリースされるタイミングを見てCOとかレジリエンシーとか考えなきゃいけないんで、
それがすごい難しい。
どのエンジニアも一緒かもしれないですけど。
ken
難しいと思いますよ。
この話も自分の仕事をマネージャーにちゃんと評価してもらえるようにっていう路線でもなんだろう、
一晩はかせるし、
あとはそのレジリエンシーという観点をプロダクトチームにどう持ち込んでいくか、
例えばその仕様設計に参加する以外にどんなことができるかっていう話でも多分すごい広がっていく話なので、
すごい面白いところにいるなと僕は思ってます。
Yosuke Asai
そうですね、仕事自体は面白くなってきたというか、いい感じはありますね。
ken
ちなみにそのビリングのシステムは自分の中でドメインとしてはキャッチアップしてる最中ですよね、多分ね。
プロダクトの重要性
Yosuke Asai
そうですかね。
そんなにめちゃくちゃ詳しく把握してるわけじゃないんですけど、
逆にそんなくらいでいいのかなって今は思ってるんですけど、
その詳しく仕様を把握しすぎる必要がないというか、
しすぎても他のことにできなくなっちゃうんで、
ほどほどの理解で今やってるんですけど、
分かった方がいいのは間違いないんで、
何とも言えないですよね。
ken
けんさんはどうですか、何かそういうの。
Yosuke Asai
今ちなみにけんさんはどういう感じですか、プロダクトSREとかプラットフォーム。
ken
プロダクトSREではなくプラットフォームSREです僕は。
なので僕のチームの他に、
例えばチェックアウトのチームとかペイメントのチームがあり、
それぞれのプロダクト、SREはいないんですけど、
そのプロダクトチームが独自のオンコールを持っていて、
Yosuke Asai
プラットフォームレベルの話になったら僕らにやってくるみたいな感じですね。
ken
ただ僕のチームでよく話してるのは、
必要な時にはディープダイブしていくっていうのは一つあって、
例えばそのペイメントで障害が起こるとしますと、
なのでプラットフォームSREなんでペイメントの詳細知らなくていいですっていう風に、
バウンダリーを作ることはできるんですけど、
例えばすごいインパクトが大きいものだったら、
短期的にガーッと入り込んでいって、
いわゆるレジリエンシーテクニックっていろいろあると思うんですね。
例えばバックエンド側依存している外部サービスが動かなくなった時に、
フェイルオープンな仕組みを作る方法とか、
サーキットブレーキングどうするとか、タイムアウトどうするとか、
そもそもインシデントが起こった時のインシデントハンドリングのコミュニケーションが
ちゃんとトレーニングできてないように、
多分いろんなメタ的な観点があって、
それをチームに一つ一つ装着していくみたいなのを、
そのチームの状況を理解して、
かつドメインモデルも理解してってやらなきゃいけないんで、
結構、短期的にメスを入れていく感じですよね。
理想的なチームを作ろうとすると、
レジリエンシーを担保するというか、
障害を可能な限り少なく、
でもアジャイルに機能開発していく完璧なチーム像からブレイクダウンして、
そこを目指そうとすると多分やることいっぱい出てきちゃうんで、
多分今の現状のビリングチームの一番のレジリエンシーのボトルネックがどこか、
みたいなのを一個一個潰していく。
それを評価のタイミングではちゃんと見える化するっていう方が、
やりやすいんじゃないかなと聞いて思いましたけど。
Yosuke Asai
そうですね。
今あるところ見えやすいところからやっていってっていうところですね。
ken
例えば今アサイをビリングチームからなくしたら何が困るのかみたいな。
プロダクトSREをビリングチームからなくしたら何が困りますかみたいな。
Yosuke Asai
はいはい。
そうですね。めちゃくちゃ困ると思いますよとか言って。
ken
日本語いいじゃないですか。
Yosuke Asai
そうそうそう。
SREの基礎とチャレンジ
ken
で、それはなぜかっていうのを深掘って言語化して、
他の人もできるようなトランスファラブルな、
他の人に転換できるような知識とか、
システムのオートメーションとか、
ドキュメントにしていくみたいな感じですかね。
ありがとうございます。
でも難しいと思います。
これの過程はまた定期的に聞いてみたいですね。
1年後とか半年後。
Yosuke Asai
ぜひぜひ。
なんかそうですね。
今サービスを開発して、
新しいサービスにリプレイしようとしてるんで、
それを出すぞっていう段階になってきて、
すごいテンパってる状態というか、
なかなか改善点があっても、
見つかっても直す余裕がないみたいな状況にはあるんで、
またそのケンさんの言ったような話をちょっと落ち着いてきたら、
もっとやっていきたいなというふうには思いました。
ken
たぶんチームのミッションとかありますよね。
マネージャーが作ってる。
ありますか?
Yosuke Asai
ゴールというか、
ken
新しいビリングプラットフォームを作ってるんだったら、
ビリングプラットフォームはどういう形であるべきだみたいな。
Yosuke Asai
そういうのでもあんまないかも。
考えたら。
ken
それを作ってるフェーズなのかな。
Yosuke Asai
そういうミッションみたいのはあんまり持ってないですね。
チームとしては。
クォーターごとのやるべきことみたいのはあるんですけど、
こういう形で理想像みたいのはどうなんだろう。
ken
アライメントとれてる感じはしますか?
チームメンバーの中で何を作ってるかみたいな。
Yosuke Asai
作ってるものに対してはできてるんですけど、
やっぱりすごい他のチームとコミュニケーションが必要だったり、
あとは何だろうな。
実際にロールアウトするって意外と難しいなって思って。
特に新しいサービスでリプレッシュとかしようとすると、
デプロイがかなり複雑になったりするんですけど、
それに対して特に何だろうな。
十分に結果が練れてなくて、
もしかしたらこれは自分の責任かもしれないですけど、
みたいなことがあって、
それを最近僕がやったんですけど、
だからそういう穴みたいのがいくつかあったり、
漏れてたりとか、
他のチームに対してコミュニケーションが取れてなかったり、
結構あるんで、
そういうのもSREの仕事からちょっと分からないですけど、
もっとうまくできたらいいなと。
そういう視野を広く持たないと、
どこかで失敗したり落ちたりする原因になるんで、
そういう社会性的なところがすごい大事だなと最近思います。
すごい分かりますよ。
ken
ビリングプラットフォームが依存してる依存サービスとか
洗い出せてたりするんですか?
Yosuke Asai
ビリングに対して依存してるのが結構あるんで、
その辺は洗い出してますね、一応。
ken
なるほど。
じゃあビリングチームが、
ビリングプラットフォームが落ちたらどれくらいクリティカルかっていうのは
ある程度みんなアライメントが取れるという状況だと。
Yosuke Asai
そうですね。
そうですね。
ken
なんかそのフェーラーパターンみたいなのも洗い出せてますか?
例えばここがここ落ちたらビリングプラットフォームがこう落ちるよねみたいな。
Yosuke Asai
そうですね。
そこはあまりできてないかもしれないですね、もしかしたら。
ken
で、そのフェーラーパターンの中でどれが一番起こりやすくて
どれが一番クリティカルかみたいなのをやって、
例えばじゃあここのデータベースが
シングルポイントフェーラーになってるから、
ここはじゃあ自動でフェールオーバーする仕組みを作ろうかって提案してみたりとか、
あとはなんかすごいドキュメンテーション作って、
あとはフェールオーバーできる練習をチームでしようかみたいな。
いいですね。
あるといいかもしれないですね。
Yosuke Asai
確かに。
そういうパターンみたいなのは作れてなかったんで、
ぜひ取り入れてみます。
ちょっと全然時間がないんですけど今。
できたらやりたいですね。
ken
システムはどうしたら壊れうるかみたいな。
How could this have been brokenみたいな。
Yosuke Asai
確かに。
それを考えようと思うとやっぱりもっと詳細を理解しないとなっていうのはありますね。
そこに帰ってくることもあるのか。
ken
まあそのプロダクトの人たちに考えさせてもいいと思いますよ、そのフロントエンジニアに。
ここの領域はじゃあちょっといくつか5個ぐらい出してみてみたいな。
Yosuke Asai
はいはい。
どうしたら落ちるかってことですか。
そうそうそうそう。
フェールアップパターン、確かに。
ken
そうすると自分が全てキャッチアップするまで何もアウトプット出ないくなっちゃうので。
はい。
Yosuke Asai
いいですね。ありがとうございます。
ken
あとロールモデルの不在とかも結構気になるけど。
Yosuke Asai
なんか単純にそうですね、やっぱり何を調べるか分かんなくなったっていう感じですかね。
それこそシステムを半年後に出すぞっていう、ロールアウト半年後にするぞっていう段階で、
今僕は何すればいいんだっけみたいな。
プロダクションにもまだ出るのもすぐじゃないから、
アラームとかもまだ作るには早いしみたいな。
っていう時があったっていう感じですかね。
今はなんとなく分かってきた感じはあるんですけど、やるべきことが。
ken
いやー頑張ってますね。
Yosuke Asai
おかげさまで。
ken
スイスで頑張ってますねアサヒさん。
そうですね。
いい話だ。
Kazunari Okuda
なんか私から言えることというか、結構もうケンさんがある程度SREとしてどうしたらいいのかっていうみたいなのがカバーされたと思うんですけど。
私からだと、やっぱりケンさんがおっしゃったように難しいなと思いました。
もちろんドメインの知識は必要な時にキャッチアップすればいいんですけど、
アプリケーションの特性みたいなのがどうしても出てくるんじゃないかなと個人的には思ってて、
ビリングだったらビリングとか、例えば広告だったら広告みたいなそういうところ。
でここは抑えとかないといけないよなみたいなところはもしかしたらあるのかもしれないけど、
でもそれってもしかしたらそのビリングのドメインの経験がなかったらキャッチアップできないじゃないですか。
今全然ないところからまたキャッチアップしていかないといけないし、
しかもこれはもうケンさんが何度もおっしゃってるんですけど、
SREって限定方式というか壊さないことが前提で、壊すとそれから限定されるみたいな、
円の下の力持ちであんまり評価されづらいポジションだと私も思うんですよね。
だからあんまりSREになりたくないっていうのがあるんですけど、
でもその新しいドメインでやっぱり知識が一からビルドアップしていかないといけない状況から、
かつ壊さないような状況とかそういうオブザビリティを設定していくって、
なかなかハードル高いからすごいチャレンジングな触手だなと私は思いましたね。
コミュニケーションと依存関係
Kazunari Okuda
はい。
Yosuke Asai
ありがとうございます。
確かにそうですね、限定方式的なところはあるかもしれないですね。
でも逆にSREやってるとインシデント対応いっぱいするんで、
例えばエラーがアラームが出たら調査したじゃないですか、
バグとかも見つかって、バグがあった場合は大体バックエンドとかの人のバグになるんですよね。
で、なんかそういうのをさっと見つけると結構意外と評価されたりというか、
喜んで、喜ばれるじゃないですけど、すぐにインシデントの解決ができるんで、
ある種ヒーロー的なところもある気がするんですよね、なんかそういうのができると。
だから悪いとこばっかりじゃないなっていうのは思いますね、そのインシデント対応とかも。
Kazunari Okuda
わかります。ヒーローですよね。
はい。
解決できたりとかすごい大きなインシデントを解決したりとかそういう時って、
はい、なりますよね。
Yosuke Asai
やっぱ負荷とかで問題を受けると、そうですね、ちょっとSREに責任があるところになると思うんで、
そういうのが辛いですね。
Kazunari Okuda
だからあえて誰にも見つからないようなバグか障害みたいなのを作って、
後で自分のオンコールの時にあえて見つけるとか言っているような冗談なんですけど、
なんかそうするとヒーローになれますよとか言って。
Yosuke Asai
なんかそんな話が炎上させて。
Kazunari Okuda
時々ジョークで上がりますね。
Yosuke Asai
ありますね。
ken
ただね、それ多分長続きしないですよね、そのキャリアの積み方。
普通に他の人を助けてあげた方が、その人に対してもね、なんかこうありがとうって言ってくれるし、
自分のスキルも上がるし。
だって自分が出したバグなんて解決策わかってるんで、解けて当然でしょみたいな。
Yosuke Asai
そうですね、確かに。
ken
ショートタームのソリューションです。
やってる人はいないと信じたいけど。
Yosuke Asai
そうですね。
でもやっぱり何て言うか、インシデントやるとすごい視野が広がりますよね。
なんか全然自分が知らないところに飛び込めたりするんで、
けんさんも前言ってましたよ、インシデントイズキャンディーみたいなことが書いてあるって言ってましたけど、
本当にいろんな学びがあって、それはそれで面白いですね。
このシステムはこう動いてるんだとか。
Kazunari Okuda
私も今どっちかというとプラットフォームチームにいて、やっぱりプロダクト開発からプラットフォームに来て、
いろいろ感じることはあるんですよね。
先ほど浅井さんがおっしゃったように、
プロダクトワークって結構、
ショートタームというか結構どんどん新しい機能を作って、
どんどんリリースしていくっていうのが多いんですよね。
でもこのプラットフォームチームに来ると、
どっちかというと結構ロングタームで、
どんどんレンガを積んでいって、その結果、結果が見えるみたいな。
しかもその結果って、何て言うんでしょう。
新しい新機能を作りました、バーンみたいな感じは全然じゃないんですよ。
だから例えばその前者的に、こういうの新機能を作りましたのほうが全然見栄えはいいんですよね。
でもこのプラットフォームチームエンジニアとして、
データベースマイグレーションしましたとか、
まずデータベースなんぞやみたいな、
インターナルにこういう改善しましたって言っても、
あんまり評価はされづらいところだなと思ってるんですよね。
だから結構そこでのマインドセットの違いっていうのはかなりあるなと私も思ってて、
プラットフォームで何か、
プラットフォームチームで働くことっていうのはロングタームで、
必ずしも結果がすぐ見えるようなものじゃないものを作っていくっていうのがあって、
かつアサリさんもおっしゃったように、
マネージャーがそれを理解してくれてるかどうかっていうのも結構難しいところで、
SREの概念とその多様性
Kazunari Okuda
私のマネージャーはもともとプロダクトチームにいて、
プロダクトチームで働いてるマネージャーだったんですけど、
私がプラットフォームに移動して、
やっぱりそこのギャップがどうしてもあるんですよね。
このタスクにどうしても時間、
プラットフォームでのタスクって結構時間がかかるもんなんで、
それのギャップ、マネージャーの理解、
なんでそれに時間がかかるのか、どういう価値があるのかっていうのはやっぱり見えづらいんですよね、
どうしてもプロダクトのことしかやってなかったら。
だからそれをどんどん自分からこういうものがあるんですよっていうのをちゃんと見せていかないと、
どうしてもそのギャップを埋めていって、
マネージャーに分かってもらわないと評価されずないなっていうのは私も常々思ってますね。
Yosuke Asai
そうですね、やっぱりそうやって説明していくのってすごい大事だなって僕も思うようになって、
やっぱりみんながみんな自分が大事だと思うこと分かってないみたいなのを最近すごい痛感したんで、
その辺のテクニックとかも今度は聞きたいですね、和田さんに。
Kazunari Okuda
あとは何かカバーしたいことはありますか、浅井さん。
Yosuke Asai
そうですね、ちょっとSREとは的な話の流れで僕も記事をいくつか読んで、
やっぱりまずSREとはみたいなので、SREやCoreっていうのはないっていうのは多分もうあれだと思うんですけど、
ある記事ではEUはNot Googleっていう記事があって、
この人GoogleにいてSRE18年間くらいやった人が書いた記事なんですけど、
Googleじゃないから別にSREっていうのはGoogleが作ったものだけど、
その後はGoogleじゃないからGoogleのSREがやってたことはやる必要はないとみたいな話があって、
GoogleのSRE本もあるけどあれは教科書じゃなくてただの歴史書だみたいなことが書いてあったりして、
だから別に他の会社がやってるSRE像に固執する必要はないみたいなのはちょっと思った。
システムの真の原因を探る
Yosuke Asai
けんさんこの辺気になることありますか。
ken
めっちゃありますね。
なんかそのバッファーの話もあったんですけど、
SREをバッファーとして使うのはアンチパターンっていうのはもう本当にその通りなんですよね。
システムが障害が起こりました、とりあえずSREに一時対応も貸して実感稼いで、
その後障害対応というかルートコースアナリシスとかコントリビューティングファクターを洗い出していくみたいなことは、
アサリさんはそのバッファ的な存在であれば障害感を感じるのは宿命みたいなのが入ってますけど、
まずバッファ的な存在としてSREを置いちゃってる時点でシステムの失敗だと僕は思ってます。
この話はちょっと長くなっちゃうので。
Yosuke Asai
僕もそんな気がしました。
ken
今日はじゃあ一旦僕が別で別の収録かブログか書いてそれを読んでフィードバックもらった上でまた話しましょう。
ちょうど今読んでる本にも出てきた話でシステムティンキングの話で、
バッファとしての対してそのシステムの本当の原因に対して機能しないという話なんだけど、別でしますけど、
基本的にはアサリさんが感じているのと同じような問題意識を抱えています。
Yosuke Asai
めっちゃ気になる。
ありがとうございます。
今日は十分しゃべらせていただきましたので。
Kazunari Okuda
何か宣伝したいこととかあります?
Yosuke Asai
宣伝したい。
一応僕の会社でSREを募集してたはずなんで、もし興味があればリファイルしますので教えてください。
日本とかにいる方でもリロケーションできるんじゃないかなと思ってチャレンジしたい方がもしいれば是非よろしくお願いします。
ken
それは熱いですね。
Kazunari Okuda
スイスにですか?
Yosuke Asai
スイスに、結構募集が多いのはドイツのボホムっていうところなんですけど、
スイスもあって、あと日本でもソリューションエンジニアとか募集してて、
多分英語必須だと思うんですけど、そういうロールが日本でもいくつか開き始めてるんで、もし興味があれば僕に言っていただければと思います。
Kazunari Okuda
熱いですね。
Yosuke Asai
分かりました。
ken
ぜひアサイさんと働いてみたい方は連絡してみてください。
Yosuke Asai
という感じで本日はアサイさんありがとうございました。めっちゃ楽しかったですね。
めっちゃ楽しかったです。久しぶりに話してよかったです。
また話したいことも増えてましたね。
増えましたね。
ken
仕事の話しかしてないよ。
Kazunari Okuda
確かに。
Yosuke Asai
本当は他の話もしたいんですけどね。
ken
改まった話しかしないからね。
Yosuke Asai
またやりましょう。ぜひよろしくお願いします。
Kazunari Okuda
はい。
じゃあまたありがとうございました。本日はケンさんアサイさん。
ken
ありがとうございました。
ありがとうございます。
