エンジニアの成長は楽しい学びからをモットーにエンジニアリングに関する学びをワイワイお届けするラジオでございますはい違和感すごいなすごいですね変わった今年の収録文2025年の収録文からちょっとテーマが変わりましてエンジニアにとって楽しい成長をしていけるラジオということで楽しく成長していけるラジオかっていうのをモットーに頑張っていきましょうよ

あれ2026って言いました?2025って言ったと思いますが2025って言った気がしたじゃあなんでもないですはいということで本日はですね私今引き続きサイトリライアビリティエンジニアリングというオライリーの本を読んでるんですけども要はこの本SRE

サイトをとにかく稼働させ続けるゾーマンスーパーマンたちの本でしてその中にあったですねサービスレベル目標の話をしていこうかなと思っておりますSLOってやつですねそうなんです今日はですねそれに近しい単語でSLIっていうのとSLOっていうのとSLAっていうのは3つの指標がありましてこいつの違いをですね

死ぬほどわかりやすく解説していこうかなと思っているんでございます新年早々殺されても困りますけどねわかりやすすぎて死なないように気をつけてくださいはいということでまず通常の説明からいきます通常の説明というか一般的にどういうものなのっていう概要から説明していくとですねまず一番小さいところというかサービスレベル指標SLIから説明していきたいと思います

こちらはですねサービスレベルインディケイトということで指標になっております複数形なんですね複数形ですそれで言うと全部複数形です実はそうなの英語だとサービスレベルオブジェクティブスサービスレベルアグリメントそうなんだ

というので1個目のSLIというのはですね実際の計測値何を計測するかという部分の指標になっておりますウェブサイトでイメージするものだと可用性とか何パーセントだねみたいなのとかレイテンシーとか

通信するとき何秒遅れが発生してるねみたいなそういうところで何を計測するのかっていうような部分を示しているのがSLIとなっておりますじゃあ本当に監視ツールで取れるもの値がこのSLIなんですね左右でございますはいはいはいわかります続いてSLOサービスレベルオブジェクティブス

これはSLIに対してどれくらいの目標を持っておくかっていうようなコミットメントみたいな感じですねこのぐらい

SLAが項目でSLOはそれに対するこのぐらいにしますっていう目標ですね可用性だったら何%担保したよねとかレイテンシーだったら何ミリ秒以内にしたよねみたいなそういうところの目標を持つことがSLOとなっておりますそして最後SLAこちらはですねクライアントとの間で担保すべき約束ごとみたいな感じですかねうん

クライアントが出てくるんですねここでそうですこれは必ずしもあるわけではなくてこれはGoogleが書いてる本なのでGoogleの例でいくんですけど例えばGoogleワークスペースとかで使ってる会社さん結構多いと思うんですよ大体どこの会社もGoogleワークスペースかMS365は使ってるんじゃないかなという気がしてるんですけどそういうのって企業とGoogle間で契約してお金払って使ってるじゃないですか

エンタープライズ契約そうそうそうなのでGoogleがサーバー落ちたからすまんこの期間使えないわってなったらブチ切れるじゃないですか使ってる側もちょっと勘弁してくださいよってなりますねなのでこれ以上使えなかったら返金しますよみたいなそういう契約を取り交わしてるわけですねうんうんうん一方Google検索ってそういう契約取り交わしてないですよねただで使ってますわうん

ここもただSLAっていうのはないけどとはいえ何も測らなくていいかというとそういうことではなくてもちろん使って毎回毎回システム落ちるんだよねってなったら他の検索エンジンに流れていっちゃうそしたらGoogleのビジネスにならないということで一応サービスとして指標の計測は必要ですがこういうアグリメントは持ってませんよっていうパターンもありますこれをですね

わかりやすく説明する方法を思いついたんですよ今結構わかりやすかったですかねまあ簡潔にまとめてましたからね僕はこれ電車で例えたらわかりやすいんじゃないかなと思いまして出ました今年もよろしくお願いいたします明けましておめでとうございます明けましておめでとうございます

