オブザーバビリティの課題とは
こんにちは、エンジニアの三田です。
こんにちは、エンジニアの博崎です。
ゆるテクは、三田と博崎が、ゆるく技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、というわけで、今日も2人で話をしていけれたらいいなって思っております。
はーい。
今日はですね、あんまり私も馴染みがないんですけれども、
ちょっと最近チャレンジしていることの悩みを、博崎さんに相談したいなと思っておりまして、
最近ですね、プロダクトの、よくSREの文脈とかで出てくる、
オブザーバビリティっていう言葉があると思うんですけど、
可観測性であったりとか、監視であったりとか、そういった文脈ですね。
そのオブザーバビリティをコード化するっていう、
オブザーバビリティアズコードっていうことにちょっとチャレンジをしていまして、
おお、面白そう。
ただちょっと、何でしょうね、チャレンジはしているものの、
これって本当にいいのかな、大丈夫なのかなって、最近すごく悩んでたりしてます。
なるほどです。
はい。で、簡単に何でそういうことをやろうと思ったかって背景を説明させてもらうと、
プロメテウスとか、あとデータドックとか、ニューレリックとか、
そういったオブザーバビリティツール使っていることが多いのかなって個人的には思っていて、
そういうツールを使うと、だいたいこれまでの自分の経験だと、
そのツール特有のクエリを覚えなきゃいけないなってすごい思ってて。
ありますよね、クエリがね。一致してないですよね、結構。
そう、プロムクエリが結構いろんなところが対応してるから、
そこで統一して書けるだろうっていう考え方もあると思うんですけど、
そもそもそれを覚えなきゃいけないのも結構大変だなって正直思っています。
そうですね、SQLとちょっと違いますからね、みんなが知ってるような。
そうです、そうです。そうです。っていうのもあるんで、
そういうのを作る人ってすごく個人的には俗人化しやすいなとも思ってて、
なんで最終的にアラートとかダッシュボードを作る職人が
だいたいチーム内に生まれてくる背景があるなって思ってます。
ダッシュボード職人生まれがちですよね。
そう、ダッシュボード職人が生まれがちだし、
あそこのプロダクトのやついいじゃんってなって横展開しようとするときも、
難易度的には難しくないんですけど、何て言うんでしょうね、
心を無にした作業をしなきゃいけないなと思ってて。
そうですね、定型作業というか、決まりきった作業ですね。
はい、ネクエリコピってきて該当するとこの名前だけちょこっと変えてみたいな。
そういうことが発生するので、
これって手でひたすらメンテナンスを続けていくにはどうなのかなって思ったのが正直背景です。
クエリとツールの習熟
なるほど、結構そういう作業って多いんですか、横展開するような。
正直横展開するパターンってまだあんまり今の私の職場だと多くはないんですけど、
どっちかというと新しくプロダクトが生まれたときに、
どこどこのプロダクトいいよね、
じゃああそこの監視のやつ参考にして作ってみようで、
心を無にしなきゃいけないとかはあったりします。
そうですね、ありがち。
はい、とかとかそういったところで、
ひたすら手でポチポチするのって個人的には苦痛を覚えるタイプなので、
じゃあそこって高度化できると、
そういったペインポイントを少しでも和らげることができるんじゃないかなって思ってたりしてます。
なるほどですね。
というモチベーションの下で今それをずっとチャレンジしてるんですけど、
ちょっと悩みもあって、
背景でも話したように、
結構クエリを覚えるのが大変って話があったじゃないですか。
はい。
とはいえ、人によってはそういうクエリを調べながら悩みながら書いて、
習熟していくっていうのが、
楽しみを覚えていたりとかする人も中にはいるだろうなって思ってて、
そういったモチベーションがある方々から楽しみを奪ってることをやろうとしてるんじゃないかって、
ちょっと悩んでたりしてます。
コードで書くよりもGUI上というか、
通常で試行錯誤しながらやっていくことに喜びというか楽しみというかを覚える人がいるからですね。
そうですね。
喜びと楽しみも覚えるだろうし、
そうやってツールの習熟度って上がっていくもんだろうなとも正直思ってて、
そこのジレンマというか、ちょっとせめぎ合いがありますね。
そうですね。
似たような話で、
テラフォームから例えばパブリッククラウドの設定に入った人って、
イメージしづらいっていうのを聞いたんですけど、
テラフォームからパブリッククラウドの設定に入った人って、
イメージしづらいっていうのを聞いたんですけど、
テラフォームから例えばパブリッククラウドの設定に入った人って、
イメージしづらいっていうのを聞いたことあります。
コンポーネント間のつながりとか。
そうですよね。
なので、その辺のバランスってどう取るのがいいんだろうなとも思ってて、
多分、テラフォームとかでIACしてるところって再現性を大切にしてたりとか、
手作業の人的ミスを減らそうとする狙いとかもあったりするわけじゃないですか。
かつ、多分だけど、プロダクト開発に集中できる時間をなるべく多く作るために
そういった自動化とかもされてると思ってて、
そう思うと、プロダクト開発するエンジニアはどういうタイミングで
そういうツールを学べるのだろうとかって思ったりしちゃうんですよね。
そうですね。1回目は手でやって、2回目以降はそういう自動化ツールっていうのが良さそうには思いますよね。
そうですよね。多分、手動でできるようになって、それを初めて自動化することに意味があるみたいな感じですよね。
そうなると、今チャレンジしようとしてるObservability as Codeって、
一番最初に名前入れたら一通りのテンプレがバーンってできますってなった場合って、
それは本当にエンジニアにとって喜ばしいことなのだろうかっていうのをちょっと考えてます。
確かにな。ちょっとあれなんですよね。
イテレーションというか、自分が何かを操作して帰ってくるまでのリードタイムとかが
ちょっと長すぎるんですよね、ツールだと、このAs Codeすると。
自分がこうしたいを実現するための方法を調べて、コードに書いて、多分レビューとかを通して
マージされて適応されてみたいな感じだと思うんで。GUIだとあれですかね、ぽちぽちってやったらできるのに。
試行錯誤の時間がちょっと長くなるというか、そこかな問題は。
だからできないことはないと思うんですよね、つまり時間をかけたら。
できないことはないと思っています。
なので管理面で考えれば、もちろんコードに起こってた方が設定値の透明性であったりとか、
量産とかっていう部分を考えたときは間違いなくメリットだと思っていて。
でもそういう学習をしたい開発者の体験の面で考えると、
学習するっていう機会をある程度残しておくコードの設計じゃないと、
結局そのツールとかってあまり使われなくなっちゃうんじゃないかとかあるのかなって。
なるほどな。
手動作業と自動化のバランス
もちろんそういったツールには興味がないので、
プロダクト開発に全集中したいですって人だったらいいのかもしれないんですけど。
そうです。ちょっと時間がかかっちゃうのがネックなんですけど、
2回やるっていうのはどうですか。最初は手動で作って、それをテラフォームにインポートするというか。
でもいいし、1回手動で作った後は削除してコードで作り直す。
なるほどですね。
ちょっと時間がかかって2度出前になっちゃいますけど。
たぶん1回目で目的というか設定はできるとして、
その後の変更を簡単にするためにコードに焼き直しとくって感じですかね。
そうですね。
確かにそれはありかもしれないですね。
そうするとあれか1回目である程度操作も覚えて、
2回目以降はもうコード上でちょこちょこ変更するだけにするとかそういう感じですかね。
そうですね。自分がAWSで最初テラフォーム触ったときそんな感じでしたね。
手で作ってみて、それをインポートとかして設定値がこうなってるなを確かめながら、
じゃあもう1回作ろうかで作ったりを繰り返してた記憶がありますね。
私もそんな感じでした。1回手でとりあえず検証中は手で作りますよね。
そうそうやってますよね。
そこと結局同じフローでもいいのかなオブザバビリティもそういう意味だと。
そうですね。
今日話してみるとやっぱり1回ブラックボックスな自動化をしちゃうと、
結局自動化が壊れた時に直せませんとか手で再現できませんってなっちゃうんで微妙だなって思ってたんですけど、
確かに1回やっぱり手動を通した方がこういうものもいいんだろうなって気持ちになってきましたね。
抽象化すると探索というかのフェーズでは手動でいろいろやってみて、
その後に進化というか整備するフェーズですかね。
この時にコードに落とせばいいのかもしれないですね。
なるほどっすね。
明確に分けるという感じでしょうか。
確かにそれが良さそう。
まず手動でやれて、それが言語化というか、できて初めて次コード化ができてみたいな感じですもんね。
別ですもんね。
これが良さそうっていうのを探すのと、それを最短でできるように整備するっていうのって目的とかがちょっと違うから、
分けた方がいいのかもしれないですね。一緒にしない方がいいかも。
じゃあ結構大事になってくるのって、例えばこのObservability as Codeっていうのを伝えた時に、
入り口から最初からコードで作ることを強制するんですっていう勘違いは生まないことっぽいですよね。
そうですね。
最初からコードにして書かなきゃいけないってなるとめちゃめちゃ難しいと思ってて個人的にも。
正解を書かないといけないですからね。
そう。ましてやグラフとか作るときに正直グラフ見ながら書いていかないと分かんねえよってなりますもんね。
自分はこのas Codeで特にダッシュボードを作ったことがないので、
ダッシュボードってコードで作るの難しそうだなっていうイメージがあるんですけど。
私も正直ダッシュボードはボイラーテンプレートみたいな感じでいいんじゃないかなって思ってて。
要はテンプレのコードでアプライとかしたらよく使われるダッシュボードがとりあえずパッてできます。
その先の細かいチューニングはもうGUI上でポチポチやってねえぐらいの方がいいんじゃないかなって思ったりしてますね。
確かに確かに。大まかにそのウィジェットというかパーツというか名前違うんでしょうけど、
その役割とかだけのやつが書いてあってみたいな感じですよね。
ここは何かの指標が置いてあるみたいなことだけ決めておいて。
そうすればたぶん01のところはとりあえず敷居は低くなって、
1から10なのか分かんないですけど、そこは頑張って育てていきましょうみたいな感じでもいいかもしれないですね。
それこそさっき横展開の話出ましたけど、横展開してもその内容はさすがに変わると思うんですよね、サービスとかごとに。
いやもう特性が違いますもんね。
お、なんかやっても良さそうな気がしてきた。
あれでしたか、やらないという結論になりそうな感じだったんですか?
やらないはなかったんですけど、ユーザーは絞られちゃうかなって思ってたんですよ。
使う人がですね。
例えば背景に挙げたアラートやダッシュボードの職人が使うだけなのか、
オブザーバビリティの民主化
それとも割と使う人を絞らずにみんなが自由に使える状態の方がいいのかとかっていうのを分岐点として考えてたんですけど、
今日の話で言うと、進め方によっては後者でも全然可能なのかなっていう気持ちになってきましたね。
そうですね。いやー監視ツールは民主化したいですよね。みんなが使えてほしい。
もう監視は役割じゃなくてスキルですからね。
そうですね。出ました、はい。
大事なやつ。そこは民主化したいっていうのもあるので、民主化の最初の一歩として敷居を下げたいっていうところですね。
いろいろやってみるといいかもしれない。チームに合ったやり方がありそう。
うんうん。っていうことを最近はずっと考えてやってたっていうところで、
今日はくたけさんと話せてだいぶスッキリはしました。
良かったです。良かったのかな。良かったです。
こういう系ってオブザベリックに限った話じゃないんですけど、
自動化系とかってはくたけさんはこれまでどうでした?
導入における対話の重要性
みんなと合意を取って進めてきた感じが多かったのか、
とりあえずえいって作っちゃって導入していくみたいな形が多かったのか、
どういうパターンが多かったのかなって思ってて。
あんまりエイヤーで入れることは少なくて、
っていうのもだいたいそのどのぐらい自動化するかみたいなのって
結構決まっててチームで。あんまり自動化してないチームとかは
それなりの理由であんまり自動化してなかったりするんですよね。
自動化のコストの方が高い、その自動化機構のメンテナンスの方が
コストが高いと判断しているとか。なのであんまり無理やり入れるということはせずに、
その方針にのっとってちょうどいいのをやるみたいなことが多かった気がしますね。
そうですよね。
自動化機構のメンテナンスの方がコストが高いと判断しているとか、
自動化機構のメンテナンスの方がコストが高いと判断しているとか、
利用する頻度であったりとか、自動化のメンテコストって結構無視できないですよね。
利用する頻度であったりとか、自動化のメンテコストって結構無視できないですよね。
そうそうそう。
それこそ極端な例だと、1年に1回しかやらないような作業を自動化しても
っていうのはありますよね。
しっかりした手順が残っていればいいんじゃないかぐらいまでありますもんね、
そういう時って。
なるほどですね。
今の質問した意図として、
何て言うんでしょう。
話はずれちゃうかもしれないんですけど、
こういう何かチャレンジするとか何かを導入するってなった時に、
結構気をつけたいなって自分で思っていることは、
導入する先に対して、
説得しにいっちゃうなって思ってて。
はい、ありますね。
本来は説得じゃなくて、対話しにいかなくちゃいけないのに、
何とか導入できるように話そうとしてしまうのは、
毎回毎回気をつけながら喋らないと、
気を抜くとすぐそうなっちゃうなって思ったので、
博多家さんはそのあたりって、
どういう感じでやってきたのかなって思ってきました。
ちなみに、説得になってしまうと何が嫌なんですか。
個人的には、説得になってしまうと、
多分相手の本当のペインポイントとかを、
ちゃんと抽出できなくなっちゃうんじゃないかなって思ってるんですけど、
逆にこっちの本当の意図も、
うまく伝えられなくなっちゃうんじゃないかなって思ってたりしてます。
なるほど。
導入することだけが目的になってしまいがちってことですかね。
そうですね。
そっかそっか。
何でしょうね。
説得モードってあれじゃないですか。
多分出てきた問いに対して、
うまく表現できないような、
基本導入する方向で打ち返そうとするじゃないですか。
そうですね。
ニュートラルな目では見てないかもしれないですね。
そうそうそうそう。
なので、それはやりたくないというか、
それをやってしまうと本質じゃないなって思ってしまうので、
その辺うまくできるようになりたいなって毎回思ってますね。
そうですね。
かといって、
確かに。
この辺りの塩梅が難しいから、
誰かうまい人の話を聞いてみたいなって思ったりしますね。
どういう感じなんでしょうね。
素直にやっててうまくいくんですかね。
それこそ本当にニュートラルに、
うまくいくんですかね。
うまくいくんですかね。
うまくいくんですかね。
うまくいくんですかね。
うまくいくんですかね。
うまくいくんですかね。
それこそ本当にニュートラルに、
こういうのがあるらしいんだけど、
こういうメリットがあっていいと思うんだよねみたいな話を
したとしてニュートラルにして、
相手も普通に、
良さそうだね、やろうってなることが少ないんですかね。
それまでのその相手との関係性すごく影響しそうですよね。
そうですね。
そういう話になりそうだな。
結局そういう話になる。
いや難しいな。
そうなんですよね。
前提が、
AさんとBさんの持っている情報が同じで、
何らかのツールを導入するみたいな案が出てきた時に、
ちょっと特性もあるかもしれないですけど、その人の性格とかも。
あるかもしれないですけど、
情報が同じだったらほぼ同じ結論になると自分は一応思っているので、
なんか素直に話しちゃってもいいかもなとはちょっと思いました。
ニュートラルにというか、思うことをそのまま。
説得モードじゃなくて。
確かにな。
それででもなーみたいなってことは、
でもなーの理由がきっとあるんですよね。
持っている情報が違うはず、自分と相手で。
目線を揃えることの意義
なるほど。
まあでも単純にめんどくさいとかもあるのかな、どうなのかな、ちょっとわからないですけど。
持っている情報が違うのと、問題に対する優先度の軸が違うとかもあるんですよね。
確かにそうですね。ポジションでね。
そうそうそう。これ永遠の課題ですよね。
そうですね。人は違いますからね。
なるほど。ちょっと素直にというか、自然体で話してみようかなとしたら。
なんかすごい人はきっとこれで一回言ってみて、その時の相手の反応とかそういう揺らぎというか、そういうのを見ていい方向に進んでいけそうな感じはしてますけど。
人間観察のプロみたいな感じですよね。
そうそうそう。そう思うのか、じゃあこう言ってみようとかこういろいろできるのかも。
そこがね、説得なのか対話なのかがまた違ってくるんですよね、きっとね。
そうですね。問いのデザインとかだっけ、ああいう本ではよくその対話、自分の意見を交換するとかじゃなくて、なんか一つのものを二人で見て、議論ではなく対話みたいな感じですかね。そっちのモードがいいのかもしれない。
同じ目的地を見て、それに対してどうしようかって話をするってことですよね。
そうですね。
それはいいかもな。
なんか案の採用不採用とかも大事なのかもしれないですけど、それを通して一旦目線を揃えるとかからやると遠回りだけど実はいい結果になるかもしれないけどどうだろうな。
いや、今のすごい大事なキーワードだった気がします。
そうですか。
目線を揃えるって忘れがちですよね、こういうとき結構ね。
大体揃ってないですよね。
うん。あ、話してよかった。
なんか違う視点の意見ができたならよかったです。
はい、ちょっとその目線を揃えるを忘れずに対話してこようかなって思いました。
頑張ってください。
はい、頑張ってみます。
はい。
はい、そんなとこですかね今日は。
はい。
はい、じゃあキリもいいので、今回はオブザーバビリティアズコードと対話って大事だよねみたいなことについて話をしました。
はい。
感想などはハッシュタグゆるテクをつけてポストをお願いします。
Googleフォームからも送れます。
今日はありがとうございました。
ありがとうございました。
