この番組は駆け出しエンジニアの順平と先輩エンジニアの海一篠里が送る駆け出しエンジニアを中級エンジニアにキャリアアップさせるラジオです本日は前回に引き続き北浦さんに運用管理設計で考えることの続き座学編じゃなくて何編でしたっけ実務編って言ったらいいのかな実務編です具体例の方

あの今回の話は皆さんもちょっとキットするような話があるじゃんなぁと思って 磯を生ましい話をしていこうかなと言いますアンチパターン話楽しみ確かにちなみにアンチパターンともう1個大テーマで言うと 改善案改善ああはいお助かりますおいしからより一層運用

周りは良くなるんじゃないかっていうものを思っていますありがとうございますじゃあ早速お願いしますはいじゃあやってしまいがちなアンチパターン今回4選あります最初に4項目話しておくと狼少年アラートというものとツール依存問題あとチェックボックス監視

最後に運用監視設定をメンテナンスしない問題ってこれも4つを話していこうかなと思いますタイトルでキャッチタイトルでキャッチじゃあ早速最初の一つ目なんですけど狼少年アラートっていうものをちょっと紹介しようかなと思います

すごく運用監視を語る上だとすごくメジャーなアンチパターンでしてそうなんですね別名アラート燃え尽き症候群とかアラートのアレとかでも紹介されるものですねこのアンチパターン何かっていうと

前回のりさんが実は話してくれてた通知監視いっぱい仕掛けたいけどって大事なものだけ監視したいとかってくだりがあったと思うんですけど通知が多すぎることで生じる問題でしてこれ監視たくさんいっぱい仕掛けても

実はダメなんですよっていうアンチパターンなんでダメかっていうとまず狼少年アラートっていうその名の通りですねいっぱい通知が来ちゃうと大事な通知を取り延ばしてしまうっていう

問題があって1日100通ぐらいアラートのメール来るんですよねって人に遭遇したことがあるんですが100通の中から例えば1通重大なアラートが潜んでいてもそれ気づかないですよねっていう話100見ないですよね多分凝視しては確かに見ないですよねあとこれ別名も紹介したんですけどアラート燃え尽き症候群っていうのとアラート疲れっていうのも別名として紹介したんですけど

100件来て100件頑張ってみる人もいるんですよへーすご大丈夫です偉い神々にお前これちゃんとアラート確認してるのかちゃんと全部確認してるかって言われてちゃんと前々にしっかり確認してますっていうことをやるとですねアラートを確認してるだけで1日終わってしまって何もできない状態になってしまって

まあそのアラートを燃え尽き証拠感アラート疲れとかって言われますが 負けなどなかはいえっと運用監視の上やる上では一番あの考えなくちゃいけないアンチパターンも一つですと 僕目線で言うとあのてっ

これは絶対避けた方がいいものの一つで僕は結構システム開発とかって運用コストとかってやっぱり見る側面が多いんですけれどもシステム開発において最も貴重かつコストが高いものって

実は人なんですよね。すごくリッチなインスタンスとか建てたとしても、月に100万円とかは請求されるわけないじゃないですか。僕たち人って月単価とかで100万とか150万とか平気でかかるじゃないですか。

重要じゃない数値でそのリソースを使ってるってすごくもったいないことですよねって思うんですよねログ確認にリッチなEC2インスタンス使ってるみたいなすごくいい例えですそういうことですもんね全然もうフリーで使ってくださいドヤ顔ですね

その一番高級なリソースである人っていうものが消費されてしまうだけならまだしもアラート疲れとか燃え尽き症候群とかってなってくると鬱とかモチベーションの低下とかそういったところも引き起こしてしまう可能性があるので絶対に死んでも避けましょうとそういうことで紹介してもらったのがオオカミ少年アラートですねうんうんうん

なんでしょうねアラート系ってスラックでもメールでもそうですけど最初というか慣れないと本当に常にめっちゃ来て誰も見ないみたいないつもなってるなみたいになっちゃいがちだと思うんでいやもうグサーってなってる人

いっぱいいますはいはいはい人間の性質的にどうしようもないですよねいっぱい来たら無視しちゃうのはなんか僕あの今住んでる家が非常に線路沿いなんですね電車の音がめっちゃうるさいんですけどやっぱ半年も住むとその音が全く聞こえなくなるみたいないい例えですねこれだなってこれだな慣れちゃう慣れちゃう慣れちゃいすぎてはい

営業時間だったらまだ許せると思うんですよ深夜とか泣きちゃって電話で叩き起こされて問題ありませんでしたみたいなのが週に3回ぐらい続きますとなっちゃうとこの人結構辛いことになっちゃいますよねとかあると思うんですよ大株少年アラートなんですけどセルフチェック項目も持ってきました診断できるんですね診断できます

まずですねアラート通知を届きましたが問題ないのでクローズしますってことを皆さんやってませんかとまあ