ということで電車で言うと何なのってところをちょっと考えていきたいのと最終的にはどうやってSLを設定するのがいいのかっていう話まで落とし込みたいんですけどいいっすねまずSLIですねこれは先ほども申し上げた通り指標なので電車で言ったらじゅんぺいくん何だと思いますかデスティネーション行き先指標指標かこの

じゃあ例えばですけど京浜トーク戦って多分大宮から大船まで通ってると思うんですよ大船かなそれってこれちょっと計測しておかないと大宮まで行かない可能性あるなみたいなそういうこと?いいえちょっとなちょっと分かってないかもしれないな今のでもいいですね

さっきの説明で分かってないことが分かったからいいですねさっきの説明で分かってないわけじゃないか大事なポイントというかSLIを設定する上ですごい大事なポイントがあるんですよそれはこれを測ることによってユーザーの体験が上がるかどうかっていうのが結構大事なんですね電車のユーザーって要は乗客じゃないですかその人たちってどういう値に気をつけてると思いますか

気をつけて欲しいと思ってると思います時間いいっすね何の時間ですか目的地までの時間目的地までの時間何分で着くかみたいな到着する時間目的地の駅にが遅れないかどうかってことですかはい他はないですか他他ね

そうですねあんま気にしたことないですけどお金一応じゅんぺい金持ってるからなそうですねオーフナーまでだったらいくらでもいけますねいくらでもいけんだそれはなかなか勇気ある行動ですね結構時間かかるからな時間も気にしますねお金かお金も確かに測れますね他なんか思いつくものとかだと例えば運休率ですね

例えば1日に予定している本数に対して何本運休したかとかはいはいはいあとは乗車率パンパンこの車両に対して何%乗ってるかとかそういうことも多分測れますよねなるほどっていうのがSLIでございますで続いてSLOですねはい

じゃあ順平くんさっきいろんな指標が出てきたと思うんですけどこれに対して目標を設定するとしたらどういうふうに設定するのが良さそうですかじゃあ朝9時に大船に着きたいってなったら遅延しても9時までに着く電車に乗れればOKうん

一般的にって

そうですねこれどっちかっていうとJRとかの気持ちになってほしいそういうことか乗る側の気持ちでしょ完全にこれはどっちかっていうとサービスを提供してる側のJRの気持ちで見たほうがよかったわなるほどそしたらあるか1日に遅延が何回までとか遅延しても

何分までみたいな設定なるほど回数とあとは平均時間的な感じですかそうですね上限みたいなマックスみたいな感じ1本でも例えば60分以上がいったらやばいぞみたいなどっちもありますね平均値もそうですし1本でもあとありますか線路に緊急停止何回までみたいな

それ目標にして大丈夫ですか人いるけどちょっと目標超えそうだから引いちゃえってなんですか確かにダメですね目標にしませんやっぱりそんぐらいでいきますなるほどなるほどそうですねちなみにさっきのSLIの指標の部分で言うと例えばですけどどれくらいの運休率を目標にするかっていうのも一個あるかもしれないですね何本までなら運休OKにするかみたいな

とか乗車率も乗車率の場合とかだと何パーから何パーの間を目指すっていう目標になるかもしれないですねなんでこれの計測大事かっていうと例えばあまりにも乗車率少なすぎる場合だったら本数を減らすみたいなことも全然あり得るじゃないですかなるほど

一方パンパンすぎたら可能なのかどうか分からないですけど車両の本数台数増やすとかもしくは本数増やすことによって人を分散させればより快適な乗車をできるようになりますよねお客さんが確かにそういう目標を持つのもありですね一方さっき出てきた運賃に関してはこの目標でいうと設定しようってありますか

うんちんか高すぎるとあれですけど別に気にしてる人いないような気がするんで気にしてる人いないかどうかはちょっと分かんない学生の頃の俺は気にしていたかもしれない確かに池袋までなら200円台だけど新宿行くと300円台になるんだよなみたいなことを思ってた記憶あるもんいるのか少なからずいるんだいるよ指標はむずいですねでも

