この番組はエンジニアの成長は楽しい学びからをモットーに普段インプットした話題をワイワイお届けするラジオになっていますお届けしていきますはいカイチの理解ですはい今日はですね最近僕がですね読んでいる本入門監視あ出た伝説の一冊と名高いやつだそうなんですね結構評判いいイメージありますよちなみにめちゃくちゃ面白いですそうなんだはい

確かにめちゃくちゃ面白いしかもだいぶあれだよね本の存在感としてのさ読みやすそう感が半端ないよね確かにそうかもしれない監視っていうトピックあんまいかないじゃないですか確かにそうかでもこれは読んだ方がいいしあとはなんて言うんでしょう読むべきだと思いましたそうなんだ全員

アプリケーションエンジニアも含めて全員ってことですよねはい今日その辺の話も触れつつ北浦さんコラボ会でもちょっと触れてましたけどアンチパターンの話をしたいなと思って出たはい

出だしがアンチパターンで始まるんですよね確かそうです第1章アンチパターン第2章デザインパターンなんですけどそっちも気になるんですけど監視のデザインパターンそれはちょっと別の回でお話しできればと思います今日はアンチパターンの話ですアンチパターンアンチパターン触れつつワイワイしながら

ちょっと紹介していくんですが全部で5つ1つ目ツール依存という話ですねツール依存これは北原さんコラボ会にも出てましたけどHowから決めちゃうものですねこの監視ツール使いたいからこういう形でやっていこうみたいなパターンですねで

これはその前エピソードで触れたときはできるだけシンプルにやりたいことはなんだっけ例えばこれだけ監視できればいいよね監視って言っても極論一番何もしなくていいやつだと1個だけ見ておけばいいし今後スケールしないよねだったらAWSだけだよねだったらクラウドウォッチでいいよねみたいなそういう話も

ありつついやそうじゃなくてこのツール使いたいからみたいなのでちょっとツール依存でやっていくと不必要に複雑になってよろしくないよねみたいな

なるほどね目的に合ったものを使いましょうということですよねこの辺はねまあまあまあ多分聞いてる人もそうだねそうだねって思うんですけどその中で触れられてたちょっと一個カーゴカルトサイエンスの話があってあれなんか聞き覚えあるような気がするぞ有名な話だと思うんですけどこの話ちょっとドリさんとちょい議論したいなっていうところで

まずカーゴカルトサイエンスの話これはエンジニアリングの用語ではないんですけど形から入っても意味ないよねみたいなところでエピソードとしてはちょっと待ってくださいねカーゴカルトサイエンスの例の話なんていうんだ例え話はい

例え話というか実際あったのかもしれないんですけど話に出てくるのは南の島の住民の中で積みに進行というのがあるらしくてですねはい積みに進行積みに進行はい戦争中軍用機がたくさんの素晴らしい物資を運んできては次々と着陸してくるのを見てきたですってこの南の島の人たちはいはいはい

これ今でも続いてほしいなっていうのを私たちは思ってますと戦争終わった後もなので何したかっていうと滑走路っぽいものを作ってその両側に火を置いたり木の小屋を作ってアンテナを模した竹の棒が突っ立っているヘッドホンみたいな格好のものを頭につけた男をその中に座らせたりして一心に飛行機が来るのを待ってるらしいんですってうんうんうん

これはもう形的には整ってるけど実際はその効果はないですそれはそうですね引きたいするような飛行機はいつまで経っても来ませんこのようなことを私はカーゴカルトサイエンスと呼ぶのですというのがあのご冗談でしょファインマンさんっていう小説ですかねなんだろうファインマンさんの本ですよね天才ファインマンさんで出てくるこのカーゴカルトサイエンスっていうものの

元ネタなるほど今これ聞いてなんで耳覚えあったのか分かりました多分達人プログラマーに書いてあるなこれそうかリュウル全然書いてそうその時多分俺あんま刺さってなかったのかな達人プログラマーかクリーンアジャイルか押されたけどなんかつい最近読んだ本で見ましたねアジャイルもありそうでこれ何が言いたいかというと形だけ入ってもあんま良くないよっていうので分かりやすい