やりまくってるやりまくったそれは良くないですねもう積極的にすごく勇気のいることなんですけど不要な通知っていうのはやっぱり避けていくっていう動きをしていくっていうのがいいと思いますであったりとかやっぱり絶対に監視したいものが本当にそれなのかどうかって振り返ってもらうのがいいかなというふうに思います

アラート通知来たんだが問題ないのでクローズっていうものがもし月に一度でも起きていたらセルフチェックしていくチャンスです皆さん月に一度でもなんですね月に一度でもですアラート通知が来た順に届いたらネクストアクションが定まっているものが一番理想ですねバックでやらないっていうのが一番いいと思います

アラート設計するときにこのアラートになったらこれをやるっていうのを決めつつアラート設計していくのが理想ってことですかそうですねこれがなったらこうするってドキュメントにもしっかり明記されてるのが理想ですねリソースの利用状況とかって気になったりとかするんですよよくありますねCPUとかメモリとかストレージとか

あとソフトリミットが存在する AWSの実行数とか Lambdaの実行数とか例えばデュレーションとか レスポンスタイムとかって 直接的なアラートではないんだけれどもちょっとパフォーマンスの予兆監視的なところを やっていきたいみたいなところの側面あると思うんですけど 椅子のこと アラート監視からは外してしまって

1週間に1回代わりにパフォーマンスの定点観測会みたいなものを開いてみんな開発者で集まって自分たちのアプリケーションが日々どんな感じで動いてるのかっていうのをチェックするっていう動きをしてみるっていうのは大変おすすめですそれはどのぐらいの時間で時間帯に使われてるねとかユーザー数ここから増えるんだらリソース増やさなきゃねみたいな議論をする場みたいなそうですそうです

1週間に1回ぐらいのサイクルで開発者全員が集まってメトリックスっていうものを見ていくと気づけるんですよねあれなんかいつもと違うとか例えばプッシュ通知とかって大きなイベントだと思っててそのシステムにとってはプッシュ通知を受け取ったら一斉にユーザーとアクセスしてきますよね普通これぐらいの上がり幅なんだけどいつもよりも

山から降りていくタイミングが違ったりとか何か違うのかとかプチツチ打ってないところで山になってるけどなんだろうとか

とかっていうのがだんだん分かるようになってきたりとかあとはパフォーマンス定点観測ってずっとやっていくとトラブルシュートも早くなったりとかするっていう側面があるのでただパフォーマンス定点観測界でやっているメトリクスを見に行くっていうのが開発者の動きとして染み付いていればアラートが鳴って壊れてるらしいってなってもどこをボトルネックが追跡するのがすごく楽だったりとかしますよね

先週やったところを見ればいいんだってなると思うのでいっそのことを活動に振り切ってしまうっていうのはいいんじゃないかな個人的には思うんです確かにしかもチームでやることによって新しく入ってきたけどそういう部分よく分かんないですみたいな人にも教育的な意味でもいいですよね多分そうですね

僕が前やってた時はそれこそMobプログラミングってあって一人がドライバーで画面を操作しながら複数人で口だけでここの画面行ってとかここ見てとかってやるっていうスタイルなんですけどそれでやってて割と入ってきた年数が一番新しい人にそのドライバーをお願いすることっていうのが多いんですけどそこで画面操作して

クラウドフロントのレスポンスタイムいつも通りだねとかあれなんかちょっといつもか遅いかなみたいな話をしていくとだんだんその感覚っていうのがチーム内で共有されていくっていうものもあるので確かに記憶っていう観点もいいと思いますねちなみに具体的にどういうのぐらいの時間枠でやってたりしてましたそういうの

これはやろうと思うと無限にできちゃうんで1時間タイムボックス決めてとりあえずバツンとなるほどすごい正直がっつり運用とかやったことなかったんで今まですごく新鮮で面白いなと思って聞いてました

そうですねサービスの行き死にとかがリアルに売上げに直結するような話になってくるとここら辺の動きはとっても大切になってきますね

ちなみにそういうのを見てると例えばサービスの行き地にもそうですけどこの前売ってリリースした試作がちょっといい感じで動いてるなみたいなのとかも出たりするんですかそのメトリックスのところにそうですね例えば大型のプッシュを打ちたいんだけどさこの時間とこの時間でになった時に開発者の中でこれぐらいスケールするものを事前に準備しておけば耐えられるだろうとかっていう肌感を得られたりとかっていうのもしますよねすごい

いいな そのぐらい回ってたらいいなたったの1時間ですから 週にぜひ開発新聞の中で こういったことを活動やってみましょうって提案してみてくださいもう一つ 狼少年アラート狼少年アラートでしたじゃあ次にツール依存問題っていうのを取り上げていきましょうか

ツール依存問題これはですね有識問題でして別名つけたんですけどカーゴカルト思考問題って僕読んでるんですけどカーゴカルト思考?カーゴカルト思考ですね脳死状態っていう話ですねこれ入門監視っていうオライリーの本があるんですよ青いやつ青いやつです青いやつ

