この番組はエンジニアの成長は楽しい学びからをもとに普段インプットした話題をワイワイお届けするラジオです今回は入門監視という本から監視のデザインパターンのお話をしたいなと思います前回じゅんぺいはいなかった監視のアンチパターン界の

続きの第2章デザインパターンという丁寧に1,2をやっていくスタイルなんですけどただ今回で最後かもしれないリモ監視はコアの話をさせていくから監視にデザインパターンがあるっていうのが結構衝撃なんですけどこれですね先に言っておくんですけど

なんか思ったデザインパターンと違いました僕はあそうなんだはいただ監視のなんだやり方っていうのかなデザインパターンに近いのかなやり方を網羅的にというか体系的にまとめられたショーだなというのでちょっと紹介していきたいなと思います5つこういう監視したらいいよっていうはい5つで基本的には全部やっていくんだと思います

一つのシステムを監視していく上では何ならレイヤーが揃ってませんなるほどはいデザインパターンゴフのデザインパターンってアプリケーションのコードレベルに何かするみたいなレイヤーじゃないですかそうね今回紹介するのはそういうのじゃないですなるほどインフラだけでもいけるしアプリケーションのとこでもやれるしみたいなそういう感じのそうそうそうそうあとなんか方針レベルの話あるしみたいな方針レベルまであるのはい

まあまあでも勉強になる内容なんでじゃあ一つ目組み合わせ可能な監視デザインパターンなんですけど名前が説明的だねはいまあそのまますでこれはなんかシステム設計にも同じこと言えるなって思うんですけど組み合わせられるような監視を作っていきましょうで専門的なツールをいろいろあるんですよ例えば何でしょうねザビックスとかあそう

例えばデータ収集するやつとかデータ貯めるやつとか可視化ツールとかあるじゃないですかいろいろそういうのを組み合わせられるように監視を作りましょうっていう話です監視界隈のあれが分からなすぎてどうやったら組み合わせられてどうなってたら組み合わせられないのかが分からないかもSaaSとか使ったらあんまり考えなくていいかもと思います自前で監視

ツール作ってると他のツールと連携しづらいような形式で送ってたりするかもしれないですねパッと思いつくので言うとログ変な形式で出してると例えば何でしょうねテキストで1文で1行でガーって出すようなログがあった時にそのログからインフォログなのかワーニングログなのかエラーログなのかみたいなエラーレベルを拾いづらいことあると思うんですよどういう時に拾いづらいかっていうと

いろんなアプリがあってログの形式が揃ってないときにそのログを受け取った先でこのログがエラーログなのか何なのかって判断するロジック作りづらいなるほどっていう意味でログ出すところでは同じ形式にすることでつなぎやすい組み合わせ可能になるとなるほどみたいなことだと思ってます監視のコンポーネントって5つあると言っててはい

一つ目がデータ収集具体的に言うとアプリケーションログとかを集める送る例えばAWSで言うとラムダっていうファンクションアドサービスがあるんですけどコードだけが

書いておくと実行してくれるみたいな裏側でAWSが吉田にやってくれてるんですがラムダからクラウドウォッチっていうログ貯めるところに送ってくれますと送る部分はデータ収集ですAWSだから吉田にやってくれてるけど自分でアプリ作るんだったら別のログ集めるところにログを送るエージェントみたいなのを入れる必要がありますね多分どういうログを集めてくるんだよとかを

アプリケーションログ全部送るみたいな質問いいですか例えばEC2インスタンスにデプロイされているララベルのアプリケーションとかってそのインスタンスの中のララベルログみたいなやつをララベルが書き出してそれを例えば

何かしらの集計ツールとかで集計してツランできるようにしたりとかするんですけど今回でいうと書き出す部分が要はそれに当たりますか書き出すっていうのはどこからどこにですかララベルの中のコンポーネントがテキストファイルとして書き出す部分可視化するのって何を見て可視化してますかその書き出されたララベルログを見て集計してるはずですなるほど

