この番組は駆け出しエンジニアの順平と先輩エンジニアの海地篠里が送る駆け出しエンジニアを中級エンジニアにキャリアアップさせるラジオですということで本日平日の夜撮ってますけど珍しく珍しいですね今日なんですが僕らが全然喋れない分野ほう

運用監視設計っていう断面でですね僕の会社の僕今KDDIアジャイル開発センターという会社で実は働いてるんですけど転職エピソードとか上げてましたからその会社にいるですねすごい人詳しい人呼んじゃいましたありがたいです開発センターから開発センターから

その略し方違うけどねすいません多分ねはいなのでちょっとその詳しい人を呼んで運用監視席についてちょっと学んでみて普段の業務に活かしていこうっていうエピソードになってますはいぜひぜひ

はいというのでちょっと早速呼び ます北浦さんです自己紹介をお願いしますはいすごい人という枠でお呼び いただきましてありがとうございますすごく緊張しておりますが北浦と申します 海木さんと同じくktd.agile開発センターで勤めてましてロールはですねreadsreという枠でやらせていただ いてます普段プロダクト開発でフロントエンドの開発とかして たりとかはするんですが

僕の専門がDevOpsであったりとかオブザーワビリティであったりとかするのでそこら辺の困りごとを家具 弊社は家具と呼びますが家具の開発チーム全般でも困りごとがあったらそこのサポートをするよとかそういった立ち回りをしています

主なアクティビティなんですけど僕はコミュニティの上好きでJawsUGというJapan AWS User Groupというコミュニティがあるんですけどもコンテナ支部であったりサーレ支部というところのコミュニティをしたりとかしますこんなところでどうでしょうかすごいちょっとわからないぐらいすごいんですけどわかりやすくすごいよねそうなんですねちなみになんでカグなんですか

ブーブーグループはグループでしょ 違うじゃねえと a dj アジャイル者じゃいるのさあページ a g でえらしいですあそこなんですね なんだなぁなんで g なんだろうと思ってからそうなんですよね僕もことか聞かれるたびに何だったっけなと思うんですよね 僕今初めて何だったっけなってなりました

そうなんですよコミュニティめっちゃ運営してたりとか実はアメリカ帰りですよねそうなんですよリインベントっていうイベントがあってラスベガスで1週間がっつりと勉強してきて戻ってきたところですカジノとかは行きましたかカジノやりましたよいいですねポーカーですねいいな

行ってみたいですね僕らもいや本当ですよ暇プロとして暇プロとしていつか参加できる日を目指してるんでいいんじゃないですかラスディガス現地配信してますとかでどっちYouTuberのライブみたいなそういうとこ目指せればとどうなんだろうめっちゃ金かかりそうだけどまあいいやはいっていうのでじゃあちょっと以前北野さんにはあの

とあるイベントでお話ししてた内容をちょっとお話ししていただく感じになるので僕らはワイワイしながらなおかつちょっと分かりやすくなるように頑張って質問しながらお勉強しましょうはいどんな内容なんですかちなみに今日はですね運用監視設計をするときに考えることっていうテーマで僕が題材持ってきました運用監視設計

結構ノータッチ領域ですね実はそこに触れないでキャリアアップしちゃうエンジニアいるんじゃないかなちょっと思うんですよね最初からできてるケースが多くてそうじゃないなんか最近若干そっち踏み始めました踏み入り始めましたなんですかね今まで全然なかったんですけどそこを学べると嬉しいですね

ありがとうございますじゃあもう早速お願いしちゃっていいですかはいじゃあ話していきましょうか今回話す内容なんですけど一応ちょっと大枠教育しておくと

まずちょっと前半は打学ですねシステム開発の残念な原理原則っていうところがありまして カバーのテーマで話していくっていうのとあとちょっと運用監視って目的ちゃんとしっかりあるんですけども その目的ってなんだっけっていうのがちょっと一回足並みを揃えて共有していきましょうと

いう話をして後半が8割と結構 実務よりの話をしようと思って最初アンチパターンから紹介してもかなとうんうんうんうんうん アンチパターンが一番響きますから確かになんて言ったって多分やっちゃってませんやっちゃってます