ありそうな例で言うとGoogleでこれやってるからやってみると別にそれはGoogleと同じ効果は得られないよっていう話でそれはなんでかっていうとGoogleはその形にたどり着くまでにいろんな試行錯誤があってこういう本質があるんだっていうのを気づいた上でその本質を再現性高くするためにこういう仕組みにしましたっていう順番で形ができている

けど形から入っちゃうとその本質がぽっかり抜けた状態で形から入るから本当に必要な本質部分は得られないみたいな話をこのカーゴカルトサイエンスっていう

いつは何これはっていうのから言ってるんですよこのカーゴカルトサイエンスの話をこのツール依存っていう説ショーの一個下の説で語られてるんですけどこれ監視ツール以外にもすごい言えるなと思ってて分かる分かりますよねただスクラムやってるだけとか

あと何でしょう流行ってる技術全部に言えるんじゃない流行ってる技術確かに流行ってる技術全部に言えますしフレームワークとかもそうだし働き方とかもそうかもしれないしマネジメントとかもそうかもしれないですねなんかあり得るねなんか多分だけどワンオンワンとかそういう時期絶対あったよね今もあるんじゃないですか確かにワンオンワンとかめっちゃありそうですねそうそうそうそうそう

そうそうそうそうすっごいあるあるだし多分陥ることめっちゃあるしなんかだんだん陥ってるだろうなと思ってて世の中には形で普及されるんでこういうやり方でやってます確かに俺あのエンジニアになるときにエンジニアになろうって決めたときにMacBook Pro買いましたそういうことですねまあでもモチベになるなら別に個人だったらいい気しますけどねうん

それが集団になった瞬間にさらにむずくなるんでしょうね本質を得るのがこれに対して具体的にこうやったらいいよみたいな話は正直なかったんですけど本質チームとして本質を理解する本質のために何をするかを選択するそれで言うとさすっごい絶対プロダクションではやらないことだと思うんですけどはい

課題が出るまで何もしないみたいなのは本質にたどり着きやすいんだろうなってめっちゃ思ういやーわかる多分やってるとこあるんじゃないですかあるかなそもそも監視ツールすら最初入れないみたいなでも監視やっぱ必要だよねってなった時に初めて自分らがどういう監視が必要だったかがわかるんじゃないかなみたいな

そうですねリリース前にやるんじゃないですか監視が必要かどうかの判定をカオスエンジニアリングの話あるじゃないですかそれこそ北田さん出た時にGoogleでデータセンター1個落とすみたいなやってましたけどあれも結局何見とくべきかを特定するための営みの一つだと思っててそういう高いサービスレベルを求められるようなプロダクトである場合は

監視はでも多分長くてOKなわけはないとりあえず入れるけどリリース前にありとあらゆる緩めのきつめの敷地で荒と仕込んどいてリリース前にいろんな実験やってこんぐらいだねっていう課題を自分から作りに行って課題を作る営みをやった上で課題解決していくそれ以外はもう知らんみたいなのが

本当は綺麗なんでしょうねうん往々にしてそんなことやる暇はないんですけどねそうねちょっと個人で作ってたブログではそういう風にしようかなと思っててはいめっちゃいいですね本当に最低限まず作りますはいで最初はもう記事もえーと

テンプレートエンジンに直接埋め込みますでもそれだと大変じゃないですか更新がなので管理画面作りますっていう手順を追ってみようかなと思って本当に最低限の文字だけ出るウェブサイト作って終わっちゃったんですけどでも逆にあるじゃないですかMVPとかそういう考え方だと思うんですけどそれって

考えようによっては実はいらなかったのかもしれないですねそうねちょっとあれはMVPっていうかもうMMVPだったよなんですかそのミニマムミマンVPだったよマジでVPバイアブルプロダクトバイアブルプロダクト本当だったら何も作りきれないで終わってたかもしれないですねそこねその可能性もあった正しい肯定かもしれないうん

っていうのはすごいツール依存っていうアンチパターンから拡大解釈しつつカーゴカルトサイエンスってやっぱ大事というか非常に大事な考え方だけどちょっと周囲に広めるのはやっぱり理解してる人が集まってほしいなっていう確かにあとはまあなんかとはいえコストのバランスあるよねっていうのは思っててなんか