ちょっと難しい設定しなくてもいいですかこれこれね設定しなくてもいいと思いますなんなら計測もいらないかもしれないだって自分で決めてるしマーケティングっすよねどっちかというとマーケティングの人たちがこれぐらいの値段にしたらどれぐらい利益増えたとか客減ったとか客増えたとかっていうのに使うのにはいいかもしれないけどサービスの運行に関して言うとあんまり関係ないかもしれないですねうん

今の話聞いてると何に関わる目標を立てるのがいいんですかねっていうのも売上なのか顧客満足度なのかユーザーが使いたいと思った時に使えるか可用性?可用性とはちょっと違うかもしれないですけどあまりにもパンパンだったら電車動いてるけど使えないみたいなどういうのに向かって

SLOというかSLOを立てるのがいいんですかねなるほどね最終的なビジネス目標的なところかですですです

プロダクトによりますかね何を重視するかプロダクトによって違う気がするんでそうですねそれで言うと実際のSLOも同じでどういう性質のサービス化によって何を計測するとか何を目標にするかっていうのは変わってきますね想像するに電車は人を

の中生活を支える的なところが多分役割として大きいと思うんで 多分乗りたい時に予定通り乗って届けるっていうのを多分一番重視している気がしていて 多分儲けすぎると多分怒られると思うんですよ総務省かわかんないですけどどっかにちょっと国土交通省かどっかちょっとわかんないですけどね もっと国鉄でしょうから確かにほぼ独占市場ですからねはい

で多分それでうんち上げたらめちゃくちゃ怒られると思うんでお金というよりは最低限施設維持できる売上をキープしつつ電車を決めた本数動かす乗りたいときに乗れるそのための指標なんだろうなでSLを決めていくんでしょうねそうですねあとSLAサービスレベルアグリメントはい

これに関してはどんなものがありますか実際これ多分現実世界でもあると思うんですけどうわやばい飛んだSLAってクライアントとの取り決めですねそんなのあるんですか大宮から浦和までは200円以内にしろっていう取り決めとか電車の間隔は10分に1本は来るようにしろ

っていう話とかちなみに一個マジモンを突っ込むと新幹線とか特急は遅延すると払い戻しありますよねそうなんだ遅延だけでめっちゃ遅延すると特急料金返金するんですよそうなんだ新幹線で行ったのにドンコと同じくらいになったやんけっていうので特急分の他ね

特急というめっちゃ早いというサービスレベルアグリメント違反で転機そうなんだそれはちょっと僕新幹線2回3回ぐらいしか乗ったことないんで衝撃衝撃すぎるそれは初耳でした特急でもあります僕の中でイメージしてた取り決めだと例えば何分以上遅刻したら遅延証明書発行しますよとかもSLAの一つだと思うんですよねはいはいはい

約束してるわけじゃないけどなんとなくもう不分立というか決まってる感じするじゃないですかとかあとは運休になった時の振替輸送とかもそれに近しいものなのかなっていう気がしますねっていうのが電車で例えた時のSLI SLO SLAのイメージとなってますありがとうございますここからはですねSLIについてのまず注意点なんですけど

SLIは計測するじゃないですかしかし全部を計測してはいけないです測れるものをなんでかっていうと例えば指標を増やしすぎた場合って大切な指標が適切なレベルで注意払えなくなるってことで埋もれちゃうんですねまずそういうのでコストかけても意味ないので増やしすぎてはいけないですよと一方減らしすぎたら減らしすぎたでそれは問題で今度重要な挙動を発見できなくなるんですね

なのでさっきの例えば電車の例でいくと予定時刻に対して何分遅れたかとか運休率どれくらいかとか乗車率は何%なのか何%から何%の間なのかっていうそういう指標って