この本僕多大に参考にさせてもらってるんですけどその第一章がアンチパターンなんですよ珍しい第一章アンチパターンで第一章の一番最初に紹介されるのはツール依存問題というものでしてそれくらいにちょっと有識問題なんですけどこれ何かっていうとこの本の書いてあることをそのまま引用して読み上げると

業務の前にツールを考えてしまう組織が多すぎるというふうに紹介されているどういうことかというと運用監視っていう文脈でツールっていっぱいあるんですよデータドックとかニューレリックダイナドレススプランクマカレルザビックスとか数えてれないくらいたくさんツールがあるんですけれども

本来の運用監視の目的って先ほど紹介させてもらったんですけどそこに効果のあるツールを選定しなくちゃいけないんですよ本来はなんだけれども先にツールを導入することを考えてしまうっていう問題なんですよね

やっちゃいがちそうですよねやっちゃいがちじゃないですかモダンなやつでやりたいって言ってこれなんか流行ってるっぽいぞでいく感じですよねめちゃくちゃあるめちゃくちゃありますよね例えばAWS使ってる人とかだとデータドックとかって導入してるところとか多いんじゃないかなと思うんですけどなんとなくで入れてないかと

うんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうん

自分たちのやりたいことを叶えられるツールを選定しましょうという話でして例えば僕New Relicっていうツールがすごく好きなんですけどNew RelicっていうツールってAPMの機能がすごく充実したツールなんですよねAPMって?アプリケーションパフォーマンスモニタリングっていう技術なんですけどうん

アプリケーションコードに仕込むんですこの関数のスタートとエンドどれくらいかかったかっていうのをやるっていう技術があって

そこのビューがとても上手に表現してくれるっていうところでNew Relicってツールがすごく好きなんですけどAPMを使って自分たちの最も大事としているアプリケーションロジックがちゃんと動いてるかとかっていうことをやりたいと

だからJulicを導入するのですっていう のがあってほしいなって思うんですよね これ僕 システムコンサルティングとかで よくいろんな会社さんの運用 周りの問題とかって いろいろといろんなプロダクトで参画させて もらったところで言うと 結構ここの問題が見え隠れするところが結構 多くて なんとなく使ってますと 使って

使ってるんだけど その機能使ってる わけでもなく ログ見てるだけですとかだったらCloudWatch Logsでいいん じゃないですかとか やっぱり外部のサービスとかって使っちゃうと そこにまずデータを送らなくちゃいけないので そこで コストかかってしまうし

外部にデータを送ってそこでアカウントを払い出ししてなると そこのアカウントの管理とかもしなくちゃいけないじゃないですかというのでとてもコストが大きいっていう話もあるし セキュリティ的なところの話でいうと不要なデータを外に出してるわけなので そこら辺の管理とかもちゃんとしておかないといけないよねとかっていう考えがあるので

ちゃんと自分たちの使いたい課題を解決できるツールを選定しましょうねっていう話なんですよねこれ一方選挙眼が難しいなってめっちゃ思いますね難しいと思いますよくお勧めしてるのがもし具体的に課題がなくて何のツールを使ったらいいかわからないっていう場合は

AWSだったらクラウドウォッチCCPだったらクラウドモニタリングっていうツールがそもそもクラウドサービスの中で展開しているものがあるのでそこで運用頑張ってみましょうとお勧めしていますそこでもし難しいのであれば難しくてデータドックニューレリックとかって使ってそれが解決できる見込みがあったらそこで導入でも全然遅くないのでうん

まずは自分たちの抱えている課題が何なのかっていうのを見つけて導入するっていうのがいいかなって思ってますなんとなくで導入しないでくださいって言い続けてますそういう運用監視ツールは後から入れる方が大変さは若干増える気もするんですけどでも後からでもそんなにコストめちゃくちゃ増えるわけじゃないよっていう感じなんですかね

なんとなくで入れてしまうくらいであれば後からのコストの方がはるかに安いかなという気がします別のツールで例えば入れていてこれだと解決できないじゃんってなった時にじゃあ別のツールに乗せ替えるっていう方がはるかにコスト高いと思うのでまあ確かにうん

運用監視で何を見たいかって結構経験豊富な人がいないとなかなか難しいところだと思うんで一回シンプルなやつで走った後に考えようねはすごい

ブーブー言っ

をまずはそのなんでしょ自分たちの運用レベルっていうものをどんどん引き上げて いくんだぞっていう気持ちであの取り組んでいただくのがいいのかなと思いますなんかもうこれ運用監視に限らず結構人類がやりがちなパターンなんじゃないかなって めっちゃ思っててそうかもしれないですよ僕は元と営業をやってたんですけどあの営業とかだとその

