Ep.66 ℤ𝕆𝔼𝟛𝟘𝟚( @for__3 )さん、そーだい@初代ALF( @soudai1025 )さん、yuuki takezawa@ytake( @ex_takezawa )さんと雑談 #ツナギメエフエム

・今回のゲスト

　・ℤ𝕆𝔼𝟛𝟘𝟚 ( @for__3 )さん

　・そーだい@初代ALF ( @soudai1025 )さん

　・yuuki takezawa@ytake ( @ex_takezawa )さん

・インフラ・SRE回

・SREチームを新設した話

　・「ただ答えを教えるだけでは育たない」SREチームリーダーが語るメンバーと組織課題への向き合い方

・SLO、SLI、SLA

・The Art of SLOs

・SREはロールじゃなくて哲学

・SRE本

　・SRE サイトリライアビリティエンジニアリング

　・サイトリライアビリティワークブック

　・SREの探求

・SREはインフラエンジニアだけでなく、みんなの活動

・若手がインフラを触る機会

・オブザーバビリティ

・ISUCON

　・ISUCONの良いところはWebを支える技術をひととおり学べること 「システムがマジで壊れる」からこそ、業務に活かせる

　・時間制限がある中で「できる」と決断を下すには自信が必要 そのためにISUCON出場者が毎月実践している“素振り”

・PHPカンファレンス◯◯◯2024

　・https://twitter.com/ex_takezawa/status/1727518356037890293

・CloudNative Days Tokyo 2023

　・DRE/SREのプラクティス融合によるクラウドネイティブなデータ基盤作り

サマリー

「ツナギメエフエム」の第66回は、IT勉強会コミュニティ繋がりの方々をゲストにお迎えしています。今回は、ぞえいさん、そーだいさん、たけざわさんの3名をお迎えし、SRE（Site Reliability Engineering）についての話題で盛り上がっています。SRE（サイトリライアビリティエンジニアリング）の活動や考え方についても話し合われています。SREはソフトウェアエンジニアとしてサービスに貢献する哲学であり、他のロールでも同様の考え方があることを理解しています。また、専門性に関する雑談を行っています。専門性のサイロ化が組織の分断を生み、トラブルシューティングの困難さにつながることについて言及しています。SREチームが開発チームに活動を浸透させる苦労やチームの構成についても話されています。さらに、インフラエンジニアの情報交換やイベントの増加、オブザーバービリティの悩み、DNSサーバーに関する開発大会のエピソードについても話し合っています。また、2022年のPHPカンファレンスの話題や、若手エンジニアが地方のカンファレンスに登壇する意義についても話されています。さらに、竹澤さんが「クラウドネイティブレイズ東京2023」で「SRE」と「DRE」についての話をすることが紹介されています。

SREチームの新設

はい、始まりました。 ツナギメエフエムの第66回です。

ツナギメエフエムは、IT勉強会 コミュニティ繋がりの方々を

ゲストに迎えて雑談するポッドキャストです。

まずは、XQ Twitterの ハッシュタグについてお知らせです。

ハッシュタグはカタカナで ツナギメエフエムです。

投稿待ちしています。

今回で第66回目です。

今日のゲストは、ぞえいさん、そーだいさん、 たけざわさんの3名です。

それでは順番に自己紹介をお願いします。

まずはぞえいさんからお願いします。

はい、ぞえいです。

MillgateでEMをやっています。 よろしくお願いします。

はい、よろしくお願いします。

続いて、そーだいさん、お願いします。

はい、今は株式会社リンケージ っていう会社のCEOと

自分の会社のHubFanticっていう会社で

一人で自宅開発とか技術コモとかを やっています。

そーだいです。よろしくお願いします。

はい、よろしくお願いします。

最後はたけざわさん、お願いします。

はい、日和スターフェスティバル 株式会社というところで

何でも屋をやっています。

あとはいろんな会社で同じく 技術コモとかさせていただいています。

たけざわです。よろしくお願いします。

はい、よろしくお願いします。

はい、じゃあ今日はこんなお三方をお迎えして

なんかちょっと僕がインフラっぽい話を 3人に聞きたいなと思ったんで

ちょうどいいなと思って お呼びさせてもらった感じです。

ということでですね、最近似たようなSREの話題を ツイートしてたりとか

登壇の場があったりとか、そういうブログ記事を 書いてたりしたのをちょっと目にしてたんで

そういった話を聞きたいなと思ってます。

で、最初どの話からいきましょうかね。

うーん、ぞえさんから聞こうかな。

はい。

2021年にSREチームを新設したというところの話を ちょっとお伺いしたいんですけど

これどういった会社の話ですよね、これね。

そうですね、Urigateの話ですね。

前まではインフラチームと開発チームっていうのは

完全にチームとして分離していて

各開発チームっていうのはプロダクトの開発を担当していて

インフラチームはプロダクト横断して 星とかをやるチームだったんですけど

やっぱりそれだけだと信頼性の向上というか、 みたいなのができないっていうのと

あとやっぱり開発とインフラの境目に落ちたような カスクみたいなのがどうしても改善してるのは難しいみたいな

ところが課題感にあったので、それを改善するのに SREチームを新設しようという流れで

2021年に新設したという話ですね。

なるほど。明確にインフラチームではなく SREチームという名を与えたわけじゃないですか。

SREチームのスキルセットとメンバー選び

特にここを変えたとかいうところって何かありますか?

そうですね。インフラとSREをうちは明確に分けているのが

SREってさっきも言ったインフラと開発の狭間に落ちた カスクみたいなのを、ちゃんと情報の都合というか

考えながら改善するみたいなのをミッションにしたかったので、 インフラだけ触るんじゃなくて情報やるっていう

明確な意思を持ってやってました。 両方のスキルセットというか、持っているような人だけを

最初はSREチームのメンバーとして入れて、 改善活動をやるミッションでやったり。

そうそう、まさにそこを聞きたかったんですけど、 スキルセットを持っている人って限られると思うんですよね。

アプリケーションのアプローチの考え方が分かっている インフラエンジニアじゃないと多分できないようなことってあると思うんですよ。