それで言うと多分アプリケーションのサーバーという単位で言うとローカルで完結してるんですよね多分そこで言うとむずいなそこで言うとむずいんですけどなんでむずいっていうかっていうと素結合に考えるとデータをストレージ今データ収集の話してますけどデータストレージもまた別の場所にあることあるじゃないですかクラウドだと大概そうだと思うんですよアプリケーションとクラウドウォッチログス

って違うところに溜まってるんでログを送る仕組みがいるんですよ世の中的には送るかプルするかの2種類あるらしいんですけど送る仕組みのことを言ってましたデータ収集はだから例えばマルチクラウド構成ですと大元はGoogleクラウドで管理してますってなった時にGoogleクラウドにログを送りたいじゃないですかうんうん

Googleクラウドにログを送るためにGoogleクラウド用のログ送るコンテナみたいなエージェントみたいなやつを動かす必要があってそのエージェントのことをデータ収集と言ってますデータ収集のやつなるほどプッシュ型のプッシュ型とプル型があるって言いましたけどプル型これSNMPどうやったエージェントこれネットワーク機器のログを取ってくるやつなんですけど

ネットワーク機器の今の今ちゃんと動いてるかなとかログどうなんみたいなのを取ってくるやつなんですけどそういうのはプル型って言って定期的に取りに行って大元のSNMPマネージャーにデータを貯めるというか持ってくる動きをするらしいですとあれSNMPってSDNのやつだっけいや違うんじゃないですかソフトウェアディファインドネットワークの話ですよねSDNってとは別かNESPで出てきて

こんぐらいあるんだよなこの辺うわー怖え怖いんですけど多分違うと思います普通にネットワーク機器から情報取ってくるやつだと思ってますうんうんうんそうね監視用っぽいねそうそうそうそうで基本的にはプッシュ型の方がいいですなぜかというと拡張性が高いからですなんでそうかというと新しいサーバー増やしましたってなった時にプッシュ型だとサーバー側にもともと入ってるエージェントが勝手に送ってくれるんですけど

プル型の場合は大元で追加されたサーバー追加して取ってくるリストに加えなきゃいけないんで拡張性がちょっと悪いなるほど確かに世の中のデータ収集系のエージェントとかは大体プッシュ型になっていると思いますデータ収集ではプッシュ型とプル型があってデータ収集はプッシュ型にすることで組み合わせしやすいよねって

話ですねログのデータも2種類あってですねログとメトリクスっていうのがありますよく聞くやつですね順平に問題ですログとメトリクスそれぞれ説明してください言葉にすると地味むずなんですけどねログはいろんなやりとりを文字ベースで出力しているものメトリクスはメトリクスは

なんなんすかねあれまあパッと見るいつもはだいたいなんか折れ線グラフみたいな感じのイメージなんだよなそうわかるこれ辞書でなんて書いてるみたいな言い方されるとちょっと急に説明ちょっとむずいっていうね時間軸でパフォーマンスとかをなんか見れるように可視化したやつありがとうございますはい

三角いやーちょんかなちょんキャドイちょん合ってるんですけどねそこじゃないというかそれは見えるようにした後の状態なんでねログもちょっと広いというかなんかすごいシンプルに言うとですねこういうことなんだって僕本読みながら思ったんですけどまずログこれはですね連続した文字列ですえぇー

広く言うと連続した文字列なんならタイムスタンプがあるといいよねみたいな連続した文字列をログと言いますメトリックスこれはですね数字です数字です確かに表にできるってことは数字グラフにできるってことは確かにそうCPUのパーセントとかメモリーとか使用量とかでメトリックスって2種類あるらしくて

カウンターとゲージっていうのは2種類あるらしくてはいカウンターは増加していく数字です例えばウェブサイトの通算来訪人数とか出た切り板踏んだかどうか切り板踏んだみたいな切り板踏んだ?世代やんけそうなんだ80とかを超えたみたいないや100人ぴったりみたいな