テレアポするためのリストみたいなやつがあったりするんですね会社でそれにもともとなんか謎のコールリストみたいなのを使ってたんですけどある時そのセールスフォース導入したんですねセールスフォースってめっちゃ機能豊富なんですけど結局なんかテレアポリストとしてしか使われなかったみたいな悲しい過去があったんで

結構いろんなレイヤーで起きてそうだなと思いましたねあるかもしれないですね会社さんになると何か良かれと思ってこれ世の中的に流行ってるらしいとか

その企画としてこのツールを導入するっていうことをバリューとする人っていうのがいるんですよねいいとか悪いとかの話ではないんですけどそういう人たちがやっぱりいる中でじゃあ本当に自分たちのバリューになるものを選定していくんだっていう気持ちがとっても大事だなというふうに思いますね現場の人我々現場の人としてはそこは見失ってはいけないですね見失ってはいけないですね

よく僕が耳にしたフレーズがあって紹介しておくとうちシステムの規模めちゃくちゃ多いから何かのツールを使うんだよねってよくフレーズを僕は耳にしたんですけど仮に言わせるとシステムの規模の大きさはツールと全く関係ないので見失わないでいただくといいのかなというふうに思います何も自分たちのやっている業務がそのツールに適合しているかどうか

こう見ていってもいいかなって思ってますなるほどそれ聞いたら本当かって思えばいいですねその人下がっていって下がっていってたくのとセルフリストクリストありますこれもこれも皆さんの導入している監視ツールが仮にあったとして

これがなぜクラウドウォッチメトリクス クラウドウォッチログス クラウドウォッチシンセティクスとかっていろんな機能がAWSの中ではありますけどクラウドモニタリングでもいいんですがそれでなんで不十分なのか 皆さん説明できますかともし説明できないのであればもしかしたらこのツール依存問題かもしれないよという話ですねうんうんうん

ただとはいえこういった外部サースのモニタリングオブザーバビリティのツールって市場で長く愛されているツールはそれ相応の理由があって愛されてるっていうものがあるのでこれを聞いて無限にツールの導入

なんか変なのしちゃってるなとかっていうのであればやっぱりそのツールの良さっていうのも必ずあるのであれなんかこれなんかいろんな機能あるじゃんとかって改めていただくっていうのはすごくいいきっかけになったらいいなと思って話してました確かに流行ってるからにはなんか強みがありますよね絶対あるはずなのでじゃあ次チェックボックス監視ですね

チェックボックス監視の話をしましょうこれはですね別名監視していないといけない気がする証拠と僕は呼んでるんですけどもあー

入門監視っていう書籍からまた持ってきましたこれを監視してますというための監視システムっていう風に紹介されているんですけれどもよくありますよね何か監査チェックシートとなるものがあってあなたのシステムはこれとこれをちゃんと監視していますかと問われるとかあとは

もともと今クラウドで運用しているシステムすごく多いと思ってるんですけどオンプレミスの考え方とクラウドの考え方ってちょっと違うんですよねオンプレミスの考え方をそのまま引きずってクラウドに持ってくるとこのチェックボックス監視になってしまいがち例えばオンプレミスの場合って

実際に物理サーバーを購入してマシンルームに行ってそのサーバーを設置してやっていたわけですよとそのサーバーは例えばCPU90%使ってますと

なった場合ってこれえらいことなんですよねあのもう10%食いつぶしてしまったら またサーバーを買っサーバーを買ってまた急いでまああのもしでもに設置って設置しないとあのもう100%になってしまうとそのサービス停止してしまうんですよね だからえっとその物理サーバーのリソースを監視するというのはとっても重要なことだったんですよ

じゃあそれクラウドになったらどうかっていうとあの cpu 使用率とかっていうのは別に90%使っていてもワンクリックでスケールしますよねその3万円なので cpu 使用率とかっていうものをそのメトリクスの意味合いがちょっと変わってきたっていうのがあるんですよっていうものがあってえっとそのオンプレ時代のベストプラティクスであった cpu とメモリを監視しましょうというものが今ちょっとゲームチェンジが起きていて

クラウドだと最重要メトリクスであったCPUメモリも今やそんなに気にしなくてもいいものになってるよとかっていうものがあるんですがいまだにやっぱりCPUとメモリを監視してますよねっていうガバナンスは割と多く見かけるなと思っています

あるあるですねあるあるだと思いますこれ僕が運用監視うまくいってないんだけどさっきの狼少年アラートとかも多いんですよねみたいなところで見てみるとやっぱりCPU使用率だったりとか

メモリーっていうのを一生懸命監視してるというものがあったりとかもするのでうまくいってない気がするランキング堂々の1位かなっていう個人的な所感ですそのいい感じの設定をするのがやっぱり難しいっていうのもチームであったとしても会社全体としてガバナンス効かせる上で一定の基準設けるべきだよねっていうのはあると思うんでなんて言うんでしょうね