そういった時に、もともといたメンバーのインフラのチームからSREチームを専任したのか、

それともアプリケーション側の人を専任したのか、どっちなんですか?

そうですね、最初はアプリの人の中でインフラの方も ある程度理解がありそうな人を専任してしてあげるっていうのをやってました。

なるほど。

総代さんと竹澤さんに聞きたいんですけど、 そういう人選というか携わったことってあります?

そういったチームを作るみたいな。

僕はCTOやってるから、チーム作ったり役割作ったり考えたりするのは 割と普段からやってるって言うんですけど、

さっき土屋さんも言ってたけど、ボールの間を拾うって、 人間の気持ちというかやる気みたいなのに任せるってやっぱり継続しないんですよね。

だから、仕組み化で解決するっていうので、 チームを作るっていうのもすごい分かるし、

リッケージで言えば逆にエンジニアで言うとソフトウェア側、 バックエンドエンジニア側ができるだけバックエンドのタスクを拾うように、

逆にそっちの力学を強くするみたいなのもあって。

だからSREっていうチームを作るんじゃなくて、 君らはロールがSREじゃなくて、振る舞いとしてSREをやるんだよ。

SREするんだよっていう感じで、 必要なものは自分で用意しましょうっていう感じでリッケージをやったりとかするんで。

ここって答えがないからし、さっき赤瀬さん言った通り、 アプリケーションのことも分かってたりとか、ビジネスのことも分かってたりとか、

結局インフラとSREの間拾えないじゃんって話があったら、 誰でもできる話じゃないんで、

結局他の会社がこうやってるから、僕らも同じようにやれば うまくいくだけじゃないのがすげえ難しいとこだなと。

そうそうそう、まさにそうだと思ってて、 結局今総代さんも言ってたけど、

アプリケーションのことだけじゃなく、インフラのことだけじゃなく、 ドメイン知識もないといけないじゃないですか。

そこがなんか難しそうだなと思ってて、 だから他の会社のSREの方がやられてることが、

実写で実践してもマッチしないことなんて山のようにあって、

なのでSREと一言に言っても、それぞれの会社で 全然やってることは違うじゃないですか。

そこら辺がちょっと難しいよなと思って。

竹田さん、会社でSREのチームってあるんですか?

そうですね、あるところもあればないところとかも、 もちろんあるんですけど、いくつかの会社とか見てるんで、

あるところもあればないところもあるんですけど、 でも今、SREって、

自分のブログにも書いたりとか、よくお話もするんですけど、 いわゆるインフラって捉えるところと、

品質というか、物を良くするために何でもやるぞっていう、 その活動のことを指すのと全然捉え方が違うんですよね。

SREって。でも自分の場合はその後者の方もとにかく みんなでやるぞっていうのをやっていて、

そこと合致する、自分たちのプロダクトをもうちょっと ちゃんと見つめ直したいんだっていうところは、

そういうチームを作って一緒にやっていくっていうことを 今ずっとやってますね。

スキルセット的なところだと、そんなに高度なものは 要求していなくてやっぱり、

SLOとSLIについて

まあちょっと今いっぱい話すと話すことなくなっちゃうので、 あまり言わないですけど。

でもその自分たちのドメインを理解するのはもちろん、 それはもう理解してないと意味がないので、

あとは自分たちのシステムとか、利害関係者って どういうことを期待してて、どういうことをやると

失望しちゃうのか。 アート・オブ・SLOってワークショップあって、

そこにもあるんですけど、本にも書いてあると思うんですけど。 そこをきちんと見つけて、どういうふうにアプローチしていくかって、

自分たちで考えられる人たちを集めてやることが多いですね。 もしくはそこにちょっと知識とかパワーが足りないっていうところは、

そこを一緒に動かして、一緒に応援して組織を作っていく みたいなことを結構やってますね、今。

自分の会社で言うとSREっていないんですよ。 インフラエンジニアみたいな呼び名なんですけど、

SREっていうキーワードを聞いたときにセットで出てくる言葉が、 さっき竹澤さんもおっしゃいましたけど、SLOっていうキーワードがあるじゃないですか。

SLO、SLIですね。SLAもありますけど。 こやつらは何なんですか?

いい質問ですね。

ネットとかにいっぱいあると思うんですよ。SLO、SLIについて。 ニューレリックとかデータドックとかで計測できるよっていうのがあると思うんですけど、

あれはあくまで、HOWの話なんですよ。 曽大さんとかよく好きだと思いますけどね。

あれはHOWとかの話であって、なんであれをやるかっていうと、 自分たちのユーザーの目線に立ってみたときに、

どういうことが起きたら、何パーセント以上起きたら ユーザーやめちゃうよねっていうところまで落として、

それは可視化するとこの値だよねっていうところをやるんですよ。 あれはモニタリングをバンバンバンバンやって、

とりあえずリクエストレスポンス早いぜ、イエーイ、 みたいなことをやりたいんじゃなくて、

それが意味のあるところと意味のないところってあるんですよね、当然。 それはユーザー側、つまりインタラクションを理解してウェブサイトがどうなってる。

ウェブサイトだけの話じゃないですよ、SLO、SLIっていうのは。 なんですけど、利害関係者の人、使っている方たちがどこがヘイトに溜まるポイントなのか、

ワークショップで言うとアンハッピーなポイントがあるんですけど、 あれをうまく見つけて、そこに行かないようにそのSLIメニューっていうのがいくつかあって、

どういうところを我々は注力して計測するとか、どういう判断をする。 SLOはそのSLIを元にして、SLOはこれです。

これは我々は守らなければいけませんよっていうのを指標にして、 その指標を使って、ここからすごい大事なんですけど、その指標を使って、

その組織のあり方とか、ものづくりの仕方とかを変えていくっていうものなんですよね。 あのSLI、SLOっていうのはそういうのに使うものです。

エラーバジェットはもうちょっとそれがうまく回ってきたら、 どれだけ改善に当てるかっていうのをやればいいんですけど、

急にやりだすと多分あまりうまく進まないんで、みたいなやつですね。

キーワードに引っ張られて、本来やるべき活動じゃないところなんか頑張りそうで。