アンチパターンを紹介してばかりでもあれなので 最後にこんな感じで改善していくといいよっていう改善案もありましたっていうこの4つの話をですね 展開していこうかなと思ってますお願いしますよろしくお願いしますありがとうございます最初にシステム開発の残念な原理原則っていう話をしようと思ってまして これあのー

僕が運用監視とか監視じゃなくてもシステムの運用っていうものを考えるときに一番念頭に置くといいますか僕らのこんなことと戦ってるよねっていうものがあると思っていてちょっとそれを最初に紹介しようと思ってるんですけども残念な原理原則3つありますまず1つがシステムは何もしなければ壊れます何もしないと壊れてしまいます

で、あともう一つが、何かしても壊れます。ほぉ。もう道塞がれましたよ。もうこの時点で膝から崩れ落ちそうになると思うんですけど。最後に、3つ目が壊さないように努力しすぎると何もできない。

じゃあ何もダメだな何もできないですね押さないように努力すぎると何もできないしかし努力を応えると今度は使ってもらえないっていうこの3つを3本立てで最初に紹介していこうかな引きがすごい全部全部気になるじゃあまず何もしなければ壊れるっていう話です

なんですけどあのこれ皆さんのシステム開発しててなんか突然動かなくなったってありませんかありますねはい急に何もしてないのに壊れたって経験あると思うんですけどこれなんで壊れるのかっていう話でしてこれ一例なんですけど僕たちがアプリケーションを開発してリリースしてじゃあそれ元気に動いてますよっていうそのアプリケーションってあの

そのアプリケーションの全コードベースに占めるOSSのコードの割合っていうのが大体77%前後って言われてるんですよなるほど結構多いって感じますよね僕たちも一生懸命アプリケーションコード書いてると思うんですけど全体の20数パーセントに過ぎないと

これは70%ぐらいで動いてるよと例えば OSとか乗っけて 例えばLinuxで動かしてますってなったらLinuxのコードがありますし例えばプログラミング言語で言うとGoとかって書くとGoっていうプログラミングの中で 実装されてるコードもありますよねOSSを使おうってなったら そのOSSを使ったコードっていうのももちろんあると思いますよと確かにフレームワークとかライブラリとか その辺もってことですよねそうです そうです

っていうのがあると思っていてだから僕たちが動いている全体を俯瞰するとそれぐらいの割合なんですよねOSSの行動の割合っていうのはすごく多いんですよと思って

じゃあその中で何もしなければ壊れるっていうのは何で起きるのかっていうとOSSのフォードが割と進化するんですよねどうしても例えば脆弱性ってありますよね脆弱性って必ず時が経つと見つかってしまうものでして例えば何かのこういうモジュールを提供していたけれどもこれは脆弱になりましたとか

あった時ってそのOSSのメンテナーの人はその脆弱性を負担こうとしますよねそうするとじゃあこの提供していたメソッドは脆弱であるからこれはこのメソッド提供するのやめようとかってなるとそれを利用していた僕たちはそのメソッドに依存したアプリケーションポードを書いてると動かなくなったりとかしますよね

あともう一つの側面としてはアプリケーションって一時にすごくコストがかかるんですよねOSSがOSSを使ってるってこともあるわけですよ

脆弱性の対応とかで動かなくなってしまったシステムっていうのは必ずメンテナンスしなくちゃいけませんよねとメンテナンスするってことは人が介入しなくちゃいけませんよねとすると困ったことにメンテナンスする人いなくなっちゃいましたとかすると動かなくなったアプリケーションコードがずっとOSSとして提供されていてそれがまた動かなくなる原因になったりとかしますよね

これまだまだ全然一例でして これは複数ことが不可能なぐらいっぱいあるんですけど 例えば クラウドサービス利用してたりとかしますか AWSとかGCPとかおだしょー:AWS使ってます三宅:AWS使ってますか AWSでいうと 最近Cloud9っていうサービスが突如サービス終了してしまいましたが