一括でやっちゃうとどうしてもチェックボックス関係になっちゃうんで

そこの判断はというかいい感じの交渉していくしかないんですかねそれはチームとしてやっぱり僕もよく身を引き締めなくちゃなと思うんですけど監視項目を作ってくれって言われるとするじゃないですかそうするとすごくたくさんこんな監視もしててこんな監視もしててってすごく充実ある資料を作りたくなっちゃいませんかっていう見栄えがいいですよねとってもちゃんとしてる感出ますねちゃんとしてる感が出ちゃうんですよ

ただちゃんとしている感じを出すために監視システムを監視するものではないので監視してますというための監視システムを作るのは避けていきましょうねというアーチパターンですねこれが狼少年アラートにもつながってしまうし運用監視の目的って最初に述べましたがそこにつながらない行動になってしまうのでやめたほうがいいですよっていう話でしたなるほど

僕のとこだとCPUとか僕AzureなんでAzureモニターですかねAzureモニターでアップサービスのCPUとかを監視しててこの前顧客のCPUが80%を超えてバーラートを飛んできてちょっと見に行ってでも別に使えてはいるのでなんかいつもより高いねぐらいの感じなんですよただそれって最近新バージョンをリリースしてからちょっと高くなってるっぽいなっていう風に思って

ってなった時に新バージョンのリリースによって追加された機能のどっかのなんか負荷が上がっているというかそこに新しくデータがいっぱい入ったりしてなんか

CPU上がっちゃってるのかなみたいなところがあってなんかそういうちょっとした気づきとかはあるとは思うんですよねただ一方で前の話だとそのアラートを見て80%超えてるからといって次のアクションが特になかったんですよってなると今の北浦さんの話で言うとこれは不要な監視

うんうんですかねそうですねネクストアクションが存在しない日かもしれないのであのー

勇気を持って取り外してしまうっていうのは全然ありがたい話かなというふうに思いますちょっとした気づきがあったとしても無駄なとまではあれですけどちょっと余分な仕事になっちゃってるなって感じですかねそうですねやっぱりアナウンス受け取った時に親ってなって見に行ってっていうところがあったと思っていてそれは実動に結びつかなかったというかそうですね確かに

でアラーティングって優先度高くどうしても入ってきてしまいますよねタスクとして例えば自分がプログラム書いててっていうところでも強制的にタスクとして割り込まれるじゃないですかってするとやっぱり自分のパフォーマンスも悪化するし

気づきを得られたっていうのは収穫ではあったんですけどユースは高くなくてもいいよねっていうものだと思うんですよ今後ちょっと気をつけとこうかぐらいの感じでなりましたねそうですねであればアラーティングの仕方とか気づきを得るっていうところをどういう風に

もし今後も必要であればどうやってもどういうところどこで検知しようかみたいなところの攻め合いだと思うんですけどねうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんうんンONンONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONNONN

運用監視エンジニアだからこれもセルフチェックリスト的なものを用意してて具体的なアクションの定義がないアラート設定がないかどうかって見ていけばいいかなとさっきの例とかそうですねCPU上がったらどうするかっていう具体的なアクションがない話だと思っててそれはもう勇気を持って消してしまいましょうと

樋口:これでもだいぶ勇気いりますよね 何か大西:勇気いりますね ただCPUのエラーとかだったら 例えば100%に振り切ってエラー出てたらエラー出たよっていう監視がなるはずなんですよなのでそれをアラートの第一発砲として受け取るみたいな感じですね樋口:ワーニングぐらいで受け取るのはちょっと大西:そうですね 具体的にあるものが望ましいですね

近くの川氾濫してるから見に行くおじさんみたいな感じです増水ね氾濫してたら見に行っちゃダメだから増水増えてるぞって言って行って見に行っちゃうあとはあれかもしれないCPUとはまたちょっと違うかもしれないですけど例えばスケーリングが失敗したとか90%でスケーリングがうまく機能してなかったそういったところはアラートにしてもいいと思いますけどねうんうんうん

確かにそれはアクションして自分で直さなきゃいけないからっていうアクションが明確になるからですよねアクションが明確になるのでなんでスケーリングしていないんだろうって見に行くしスケーリングしていない問題を取り除く必要があるのでっていう活動は必要かなと思いますねなるほどですね

でも、これでも、これを消すのは監視設定から削除するのはやっぱりなって言われたら、こうやって僕も話してるわけなので、このリンクをそっと送ってあげて、話してるやつがいたよっていうふうに使われるのであれば幸いかなと思いますね。最高ですね、それ。確かに。

共有された側めちゃめちゃ情報取りづらいですけど何分みたいな動画ですからねでもあの

ここのところってやっぱりどうしても開発者がどうしても説明責任として果たさなくちゃいけないことなので頑張って僕もいろんなステークホルダーに一生懸命説明してなかなか通じなかったってたくさんやってきましたけれどもそれでもめげずに一生懸命説明していくっていうのが大事なことだと思いますというところで最後のアンチパターン紹介しましょうか運用監視設定をメンテナンスしない問題