そうそうそう。だからよく話聞きに行くと、 エンジンXとかでログが取ってるんですよって。

なるほど。じゃあそのログは何を表してるログなのかって話を聞くと、 いやアプリケーションで取れるのはこれなんですよねみたいな話をよくされて、

いや、それをやりたいわけじゃないよね。

APIをいくら早く変えそうが、フロントエンドめちゃくちゃ遅かったら、 それユーザーやめますよね。

じゃあ計測するとこリクエストレスポンスじゃないじゃんみたいな話だった。

そんな感じでインタラクションを全部理解して、 自分たちのユーザーは、ユーザーって言ってもお金を払ってる人払ってない人を 区別も結構するんですけど。

それは事業のドメインによって違うんですけどね。 その人たちがハッピーになるところをどこなのか。

それをきちんと見つけましょうっていう感じ。 そのリクエストレスポンスがどこまで取ってるかバーってもらって、

これはユーザーがどういうところをするときのものに当たるのかみたいな話を結構して、 そこからも煮詰めていくっていうことをよくやってます。

それをひたすら頑張るっていうね。

さっきZoeさんもチームの立ち上げの時に、

SRの方の話をチロッとされたかもしれないですけど、 それは擦り合わせて決めるみたいなことをやったんですよね。

そうですね。相竹さんがおっしゃってるように僕も、 うちも結構複数のプロダクトを扱ってるんですけど、

プロダクトの性質によって重要なメトリクスというか、 そうじゃないメトリクスみたいなのとかが全然違かったりして、

B2Bっぽいやつだとやっぱ記事ページみたいなところの レスポンススピードとかが大事だし、

画像とか出てないとめっちゃ困るんですけど、 一方でB2Bみたいなサービスだと、

サービスのコアみたいなところがもうちょっと違う、 集計した数値とかの信頼性みたいなところが重要になってくるので、

SREの活動とは

集計するロジックの妥当性というかが大事だよねみたいなのを、 各プロダクトごとにちょっとずつ擦り合わせていくみたいなのをやってました。

SRE活動とはみたいなのが本当ふわふわしてて、 本とか記事とか本当たくさんあるけど、

結局会社ごとにやってることは全然違うので、 それによってSRE活動って全く違うじゃないですか。

実際みんなどんなことやってるんだろうなっていうのが気になってて。

相大さんのところにはSREっているんですか?

さっきも言ったけど、 SREっていうロールを置いてるっていうわけじゃないんですけど、

SREが他の会社さんでインフラ面倒みたいなのとか、 自分たちのサービスの信頼を上げる仕事をやっていかないといけないから、

明確にロールはあなたはSREで決めてるわけじゃないけど、 やってる仕事が多分SREって呼ばれるようになって、

仕事をする人とかタスクってのがあって、 興味的にも他の会社でSREやってる人が、

うちの会社に立ち上がってくれてるパターンもあるし、 うちのバックエンドエンジニアの人がそれをやってるパターンもあるけど、

さっきのSLOの話あったんですけど、 サービスを良くしていくっていうのは、

ユーザーが困らないために ここは絶対守りましょうし、

ユーザーさんが喜ぶために こうやっていきましょうと。

あとはプラットフォームエンジニアが、 僕らのこの前の65回でも話題になってて、

チームを良くしていくと最終的にサービスも良くなるし、 サービスを良くするためにここを良くしなきゃいけない。

僕らはSREの文脈として結構やってて、 一番分かりやすいのはデプロイ。

CICD良くしていくとか、テスト早くするとか、

あと、うちだとあるんだけど、 AWSのコストを毎日スラックに投稿して、

スコアが上がってる、下がってるとか、

思ってないところで値段が上がってるから、 これは使い方間違ってるみたいなことも見える化したりとか、

そういう風なところもSREの文脈として やってたりっていうのはありますね。

やっていいっすね。

単純にコストのやつ、良いな。 真似しようかな。

やってないよ。

コストやるな。

月1ぐらいでは見るんですけどね。

グラフにするとめちゃくちゃ良いです。 増えてる時点というかすぐ分かるから。

あとちょっとさっき竹澤さんが、 ちょこっとだけ話したけど、

アートウェアSLをワークショップって、 僕全然知らなかったんですよ。

こんなのあるんですね。

ありますあります。 これ絶対やったほうがいいですよ。

このワークショップやると、 SREって何かっていうのがすごいはっきり分かるんですよ。

これおすすめです。

グーグルのページにそういうスライドとか、 ワークショップの資料が上がってて。

ありますあります。

日本語訳も途中までされてると思うんですけどね。

スピーカーノートついてるんで、 誰でもやろうと思えばやれると思います。

そうなんですか。

自分はそれ結構何回もやってるんで、

よくファシリテーターとして呼ばれてやるんですけど。

なんかテキストみたいなのに沿ってやる感じなんですかね、 この提供されている。

そうですね。

スライドはストーリーというか、 SREって何っていうところから、

SLO SLIとかESLIって何みたいなところを やって掘っていくんですけど。

一通りやった後に実際にゲームの課金ですね。

アプリのゲームの課金の題材を使って、

急にESLIをみんなで選びましょうってやるんですよ。

チームに分かれてインタラクションどうなんだっけとか。

初めて見るやつ。

初めて見る前に一応ハンドブックがあるので、

それを事前に渡して中身を読んでもらったり。

読んでない人向けにも事前に説明するんですけど。

どういうSLIが考えられるかやってもらう感じですね。

それ終わったら答え合わせとかは別にしなくて、

一番大事なのはどこがどういう風になって何が大事なのかって、

チームでディスカッションしてもらって、

それをアウトプットしてもらうことが一番大事なので。

合ってる合ってないは別にあんまどうでもいい。

どうでもよくないですけどね。

真面目にやってるところはちゃんとやりますけど。

そこは重視ではなくて、

どういうコミュニケーションをしてどういうことを考えてたか

っていうのがやっぱりすごい大事にしてる。

SREの哲学

それが終わったら回答例がですね。

SLIが4個ぐらいかな。

作れるんですけど。

頑張れば4、5個ぐらいいけるのかな。

5個ぐらい多分いけると思いますけど。