そうなんですよっていうこともあってやっぱりクラウドサービスの事業者もお金をかけてサービスのメンテナンスっていうのをしているのでビジネス的な側面でサービスが突如終了してしまうことも全然多いにあり得るんですよねっていうところで何もしなければ壊れてしまうっていう恐ろしい原理的なことがありますよっていう話でしたちなみにちょっと遡って質問したいところがあるんですけど

脆弱性って必ず見つかるものですよねみたいなのがちょっと前半部分にあったと思うんですけどそれはなんかあれですか周りが変わったことによって脆弱性になったよみたいなケースを指してるみたいな感じですかそれとも

世の中に完璧なものなんてないんだからきっといつかは脆弱性出てくるだろうみたいなそういう感じですかどちらかというと後者だと思っていてもともと安全だったコードっていうのがいろんな技術の発展によって安全ではなくなるっていうケースがあるんですよねなるほど暗号化とかが例えば昔は計算できない量だったけど今はできるようになってしまったとかそうですね

あとはいろんなOSSも利用しやすいようにっていろんな開始を加えているんですけどそこでバックドアが見つかってしまったとかですねというのもやっぱり機能開始をしていく上で見つかってしまう脆弱性とか大きいところで言うとログ4Jとかって大きいところであったと思うんですけどあれとかもそうですねバックドアが見つかってしまったっていう脆弱性だったと思うんですけど

なるほどありがとうございますこの調子で次いきましょうか何かしても壊れるって話ですね何もしなければ壊れるし何かしても壊れるんですって話してこれデプロイ皆さん開発者ですよねデプロイした瞬間に壊れたことはありませんかっていうもう

もうしょっちゅうありますよ言っていいのかあれですけど僕自身もしょっちゅう壊してしまうことでしてといっても本番環境にデプロイするまでに何回か壊れるのを確認できるポイントがあって

なんとか本番環境までには再現せずにっていうことが多いんですけどそれでもやっぱり本番環境までデブロしてしまって壊れてしまうってこともありますよねっていう話でしてこれはもうもともとというかかなり一般的な考え方になってきたのかなっていうのが僕の所感としてありまして

最近の書籍から引用したんですけどエレガントパズルっていう書籍があるんですエンジニアのマネジメントという難問にあなたはどう立ち向かうのかみたいな紹介されている本なんですけどその本から一例で紹介すると障害のほとんどはデプロによって引き起こされますと

したがってデプロイが増えると障害が増え 結果としてインシデント管理軽減策ポストモーティングが必要になりますよって紹介されてるんですよね結構割とこのエレガントパズルのように 書籍の中でもエンジニアリングっていう文脈の中でデプロイっていうものはやっぱりそれだけの慎重な作業に使われてると

その努力を怠ってしまうとやっぱり壊れてしまうしどんなに努力を重ねてもでもやっぱり壊れてしまうっていう残念な原理原則があるという見方もあるのかなと思ってるんですよねこれもどんなにチェックしても本番環境で発言してしまう事象は存在するのがやっぱりキーになってるのかなと思って検証環境って皆さん立てますか

例えばはいで職業でどんなに頑張ってもやっぱり本番環境であの再現してしまう バグってあると思っていいああああああやっぱりあのなんでしょうね本環境と同等の8 ユーザーのリクエストだったりとかユーザー同性みたいなところを完全に再現しきるのってやっぱりいくら時間があっても不可能だっていう そういう壁があると思っている

ですしやっぱり検証環境っていうと構成自体がそもそも本番かけどちょっと違ったりとかっていうケースも十分としてあるでしょうしっていうぐらい難しい話だなというところなんですよノリさんもこの前長時間かけて発生するバグがあったりとかそういうのなかなか分かんないですよね思いもよらぬユーザーの行動とか

過去のデータのせいでみたいなのとかデータのパターンによっても起きるのもあるなって感じますねそうなんですよ何かしても壊れるっていうところの宿命はずっと隙間とうものでして

AWSさんとかかなりSLAとして99.99%みたいな可用性を持っているサービスとかあると思うんですけどもう並々ならぬ努力を重ねているっていうエピソードとかもあったりとかしてめちゃくちゃ有名なところで言うとGoogleさんとかはこの可用性を保つためにデータセンター一つ潰すらしいんですよ