結構重要な指標かなと思っていてこれって電車がちゃんと時間通りに乗って時間通りに目的地につけるかっていうところが守れてるかどうかの指標になってるじゃないですかとってもユーザーの関心ごとが高いポイントなんですけど一方例えば測れるもので言ったら電車のスピードとか消費電力とかも計測できるかもしれないけどユーザーからすると結構どうでもいいですよね

っていうのでそういう関係ない値とかは別に計測しない方がいいよみたいなそういう部分がありますとなるほどめっちゃむずいですねそうなんです特にウェブサービスだとむずいよねむずい電車は電車なんですけどすみません言ってる意味わかんないですがアーキテクチャによって変わりそうですよねインスタンスというか

インスタンスサーバーありなのかサーバーレスでマネージドサービス使ってればこれ見なくていいよねとかあるかもしれないですしはたまたオンプレでやってるんだったらハードウェアのここ見なきゃいけないよねとかむずいですね本当にサービスの質によっても結構変わるかなと思ってて例えばファイル共有のギガファイル便とかだとさ多分アップロードの速度が大事だと思うんですよね

スループットって言うんですかはい一方通常のウェブサイトでそんなでかい書き込みとか読み込み発生するわけじゃないんでそこのスループット大事っちゃ大事か言ってる意味わかりますただなんかギガファイル便だけの都合じゃないところもあるんでそこを測るかどうなんでしょうね確かにあとはストレージのシステムとかだと耐久性とかも大事になってくるよねみたいなそうですねとかはいろいろありますねはい

そしてその次の注意点指標の計測方法なんですけど指標は結構適切なのを選ぶの大事なんですよもちろんここでよく使われがちだけどミスが発生しやすい例としてですね平均値というのがあるんですね平均値というのはですねかっこよく言うと統計的な誤尾というのが発生しやすくて

え?なんてことだったの?統計的な語尾が発生しやすいんですよ語尾統計的な?統計的な語尾が漢字で書けないですね語尾漢字では書けないかもしれないことわざみたいな感じですよねそうそうそうことわざって確かにそれっぽいなこれは要は統計で直感に当てはまらないケースが起きてしまうみたいな感じなのかななんかあれですよねあの

例えばやってるかわかんないですけど日本の平均給与みたいな上の人がめっちゃ釣り上げてるから中央値と平均値めっちゃ乖離あるよみたいなそうそうそうそうそうあってそうに見えるけど実は正しくないよねというかあんま適切じゃないよねみたいな時によく使う言葉なんですけどこのSLOもですねSLOかいやSLOか

あんまり平均値で見てはいけないですよと言われてますへーそうなんだ分布として考える方がいいと言われてて分布はですねここでまたもう一個難しい言葉が出てくるんですけどパーセンタイルという考え方を使うといいですね出ましたパーセンタイル順平は理系だからわかるかな

やってないなわかりませんやってないかはいこれどこで並ぶ何なのかよくわかってないんですけど統計じゃないですか統計か要は数字を小さい順から並べていきますとちょっとわかりやすいように100まである1から100の数字があるとするじゃないですかはい95%タイルつったら小さい方から並べて95%の位置にあるやつだよみたいな95枚目のタイルだ

多分わかんないちょっとこのタイルその語源はわかんないけど平均が50%あるんですよねそうそうそうそう中央値が50%ある並べていったときの位置うんちょうど真ん中にあるやつが中央値平均値は全部の値を足して全部の数で割ったやつはいはいはい

この95%Lっていうのは中央値の95%目の位置にあるやつバージョンみたいななんか統計の授業やった気がしてきたやったんかいあった気がしましたこれはなかったさっきの電車の遅延の時間に対する目標で設定するとですね問題が分かりやすいんですけど例えば平均の遅れのSLOを3分にするとするじゃないですか3分遅れって別にそんな珍しくないですよね

たまにあるみたいなよくあります12本連続で電車が30分遅延した場合ってどうですかすごいですねダイヤめちゃめちゃになってますよねダイヤめちゃめちゃその30分きっかりで収束したものと考えましょうか最後の12本が30本連続で遅れたみたいなめったにない