4つぐらい回答例があって、

それをザーッと説明して。

で、体験してもらうって感じですね。

そこから先は、

うちでもぜひやりたいって言われたら、

本社のサービスのどういうとこからやるか、

まずもドメイン全部教えてくれ。

そこから大事なとこから、

ここやりましょうとバーッと入ってくるんですけど。

それでやるとみんな結構わかって、

ついてくるって感じですね。

いきなりやっぱりメトリクスだみたいなことを

やってるところはうまくいかないので、

そうじゃなくてまずこっちやろう。

それを経験してもらうとみんな、

全然違ったんですねって。

結構評判いいんですよ。

やっぱりやると。

みたいなやつです。

これ初めて知ったので、

こんなのあるんだと思って。

おすすめです。

でも多分長く経験してるエンジニアから見ると、

当たり前のことじゃね?って

多分思うと思うんですけどね。

ありがとうございます。

そうですね。

総代さん先ほど、

SREはゴールじゃないみたいな話を

してましたけど、

この哲学って書いてるのは

どういうことですか?

いや、SRE本っていうのもそうだし、

SREの探求っていう

続編みたいな、

フォライディーの暑い方もそうだし、

あれどっちも、

SREっていうEって、

SREのサービスリライアビティエンジニアリンクなんですよ。

人のことを指してるわけじゃなくて、

エンジニアのことを指してるわけで、

振る舞いなんですよね。

だからこういうふうなサービスの作り方をやっていこう、

僕たちが良いことをやってみて、

こういうふうな考え方で、

だからこういうことをやりましたよ、

そういう振る舞いって、

どういうところで決まっていくかって、

自分の考えている課題だったりとか、

思いみたいなものを具現化していくためなんですよ、

わけじゃなくて、

それって中心にあるのは、

哲学だと思って、

だからSREって言ってるけど、

SREは自分がどういうふうに

ソフトウェアエンジニアとして

サービスに貢献するかという哲学のことを

チームの改善

まとめてあるものだなって思う。

これが他のロールでも、

CREだとCustomer Reliability Engineering、

これは顧客と向き合うために

どうソフトウェアを提供するかとか、

ソフトウェアを通じてどう顧客と向き合うか

という考え方だと思うし、

DBREだとデータベース、

データをどうユーザーに届けるか、

守るか、チームで活用するか、

そういう考え方がたくさんあって、

そういうのをたくさん学んだりとか、

自分のものにして、

エンジニアとして成長していくとか、

価値のあるサービスを提供できるようになっていく

エンジニアに、

振る舞いが追いついていくってことかなって思う。

僕最近、

インフラ寄りの書籍を何冊か読んだんですけど、

技術のことももちろん書いてあるんですけど、

結構人間性みたいなことが書いてあって、

それ答えないやつじゃなくて、

割と何冊読んでも書いてあるんですよ。

いい人になれみたいなのが書いてあって、

いいフレーバー寄せようみたいな。

特に、

そもそもソフトウェアエンジニアって、

生の本番のソースコードに近いところで

回ってるから、

センシティブな情報を見れたいとか、

データベースの中身を見れたいとか、

バグを出したらそれだけでたくさんのユーザーに

迷惑かけちゃうとか、

すげえ権威的なんですよね。

力がある。

特にその中でもインフラって、

より権威的だから、

逃げ恥のシーンで、

この会社の命運は俺らが握っている、

このクソインフラエンジニアめ、

みたいなことを言われるシーンがあるんですけど、

あれとかって、

あのシーン自体は笑い者になる。

でも実際そうで、

インフラエンジニアが本気を出したら、

その内緒が起こせるわけなんですよ。

だから、

そういう意味では、

人間性ってめちゃくちゃ大事だなと。

うん。

確かに。

それぐらいの操作ができますもんね。

そうそうそう。

悪意持ってVPCごと削除するとかできますからね。

笑

そんなことやらないけど。

笑

怖いけど。

そんな関係を持っている。

笑

確かにな。

あとあれです。逆に、

インフラエンジニアに限らず、

エンジニア全体そうなんですけど、

僕ら一人でできることだけが知ってるから、

みんなに手伝ってもらいながらやっていかなきゃ。

それって、

嫌な奴のことは手伝ってくれないし、

伝わらないから。

だから、

良い人で歩くことってインフラエンジニアに

めちゃくちゃ大事だし、

他の事業部だったりとか、

コミュニケーションするってインフラ多いから、

やっぱ大事なんで。

そういう意味では、赤瀬さんは向いてるなって思いますよ。

笑

怒られた。ありがとう。

笑

でも武田さんまさにそういうことを、

記事に書いてましたもんね。

そうですね。

そうですね。

しっかりまとめられてて。

めっちゃ読みましたよ、あの記事。

ありがとうございます。

うなずきながら本当に読みました。

笑

そうなんですよね。

最近思うのは、

アプリケーションエンジニアとか、

インフラエンジニアって、

明確じゃないけど、

千引きをだいたいするじゃないですか。

いらないんじゃないのかって、

最近すごい思っていて。

なんでかっていうと、

クラウドとかがやっぱり多くなっている中で、

アプリケーションだけど、

クラウドは触れないっていうことは、

絶対あり得ないじゃないですか。

コンテナ使うんだったら、

ネットワークは分かってて当たり前だしとか、

Kubernetesやるんだったら、

自分たちネットワークをちゃんと設計できないと、

使えないわけですから。

それが、たとえば分からんから、

インフラエンジニアお願いっていうのは、

間違ってると思って、ずっと思ってるんですよ。

何年もそうなんですけど。

SREっていう考え方っていう活動とかの話になると、

それはもう通り越して、

きちんと向き合うものは、

今持ってるものじゃなくて、

向かいにいるユーザーだから、

そこに行くためには何でもしないといけないですよね。

それがチームをよくするんだったら、

CICDから始まるしとか、

それが、たとえばPDMと

仲が悪いとこがいるんだったら、

そこに入って、

エンジニアリングの専門性とサイロ化

それは良くないですよみたいなところに入らないといけないし、

何でもしないといけないわけですよ。

それがアプリケーションエンジニア、