何でもかんでも必要なものになってから追加みたいなのを全部でやるとすっごい選択に時間がかかる気がしててある程度だいたいこういうパターンの時ってこういけるよね的ななんかカジュアルなデザインパターンじゃないけどそれなりのなんかセットみたいなやつはあるかなって気がするんでコスト削減みたいな意味でそういうのはありかなとも思う答えある系はそれでいいんでしょうねうん

あとセオリーか定石がある系そこの見極めはマジで感と経験かもしれないですけどスペシャリストが求められる現場ですね現場仕事っていうのが一つ目ツール依存の話で僕がなんかちょっと引っかかったというか刺さったところでしたはいじゃあ二つ目いきますはい

2つ目が役割としての監視というアンチパターンです役割としての監視はい監視ってのは役割じゃないっていうことを言ってるんですけどどういう意味で言ってるかというとまず一般的な会社で会社が大きくなるにつれてプロダクトが大きくなるにつれて普通役割分担が発生しますとこの人はここの部分やってこの人はここの部分やってみたいな

っていうのが普通だしそれはそうあるべきですとってなった時に監視はその中の役割であるべきではないということを言っていますなのでどういうことかというと誰かが専門的にやるものではないという意味で役割であるべきではないと言っていますそれは何でかっていうと

監視を作るため監視項目とか指揮地とか作る上では監視対象に対する深い理解が必要ですとそれが動いてるよねとか健康な状態であるよねっていうのを言うためにはどういう条件を設定すべきかは中身を知らんと詳しくないとできないなので監視の設計とかはその部分を担当した人がやるべきですよねとネットワークだったらネットワークアプリケーションだったらこのアプリケーションを作った人

っていう意味でだからみんなやろうねなるほどねインフラとかだと横断チームみたいなやつあったりするじゃないですかいろんなプロジェクトのインフラ全部やってますよみたいなそういう風にすなってことですかねインフラを作ってるならいいんじゃないですかその人たちがインフラのロールの人たちインフラ役割インフラ担当の人たちがインフラの鑑賞するのいいんじゃないですかただ

監視担当の人にアプリケーションの監視をさせる外形監視作ってもらうのかとかですかねどの外形監視どこを監視すればいいとか何のメトリックス見ればいいとかっていうのをインクラ担当の人に設計とか全部やってもらうのは多分オーバーヘッド大きいよねってことだったと思いますこれオーバーヘッド的な意味でなんだ

深井 何がまずいかはっていうとオーバーヘッドがまずいっていう書き方をされてないんですけど僕の解釈としてはオーバーヘッド含め作った人が全員本番環境に関心を持つべきっていう考え方がDevOps的な意味で責任を持つ必要があって責任を持つというのはどういうことかというとちゃんと本番環境を監視できる監視することをすべきDevOps的には深井 うんうんうん

っていう意味で全員がちゃんと監視をすることによって全員が本番環境を意識して今の本番で動いてるやつがまずいことがあれば何がまずいのかをちゃんと把握できるしその監視の設計ができるという風に捉えてますオーバーヘッドもだからあるんですけどそれだけじゃないみたいなことを言いたかったです監視は独立させるなってことですねそうですね

デブオプス的な考え方ですね結局教科書的にいろいろ言われてますけどデブオプスいいよねっていうのは僕もすごい思っててそのいいよねの要素の中で結構ウエットっていうかウエットって言い方ってわからないんですけど運用してみないと運用しやすいソフトウェアって作れないよねとかそういうのは

結局ソフトウェア作りの一番綺麗でいい形って保守しやすい運用しやすいものを作れるからだと思うんで開発者としていいものを作るためにはやっぱり運用を見ていく必要があるそうすることによって開発段階でストイックに運用しやすいものを作らなければいけないという全員が思えるそれがDevOpsはいいと僕は思ってるんでそういう意味で役割として監視するんじゃなくて

もちろん一時受けは別にいいと思います一時受け?はい改がった時に一時的にそういうことか一時的に一旦正常確認する人が別にオペレーションセンターがあるのは別にいいと思うんですけど監視設計とかは自分たちでやった方がなるほどね運用というか実際のオペレーションはさておき携わっておくみたいな開発者が