霧のいい番号ですか霧板は分かるんですけど霧板踏んだってなるとそこまで行ったっていうこと昔のウェブサイトとかだと結構来場者カウンターみたいなのがあってそれでちょうど霧板だった時に霧板踏んだとか言うよね自分がそこを踏んだそういうことかなるほどなるほど理解です1個目がそういうカウンター増えていくやつ2個目がゲージこれある時点の値ですねメトリックスで多く使われるのはゲージなイメージですね僕は

この時点のCPU使用率みたいなカウンターの方もネットワークインターフェースのバイト数とかで使うらしいんですけど通算でどのくらい使ったみたいなちょっとこれ正直あんま分かってなくてなんか摩耗するみたいな話なのそっちなの?あれで使うイメージあるけど料金計算というか料金計算使いますね確かに

今月何ギガ使ったみたいな確かに確かにありがとうございますすっきりしました話は戻りましてデータ収集1個目ですねやり方プッシュとプルがあってデータはメトリクスとログがありますという話でした2つ目の要素データ収集して送ったやつを貯めるとデータストレージ

これはあんまり深掘りしないんですけどイメージ通りですねS3かもしれないしクラウドウォッチかもしれないしはたまた時系列データベースに入れるパターンもあるみたいですね時系列データベースってなんだっけタイムスタンプと値の組み合わせで入れるデータベースらしいですノーSQLの一種的な感じですかなのかなと思って読んでましたほう

でこの時系列データベース僕もあんまり使ったことないんですけど正直クラウドウォッチとかはその類なのかもしれないですけどどうやら一定期間経つとデータの間引きとかしてくれるらしいですそうなんだと思いながらはいでは2つ目データストレージですで3つ目ためたデータを見るところ可視化するところですねメトリックスの可視化とかよく見ますねさっきじゅんぺいが言ったグラフみたいなのね

クラウドウォッチでもできますしグラファナとかいろいろあると4つ目分析するところこれはSLAがもし設定されていたとしたらこの期間でSLA達成してた達成してなかったみたいなものを分析してレポートするとかそういう使い方があるみたいです

この中の章で言及されてたSLAの話があってちょっと面白かったんでやや触れるんですけどこれ北浦さんのエピソードでもちょっと触れてたとこなんですがなんか可用性あるじゃないですかこれって9で表すんですよ数字の9で99.99%99.99%あーはいはいはいなんかあれだよね11.9とかなんか

S3は11ないんですよみたいなそうそうそうそう1ヶ月のうちに93分間ダウンタイムがあった場合これって可用性99.7%って言えるんですよただこれって観測するの難しいんですよというのも93分間のダウンタイムあったよねっていうために少なくとも1分間隔でメトリックス取らなきゃいけないんですよなるほど

なのでもっと99.99とか99.99999.99とかになった場合とかはめっちゃ細かくメトリックス取んないとそのSLAって言えないなるほどねもうその1間隔アウトになっただけでもっと減っちゃうみたいな減っちゃうしあとは何なら見逃してるよねっていうそれちゃんと観測できてないよねっていうロジックになるしうん

それゆえ99.9の9の数を増やしていく増やしていくほどコストかかるよねっていうのはあると思うんですけどそれはシステム構成の話もそうですし監視側の作りでもそのコストが上がるんだっていうのはちょっと僕はあんまり知らなくてそうなんだと思ってちょっと本読んでましたえってことは

S3のさっきの11.9とかは正気の沙汰じゃないってことですかいや異常ですよねあれは堅牢性ですけどね堅牢性なのかあれは可用性じゃなかったです確かでも可用性は99.99とかだったかいやそれも結構正気の沙汰じゃないですけどね正気の沙汰ではあるかでも一番すごいぐらいあともっと思うのは99.99ってAWSのマネージドサービスで実現するのめっちゃ難くないかって思いますね

ラムダとかでも99点何パーなんですよ可用性それが直列に繋がるわけじゃないですかラムダとAPIゲートウェイトとかデータベースとそうすると可用性下がるじゃないですか99.99にするにはどうしたらいいのっていうのはまだ難くないって思っちゃいます確かにコンポーネントデータ収集データストレージ可視化分析とレポートときて最後アラートですね

