Answers: <p>Whilst not strictly a standard approach, Google has published an SLI Menu and a <a href="https://www.usenix.org/sites/default/files/conference/protected-files/srecon18emea_slides_fong-jones.pdf" rel="nofollow noreferrer">process for developing SLIs for user journies</a>:</p>
  
  <ol>
  <li><p>For each User Journey/Data Flow identify from the SLI Menu suitable types of SLI:</p>
  
  <p><a href="https://i.sstatic.net/guvo8.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/guvo8.png" alt="The SLI Menu"></a></p></li>
  <li><p>Make a decision about how to measure <strong>good</strong> and <strong>valid</strong> events,</p></li>
  <li>Decide where to measure the SLI From out of the following: End User, Client-side Instrumentation, Synthetic Clients, Front-end Metrics, Application Metrics or Server-side Logging.</li>
  </ol>
  
  <p>The document then goes on to describe, how you collate all of your SLIs for all of your user journies then walk the journey to look for coverage gaps.  Then finally set SLOs based upon the SLIs either based upon <strong>business need</strong> or <strong>past performance</strong>.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-10-25T10:17:15.780Z
Answers: 2019-10-25T10:17:15.780Z
Answers: Richard Slater
Answers: <p><a href="https://keptn.sh" rel="nofollow noreferrer">Keptn</a> has a <a href="https://github.com/keptn/spec/blob/master/service_level_indicator.md" rel="nofollow noreferrer">specification for SLIs</a> and <a href="https://github.com/keptn/spec/blob/master/service_level_objective.md" rel="nofollow noreferrer">SLOs</a>. <a href="https://openslo.com" rel="nofollow noreferrer">OpenSLO</a> also provide a slightly different take.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-08-11T21:58:07.800Z
Answers: 2022-08-11T21:58:07.800Z
Answers: A. Gardner
Answers: <p>I thought I'd add on one point... SLIs/SLOs are not a tool for monitoring in and by themselves.</p>
  <p>They are the basis for proactive and continuous site reliability engineering. With only a set of SLIs/SLOs you will be able to assess the service reliability over a prolonged period of time and plan around that (e.g. prioritize reliability enhancing activities over new functionality in order to improve your SLI).</p>
  <p>In order to add the monitoring aspect (i.e. early detection of a degradation of the service) you will need to add Burn Rate Alerts on top of your SLIs. Only with those you will have acceptable detection and reset time that serve the monitoring of potential issues. Burn Rate Alert Implementation is covered in Chapter 5 of the SRE Workbook: <a href="https://sre.google/workbook/alerting-on-slos/" rel="nofollow noreferrer">https://sre.google/workbook/alerting-on-slos/</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2022-08-08T15:21:31.260Z
Answers: 2022-08-08T16:34:01.223Z
Answers: 2022-08-08T16:34:01.223Z
Answers: Sophie
Answers: <p>You have to define what matters the most to the customers (or users) in a cross functional manner, e.g dev, PM, Support, execs, SRE.</p>
  
  <p>For example, memory usage alone does NOT usually directly matter to the customers and most of the roles above. It does matter for capacity planning though -- so while it is not an application SLI/SLO, it may be important for devs/SRE and eventually execs (funding). There may be an internal SLI/SLO around keeping efficiency high.</p>
  
  <p>A mobile application taking too long to perform an operation or failing too often are likely to negatively impact many customers or a subset of customers that's very relevant to the business. These often turn out to be a customer facing cross functional issue, i.e support tickets are filed, execs may get called, SRE may be oncall trying to resolve the issue and will need to loop in feature [dev]elopers.</p>
  
  <p>Given all that, there is a need for cross functional metrics (SLIs) and boundaries (SLOs) that will represent customer pain/unhappiness. The absence of such common metrics tend to cause the following effect: "memory usage is low" (devs/SREs), "features have been shipped" (PM), "I didn't get a call" (execs), "users are not happy" (Support).</p>
  
  <p>Google has also published their workshop (under CC-BY 4.0) on how to define SLIs and SLOs:
  <a href="https://cloud.google.com/blog/products/management-tools/learn-how-to-set-slos-for-an-sre-or-cre-practice" rel="nofollow noreferrer">https://cloud.google.com/blog/products/management-tools/learn-how-to-set-slos-for-an-sre-or-cre-practice</a></p>
  
  <p>There is also a blog post on how to tune-up the SLIs (and SLOs) over time:
  <a href="https://cloud.google.com/blog/products/management-tools/tune-up-your-sli-metrics-cre-life-lessons" rel="nofollow noreferrer">https://cloud.google.com/blog/products/management-tools/tune-up-your-sli-metrics-cre-life-lessons</a></p>
  
  <p>Disclaimer: I work for Google.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-01-29T22:43:18.060Z
