summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authork8s-ci-robot <k8s-ci-robot@users.noreply.github.com>2018-08-30 06:58:12 -0700
committerGitHub <noreply@github.com>2018-08-30 06:58:12 -0700
commite86730f6c9ede36149c40ddb98d50da5692cce8a (patch)
treedfe75fd7af2eb91f832dc37a100c8b627a4ae454
parent265a4667222b4e7c6e42a25e500698429e013cb3 (diff)
parent45827d8ec912a2d2a2e0160f3f3a62f583399a62 (diff)
Merge pull request #2604 from wojtek-t/minor_fixups
Clarify some things in main slo page
-rw-r--r--sig-scalability/slos/slos.md27
1 files changed, 15 insertions, 12 deletions
diff --git a/sig-scalability/slos/slos.md b/sig-scalability/slos/slos.md
index 6f7ffff0..37241cdc 100644
--- a/sig-scalability/slos/slos.md
+++ b/sig-scalability/slos/slos.md
@@ -11,26 +11,29 @@ in these areas.
## What do we require from SLIs/SLOs?
-We are going to define more SLIs and SLOs based on the most important indicators
-in the system.
+We are in the process of extending the number of SLIs ([Service Level Indicators])
+and SLOs ([Service Level Objectives]) built on top of these SLIs to cover more areas
+of the system and user expectations.
-Our SLOs need to have the following properties:
+Our SLIs/SLOs need to have the following properties:
- <b> They need to be testable </b> <br/>
- That means that we need to have a benchmark to measure if it's met.
+ Ideally, they (SLIs and SLOs) should be measurable in all running clusters,
+ but if that isn't possible a benchmark may be enough in some situations.
+ That means that not every SLO may be translatable to SLA ([Service
+ Level Agreement]).
- <b> They need to be understandable for users </b> <br/>
In particular, they need to be understandable for people not familiar
with the system internals, i.e. their formulation can't depend on some
arcane knowledge.
-However, we may introduce some internal (for developers only) SLIs, that
-may be useful for understanding performance characterstic of the system,
-but for which we don't provide any guarantees for users and thus may not
-be fully understandable for users.
+We may also introduce internal(for developers only) SLIs, that may be useful
+for understanding performance characterstic of the system, but for which
+we don't provide any guarantees for users (and thus don't require them to be
+that easily understandable).
-On the other hand, we do NOT require that our SLOs:
-- are measurable in a running cluster (though that's desired if possible) <br/>
- In other words, not SLOs need to be easily translatable to SLAs.
- Being able to benchmark is enough for us.
+[Service Level Indicators]: https://en.wikipedia.org/wiki/Service_level_indicator
+[Service Level Objectives]: https://en.wikipedia.org/wiki/Service_level_objective
+[Service Level Agreement]: https://en.wikipedia.org/wiki/Service-level_agreement
## Types of SLOs