インフラエンジニア、

日本って特にそうかなと思うんですけど、

引いた上で、

立ち向かうっていうか、

そこからSREとしてやっていくぞっていうのは、

ちょっとハードル高いようになってすごい思うんですよ。

だから、

じゃなくて、そもそもアプリケーションエンジニア、

インフラエンジニアっていう考え方すら

やめたほうがいいと。

もうなんか、

DevOpsって言ってる時点で、

負けてるんじゃないかと僕は思っていて。

いや、そうそう。

そんな気がするんですよね。

そうそう、そうなんですよ。

そうなんですよ。

そういう概念すら、

なんかもう、

いいじゃん、みんなでやろうよみたいな。

そうそう、そうなんですよね。

いや、もうまさにそうですよ。

だってCICD他の人に作ってもらうって

ありえないですよ、普通は。

自分で作ったもん、自分で動かすやつって話ですから。

それはなんか、分かりますね。

うん。

極端な話ですけどね。

新しいロールが出てくると、

みんなそれになりたがるんだけど、

格好よく見えたりもするし、

気をつけたりもするんですけど、

結局それって、

よく本に書いてある、

サイロ化を起こす原因なのでは?

って思ってまして。

結局分断を生んでるんじゃないかな

っていう気はちょっとしますね。

なんかその、

今のエンジニアリングの

こういう界隈って結構

明確な、明確なっていうか

狭めようとする

動きというか、

専門性大事みたいなところ

結構多いじゃないですか、今だと。

だからそれも、

本当に良いようであんまり良くないんじゃないかな

とは思っていて、もちろん専門性って大事なので、

一般のウェブアプリケーションの人が

いきなり機械学習の論文を書けてたらできないんで、

それはある程度は仕方ないとは思うんですけど、

なんかそれがいきすぎるとやっぱり

サイロ化が起きてしまうんで、

サイロ化が起きるとやっぱり組織もサイロ化になっちゃうしとか、

自分はデータ周りとかに入ることがよく多いんで、

なんか営業チームとアプリケーション側の

見てるデータが違うとか

よくあるんで。

でもやっぱそれって

活動の幅を狭めるからこそ

余計起きちゃうんですよね。

SREチームの活動と苦労

だからなんかこう今の世の中

良いのかなって。

もうチャットGPTとかがあるんで

楽できる分、なんかもうちょっと

緩くなってくんないかなって思ってますよね。

Zoeさんが2021年から

立ち上げて

もう2年経つわけじゃないですか。

その中で

そういうチームを立ち上げた

活動の中で

苦労してきたこととか

こういうとこが

難しかったとか、

そういったところってありますか?

苦労したので言うと

やっぱ

さっき東大さんとかが言ってたような

SREの哲学というか

我々のサービスを

どう良くしていくのか

みたいな活動を

開発チームに浸透させる

活動みたいなところは

結構最初は苦労

で

どうやって良くしていくんだっけ

みたいなのを

今までは球体維線のやり方で

やってきてみたいな

ところだったんで

本当はもっとこういう風にした方が

良いんだよみたいなのを

一緒にやっていくぞ

っていうのが最初は苦労したところ

でしたね

最初にそれを

話したのと

あと

地道な改善活動みたいなのをやっていって

実際それで

すごい助かるわみたいな

感触というか

確かにこれやった方が良いわみたいなのが

出てきてからは

やっていこうみたいなところになって

ライブラリアップデートとかも

ちゃんと定期的にやらないといけないわとか

CIDとかも改善しないといけないわ

みたいな感じになってきて

でもチームだけで今までやってきて

なかったんで

単独のチームないだけだと

難しいっていうところも

あるのでSRHMが

お手伝いしながら一緒にやりますよ

みたいな感じで

最初は動いていった

2年経って

軌道に乗りつつある感じですか

そうですね

徐々にですかね

まだ結構

いろんな部分が

技術的際じゃないですけど

あったりとかして

まだチームだけの力でやるには

パワーが足りないというか

みたいなところがあるので

そこをもうちょっと

起こそうというか

できたらもうちょい

独力で

走っていける状態になるんじゃないかな

という風に思ってる

そのチームって

インフラとアプリケーションの関係性

何人ぐらいで構成されてるんですか

SREチームは

兼任メンバーで

だいたい構成されてるんですけど

今

チームメンバーは3人

2人と

業務委託1人って感じで

やっていて

そこのリーダーを僕も兼任して

合計4人って感じ

なるほど

インフラな

インフラ大変ですよね

運動していくの

確かにめちゃくちゃ大変ですけど

僕らさっきの

専門性の話は確かになと思うし

人育てる大変さなんですけど

若い子逆にインフラ

触る機会がすげー減ってるから

大変そうだなとは思いますよね

それねたびたび

話してるんですよそれ

どうして

いく方がいいのか

っていうのと

そもそも若手の人が

やりたいのかっていう面もあるし

やらせた方が

いいのかっていうのもあるし

いろいろ難しいなと思っていて

確かにそれで言うと

例えば

僕らってメモリとかも

CPU抽象化された言語しか書いてないじゃないですか

なんなら

PHPとかそうだし

Javaとか書いてると

実行環境あんま意識しなくて

Java自体は動くから

これって抽象化されてるって話だと思うんですけど

インフラが

クラウドによって抽象化されたり

コンテナによって

プロセスが抽象化されて

アプリケーションを置くだけで

抽象化されていくこと自体はいいんですけど

どっかのタイミングで

漏れるある抽象化とか

そもそも抽象化自体をメンテナンスしなきゃいけない

タイミング

知ってるかどうかって大事で

どこまで

僕らがアセンブラを勉強するかとか

C勉強するかみたいな話に近くて

結構全員が

やらなくてもいいと思うんですけど

誰かがやらないといけないから

差し掛けが難しいなとは思います

そうそうそうそう

全員じゃなくてそうなんだよな

全員じゃなくてはいいんだけど

トラブル発生時に

誰かがやらないといけないわけじゃないですか

そうそうそうそう

その時に

誰が触れるかっていうと

誰も分かりませんだと辛いし

ってのもあるんですよね