うんうんうんアラートかアラートうんこれ僕の中の最近の関心事なんですけどアラートあそうなのはい何か仕事で辛いことでもあったんですかいや辛いことはないですけどあの今鑑賞ずっと見直し続けてますね今の今うーん

動いてるけどなっちゃうことがあるので直してるみたいなイメージですねこのアラートの部分ちょっと刺さったんでそのまま言うんですけど私は監視の目的を理解しないまま監視の仕組みを構築している人が多いことに気づきましたそういった人たちは何か問題が起きたときにアラートを出すことが監視システムの目的だと信じているのですっていうので

なんかが起きた時にアラートを出すのが監視の目的だと思っている人がいるっていうのはすごい書かれてては確かにありそうって思いつつ監視にはもっと高い目的があります私の友人はこう言ってますっていうので監視は質問を投げかけるためにあるっていうどういうこと?指摘すごい詩人かと思った

監視とはアラートを出すために存在してるんじゃないですと監視はアラートは結果の一つの形っていうだけでこれ本当にいいんですかみたいな質問を投げかけるためだけにあるわけで決して別にグラフとかメトリクス全部をアラートに出す必要はないですよと気づくきっかけだと北浦さんが言ってたメトリクス監視するんじゃなくて定期的に週一でみんなで眺める会しておけば急激な

リソース足んなくなるとか察知できるんじゃないみたいな話してたんですけどその話に近いのかなと思ったりしますねアラートを減らす勘どころというかなるほどね予想してた答えと違ったわ何予想してたの?正しく動くことを保証するためにあるみたいなテストみたいなこと言うのかと思った秒速で対応できるようにするためかと思いました質問を投げかけるためらしいです

秒速でみたいな稼ぐよざわ翼みたいなこと秒で億稼ぐみたいなはいこれ以上が組み合わせ可能な監視というデザインパターンの話ですねこれちょっと一番ボリュームあったんですけどはい組み合わせ可能なようにパーツコンポーネントがデータ収集ストレージ確か分析レポートアラートっていうのがあってそれぞれ監視可能に監視じゃないやえー

組み合わせ可能に作っていくっていう風なだからツールを良しない使い分けるっていう選択肢を持っておくって話かもしれないですねなるほどここの部分だけ入れ替えたりとかもできるようにしとけよみたいなそういうことはいそう結合だなこの後の章に出てくるんですけどサービス作りたての時は既存のSaaSでよくて後々サービスがどんどん大きくなったりとかして

あと可用性が高いのが求められたりするようになるにつれてこの機能足んないなっていうのが出てくるらしいんですよそうなった時に自前の監視ツール作るんですってXとかNetflixとかそういう次元かもしれないですけどそうなった時に入れ替えやすくしとくっていうのが今の話なのかなと本読んでて思いましたなるほど次2個目ユーザー視点での監視ですねおー

これもタイトルの通りなんですけど何を監視するかって話でアンチパターンで動いているかどうかを監視しようみたいな話したと思うんですけどしたんですけどユーザーが気にするのってあくまでアプリケーションとやり取りする部分で動くかなと

いうのを気にしてますなのであるメトリックスが異常値でもそれはユーザーのレスポンスやレスポンスタイムに影響があるでしょうかっていうところこの辺を自問自答しながら監視していきましょうねっていうのが2つ目ユーザー視点の監視でしたなんかこれSREでも同じこと言ってた気がするわはい真理ですねあとは監視をするにしても何でしょうね

メトリックスも大事なんですが一番はユーザーのエントリーポイントっていうんですかUIかもしれないしAPIだったらロードバランサーとかっていうちゃんと入り口から見ましょうねこれが全てじゃないですメトリックス監視するのも大事なんですけどまずはユーザー視点で監視するところから始めましょうというのが2つ目です3つ目作るのではなく買うっていうのでほう