っていう場合に結構問題起きてそうだなって感じするじゃないですか一方ですね京浜東北線って1日に141本電車走ってるんですよそんなにすげえなのでさっきの12分30分遅延した場合でも他がちゃんと動いてれば平均の遅れって2.55分なんですね2分30秒ぐらい大したことないですね

2分30秒ぐらい遅れても電車は別にそんなイラッとしないしちょっと遅れてるなぐらいで済むじゃないですかなので全く問題ないように感じるんですけど果たして本当に問題ないでしょうかねっていうなのでここを例えばパーセンタイル使って目標設定しておくとよくて例えば95%タイルで15分以内の遅延で済んでることっていうのであれば95%の位置にあるやつ

が15分以内の遅れで済んでるかどうかでチェックするわけですねなので今回の場合だったら95%は141だからちょっと待って計算が0.950.9が129133か4か5本当か12本だと8.5%の位置にあるんですよだから91.5の位置にあるのかな

さっきの12本連続で30分遅れて他はきっちりとしてた場合っていうのはだいたい91.5%の位置に30分遅れの奴らが並んでくるんですねグラフで言うとずっとゼロだったのが91.5のところでいきなりズドンって30分のところに行ってそのまま横ばいみたいな感じですねうんうん

っていう計測をしておけばこれは何か問題あるぞっていうのをキャッチすることが実はできたっていうなので基本的には平均ではなくて分布として測る方がいいことが多いよっていうもちろん100%ではないと思うんですけどただそっちの方で設定した方が見つける可能性高いよっていうのがあります

これムズイなと思うのはこのデイリーするのかウィークリーにするのか マンスリーにするのかこれは職人技ですよね確かにね まあ電車の場合だったらデイリーで済むけどデイリーながら本当にえっだって毎年元旦とか大晦日絶対にエラーでそうじゃないですか お祭りの人か絶対チェーンしません多分そういうイベントがあると

でその日のアラートとりあえず無視するっていう状況になり得ると思うんですけどそれは果たしていいのかとかちょっとその辺難しいですねまああの

一回は簡単だからってなってるかもしれないですけどね実際はもしくはデイリーで測っておかないと吸収されちゃう気がするけどねそれもありますね毎年取っていった結果この日とこの日とこの日は結構増える傾向があるなぜならこれがあるからっていうのが導き出せて結果例えばその時だけ本数を増やすみたいな対応ができるようになるんでやっぱデイリーがいいのかなって気はしましたけど時間かもしれないしそうね

なんか今のすごいSLOの本質かなと思ってて結局じゃあその計測した結果アクションを起こせるっていうのはめっちゃ大事だと思うんですよねそうですねマンスリーとかで取っちゃうとそこが吸収されて行動できなくなってしまうのでとんでもないことにならない限りはそうそうそうとんでもないことになったらキャッチできるかもはいっていうので適切な確かに期間の区切りっていうのも大事かもしれないですねそして最後

SLOの設定方法ということでコツを2つご紹介して終わりにしようかなって感じなんですけどその1安全マージンを確保する安全マージンこれはですねどういうことかというと外側に言ってる目標と内側でこっそり持っておく目標は別々で設定して内側でこっそり持ってる目標をより厳しくしておくよみたいなやつですね

人生の教訓かもしれないだから例えばテストで目標90点取るよって親には言いましたと自分の中では95点取るぞって気持ちでやるみたいな大事あるあるっていうやつめっちゃ大事こういう風にしておくことで先に内部の方のSLOが引っかかるんで外に出る前に気づけると

そういう力もやっぱりエンジニアに求められるんですよね確かに小魅力しかも多分テストの例で言っちゃうと今度のテスト難しそうなんだよなみたいな空気感出すのも大事ですよね多分80取ったらすごいよな多分な今までの俺の感じっていう空気出してから90にしますって言うんだけどハードルなるべく下げるやつそうそうそう