分かんないと想像できないですしね

トラブルシューティングの時は

めちゃくちゃ出ますねインフラの時し

絶対そうだと思うんですよね

ありますね

障害

障害はもうまさに

まさにそうですよね

パケットの奥まで来とんねん

みたいな話ですよね

そうそうそうあります

でも

あれじゃないですか最近とかだと

いや分かんないです

皆さんの周りは分かんないですけど

自分の周りとか観測してるとこはやっぱり

今だとアプリケーションの作り方だと

イベントソーシングCQRして結構

キーワード出てくるとこが多いかな

と思うんですけど

あれやるんだったらインフラ知識ないとできないですからね

正直なところ

だからこうhowばっかり

こういうエンドポイント叩きましょうとか

グラフQLを使いましょうっていう

正常系を作ることっていうのは

howだけで知っててもいいですけど

まぐったとデバッグするときは

裏側想像できない

できない

そうそうそうそう

そこだなと

うん

やっぱり避けると

限界値が来ちゃうんですよねすぐ

インフラを避けちゃうとやっぱり

どこでどういう通信とかが行われてるのかを

想像できないと

まじで障害対応できない

そうなんですよね

クラウドを使って新しいサービスが出て

余計システムが分散されると

余計ネットワークとかちゃんと意識しないと

できないですからね

そうそう

アプリケーションの開発が簡単になればなるほど

システム複雑になってるじゃないですか

うんなってますなってます

そこが難しさだよなって思ってるんですよね

まじでトラブったときに本当に分かんないんで

どこの画面のログを見ればいいんだろう

例えばAWSとか

AWS

それは感じますね

困ったら全部クラウドトレイル見て

S3とかクラウドウォッチ探すのめんどくさい

しかもああいうのもちゃんとログを出力する

設定にしとかないとログ出なかったり

それも知っとかないといけないじゃないですか

そこら辺はやっぱりトラブルシューティングして

なんで分からなかったのかというところから

徐々に自分たちでやってもらって

グってこういう風に出さないといけないんだよね

というところから始めてもらうとか

それまさにさっき言った

正常系だけを触っていると

分からないところですよね

そうそう

どうなんでしょうね

SQLはやりたいんですかね

どうなんですかね

だって最近SQL

生SQL書きたくないって人が多いから

みんなやりたいと思う

業務上SQLをよく触る方なので

触りたくないのか

どうやって触るんですか

触ったら

何で触るんですか

SQLは全部ORマッパーです

生SQL書いたら負けみたいなのが結構

ミックスで

違うだろって思うんですけどね

インフラやるっていうことは

やっちゃ負けみたいなこと

自分たちは思わないですけど

もしかするとそういう風に思っていることを

やらないといけないかもしれないですね

SREなんかそうですよ

意識を超えてやっていくことが多いんで

キラキラ大事だと思うので

もっとかっこよく見える何かがあるといいんじゃないですか

すみません適当なこと言いました

キラキラっていうかSREは儲かるっていう

バーケティングすれば

若者はそこでしょ

儲かるのかみたいな

確かに

大事なことですけどね

キラキラも

裾野が広がらないといけないんじゃないかと思う

狭める必要はないと思うので

できる人は増えてほしいなと思いますね

そのかっこよさの話でいうと

SREというか

ログとかインフラの状態とか

アプリケーションがどういうことなのか

理解している人がいると

障害発生時とかにも

特定までの時間とか

解消までの時間が圧倒的に早いんで

それを目前にすると結構かっこいいなって

インフラエンジニアの情報交換とイベントの増加

多分思うと思うんですけど

そういうところとかを

もっと表に出していった方がいいのかもしれないですね

最近はだいぶ

そういうイベントも増えて

事例とか

こういう活動をやってますっていうのが

だいぶ目にすることが多くなったんで

前よりはいいかなと思いますけどね

インフラエンジニアって

表に出てこない人が多いみたいな

イメージだったんで

データセンター行ってるとか

そうそう

そういう時代と比べると

全然今は変わってきたかな

と思いますけどね

誰かが楽に入れてくれてるんだよな

だいぶ

インフラっぽい話できたんですけど

なんかこれ話したりないみたいなところってありますか

インフラと話したと

トラブル対応するにやっぱ

オブザーバービリティとかみんなどうしてるんだろう

あーそうね

どうしてるんですかね

これね

自分も聞きたいですよ

悩ましいなと思って毎回

ツールに頼るしかねえっていうので

みんな多分結構そうかなと思うんですけどね

どういうものを可視化してたり

数値化

取ってたりするんですかね

そこも気になってはいて

まあ冒頭でも話しましたけど

会社でそれぞれ

見るべきポイントが全然違うんで

それによって変わるとは思うんですけど

どういったものを

一般的に数値化した方が

いいのかとか

可視化した方がいいのかみたいなところって

きっとあると思ってはいて

他社さんはどうなんだろうな

と思って

気になるところである

あの話せない内容も

きっとあると思うんですけど

オフザーバビリティは難しいな

と思いますけどね

自分の場合はとにかく

どこで何が起こっているのかわからないことが

すごく多いんで

まずは経路とか全部

わかるようにして

ニューレリック様様って感じですけどね

あとそこに出てこないのは全部自分たちで

構成図書いて

アプリケーション内どうなっているか

ニューレリックまで行って

それでまず

何が起きても大丈夫だように

まず一旦それで

基礎的なところは作って

みたいな感じですよね

細かい数値化とかは

全然やってないです

どこで何が起きているのか

まずわからないからそこからだっていう

うちの場合だと

話で大丈夫なのかな

難しいけど

数値はだいぶ

仕組み化されてますね

あらゆるパターンの

これは今こういうことが起きてそう

みたいなのが

通知されるような仕組みになっていて

当たりがつけられるようになっている

偉いエンジニアが

ちゃんと実装してくれてるんで

通知難しいんですよね

あからさまにやばいやつとかって

多分皆さんもあると思うんですけど

常に遅いとか

そういうやつ絶対あると思うんですけど

直さないといけないし

これはここで恐らくこういうことが起きてる

ってわかってて通知出しても

いわゆる狼少年みたいになっちゃって

