## Memo クラウドのように複数の顧客がリソースを共有するシステムにおいて、[[SLO]]を定義する難しさを提起する論文。SREbookにかかれている顧客満足度を表現するSLOだけだと、リソースを過剰使用する顧客によって、他の顧客の満足度が低下するという問題に対して、Customer Behavior Expectations(CBE)と呼ばれる顧客に対して望む振る舞いを定義して、顧客がCBEを満たしてくれる限りにおいて顧客満足度に基づくSLOを適用するというアイデアが提案されていると理解。 - Morning Paperでの紹介。[Nines are not enough: meaningful metrics for clouds | the morning paper](https://blog.acolyer.org/2019/06/19/nines-are-not-enough/) - SLOの種類 - **Contractual SLOs**: 契約上のSLO。 - SLAと同じ。 - **Customer satisfaction SLOs (SLEs)**: 顧客満足度SLO - [[Site Reliability Engineering - Google|srebook]]におけるSLOと同じ。 - しばしば組織内部的に定義される。 - **Compositional SLOs**: 構造的なSLO - クラウドのリソースセットに対するSLO - 顧客のアプリケーション設計に情報を提供するもの - **Control loop SLOs**: 制御ループSLO - クラウド事業者が積極的にリソース使用を制限するようなSLO - 制御ループSLOが満たされないと、障害が連鎖し、他のSLOにも違反する - CBE（Customer Behavior Expectations） - 提供者が顧客に期待できること。 - CBEを顧客が満たしたときのみ、SLEやSLAが適用される。 - （意訳：顧客が最悪時の振る舞いをしたときに、SLEを残ったとしても、プロバイダーは責任をとらなくてよいようにする？） - 飲食店で、お客さんが法律を違反するような振る舞いをしたときに、飲食店はお客さんを満足させる責任をとらなくてよい。 - ネットワーク、VM、ストレージシステムのパフォーマンス重視のSLOだと難しい。 ## Abstract クラウドを利用するお客様は、自分たちのアプリケーションが信頼性の高い適切なパフォーマンスで動作するという、強力でわかりやすい約束（[[SLO]]：SLO）を求めていますが、クラウド事業者は、お客様の恣意的な行動や、共有リソースの統計的な多重化によってもたらされる隠れた相互作用に対応することは技術的に困難であるため、SLOの提供を望んでいません。既存のクラウドのSLOは、通常の動作を定義するよりも、コーナーケースに対する防御を重視しています。このような問題があるため、SLOを定義するのは非常に困難です。私たちは、この問題が、サンプルデータに基づいて意思決定を行うために統計学を適用する際の課題と、いくつかの共通点があることを示します。そして、サービスレベル期待値（SLE）と顧客行動期待値（CBE）という相互に有益なセットは、顧客とサービスプロバイダの間でリスクを明示的に共有することで、今日のSLOの問題の多くを解決することができると主張します。 [[2019__HotOS__Nines are Not Enough Meaningful Metrics for Clouds__translations]]