> 今サービスの品質を表すSLI/SLOの定義を考えていて、よく言われる稼働率やリクエストベースの可用性の定義だと「月間で一回1時間ダウンしたのと、月間で1分ダウンしたのが60回発生したケースの区別が数値上で現れない」が、明らかに後者のほつがエンドユーザーから見てサービスへの信用度が低下する…ので、ダウンした頻度の変数も絡めた「サービス品質？の定義（仮）」について、何か知ってたりしないかなぁ、と思いました！ --> SRE Lounge Slackへ質問 こういう質問を知り合いから受けたんですが、停止頻度を含めたSLOの事例って見かけたことがある方いらっしゃったりしますか。 > 停止頻度を含めたSLIは、SREの文脈ではまだみたことないですね。やるなら単にSLIとして頻度を設定して、SLOとして月間10回に設定するみたいな感じですかね。もうちょっと精緻にやりたいのであれば、月間n分m回ダウンとしたときにnとmを使ってスコア式をつくるような感じでしょうか。 SREでは修復時間が短ければ頻度は気にしないという暗黙の主張が多い気はします。なので、直接の回答はもっておらず…という感じです。nとmの関係について、nが十分小さければユーザー近傍のネットワーク不調と区別がつかず、1分程度の停止であれば意外とユーザーは普段からその程度の不調に慣れていて気にしていない可能性もあります。なので、停止頻度が大きくても修復時間が十分速ければユーザー体験に影響はないといえるかもしれません。 今の所こんな感じの話はしています。 :+1: 6 15 replies Also sent to the channel katsuhisa_ 1 day ago ご期待する答えになっているかは分からないですが、Google App Engineのこのドキュメントの中のDowntimeとDowntime Periodを区別して整理する考え方から何かしらのヒントが得られるかもしれません。 要するに、一定割合以上のエラーレートが連続時間発生した場合にはじめてDowntime Periodとして計上し、サービスレベルに勘案するというものです。 ので、この考え方を活用すると、元々の質問者の方が懸念されているような1分ダウンしたのが60回発生したケースをサービスレベルに影響を与えるDowntime発生ではないとみなすことができます。 https://cloud.google.com/appengine/sla Also sent to the channel katsuhisa_ 1 day ago あとは僕が自社でSLOを考えるにあたり参考にしたのは、SRE Workbookのこのあたりでしょうか。 https://landing.google.com/sre/workbook/chapters/implementing-slos/#choosing-an-appropriate-time-window chaspy 1 day ago そうですね、n分以上のdownという風にSLIをまとめる、という方法もありそうですね。 netmarkjp 1 day ago このへんの実影響的なお悩みを抑え込むために、時間ベースのアップタイムではなく、リクエストベースのエラーレートを使うんだと思っていました。 時間ベースアップタイムで頻度を含めたいなら、短い集計単位を組み合わせる(日単位を併用する)とかでカバーできそうな気がしました。未検証。 chaspy 1 day ago 「月間で一回1時間ダウンしたのと、月間で1分ダウンしたのが60回発生したケースの区別が数値上で現れない」が、明らかに後者のほつがエンドユーザーから見てサービスへの信用度が低下する これは本当にそうなのかなあ chaspy 1 day ago 月間で一回1時間ダウンした のほうがインパクトでかいように僕は思ってしまいました。。。 netmarkjp 1 day ago 例が 1分 だからわたしも違和感ありましたが、10分だとしたらわかるな、と思いました (edited) yuuki 1 day ago ありがとうございます！参考になりますー。 修復時間が短ければ無視するを表明してやってる一例ですね。 GAEは連続5分で意外と緩いんですね。SLAなのでSLOよりはおそらく緩めにしているのだろうなあと思いました。 :+1: 1 yuuki 1 day ago n x m の値は同じでも、nとmの値によってユーザーが感じる信頼性に差異があるかは、議論の余地がありそうですね。 :+1: 2 chaspy 1 day ago この議論は面白そうですね。csと連携したり、ユーザ満足度との関連を見てる会社さんの現場の例とか知りたいな。 :+1: 1 katsuhisa_ 1 day ago ユーザー満足度との関連、めちゃ気になりますね :eyes: ぼくは自社でSLOを策定した時は、そのへんをふまえたものとするために、PdMと合意をしましたが、 より踏み込んでユーザー満足度との関係性は確かに知りたい。 chaspy 1 day ago CSとの連携、ふんわーーりとしょうらーーい的に考えているけどまだ何も絵がないんですよねー :+1: 1 lylephone 1 day ago 1min * 60回のケースをユーザ側から考えると使おうとすると高頻度で落ちてる、みたいな感じですよね？ 毎日お昼休みがピークタイムみたいなリズムが有るサービスだと月に1回の1hよりも毎日ピークタイムに2min落ちるのほうが印象悪いかもなーみたいなのは思いました egmc 1 day ago リクエストベースのエラーレートを使うんだと思っていました。 基本これに同意なんですが、エンドユーザーへの影響という意味では何回落ちたからよりいつ落ちたか（ゲームならイベント中、ECならセール中、月初などなど）の方が重要ですよね。 このあたりの変数をimpactとして段階別に扱うみたいなのもどこまでみた気がしますが、このあたりの指標は扱うシステムによって異なると思いますので、汎用的に扱うのはなかなか難しそうですね。 Also sent to the channel usadamasa 16 hours ago いつ落ちたか そういえばSLOを特定のイベントと関連付けて設計するといった話はあんまり聞いたことない気も。 ビジネス上のImpactが大きいなら想定する売上も決まってるでしょうし、サービスダウンによる機会損失額をパラメタとしてSLOを変動させるなど?