これはですねSaaS使おうと最初車輪の再発明すなよってこと?そうですねSaaS使った方が自前で作るより安いぞという話ですなんなら最初から作ろうとした時に多分作る人って監視システムのスペシャリストじゃないんですよなんでいいやつできないですと

いいやつ作るにはまず一旦使ってみて何が必要かこのアプリで何を見る必要があるかとかどういうことをやる必要があるか運用していく上でどんなフローがあるかみたいなのを確立した後に運用フローって変わるんでリリースした後もその後でいいんじゃない自分で作るならっていうので作るのではなく最初は買いましょうといやそうよな大概SaaSがいいんですが必死が利く限りSaaSを使わない合理的な理由は2つありますと

使わないときの一つ目SaaS監視サービスで機能が足りない場合最初からそれが分かっている場合ただそんなのは稀ですと二つ目セキュリティやコンプレイヤース上の問題でログをそんなSaaSに上げるなんてよろしくないと言われているとき機密性が高いアプリだとそうかもしれないですねちなみに

別にSaaSじゃなくてなんかOSS的なものをサーバーにインストールするケースとかもありますよねこれってそれよりもSaaSがいいよねってそういう比較軸ですかこれってそうですねマジでプレーンで使うんだったらいいと思うんですけど監視ツール作る時もそのOSSを改造して作ると思うんで

OSS改造するよりはSaaS使いましょうねっていう話ですね運用コストとかもかかると思うんだよねただマジでプレイで使うんだったら選択肢になるかもしれないですねこれは本格そう言ってたじゃなくて個人的にでもSaaSでやりたいです

面倒見なきゃいけないやつが一個増えるのはやばすぎますね大変最初5つって言ったんですけど4つでした最後継続的改善ですそれはそうだというアラートは監修は定期的に見直していく継続的に見直していきましょうって話ありますけどGoogleとかって

こんないい監視してこんなことをやることによってGoogleっていうずっと動いてるサービス運用してるぜみたいなことを言うじゃないですかGoogleもGoogleって別にこれは継続的改善の上で成り立ってますと何年もかかってるともっと言うと監視に対する仕組みとか取り組み方って時代によってどんどん変わってきますなんか10年前なかったことはあると思うんでねうん

10年前なんならパブリッククラウドそんなだったと思いますしねちょうど移行期ぐらいかどうだったんだろうな僕新卒で入社したときはほやほやぐらいでしたね多分社内プロジェクトで使う上ではそうなんだ当時はVMウェアとか仮想サーバー

使ってたイメージ僕一社目営業だったもののIT系の会社ではあったのでエンジニアの人たちが定期的にサーバーデータセンターかに行くのを見てましたねそうそうそうそう10年前はそのぐらいだったけど10年経ったら

まるっと変わってるレベルだと思うんでなかなかね10年生き残るシステムもレアなのかもしれないですけど監視していく上ではどんどん仕組み変わるんでね継続して改善していくとなんなら改善できるような形にしておくってことですねうん

これは確かに他と抽象度が違いますね違いますみたいな感じで思ってたデザインパターンじゃなかったんですけど確かになだってこれデザインパターンゴフの方のデザインパターンで言うとさ作った後もちゃんとリファクタリングしろよってパターンが一個あるみたいなそんな感じだよねそうそうそうそうしかも作るのではなく買うに至ってもデザインパターンとかじゃなくてこのライブラリ使えよっていう確かに確かにな

方針だな思ってたのと違うやんけってなったんですけどとはいえ割と監視作る上で設計する上で考えの拠り所みたいなのはふわっとしてたんで面白かったので共有させていただきましたというので以上ですねデザインパターン4つ組み合わせ可能な監視ユーザー視点での監視作るのではなく買う継続的改善全部心構えかもな

まあまあそうですねショーの名前はそうですねこういう風にモニタリングを組み合わせるとなんかうまくいきやすいよとかそういうのじゃないんだね一個も具体的なこと言ってないですからねでもデザインパターンって言ってたんでそうかデザインパターンらしいっすじゃあしょうがないか納得いかない?じゅんぺいや難しいっすね継続的改善って難しいですよね