データセンター一つ潰したとしても動くよね確認をするために爆発するんですか?うまいことだよもう使えなくするとちゃんとサービスが動くよねって確認をすると

いうくらいに何かしても壊れるっていうことを防ぐっていう努力をし続けてるっていうのがグローバルのサービスで使われてるサービスが一生懸命頑張ってることこんな避難訓練みたいな感じで

すごー カオスエンジニアリングっていう文脈の技術もありますけど あるところもそうですねステージング環境とかで 擬似的に例えばデータベースがバーンと切れても自分たちの想定の通りにアプリケーションが動くとか

確認するためにわざと壊したり、何かしたりとかして、本番環境が上手に動くんですっていう安心感を勝ち取ると。するくらいに、どうしても何かしら壊れちゃうんですよね。残念な原理原則その2でした。救ってくれって感じですね。何もしなければ壊れるし、何かしても壊れると。

まあでもしないでする効果よりやってする後悔ですよねそうです もう一つも進むしかないので間違いない最後に交わさないように努力すぎると何もできないしかし努力を怠ると使ってもらえないっていう これも残念な原理原則の話最後なんですけど

いつも僕この説明をするときにエクササイズしてるんですよちょっとせっかくなのでやってみてもらおうかなと思ってるんですがちょっと想像してくださいとあなたは仕事で膨大な量のタスクを今管理してますとそれを同時にさばかなくちゃいけないのがあなたの責務です会社から用意されたアプリケーションがありますこれを使ってどうにかしなさいと

一つアプリケーションがあります どっち使えますかっていう話なんですけどまず一つ目のアプリがTODOの管理ソフトで どっちもTODO管理ソフトなんですけど一つ目のアプリがタスクの登録と削除の機能 これしかないけれども絶対に期待したとおりの動作ができますと 可用性100%ですと

もう一つのアプリが僕Notionっていうアプリが好きなんですけどNotionのように魅力的な機能をたくさん備えてますとすごく便利な機能がたくさんあるんですけれども3回に1回くらいの頻度で操作が失敗します多いですね恐ろしいですねなるほどじゃあどっち使いますかっていうエクササイズをしててこれ正解はないので安心していいんですけどどっち使いますか僕からいいですか

僕多分あの2使い始めてイライラして1に切り替えて文句言いながら1を使いまくりますねそれはあるかもしれないまあ1ですねまあ1使っちゃいますよね絶対に期待してると総理の操作がしたいですかやっぱ100%って言われるとちょっと魅力的ですね3回で1回は多いですね15回で1回は多いですけどね15回で1回は多いですけどね

僕もじゅんぺいとのりさんと同じですね多分失敗するやつはなんかうわーせっかく作ったのにって言って消えるタスクとかノーションぐらいのボリュームで書いて吹き飛んだ時はイライラがやばそうですねやばそう泣いちゃうかもしれないですよねありがとうございますこれ選んでいただいたっていう過程が大事でしてどっちが正解ってならいいんですが

これ可用性と機能性のトレードオフを体験いただいたんですよこれって言ってしまうとどちらも市場では選ばれることがないんですよねすごく考えていた時にどっちも嫌だなって思いませんでした確かに

思いましたCで選ぶならって感じでしたねおそらくこっちどっちか使っていいよって言われてもどっちも使わないんじゃないかなって思うんですよねメモ使ったりするかもしれない絵のアプリってタスクの登録と削除の機能しかないのでメモの方がいいとも言えますよね

なんでこのエクササイズをしてもらったかっていうとこれ冒頭覚えてますかこの原理原則を壊さないように努力すぎると何もできないしかし努力を怠ると使ってもらえないっていう話につながるんですけれどもこれすごく極端にした例なんですけど僕いろんなシステム開発をしていく中でどっちかに考えが寄ってるっていうことが多いんですよ

壊さないように壊さないようにってすごく頑張ってしまうがために機能性が欠如してしまうあるいはよっしゃいけいけどんどんだっていっていろんな機能開発するんだけれども今度は可用性が欠如してしまうという話でしてこれどうしてもトレードオフになってしまうよねっていう話なんですよね