そうそうそうそうっていうのは思いますね僕は今ちょうど運用監視をし始めたというか初デブオプスプロジェクトなんですけど僕恥ずかしながら今のところなんとかよりに電話も来ずやれてるんですけどとはいえやっぱこうしときゃよかったらすごいいっぱいありますねなるほどねはい

オンコール対応ありなのかあります24365でございますそうなんだやったことないから慣れてないだけなんですけどなかなか痺れますよねそうだね休まらないよね心が休まらないですね慣れるんでしょうねきっとねだから毎朝電話鳴ってないよなってなります俺寝過ごしてないよなこれもエンジニアとしてはいい経験だなと思ってます

っていうのが役割としての監視だから僕はこれを全員読んだ方がいいと思ったということを最初に言いました入門監視みんな読んだ方が良さそうデブオプスプロジェクトじゃなかったら強制はしないですけどぐらいです3つ目チェックボックス監視ですこれは北浦さんの話にも出てきましたねなんかこれ動いてるかなチェックリストがあってチェックリストを

埋めることによって満足するような監視は良くないよっていう話出てたんですけどその中でのエッセンスだなと思うのは動いているとは何かというのを定義しようっていうのはすごいエッセンスだなと思いましたエッセンスだな監視する上で何が大事かっていうのは動いているかを監視するのが監視だとただその動いているっていう定義は物によって違うので

何がどうなっていれば動いていると言えるかというのをちゃんと企画が含めなのかみんなで合意しておいて

動いてるかを確認できる最低限の監視をするっていうんですか大事ですと具体的な話をすると何ミリ秒以内でレスポンスが100%返ってくる何リクエスト中どんぐらい100%返ってくるなのか何リクエスト中90%返ってくる80%返ってくる多分現実的には100じゃなくて90とか80とか

エラーバジェットっていうものを設けるんでしょうけどこれの定義をすることによって無駄なアラートがならないっていうんですかアラートが鳴った時に何もしない何もしないというか正常を正確にして動いてねOKOKみたいなアラートって究極アラートいらないんですよ考え方によってはなので例えばCPUが100%に張り付いたとしても

レスポンスが時間通り返ってくればOKっていうのを動いていると定義していればCPU見なくていいよねと外形監視で何秒に1回リクエストして時間通り返ってくるかを見ていればいいという定義にできればCPU100%になった時のアラートはいらないみたいなそういう話があるんですけど

エッセンスは動いてるかを定義するここに執着するなとこの本を見て思いましたそうなんだなんかさ健康診断あるじゃないですか健康診断って死んでるかチェックしないじゃないですか一方

そういう死につながるような数値が出てないかをチェックしてるなと思っててそうですね監視ってなんかそういうなんかいわゆる血圧みたいななんかそういう指標ってあんまり見ないんですかね

それはプロジェクトによってちゃんと動いているの定義によると思うんですよちゃんと動いているの定義の中にCPU使用率が90%超えないよねとかメモリとかストレージが何%いってないよねみたいなそういう定義を入れるかどうかなんだと思いますなるほどね例えばCPUは正直スパイクで上がったりするんであんま見ないとして

ファイヤーストレージみたいなストレージサービスをもしオンプレでやってたとしたら80%超えたらストレージがパンパンでちゃんと動いてるというよりはギリギリ動いてる状態だよねっていう定義ができるんだとしたらストレージ増設しなきゃねみたいなそういう経済圧上がってるから塩分控えめにしましょうねみたいなそういうちゃんと動いてるをどう定義するかそういう計測項目をちゃんと自分たちで考えて

作っていこうぜってことかな要するにそうですね作っていく上でちゃんと動いてるの定義があって何見なきゃいけないねって項目ができていくそれをチェックリストにしてしまうとあれかそういう定義が例えばプロダクトの運用において変わっていった時とかにもそのままになってしまうこともあるしそもそも目的が分からないままチェックしてるよじゃあ全然ダメだぜみたいなそういうことですか

どちらかというと会社標準の監視項目みたいなのがあってそれはそのプロダクトは本当は見なくていいはずのアラートなのに監視しちゃってるのをチェックボックス監視と言っていると書いておりますチェックリストって固い企業だと何かのインシデントが起きましたこの再発防止策としてこのチェックリストを