ですねうんうんうん説明監視設定終わってるから問題ないでしょ諸国軍必要なんですねはいこれは必要ですねなるほどこれはもうよく

そのなんでしょうね業務委託とかでシステムを納品したみたいな時によくやってしまいがちなものなんですけど監視に変更を加えることが想定されていないっていうプロダクトというか組織の方針として監視に変更を加えるものじゃないよねっていう認識でいるという問題でして

ここまで話していただくとすごくイメージはくともですけど運用監視の設定ってすごく変更をかけてくるんですよねどんどん進化によってとしてもそうですしユーザーの動線の変化とかでも監視力っていうのがどんどん変わってきますよね必然的に何を監視にしなくちゃいけないのかっていう監視力も変わってくるはずなので監視の設定っていうのもどんどん変わっていくのが理想というか変わっていくべきなんですよ

なんですけど監視に変更を加えることが想定されていなかったりとかって例えばシステムの構築時に運用監視パッド作ってその人をリニューしちゃいましたどうやって変更をかければいいのか分かりませんみたいなねっていう風になってしまうと本来の運用監視の目的を果たせなくなってしまうんですよねうんうん

なので運用監視っていうものはどんどん洗練させていくものだしどんどん良くしていく自分たちのプロダクトがよりユーザーに使ってもらえるように進化していくっていうことをやりたいんですけどそもそもいじれないとかっていう状態になってしまっている問題ですね

これって前半のエピソードの話ちょっと持ってきてしまうんですけど早く気づいて早く直して故障の頻度を減らそうっていうのに向けて多分監視の荒ととかを改善していくっていう話だと思うんですけどどう改善していくんでしょうね例えばとか具体例とかなんかありますかね

よくある例例えばもう問題が起きちゃった時にじゃあその問題が起きた時に例えば1時間停止してしまったとかでSLOがこのままだとマンスリーで言うと96%ぐらいになってしまいそうですなった場合はじゃあその90上げるために何をしなくちゃいけないのかっていう活動をしていくっていううんうん

動きにつなげていくっていうのが大事かなと思います障害とかが発生したらその辺の改善を検討する営みが走るみたいなイメージなんですかねそうですね

ちなみにあの運用監視力が低すぎて なんかその監視軸ってどういうのがあるかみたいなのがあんまりこう具体的にイメージがないんですけどなんかどういう感じの軸があるんですか 一番イメージしやすいのはさっき言った自分たちのえっとを一歩とも大切にする機能が停止してしまったら

困りますよねどれだけ早く気づいてどれだけボトルネックを解消するためのスピードを上げられるかここの時期でまず考えていただくのがいいのかなって思いますうーん

具体的に言うと 一番分かりやすい のが アプリケーションロードバランサーのhttp/status-500エラーを返しました とか 分かりやすいですよねエラーっていうとサーバーがサイド のエラーなので 何かしら僕たちのシステムが起因することによって エラーを返してるっていう

いうものなのでドアケーラーは必ず仕掛けるように僕はしてたりとかあとは僕コンテナを使うんですけどコンテナのタスク数ゼロになっちゃってるとかわからないとかもうこれも具体的に絶対にユーザーのユーザーのイクスに応答できないので

あとはアプリケーションログで自分たちがロジックとして最も大切なものが何かしらの不調を起こしているアプリケーションログを吐くようにしておいてそのアプリケーションログが出たら

なるほどすごい幅広いというかインフラからアプリケーションまで多岐にわたっていろんな観測軸みたいなのがあるって感じなんですかねそうですねありますねシステムは動いてるんだけどどうしてもここのところのレスポンシビリティはどうしても遅くなったら解消したいとかっていうのもビジネスニーズにとってはあると思って例えばこのさっきのECサイトの例で言うと

カートに入れるっていう動作が5秒以上は絶対に許容できないとか起きてしまうとユーザー離れちゃうそこでとかっていうのがそのシステムにとってはもしかしたら動いているっていう状態かもしれないけれどもビジネスにとってはすごくクリティカルなダメージを与えてるってケースもありますよねっていうので運用解析を仕込んでいくっていうのはっていう動きができるとすごく理想ムーブだなって気がしますねなるほど

ちゃんとレイヤーの切り方合ってるか分かんないですけど運用監視ってめちゃくちゃデブというかオペレーション側の作業と思いつつやっぱりビジネスにめちゃくちゃ効いてくるところだからビジネスに何が重要かビジネスを成功させるのに何が重要かっていうところにかかってくる運用と監視をしていくのが大事なんですねやっぱり

ユーザーのいないサービスって存在しないのでユーザーにとって一番何が嬉しい行動になるのかどうかっていうのをエンジニアリングとして紐付けていくっていうのがすごく運用監視にとどまらずですけども大事なことですよね新機能を追加してくれた方が嬉しいのかそれともSLOが99.9%から99.99%になるのが嬉しいのか