運用監視してる人の熱量次第なのかなと思っててうんあの今僕24365なんでシステムが24365で電話がかかってくる可能性があるという生活してるんですけどそのプレッシャーがあるとすごい熱量でこれ直しませんかって言ってます周りに深夜に火吹かれても困るしそう火吹かれたらさすがに呼んでほしいんですけどあの

余計な監視項目とかアラートとかで普段の業務が若干圧迫されてるんでうんうんうん早く改善したいってなるほどなんか今のシステムがあるお客さんだとメモリ使用率がだいたい70%前後で推移するんですけどうんうんでアラートを80%と90%で置いてて80%ってたまに行くんですよ70%くらいで推移してるんでうんでこの前

まあアラート出てなんかたまに出るんですよね そのスパイクでパーンと上がる時ですよね80%でそもそもこれあってますみたいなことを言われてそうだよなぁと思うんですよでもなんかそれ以上で結構85% 90%で置くとかってなんかあんまり意味なかったり5%しか違いなかったりなんか

100いく前にはもちろんアラートしっかり出したいけど70%まであるんであんまないんですか予知がってなった時にこれどう改善したらいいんだろうなってそのこと80のアラートやめちゃっていいんじゃないかなとか思うんですけどそれで最近ちょっと問い合わせもらってどうしたもんかなっていう風に悩んでちょっと業務が圧迫されたなっていう思い出が蘇って

改善難しいなっていうこの本にその答えがちょっと書いてるんですけどどっから発想かなまず式位置の話じゃないですか今のって70にするか80にするか式位置の設定の仕方はこれはツールにもよるんですけど何分間の平均みたいな取り方もできるわけじゃないですか5分間

メモリーが100%に張り付いてたらいよいよやばいよねっていう見方にするのかみたいなそこを何に設定するかはマジでアプリによるしチームによるし心配性だったら敷地下げすぎちゃうんですけどただその1点超えた以外の統計的にもいろいろ計算できますしね1日のメモリーが

メモリのうち上位20%のメモリ使用率が70超えてたらみたいな1点だけじゃなくて統計的に計算してメトリクス作るの敷地作るみたいなアプローチもあるんでそういうのを駆使することによって実際にアプリケーションの挙動に影響しそうなメトリクスの監視の仕方できるよねみたいな

ショーがありました確かにそれでいうと1日のうちに4回アラートが鳴ったのかな80%超えたやつ5回っていう平均をもし取ったとしたらその時はアラート発布しなかったですね5回っていう設計にしてたら平均5分間の平均とかなるほどっていうのとあともう1個あるのがこれは動いてるかみたいな話なんですけど例えばCPU使用率100%になったらって

というアラートがあった時にCPU使用率って確か単位時間あたりのCPUを使ってる割合なんですよ100%になってる方といって異常は起きないって言うんですかストレージ100%だと異常が起きるんですけどCPU100%ってただみんなが働いてるだけなんですよ確かにただそれがめっちゃ長時間続いたり頻繁にいくようだったらもちろん

性能面で問題あるのかもしれないですけど一瞬とか一時的に100%いくだけってアプリケーションの動きとしては何の影響もないっていうんですかね全部使ってるだけで処理は進んでてただ他のものは入ってこれないですよっていう状況まあそうかなただ処理ロジックにもよるじゃないですか別にCPU全部使ってなくても他のもの入ってこれないこともあるし本当にでもこれもアプリとハードウェアに詳しくないと

そして周りにも理解してもらえるような説明ができないと設定できないんですけど入門監視の中ではそういう話がありましたね一般的な話でCPUとかってどうなんですかね結構100%で推移するものとかって世の中には割とあったりするんですかそれでもさすがにそれは少なくてだいたい80%とかでとどめさせたりするような