使って都度チェックしますみたいなのがあるあるなんですよじゃあこのチェックリストが埋まってるってことはこれは空想なんですけどこのチェックリストがちゃんと埋まってるよしよし承認っていうことあるんですよ空想ですよっていう場合ってチェックボックス埋めることによって安心しちゃってるじゃないですかこれは本質じゃないというか

チェックボックス埋まってればOKよねっていう感じではなくてやっぱりちゃんとそのサービスが動いてるかを監視よねっていう意味でチェックボックス監視はアンチパターンですっていう話だと思ってますここまでが3つ目これ折り返しましたね4つ目これちょっとすみませんさっきの話に似てるんですけど監視を支えにするっていうアンチパターンで監視を支えにするがアンチパターンはい

これはちょっと聞いたらセアなって思うと思うんですけどとあるチームでアプリを動かしてますと何かが壊れましたとアラートが上がりましたとアラートが上がらなかったわ何かが壊れたけどアラートが上がりませんでしたそしたら都度その監視を追加するということをしてましたと

ただアプリは完璧に動いてるわけじゃなくて不完全に作られている例えば無駄な具体的にどんな処理があるんだろうアプリの不具合を監視によって解決するってことをやってたチームがありましたとこれは良くないぞとアプリの不具合を監視によって解決していったそうですねあるとしたらなんだろうなそれ見つけて都度

回収してったとかではなくてそうそうそうそうどういうことだちょっと合ってるか分かんないんですけど握り潰すようにしてったってことそうそう握り潰すか極端なこと言うと1週間に1回再起動しなきゃいけないアプリがあったとしてバグで1週間に1回再起動しないようにしなくていいように修正するんじゃなくて1週間に1回再起動してねって改めてあげるようにしたみたいなはいはいはいはい

これは直感的に良くないやろっていうので本質的に根本解決してませんと問題をちゃんと本体直しましょうねなるほどねこれ4つ目ですこれはもうサクッと終わります5つ目手動設定っていうアンチパターンですねこれもせやなって感じなんですけど監視対象の追加まあ

本番運用してるので新しいコンポーネントを作りかするのかもしくはスケールアップオーバースケールアウトスケールアウトかすいませんスケールアウトでインスタンスかコンテナか追加されるようなとき監視対象の追加が必要ですよねこれを自動でできるようにしましょうとっていうのが手動設定

ってアンチパターンなんか手動だとコンテナとか追加してスケールアウトさせようと思ったらなんか監視エージェント入れてログちゃんと送るように設定してとかってやらなきゃいけないかもしれないですけどそうじゃなくて手動でやるようにしましょうねとなるほどね今時それ手動でなるのか手動の

意味わかんない作り手だったらなんじゃないですかなるのかいやわかんないですよ普通に作ったらなんないですよねAWSとかだとクラウドウォッチだって全然普通に動いてますよねまあそうですねあとはコンテナイメージとかにちゃんと設定とか入れてコンテナで動いてる場合にはなると思いますねなるほどなるほどパターンだけ聞いた時全部IACにしようぜってことかと思ったらそういうわけではないですね

それも含まれますねそれも含まれますもう一個の手順書依存も気を付けようっていうのがあってコマンド打ってコマンド打ってみたいな手順書があったらそれはちょっともっと自動化できるよねっていうとかもあるんですけど結局コマンド打ってコマンド打ってとかもね実はじゃあAWSクライアントAWS CLIかCLIのコマンドがガーって並んでて

スケアプラさせましょうとか設定というかAWSのサービス追加しましょうみたいなのがあったらそれはIAC化できるよねみたいなことかもしれないですし監視もすごい変更すごい結構あると思うんでこの辺自動化してないと後で複雑化した後に追加するのも更新するのも苦しくなるんで自動化しましょうねっていうのが

最後の手動設定というパンチパターンでしたなるほどはいというので今日ツール依存この中でもカーゴカルトサイエンスの話触れたのとあと役割としての監視これはみんな監視やろうぜっていうのとチェックボックス監視ちゃんと動いてるか動いてるってなんだろうねを定義した上で動いてるか監視しようって話監視を支えにする監視