結局テスト前勉強してねって言ってるやつも同じかもしれないなあれ安全マージンなんだ安全マージンかもしれないなので安全マージンを確保するっていうのが一つ目ですと二つ目過剰達成を避けるなるほど目標設定したけどそれを過剰に達成するっていうのは避けた方がいいよっていうのがあってこれ一つはまずめっちゃコストかかるというか

99.99%を99.999%にするのにめっちゃコストが増えてしまうっていうのもありますしあとはちょっとこの本で出てたのはそういう見方もあるんだと思ったんですけどこれ実際Googleのサービスで通用率がすごい高いサービスがあったんですねGoogle検索じゃなくてじゃなくて分散システムのためのロックサービスですってあるんですけど何それチャビーっていうサービスをやってて

これすごい信頼できてたんですよほとんど障害起きないみたいなすごいなでもそれをやることによってどんな問題が起きたかっていうとこのチャビーに依存するサービスがチャビーってほぼこけることないからその想定で作っちゃえってなったらしいんですね気持ちわかるよそれは

その結果チャビがダウンすると動かないサービスがめちゃめちゃできてしまうという危険な状況になったんですよそこで取った驚きの行動がですねあえて計画的に停止させるっていうどういうことSLOを設定してるじゃないですかそれを過剰に超えそうになったらあえて停止するっていうお客さんにいつでもあると思うなよっていうメッセージを伝えるってこと内部的なサービスなのか外部に出してたのか分かんないんですけど

すごいなてかちょっと最後まで聞こう気になるほぼ終わったんですけどそれをすることによって一応サービスレベル目標は達成してるけどあんまり大きく超えすぎないようにしたんですねそうすれば他のサービスもこのチャビーに依存することないような形に作っていくことができたみたいなそういうもんなんだ本当にすごいよねこれだからこれ意外だなと思って

なんか今の話って普通のりさんが最初に話していた99.9を99.99にするのってめっちゃ大変だよお金もコストも労力もかかるよみたいな話かと思いきやめちゃめちゃ可用性上げたら周りのサービスがすごい

寄りかかってくるからそうならないようにしろよっていう話ってことですよねそうだからあまりにもいい商品すぎて他のみんなが堕落してしまったからあえて悪い商品を出したみたいなそんな感じだよねなんかでも別になんかその可用性めっちゃ高くなかったとしてもすっごい頼りません?GitHubとかアトラシアンっていうかJiraとかスラックもうなんか落ちたらみんな仕事やーみよってなってますよねXで確かに

だからなんかそういう問題じゃない気がするでも面白いですね車内システムだってあるかもしれないですねそうね電車の例で言うと電車があまりにも信用できる時間に来てしまうので

遅延した時にあまりにもすごいクレームが来るようになってしまったみたいなだからあえて定期的に踏切の中に何もいないけど何かあるように見せかけて止まるようにしたみたいなそういうことですよね

そういうことですねもしくもホームでいつまでも扉閉めないみたいなあるなそういう時点検作業のためにちょっともうしばらく停止してますみたいな確かにな異音が生じましたんだみたいな電車乗ってて異音聞いたことあんまりないからなというので過剰達成を避けましょうっていうのが書かれてますねなるほど大事ですね他のことやったほうがいいですからね大体その労力でという

今回はSREの人たちが見ているというか見るべきSLI SLO SLAについてのお話でございましたありがとうございますSLAはなんか分かりやすいですね多分営業というか営業なのかな企画の人なのかなが多分立てるお客さんがこれ大事だろうなっていうのは立てると思うんですけどSLI SLOに関しては多分エンジニア側で頑張ってうんって考える必要があってうん

それはめっちゃむずそうなんで 多分本当に新規とか新規リリースするものについては 最初からカッチリとしたもの決められないでしょうねいいこと言いましたね 最初から完璧でなくても良いってことなんですねって書いてます多分これならOKがしないっしょって決めてやって OKがしながら直していくんでしょうねとはいえ最初の値もちゃんと考えた方がいいとは言ってますね