みんな見なくなっちゃうんですよ

それが当たり前になって

これがね

ずっと直せないのちょっとなって

ずっと思うんですけど

そこが難しいなと思うんですよね

やってる人がいい人だから

めちゃめちゃ気になってるのかもしれないですけど

他社さんはね

どういう風にやってるんでしょうねって

本当気になる

めちゃめちゃ気になりますこれ

カンフォレンスとか

あったら

直で聞くしかないなとか思って

きっと出せない話も多いんで

綺麗な話ばっかりじゃないですか

表に出るの

こういう話で言われると地道だね

話がすげー多いから

インターネットには出せないですよ

いつかの時に

壮大さんとのび会で

その話をずっとしてた

思いがありますね

めちゃくちゃ盛り上がる

のび会ではめちゃくちゃ盛り上がる

さっきからみんな探りながら

何も喋らないっていう状態が続いている

簡単に言うとまずい話になっちゃいますからね

その通りです

僕はマカレルのエヴァンジリストだから

マカレルの文脈で

いろんな会社さんの

オブザーバビリックとか

いろいろ聞くけど

やっぱ

最初の方でSREの話になる

SLOとか

なんで作るか

監視がそれないと

ここ監視しようと決まらないし

ユーザーさんここ困ってるなって

そこ決まらないし

もうちょっとすげー頑張ったら

インセプションデッキみたいな

ドメイン

これを全部埋めていくと

自分たちのサービスだいたいこういう感じだよね

特性わかって

そのためにはこういう

場所が監視のポイント

パーティーの数とか

必ず新規登録されてるかとか

見なきゃいけないよね

データベースのこのテーブルめちゃくちゃ負荷高いから

見なきゃいけないよね

データベースの構成とかアプリケーション

全部壊せて

ドキュメントを壊せると

出てくるみたいな時代にならない

こないだ

それやってた人いましたね

いるの

そういう

データベースの構成とか

アプリケーション

全部壊して

ドキュメントを壊せると

オブザーバービリティの悩み

出てくるみたいな時代にならない

そういう

いるの

そういう話

これは延長性して

こっそりみんなで共有したいぐらいの

いい話

よし じゃあ

話題を変えますか

沢山できたんで

時間が少なくなってきたんでね

イスコンの話をしましょうかね

出た

みなさん出られたんですか

僕今回参加しなかったんですけど

出ました

みんな出たんですね

どうでしたか

惨敗ですよ

惨敗ですね

みんな顔を消して

どんな問題だったんですか

代表説明すると

YouTubeあるじゃないですか

YouTubeみたいな動画配信サイト

赤瀬さんがVTuberだとして

YouTubeのチャンネルを作りたいと登録すると

赤瀬.ハロハンテックJPみたいな

自分のアカウント名が

ドメイン名になる

ポスト名になる

Yahoo.JP

スラッシュ赤瀬じゃなくて

スラッシュ.Yahoo.JP

アカウントが増えるために

DNSに登録しなきゃいけない

なるほど

これがね

DNSサーバーを

10年ぶりぐらい触るみたいな

立ってるんですよ

これはなかなかみんな触らんでしょう

スコアが上がっていけば上がっていくほど

DNSに

さくらインターネットの風村さんが

作ったDOSが来るんですよ

DNSDOS

なるほど

あれをどう裁くかっていうのは

ボトルネックになる

僕らのチームは爆死します

だいぶ黄色が違いますね

一応普通の

Nプラ1とかもあるんですけど

そこだけだとやっぱ

最終的にスコア

ギリギリ伸びないみたいな感じ

面白い

全然準備しなかったので

そこ全然できなかった

やっぱみんな

DNSに苦しんでた感じなんですか

優勝するチーム

優勝したチームとかめちゃくちゃ若いし

他にもスコア高い人とか

若いはずなのに

DNSサーバー自分で立て直したり

みんな普通にDNSサーバー変更してて

すげーな

DNSサーバーを変更するみたいな

こともやるんだ

登録してない

ドメインっていうかホスト名だったら

DNSサーバー開発大会のエピソード

IPテーブルで

ドロップしちゃうとか結構やってる人とか普通にいて

うん

すごい

和風の設定

自分でするとか

そんな8時間の間で思いつくんだ

そうそうそうそう

マジでおかしい

それはでも

あれだろうな現場力だろうな

鍛えられてるんだろうな

ほんとですよ

面白そう

ちょっと問題見よう

もう公開されてるんで

ほんとですか

見てみます

DNSがクセ者というか

すげーいい問題なんですよ

でもそこ

気づいたのも後半だったんですよ自分は

これもダメだろうと思って

とりあえず

それはDTL全部ゼロだから

少し長くしようって

そっかそっか

ゼロとかなってんだ

毎回問い合わせられるんだな

なるほど

いい問題

いろいろ見たら

もうそれだけじゃなくて

もっといっぱいやらないといけない

DNSにまつわるチューニングみたいなことも

あったわけですね

そうです

あとはもちろん定番の

Nプラス1とか

ありますけどね

絶対に手を入れないといけない

プログラミングの箇所があって

直さないと早くならないんですよねきっと

そうそうそうそう

あと今回面白かったのが

配信中の

投げ線の総額が

スコアになるんですけど

投げ線

しそうな人とか

あとは

長時間配信のほうが投げ線が多いんで

長時間配信の人とか

っていうラベルとかがあって

それをどううまく使って

チューニングじゃないですけど

変えていくかみたいなのも

含まれてて

やっぱスコア上がってるチームとか

それをうまく活用して

そういう人のやつは

早く返してそうじゃない人は

ちょっと緩くレスポンス返すみたいな

こととかもやってる

すごいなって思いました

そこまでは発想が至らなかったなって思って

そうだいさんいつ優勝するの

毎年言ってるじゃん

毎年優勝したいですけどね

僕今年はめちゃくちゃ準備したんですよ

僕だって

PHPカンファレンス

沖縄行って

土曜日じゃないですかね

日曜日

月曜日沖縄で

素振りやってますから

結構早くからやってる

準備した感じは

ありましたもんね

めちゃくちゃ準備して