これなんですけど この原則の中で大事なこともありまして例えば 可用性ってサービスレベルオブジェクティブとかSLOとかって呼ばれて この目標で頑張りましょうとかって動きをすると思うんですけどSLOを上げていきましょうってなったときに 気をつけなくちゃいけないのが例えば99%のSLOで頑張りますとか

なので 100回に1回失敗することを 許容しますっていう目標ですね100回に1回失敗しますっていうことは 許容しますというレベルであればやりますとしたときに もうちょっと サービスレベル上げましょうと99.9パーセントにしますと なので 1000回に1回の確率で失敗することを許容します

上げましたと次に99.99%に上げましょうとした時に次1万回に1回失敗を許容するっていう話になるんですけどその時に99.9%にかかったコストの10倍かかるよって言われてるんですよね一般の

うーん いやその q を1個追加するたびにあのその努力の10倍のコストかかるとほう どんどん大変になるわけですねで僕あのリード sre 方だけじゃないですか エサが類ってあのいろいろと何してるんですかってよく聞かれるんですけれどもまさにこのトレードオフをサービスでベルっていう

目標をキーにして 可用性を上げて いきましょうであったりとか やっていきましょうっていうのを上手にジャッジするっていう プラティクスがSREというものでしておだしょー:エラーバジェットみたいな 中村:そうです エラーバジェットですねおだしょー:本で読んだやつやりました 中村:やりましたね 最近

エラーバジェットっていう単語が出たのでちょっと紹介するんですけど僕エラーバジェットっていうものがすごく好きで多分トモや北浦で検索すると多分一番最初にヒットするのがSREマガジンっていう記事で僕エラーバジェットについて話しているのでよかったら見てみてくださいリンクに貼っておきましょうよろしくお願いしますはい貼っておきます

ここまでがシステム開発の残念な原理原則ですね運用監視によらず運用っていうものを考えるときにここを念頭に置きながら戦っていくというものですねなるほど ちなみにちょっと横道にそれる系の質問なんですけどSLOってあったじゃないですか基本情報とかやるとSLAみたいなサービスレベルアグリーメントみたいなやつも出てくると思うんですけどこれ単語似てるけど別物ですか?

全く別物です全く別物はい 全く別物ですSLAはお客さんに対して提示するやつみたいな感じですかそうですね 毎回SLAとSLOの話をするときによく話すのがSLAっていうのは営業活動みたいなものですSLAのそもそもSLAを設定しましょうっていうところのモチベーションってどういうものかっていうと

僕たちが提供しているこのサービスがありますと僕たちはこのサービスにおいてこれだけの品質を提供しますので使ってくださいっていうアピールとして使うものがSLAなんですよ例えばSaaSのサービスでAPIを提供してて

なったときに利用者からしたら一番気になるのってこのサービス使ったときに落ちないかどうかってすごく気にしますよねそのときにSLAっていうものは制定されていて例えば99.9%のSLAを持っていますよとそれ以上の障害が起きた場合は返金いたしますというふうなものが

もし存在するのであれば安心して使ったりとかしますよねだからSLAっていうものは先に信頼の前借りですとほう

例えば SIR であったら別の使い道もあると思ってて例えば納品しますよとシステムをというときに SLA っていうものがあって僕たちが納品するこのシステムは可用性99.9%で納品いたしますなので信頼できるものですよっていうのでクライアントから契約をいただくとかこういうもので使われるのが SLA です

ちょっと保険っぽいですねそうです保険ですねSLOっていうのはSLOの話ありますか大丈夫ですか納得しましたSLOっていうのは何かっていうとこれもう全くの別物で開発チームが目標とするものなんですよね

8分というよりかはそのプロダクト全体が目標とするものですね このプロダクトにおいてはこれぐらいの信頼性があったらユーザーが使ってくれるだろうと いう期待値で一番いいものを狙っていくのがでせるんですね