まあそうではあると思うんですがまあ難しいじゃないですかなかなか多分ちゃんと考えた上でうわこれなんかアラートいつも飛んでくるけど問題ないから消すかとかこれ見てなかったからすごいユーザーからクレームきたみたいなあるんでしょうね結構そこのラインを定めるのは難しそうだなと思ってて一個まず現在のパフォーマンスに基づいてターゲットを選択してはならないとあるんですよ

だから例えばもう今サービス動いててじゃあやっぱSLO決めなきゃダメだよねってなった時に今の通りとかを見て決めるのはあんまり良くないとは言われているああそうですね手段が目的かじゃないですけどあくまでユーザーの何かを達成するための目標ですもんねそうですね

であとその何も考えずに値を設定してしまうとあのターゲットを満たすために超人的な努力をする必要が出てきてしまうのでそれもあんまり良くないよねとは言ってますねだからまあ最初の値もやっぱちゃんと考えて設定はした方がいいよでも最初から完璧でなくてもいいよとも言ってるっていうねはいはいちなみに緩めのターゲットから厳しくしていく方がいいって言ってますねざっくりってことですねうん

なるほどねなんかちょっと本当に勉強しても分かんなさというかプロダクトによって全然違いそうなんでとはいえシステムの場合そんなに変わらんとも言ってるけどねそうなんですねそんなに変わらんというかここを押さえとけばいいでしょみたいなものはある程度あってだからそこはテンプレ化した方がいいと言ってて

なるほどまずはその目標の設定の仕方に関してはユーザーの関心ごとに基づくものじゃないとダメですよっていうのはさっきの電車の例と同じなんですけどその上でだいたい可用性レイテンシースループット耐久性この辺が多いですねなるほどなあれですかなんていうか分かんないヘルスチェックでリクエストしてみてその指標を取るみたいなイメージなんですかね計測するってなったらそうなるよねはいはい

半年もしたら僕は何かを運用してる気がするんでまたこれを聞いて身に染みつつ何言ってんだこうだろうってなってるかもしれないですしいい予習になりましたちなみにGoogleの場合とかだとあまりにも規模がでかすぎてあんまり可用性は意味ないらしいんですねほう

多分どっかのエリアの何かは動いてるだろうという状況になってしまってるのでそういう意味での可用性ってなったら計測が難しいらしいので基本的にはhttpリクエストに対する失敗率で測ってるらしいですよ失敗するの?失敗するのかな失敗することはあるんじゃないかな何やってんだろう

単純に500エラー出ることもあるらしいしそうなんだその時サーバー落ちてるケースもありえるんじゃないロードバランサーがヘルスチェックする前にとかだったらありえる気がするんでというSREの人たちが掲げている指標のお話でしたありがとうございますアルファベット3つ分かりづらいよねって前北浦さんのエピソードコラボエピソードでもやりましたけど解像度上がったですね

SLAが指標SLOがその指標に対する目標SLAがクライアントとの間でのお約束って感じですねありがとうございますハッシュタグひまじんプログラマーでSNSでフィードバック募集してますのでSLOの勘どころとかあるあるみたいなのがありましたらぜひ気軽にポストお願いしますお願いします

説明欄からGoogleフォームで番組への要望・感想・質問何でもお待ちしてますのでお気軽にお願いいたしますお願いします各種ポッドキャストプラットフォームでのフォロー高評価もお待ちしてますのでお願いしますどんどんフォローしてくださいいいねお願いしますまた次回バイバイやめて!ラーのバグ侵入の特殊能力でマスターザブランチが焼き払われたら闇のスパゲティコードと見つけ都合しているじゅんぺうちの心までクラッシュしちゃう

お願い死なないでじゅんぺうちあんたがここでクラッシュしたら戦法との契約はどうなっちゃうのソースコードはまだ修正の余地があるここを耐えればコード納品できるんだから次回納期間に合わずデバッグスタンバイ