エラーを握り潰すんじゃなくて本体直せよってのとあと指導設定自動化しようねっていういつ紹介しましたなるほどアンチパターンってさこれやっちゃうわみたいなやつコードのとこなら分かるんですけど監視だとこれがどれくらいやっちゃうあるあるなのかがピンとこないんですけど結構やっぱあるあるなんですかね物によると思うんですけどチェックボックスめっちゃあるあるなんじゃないですかね多分あの

もちろん時代が変わったのはあると思うんですけどおそらく大きい企業だとここ見とけよみたいなのはあるはずでCPU見ときましょうねみたいなCPU見とく必要があるかは絶対にサービスっていうかアーキテクチャによると思いますチェックボックスが一番あるあと役割もまあ

チームとして監視をしてたとしてもチーム内で全員が監視に興味あるかはまた別だと思いますね興味持たせるのは結構むずいかも自分で持つしかないですよねこれは役割は偏るべきじゃないと思うんだよな一人立ちした後に苦しむ気がしますしねサービスを作って出す上では必要な工程というか

ものだと思うので経験できるうちにしておきたい個人的に思いますツール依存はどうなんでしょうね慣れてるの使うのはあるんじゃないですか慣れてるの使うのは悪くもない気がしますけどね確かに戦略的には全然ありだよなそんな気がしますねお金かかるもんじゃなかったらそうですよね

とか言ってそんなわけねえよっていうのもある気がしますけど最適なものを選べよみたいなでもやっちゃうと思うけどなそうですよねやっちゃうなそれはやっちゃう気がするちょっと下の監視を支えにするとかはちょっとよくわかんないというか怖い話ですね怖いね怖い話本当にやったか怖い話ですねうん

まあチェックボックスはマジで気をつけようと思います 今なんかもうあるもう本当にこれあるめっちゃある見たくなるしね cpu とかねあーだからいやそうだねなんかそれ確か北浦さんがゲストで来てくださった時も多分 cpu を見るかどうかみたいな話あったと思うんですけどはい見ないの不安じゃないってなっちゃうけどね でも上がるんですよ cpu ってうーん

ふとした瞬間にそれで毎回呼び出される呼び出されないようにしとくのもいいんですけどただ呼び出される人は確かにいるんですよね一重系の人は少なくとも呼び出されて一重系の人は少なくとも何かの対応をしてるんでそれが正しい姿だとあんまりなんか思えてないですね申し訳ない申し訳ないうーん

でもまあそうとも言い切れないシステムもあるからまして作ったアプリケーションに対してハードウェアまで詳しい必要があるのかな言うたらハードウェアかデータベース100%でこれは大丈夫だよみたいなのを言えるかどうかってことですよねCPU見るべきかってうん

ノウハウっすねそれは多分大体は本番運用した後にいらんくねってなるんでしょうね新たに上がってるけどこの時毎回何もしてないなってなって削るみたいなそうそうそうそうもしくはCPUなくしても外形監視でレスポンスタイム見てるからいいよねみたいなことかもしれないですねっていう風に思いつつちょっとこれも読み進めつつ僕も仕事で監視というか

監視はしてるというより監視仕込んでる側なんですけどちょっとなんか学ぶものがあったらまたお話できるといいなと思いますオプスじゃあ終わりますハッシュタグひまじんプログラマーでSNSネックスでビードバック募集してますのでそうですねあるあるとかありましたらお願いします説明欄でGoogleフォーム番組のお便り要望感想質問何でもお待ちしてますのでお願いいたします何でも聞いてくださいはい

最後に各種ポッドキャストプラットフォームでのフォロー高評価もお待ちしてますお願いしますはいまた次回バイバイ正直者のエンジニアは不可分散ができるようになりました

それを見ていた欲張りの男がサーバーを落としましたあなたが落としたのはこの金のサーバーですか?へい、その金のサーバーを落としましたどうやらあなたは嘘つきのようですそう言って女神は帰っていきました欲張りの男は復旧できないサーバーの前でわんわん泣いていました

サーバーを落としたくないあなたへひまじんプログラマーの週末エンジニアリングレッスン