例えばその何でしょうね使っているサービスで じゃあECサイトを使う運営していたとして例えばカートに入れるっていう動作が動作しなかったら もうイライラしますよねすごくっていうのでそのカートに入れるっていう動作は 信頼値が高ければ高いほどそのユーザーに使ってもらう確率が上がるわけですよ

でじゃあそれはじゃああげましょうとか 一方で例えばなんかそのすごくエッチな8サービスでなんか自分のプロフィールが編集できますよっていうところは例えばのそれはあの100回に1回ぐらいの失敗でもユーザーって許してくれたりしますよね うんでそのサービスのほとんどってあの

自分たちが自分たちの提供しているサービスがどの機能がユーザーに一番使ってもらってるんだろうって大体把握してるものだと思うんですよだからそこの組み合わせでこのAPIとこのAPIとこのAPIは呼べるよね100回に1回ぐらい99.9%の確率で成功するよねっていう風にしたいとかそのユーザーの獲得に貢献するのですとか

っていうのを決めていくのがSLOっていう考えですねなるほどここの話すごく長くなりますよSLIとか登場させるともうそれだけでSLIまさか全部の名前があるんですかSLなんちゃらシリーズそうですねSLI SLOが主なキーメトリックスですね

インジケーターの愛ですかそうですねインジケーターの組み合わせでSLOが作られるっていうチャンクしてるみたいな感じなんですかねそうですねSLI例えばECサイトの例で言うと最初にユーザーってまず商品を検索するじゃないですか

検索するっていうAPIが存在するとして次に商品の詳細ページを見る

詳細ページを見るときに呼ばれる APIっていうものもありますよねとカートに入れますと で 決済しますと 検索 詳細 カートに入れる 決済って4つ出てきたと思うんですけど これぞれが全て成功するっていうのを一つのユーザージャーニーとして SLOっていうものを設定していくっていう感じですねなるほど なるほど

だからユーザーが商品を買ってもらうまでっていうのがその機能の一番クリティカルユーザーチャーニングです一番大事な動線ですよとそしたらその機能って一番守りたい守りたい

だからそのSLOっていうのを組んでその目標値を持ってシステム開発をしていくっていうというのがSREっていうものの考え方の一つですねなるほどシナリオテストの1ケース分を担保してるのがSLOみたいなそんなイメージですかそうですねそのイメージもいいと思いますユーザージャーニーって言うんですねなんかいいですねこれ一般的ですか

ユーザージャン結構アジャイルとかの文脈でもユーザージャニーズ登場するようになったなぁ と思っててユーザー当選とかでもいいと思いますかそうなんですねユーザーストーリーとかっていうことが多かったかもしれないですけどちょっと使ってこう知ってるかね知ってるかねエラーバージョンとかエラーバージョンとかはい

昨日学んだことを明日そのまま言うやつ我が物顔でちょっとつかまれるとあんまり説明できないそれが勉強のきっかけになりますねちょっと話されましたかっこいい単語が出てくるとねやっぱり僕結構かっこいいフレーズとか覚えてそれをモチベーションにできるタイプなのでぜひアドバイスいただければいいかなと使ってきます聞いてる方もぜひはい

とりあえずだいぶ重かったですねここだけでも結構まだ4つ分野ある1つですよねなかなかですね運用監視の目的の話をしていきましょうかちょっと聞いてみたいんですけれども運用監視っていう文脈で何がどうなってたら成功してると言えるのでしょうかってこれのリスナーの方も一緒に考えてもらいたいですけどどうでしょうか運用監視の成功とは

順平のターンかないや来てますねこれ結構難しいと思うんですよね聞かれるとそれっぽいものは多分頭の中で浮かぶんじゃないのかなと思うんですけどそれが汎用性のある答えだろうかってちょっと気にしませんでしたか

気にしますちょっとじゃあ駆け出し運用監視エンジニアとしていいですかそうなの踏み入れ始めたんだようわぁなんかまとめられないですけど何でもかんでも監視するわけでは監視すればいいわけではなくて監視したいところだけ監視したいんですけど

なんて言えばいいんだろうなあーくそれあのさえとあれですね 今の話あおっしゃっていた通りの話であっててあのこれを背後で詳しく話そうと思います もういいすぎないようにしてくださいねええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええええ ー ー 中�半パな回答でしたでこれ僕なりの答えで話すと結論ですねあの