感じだったりするんですか一般的なこと聞きたいですメモリについても一般的にはあんまり100%で張り付くのを許容するシステムないんじゃないですかねなんか処理どんどんスタックしてきそうじゃないなんかずっとそこで張り付いてたらただスパイクする一般的にはスパイクも許容しない人がいると思いますそれはなぜかっていうと怖いから怖いですね100%怖いです心配しなくていいと思いますスパイクなら100%で張り付くとかだったら

危ないかもしれないですねその処理が滞ってるというか詰まってるというかずっと頑張らなきゃいけない状態だと思うんでそうじゃなくて一瞬パーンって上がるぐらいだったら処理しきれてるわけですから確かに気にしなくていいよねっていう判断はあるかなとあるかなというか普通なんじゃないかなと思います80%とかでも別に80

80%に関しても余力があるわけですから例えばそれがもし50%以下とかだったらちょっとスペック高すぎてるからもうちょっとコストを抑えるためにスペック下げたのを使おうかとかっていう話になったりするあんまりコストが課題になったらじゃないですかシステムのメトリックスキーでその話にはなんない気がしますね企画側が売上とかコストを見返した時にインフラ代高くねえかってなった時に確かに

ここ余力あるから削れるかもねっていう会話になる順番な気しますねなるほどなCPUの使用率で言うとそんなになんだろう気にするタイミングってコストも違うなエラーとかそういうのが起きた時に見るぐらいですねエラーとかあとは長時間張り付いてたら気にした方がいい長時間ってか

ずっと張り付いてたらかなるほどメモリーだと同じような答えがいると思いますなるほどありがとうございます最初の頃とか見てたときわかるわかるこんな感じなんだって何も読み取れなかったんですよねめっちゃわかるなんとなくはい感覚がわかりましたただ

エンジニアの一存で決めれないとかあるなと思っててこのMetricsって発注者側というかプロダクトマネージャーというか側が設定する場合はやっぱりCPUちょっとでも100%いったら新たに鳴らした方がいいんじゃないって気持ちになっちゃうじゃないですか確かに

それゆえそういう風になんだろう動いててもアラートが鳴るみたいなことが多いんじゃないかなと思うのでエンジニア側からうまく伝えるっていうのはすごい大事かなと思いましたありがとうございます今後これ2章目の話なんですけどその3章4章5章でどういう話が続いていくかっていうとさっきの統計の話とか統計の章あったりとかここに来て俺の統計2級が生きていると思いながら

ついに伏線回収今やっと分かると思いながらあとアプリケーションとかフロントエンドとかシステム監視こういうことやるべきだよねみたいな深掘りが続いていくような感じで楽しくて読みやすいめっちゃ読みやすいんで全エンジニア監視に関心を持つべきだと前回のアンチパターンのエピソードでも言いましたが今回も繰り返しで読んでくださいっていうのをお伝えしましたなるほど締めます

ハッシュタグひまじんプログラマーでSNSのXフィードバック募集してますので今日のエピソードの感想とかあとは監視周りの本でお勧めありましたらお願いしますシェアを僕らもX監視してるんでぜひハッシュタグつけてお願いします

継続的に見直していきますあとは説明欄からGoogleフォームで番組の要望・感想・質問などもお待ちしてますのでお願いしますお願いします各種ポッドキャスト・プラットフォームでのフォロー・高評価もお待ちしてますのでお願いします人気番組にしてくださいフォロー・いいねお願いしますではまた次回バイバイあなたが落としたのはこの金のサーバーですかそれとも銀のサーバーですか

いいえ私が落としたのは普通のウェブサーバーですすみませんあなたは正直者ですね全部のサーバーをあげましょう正直者のエンジニアは不可分散ができるようになりましたそれを見ていた欲張りな男がサーバーを落としましたあなたが落としたのはこの金のサーバーですか?へいその金のサーバーを落としましたあなたは嘘つきのようです

そう言って女神は帰っていきました欲張りの男は復旧できないサーバーの前でワンワン泣いていましたサーバーを落としたくないあなたへひまじんプログラマーの週末エンジニアリングレッスン