全く戦えなかったってわけじゃないし

何なら僕らのチームはマインスケールから

素振りに移行してるから

多分他の人たちよりも

手数は多かったと思うんですけど

それでも優勝チームとの

スコアの差が開きすぎてて

優勝チームあれでしたよ

12時過ぎには5万点が

特別賞だったんですよ

5万点出してて

めちゃくちゃ早かったんですよ

5万点出したら

トップ30に入るんですよ

2時間でも

5万点出してる

すげーな

46万とかでしたからね

そうそう優勝スコア

2位にダブルスコアとかでしたよ

2位にダブルスコア

2位にダブルスコア

2位にダブルスコアとかでしたよ

桁が違いすぎて

だから僕ら一応優勝目指してたから

Nプラス地味に直してて

この優勝チームに

絶対勝てないから

飛びどくでもいいからなんとかするぞ

みたいな感じでドロドロして

とにかくキャッシュだ

こわい

毎回イスコン面白いですね

面白いですよ

来年もぜひ

みんなで

2022年のPHPカンファレンスと地方のカンファレンスへの登壇

あれですか

皆さん毎年出てる感じですか

僕は今回久しぶりに

もう一回参加って感じです

自分も

同じく久しぶりに

そうだよね

やるぞって感じで

毎年

爆発しますけど

去年も爆発してた気がする

去年は

新卒のこと2人で出たんですけど

若い人と出たりとか

普段一緒に仕事してない人と

行動書く機会ってなかなかないから

そういうのもやっぱ面白いですよね

お祭りですからね

いいと思います

勉強にもなるし

PHP カンファレンスの沖縄の話が

ちらってましたけど

来年のPHP カンファレンスの話は

しますか

いいですね

福岡の話ですか

福岡っていうか

たくさんあるじゃないですか

来年ありすぎてどうしちゃったの

わかんないです

どうしちゃったのって感じですよ

結構プロポーザルの募集も始まって

終わって

タイムテーブルが出始めた

ところもあるんで

1月が北海道で

2月が関西

3月がペチパー会議で

4月小田原

5月香川

6月福岡です

皆さん出されてますよね

プロポーザル

そっか武田さん出さないって書いてたね

ペチパー会議だけ最後だけ

1個だけ出しましたけど

そろそろ若い人たちに

喋ったほうがいいと思ってるんで

若い人が

地方のカンファレンス

行ってほしいっていうのは

2つ意味があってもちろんね

登壇すると

いろんな人とのコミュニケーションが

ハーブになるから

登壇してほしいな

会社の経費で

行きやすくなるじゃないですか

その枠を奪うのは

よくないな

自分の金で行けって思った

確かに

私は主催側なので

主催的な

話をしたほうがいいのかなとは思うんだけど

せっかく

この1月から6月まで

こんなに機会がたくさんあるので

登壇チャンスがこんなに

生まれてることないと思うんですよ

ぜひこの機会を使ってほしいなと

僕は思って

本当に

本当に

本当に

登壇してほしいなと僕は思っています

PHPの話をしたかったら

どっか頑張って

刺さればいいわけじゃないですか

だからどんどん出していってほしいなと

僕は思います

それこそ北海道落ちたけど

僕同じテーマで大阪受かってるんですよ

場所が違うと

求められるテーマも変わるだろうから

あそこ落ちたからやっぱダメなんだ

じゃなくて

とりあえず応募してみるか

全然いいと思うんですよ

そうですね

最初なんか

これ面白いのかなみたいな

そういうのあると思うんですけどね

それももう全部関係なく

気軽に

本当その通りです

気軽に出してほしいですね

自分が

こんなのって思ってても

それを聞きたい人は意外といるんで

そうなんですよね

今のときたぶん

PHP 5.3とかの話もしても

全然いいと思うんですよ正直なところ

だっていっぱいありますから

5系なんか

8.3が出たばっかりだけど

5はあるよ

そうそうそう

だってたぶん

8とかよりも5のほうがまだ多いんじゃないか

って思いますけどね

多いですよね

現場を見ると多いと思う

あとちょっとイベントの話で言うと

竹澤さんの「クラウドネイティブレイズ東京2023」の話

竹澤さんなんか出られるんですよね

はい来月

クラウドネイティブレイズですね

クラウドネイティブレイズ東京

2023ってやつですかね

有明ですね

どんなこと話されるんですか

えっとですね

これは

今日のテーマにもちょっと絡むやつですけどね

SREと

DREっていうところですね

SREのプラクティス

いろんなプラクティスを使って

データ基盤を作っていくとか

作り方というよりも

作り方はもちろんお話ししますけど

そこにどういうマインドが必要なんだ

どういう取り組みが必要なんだ

そういうのをサポートするには

こういうクラウドのサービスがあるよね

クラウドのサービスの話はおまけぐらいにしないとは思うんですけど

そういう話はする感じですね

これオンラインでもあるのかな

オンライン確かあったと思います

なるほど

ぜひぜひ聞きたい

ぜひお願いします

SREメニューのお話もちょっと

もちろんするのと

あとはデータ基盤とか

データマネジメントみたいなのをするときの

マインドセットというか

思考のお話があるんですよね

クリスプDMってやつがあるんですけど

そこら辺のお話とか

表に見えるものだけは信じないとか

そういうお話もしたりだとか

あとクラウドならではの権限管理とか

こういったものでうまくできるように

SREのメニューによって

どれくらいの速さでデータ基盤の

こういうものが必要なのか

そんな感じの話

まさに今日話したようなことも話されるっぽいので

これをぜひ聞きたいですね

はいはい

興味ある方はぜひ

私有明の会場にいる予定なので

はいありがとうございます

はい

はい

といったところで1時間経ちました

あっても

あってもだった

はい

じゃあ第66回は

この辺で締めさせてもらおうと思います

最後にもう一度

XQ Twitterのハッシュタグについて

お知らせです

ハッシュタグはカタカナで

リクエストお待ちしています

はいということで

今回のつなぎMeFM第66回は

土屋さん 総代さん 武澤さんを

お迎えしてお話させてもらいました

今日はどうもありがとうございました

ありがとうございました

ありがとうございました