その前にこれ指標があるんですよね運用監視に関してはアメリアビリティメトリックスって呼ばれているものでこれ考え方がたくさんあるんですけれども今回ちょっとAWSさんの出してるホワイトペーパーから引用してきた考え方なんですけどちょっと専門用語が並びますMTDってやつとMTDRとMTBFって3つのメトリックスがありまして

簡単に話すとMTTっていうのが検出するまでの時間ですなんかバグりましたなった時に僕たち開発者あるいはシステムがそれを検出するっていうまでの時間がありますうんうん

次にMTTRっていうものがあって これは平均の復旧時間ですね障害が起きましたってなってから 実際に回復できるまでの時間あとMTBFっていうものは 最後ですけど 平均故障間隔時間っていうものでして簡単に言うと正常に稼働している時間ですね

検知するまでの時間と回復するまでの時間そして正常に動いている時間この3つがありましてMTDとMTTR検知時間と回復時間に関しては早ければ早いほどいいですよね早く気づいて早く直した方が良いMTDFに関しては長ければ長いほどいいですよね

壊れるヒントが少ない方がいい運用監視という文脈で何を目的にするのかというとこのMTD MTDRに関してはより短くしていきますMTBFというものをより長くしていくこれができていたら運用監視はうまくいっているのであろうと

いう風に僕は捉えていますっていう話ですねなるほどちなみにMTTDとMTRはちょっと被ってます?被ってますなるほど先頭部分が被ってるみたいな感じですかねイメージつきました完全に図ができましたねノリさんの中でそうです

アメリカビリティメトリックスとかでググってもらうと図が多分出てくると思うので手元フリーな方は検索いただきながらずっと一緒に見ていただくといいかもしれませんじゃあここまでで一旦システム開発の残念な原理原則と運用開始の目的っていうちょっと座学的なところの話をメインにさせていただきました

ありがとうございますざっくりまとめるとシステム開発の残念な原理原則は何もしなければ壊れる何かしても壊れる壊さないように努力すぎると何もできないしかし努力を怠ると使ってもらえないって紹介をしたんですけど僕たちシステム開発をしていく身としてこういう原理原則と戦って悲しちゃいけないよねと戦っているその敵は一体何なんだって皆さんに知ってもらえたんじゃないかなというふうに思います

ノリさんが言ってたやらない後悔よりやる後悔ですね絶望の袋工事ですからねあそこはこれは後半ちょっと救いがあったりするんですかね後半ここのところに関しては残念ながら救いはないです立ち向かうしかない見た目で

ちょっとボリューム増えちゃったんで また後半にっていうところでちょっと前半の切れ目でお知らせ等ありましたら 北浦さんお願いいたします北浦:K2DIJR開発センターでは 一緒に働く仲間を募集しておりますのでぜひご応募いただければなと思いますあと僕個人ですけれども 僕の専門であるDevOpsであったりとかObservabilityっていうところで コンサルティングのサービスを始めました

なので興味のある方はですねXのDMとかでお気軽にご連絡いただければなと思ってますそんなカジュアルに送っちゃっていいんですかちなみにカジュアルに送っていただいて大丈夫です今後送ってもいいかとかでも全然構わないです結構割とここのところに関してはちょっと相談したいんだよねっていうレベルであれば無償でOKしようかなと思ってっていうのもあってすんごい

圧倒すると押しちゃいますけど大丈夫ですか大丈夫です僕も勉強にもなりますしお互いちょっと勉強しながら実際に手も動かしてサポートしましょうかっていうところの話になったら弊社の営業とおつなげしてディズニーの話で段取りで進めていければなと思いますぜひ運用設計とか監視の部分でお困りの方は

DMでXのリンクを貼られるんですかね概要欄に貼ります概要欄のリンクからお願いします北野さん弊社内でも駆け込み寺なんでぜひDMと相談とかありましたらお願いいたしますではじゃあ順平が後半へ続くって言って続きますじゃあ後半へ続きますキートン山出してくんないそのまま

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

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