そういったところもやっぱり僕たちも時間っていうものは無限じゃないから限られたリソースで何をしていくのかっていう上手に意思決定していくっていうのが大事ですねなるほど暗示パターンの話はこれで以上ですねはいありがとうございますありがとうございます

これ改善案の話もソフトにいきましょうか軽く触れていきますね改善案まず検知時間を短くしましょうねっていう改善案を持ってきましたこれはただと言うとまず監視対象を見直ししましょうねっていう話です大事じゃないものを監視してないかどうかっていうのとアラーティングの最適化ですね検知サイクルを高頻度にするっていう

大事なものは高頻度に取得する ようにしましょうメトリクスの取得5分から1分にするとか あとはオンコールシフトとか組んでる場合はそれ見直ししていき ましょうねと 誰かに負荷かかってないかとかおだしょー:オンコールシフトは呼び出し みたいな感じですかおだしょー:そうですね クリティカルなものとかだと 夜間とかで電話かけてても直したいっていうものあると思うんですけど

これは誰かに負荷かかってるとかやっちゃうと出れなくなっちゃうので経験談なんですけど僕は割と全員集合で割とやってました全員集合もう新たになったら誰かが当番とかじゃなくて全員集合ってやってました学校の教室今思い出しましたね誰かの物がなくなったら入りの会終わんないみたいな同じかな同じじゃないか

まあでもあのこれは割とハイコストだと思うんですけどあのそれだけビッグイベント として扱われるのであのやっぱり監視でアラートを吸ってないより絞ろうという意識が向きますよね 確かにあのなったらもう絶対壊れてる気持ちで臨むのでこれだけ意識高く全員集合してくれる あの

動きになりやすいかなと思ってます確かに壊れてないのに全員集合したらこんなのやってられるかってなりますよね実際そういうこともあると思うんですけどやってられるかって気持ちになりますよねそしたらこんな監視設定外してしまえってなりますよねなりますねっていうのを狙って全員集合っていうのをやったりしましたけどもっとは結構それでよかったなと思ってます

面白いこれは半分ネタですけどオンコール対応があったら次の日は打ち上げとかね頑張ったって言って打ち上げ酒飲みに行きましょうというやつですね酒じゃなくてもいいですけどちょっとした褒美があったらそれがちょっときっかけでモチベーションになったりとかもするので用意しとくと嬉しいっていうケースもあるじゃないですか次の日打ち上げだから頑張るぞみたいな感じのアイスブレイクが冷めたりとかもするからいいかなと

オンコールで全員集合して解決したら即みんなでその場でビールだいぶゆるいな会社がそれ一部負担してくれたりとかしたらもう最高いいっすねいいっすね

経営やってる方いたらぜひ検討してあげてください確かに福利厚生会社のBLサーバーいいですねあと復旧時間の短縮ですねっていうところのアプリ案としてはオンコール対応の話にもつながるんですけど最近インシデントコマンダーっていう主砲ですかね戦略ですかね

っていうのが最近流行っているところで障害対応っていうところの旗振り役をやっていきましょうねとかっていう話でしてそういう人を立てたりとかっていう制度を採用してみるとかちょっと話しながらなくなっちゃうので紹介しておきますねあとは障害訓練じゃないですけどインシデントレスポンス訓練やってみて障害を一通り起きたときの普及までのイメージを持ってもらうとか

おだしょー:それは前半であった Googleのデータセンター止めるみたいなやつですか?おだしょー:どっちかっていうと人寄りですけどね こっちは あとはPlaybook整備しましょうね 一つ前のバージョンへのフォールバック手順ぐらいは整備しとくといいかなというふうに思います 回ったときは一つ前のバージョンに戻そうって すぐ戻せるっていう気持ちでいるとそれだけでも全然復旧時間って短縮できると思います

そうですよねなんか染みてますね復旧切り戻し手順小作成とかって後手に回りがちですからねそうなんだ

絶対に信頼性の高い手順があるだけで 気持ちとしては楽になりますよねあとはダッシュボード整備しましょうとかちょっとだけ紹介したAPM導入しましょうねとかそういったところをやっていくと 復旧時間というのが早くなりますよという話ですねあとは稼働時間を 定常な時間を長くしていきましょうというところの改善なんですけど

このところに関してはポストモーティングの再発防止アクションを実装していきましょうね障害があったときに振り返りですね簡単に言うと振り返りをして再発防止アクションを実装するということをやっていきましょうとかあと過去に何があったのかっていうのを臨読回しておくとためになることが多いですよと臨読回自社で蓄えられた秘伝の

自己主義みたいなやつですかそうですそのプロダクトで起きた過去の事例ですねうーんっていうのを見ていくとプログラムってなんかあのいろんなところで障害が起きないですよねバグりやすい箇所っていうのがあるんですよ