Answers: 2020-01-29T22:43:18.060Z
Answers: Gustavo Franco
Body: <p>I've come to the point where I am starting to adopt principles from <a href="https://landing.google.com/sre/" rel="nofollow noreferrer">Site Reliability Engineering</a> to operate Cloud Native applications in a modern way.</p>
  
  <p>From my reading to date, I have established that one of the core practices is monitoring. The way that SRE approaches monitoring is by defining <em>Service Level Indicators (SLI)</em> which measure an aspect of the end-user experience, then identifying a threshold around the SLI which is called a <em>Service Level Objective (SLO)</em>.</p>
  
  <p>is there a standard or common approach to defining Service Level Indicators?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-10-24T16:00:39.740Z
Comments: be aware Richard: this question smells like "primarily opinion-based" ... Consider rephrasing ...
Comments: Pierre.Vriens
Comments: CC BY-SA 4.0
Comments: 2019-10-24T19:59:16.303Z
Comments: Given that SRE as a practice seems to be quite rigorous, I would be surprised if there wasn’t a definitive answer out there.  I suspect I just haven’t encountered it, if it doesn’t exist then so be it.
Comments: Richard Slater
Comments: CC BY-SA 4.0
Comments: 2019-10-24T20:05:47.327Z
Comments: Looks like we have a different ***opinion*** (oeps) ... oh well, that's fine with me. Let's wait and see if more opinion related flags / close votes / answers come up. Good luck!
Comments: Pierre.Vriens
Comments: CC BY-SA 4.0
Comments: 2019-10-24T20:10:08.607Z
Comments: I think this type of question can go either way, sometimes there is a commonly agreed upon answer, sometimes the answer is ‘everyone does it differently’ in which case it is opinion based, at which point I would likely delete my own question.
Comments: Richard Slater
Comments: CC BY-SA 4.0
Comments: 2019-10-24T20:47:16.507Z
Comments: ok, except for the "...delete my own question ...": depending on the type of answers (ie if there are upvoted ones), *you* may not be allowed to do that (as per the rules of any SE site, which "I" did not invent ...).
Comments: Pierre.Vriens
Comments: CC BY-SA 4.0
Comments: 2019-10-25T08:05:17.390Z
Comments: This is the problem with lack of space in comments ;-)... if I get no answers and it looks like there is no value in the question existing I would just delete my own question.  I actually do it surprisingly often, as 10 minutes critical distance from my own questions often makes me realise I have made a logical error that means the question is unanswerable, or if it is answerable there would be no value in it.
Comments: Richard Slater
Comments: CC BY-SA 4.0
Comments: 2019-10-25T08:09:06.457Z
Comments: That being said, I have rephrased the question because I might have actually found the answer, need to finish watching the video before I know if it really is an answer or just noise.
Comments: Richard Slater
Tags: <sre><operations><operating-model>
Title: is there a standard or common approach to defining Service Level Indicators?
UserDisplayName: Richard Slater
ThreadText: # is there a standard or common approach to defining Service Level Indicators?
  
  (Asked by: username_0 on 2019-10-23)
  
  I've come to the point where I am starting to adopt principles from [Site Reliability Engineering](https://landing.google.com/sre/) to operate Cloud Native applications in a modern way.
  
  From my reading to date, I have established that one of the core practices is monitoring. The way that SRE approaches monitoring is by defining *Service Level Indicators (SLI)* which measure an aspect of the end-user experience, then identifying a threshold around the SLI which is called a *Service Level Objective (SLO)*.
  
  is there a standard or common approach to defining Service Level Indicators?
  
  **Tags:** sre, operations, operating-model
  
  > **Comments:**
  > **username_1**: be aware username_0: this question smells like "primarily opinion-based" ... Consider rephrasing ...  
  > **username_0**: Given that SRE as a practice seems to be quite rigorous, I would be surprised if there wasn’t a definitive answer out there.  I suspect I just haven’t encountered it, if it doesn’t exist then so be it.  
  > **username_1**: Looks like we have a different ***opinion*** (oeps) ... oh well, that's fine with me. Let's wait and see if more opinion related flags / close votes / answers come up. Good luck!  
  > **username_0**: I think this type of question can go either way, sometimes there is a commonly agreed upon answer, sometimes the answer is ‘everyone does it differently’ in which case it is opinion based, at which point I would likely delete my own question.  
  > **username_1**: ok, except for the "...delete my own question ...": depending on the type of answers (ie if there are upvoted ones), *you* may not be allowed to do that (as per the rules of any SE site, which "I" did not invent ...).  
  > **username_0**: This is the problem with lack of space in comments ;-)... if I get no answers and it looks like there is no value in the question existing I would just delete my own question.  I actually do it surprisingly often, as 10 minutes critical distance from my own questions often makes me realise I have made a logical error that means the question is unanswerable, or if it is answerable there would be no value in it.  
  > **username_0**: That being said, I have rephrased the question because I might have actually found the answer, need to finish watching the video before I know if it really is an answer or just noise.  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_0 on 2019-10-25. Score: 3
  
  Whilst not strictly a standard approach, Google has published an SLI Menu and a [process for developing SLIs for user journies](https://www.usenix.org/sites/default/files/conference/protected-files/srecon18emea_slides_fong-jones.pdf):
  
  1. For each User Journey/Data Flow identify from the SLI Menu suitable types of SLI:
  
     [![The SLI Menu](https://i.sstatic.net/guvo8.png)](https://i.sstatic.net/guvo8.png)
  2. Make a decision about how to measure **good** and **valid** events,
  3. Decide where to measure the SLI From out of the following: End User, Client-side Instrumentation, Synthetic Clients, Front-end Metrics, Application Metrics or Server-side Logging.
  
  The document then goes on to describe, how you collate all of your SLIs for all of your user journies then walk the journey to look for coverage gaps. Then finally set SLOs based upon the SLIs either based upon **business need** or **past performance**.
  
  
  ---
  
  ### Answer by username_2 on 2022-08-11. Score: 0
  
  [Keptn](https://keptn.sh) has a [specification for SLIs](https://github.com/keptn/spec/blob/master/service_level_indicator.md) and [SLOs](https://github.com/keptn/spec/blob/master/service_level_objective.md). [OpenSLO](https://openslo.com) also provide a slightly different take.
  
  
  ---
  
  ### Answer by username_3 on 2022-08-08. Score: 0
  
  I thought I'd add on one point... SLIs/SLOs are not a tool for monitoring in and by themselves.
  
  They are the basis for proactive and continuous site reliability engineering. With only a set of SLIs/SLOs you will be able to assess the service reliability over a prolonged period of time and plan around that (e.g. prioritize reliability enhancing activities over new functionality in order to improve your SLI).
  
  In order to add the monitoring aspect (i.e. early detection of a degradation of the service) you will need to add Burn Rate Alerts on top of your SLIs. Only with those you will have acceptable detection and reset time that serve the monitoring of potential issues. Burn Rate Alert Implementation is covered in Chapter 5 of the SRE Workbook: <https://sre.google/workbook/alerting-on-slos/>
  
  
  ---
  
  ### Answer by username_4 on 2020-01-29. Score: 0
  
  You have to define what matters the most to the customers (or users) in a cross functional manner, e.g dev, PM, Support, execs, SRE.
  
  For example, memory usage alone does NOT usually directly matter to the customers and most of the roles above. It does matter for capacity planning though -- so while it is not an application SLI/SLO, it may be important for devs/SRE and eventually execs (funding). There may be an internal SLI/SLO around keeping efficiency high.
  
  A mobile application taking too long to perform an operation or failing too often are likely to negatively impact many customers or a subset of customers that's very relevant to the business. These often turn out to be a customer facing cross functional issue, i.e support tickets are filed, execs may get called, SRE may be oncall trying to resolve the issue and will need to loop in feature [dev]elopers.
  
  Given all that, there is a need for cross functional metrics (SLIs) and boundaries (SLOs) that will represent customer pain/unhappiness. The absence of such common metrics tend to cause the following effect: "memory usage is low" (devs/SREs), "features have been shipped" (PM), "I didn't get a call" (execs), "users are not happy" (Support).
  
  Google has also published their workshop (under CC-BY 4.0) on how to define SLIs and SLOs:
  <https://cloud.google.com/blog/products/management-tools/learn-how-to-set-slos-for-an-sre-or-cre-practice>
  
  There is also a blog post on how to tune-up the SLIs (and SLOs) over time:
  <https://cloud.google.com/blog/products/management-tools/tune-up-your-sli-metrics-cre-life-lessons>
  
  Disclaimer: I work for Google.
  
  
  ---
  
  