ブーブー言っにょんっ 気をつけって気持ちになったりするんでポスポンってもリンドック会とかってして地形を高いってくる ok

あとはもういっそのことアーキテクチャ見直ししちゃったりとかリリースはビッグバンリリースじゃなくて細かいリリースに分割しましょうとかあとはデプロイがもし自動化していないものがあるんだったらデプロイ方式最適化していきましょうねみたいなこの方式を見るといかがかなというところでさらっと改善案のところご紹介させていただきましたありがとうございますありがとうございます

いやーなんかなんて言うんでしょう聞いててすごい分かりやすくお話ししていただいてるんで言ってることはすごい分かるんですけどやる若田氏って感じです確かにそうですおっしゃる通りですもう泥水すりながら頑張ってます僕もいやいやいやなんかすごいやっぱり運用監視って奥深いなって言う言葉で言うとそれとすんげー簡単なんですけど稼働させるためには

こういうことをやるべきでそのために具体で何するかっていうのはやっぱめちゃくちゃ難しかったり何が大事かっていうのはまあすごい何でしょうねいろんな知見がいるなと思ってたりするんでまあそういうのをねやっぱ会社の中に詳しい人がいるかましくは実践地で蓄えていくか外部の詳しい人に頼ってみるかとかっていうのをやっていくんですかね多分そうですね困ったら北浦さんのXに

DMを送ると相談に乗ってもらえるという噂をはい

あの軽い壁打ちに付き合ってほしいとかでも全然いいですし僕も何よりあの 精進する身なのでいろんな事例とか聞かせてもらってこうかなとかあのディスカッションできたら嬉しく思います 交渉すぎますね活動が本当にやっぱりなんか現場で得られるものがやっぱり一番多いな 印象ではありましたうん

いろんなセッション聞きに行ったりとかももちろんするんですけど何より一番強いものはやっぱり現場で培う知識だと思っているのでめっちゃその手があったかってすごい思いました実践というか現場で得る知見が一番深いというか立体感がある知見を得られるじゃないですかそうですね相談を受けるとそういうのが確かに情報として得られるんですねなるほど

分かってるんだけど解消できないとかっていうものもあるじゃないですかそんなものばっかりだと思うんですよそれをどうやって解消していくのかっていう割とエンジニアとしての腕の見せ所かなって思ってますねありがとうございますではちょっと今日のお話を軽くまとめていただいていいですか

僕からはアンチパターン4選と改善案について紹介させてもらいましたまずアンチパターンのところが狼少年アラートとツール依存問題そしてチェックボックス監視と運用監視設定をメッセージしない問題ということでセルフチェックの提案をさせてもらったのでぜひ聞き返していただいて何か得られるものになっていただいたらいいかなと思いますあと改善案ですねこれは

運用開始の目的として紹介した検知時間と復旧時間、成長時間をいかに長くするかというところなんですけど、それをより良くしていくために何をしたらいいのかというところを紹介させていただきました。ぜひ参考にしていただければいいなと思います。ありがとうございます。ありがとうございます。すごいサービス運用しているチームの方はグサグサくる内容だったと思うので。はい。

そうですね頑張って改善していきましょう皆さん頑張りましょうめちゃくちゃなりました北浦さん最後に何か制限とかあれば

ちょっと先もしていただいたかもしれませんがお願いします一部でもまた同じことを話したんですけどもKDDI Agile開発センターではですね一緒に働ける仲間を大募集してますのでぜひ興味がある方はご応募いただければなというふうに思いますというのとあと最近僕個人でKDDI Agile開発センターとしてスポットコンサルティングのサービスを始めましたと

僕の専門がDevOps Observabilityといった分野なのでそこら辺のお悩みを抱えている方はお気軽にDMいただければなと思います簡単な相談であれば無償でお受けしますので本当に軽い気持ちでDMいただければなと思いますありがとうございますリンクを説明欄に載せておきます

はいでは最後に改めて北浦さん本日はありがとうございましたありがとうございましたものすごく勉強になりましたまたぜひ遊びに来ていただけるとものすごく喜びます僕も話してすごく楽しかったですありがとうございますでは最後にお知らせですハッシュタグひまじんプログラマーでSNSでフィードバック募集してますので運用監視のアンチパターン引っかかってるよとか

悩みとかありましたらシェアもしくはもうハッシュタグで今日のエピソードの感想とかありましたらみんな喜ぶんでぜひお願いしますお願いしますあとはGoogleフォームで番組へのお手入れ要望感想質問何でもお待ちしてますのでお願いいたします最後に各種ポッドキャストプラットフォームでのフォロー高評価もお待ちしてますこちらもお気軽にお願いいたしますお願いしますではまた会社のすごい人呼んでこうやって頑張ってきますすみませんありがとうございますやれるかやれないか分かりませんが

ではまた次回バイバイ