Error budget policy - considerations

 

Congratulations! You passed!

Grade received 50%

To pass 50% or higher

1.

Question 1

What are some of the considerations when setting an Error Budget Policy? Choose all that apply.

0 / 1 point

The policy is consistently applied and the consequences on NOT applying it are clearly defined

Correct

Yes, a good policy explains the consequences of NOT applying it. And it’s important that the policy is consistently applied by all teams.

The policy can be renegotiated at the time of an incident

The policy is determined solely by the executive responsible for the application

The policy clearly describes how and when it should be applied

You didn’t select all the correct answers

2.

Question 2

What are some examples of criteria of thresholds set in an Error Budget Policy?

1 / 1 point

Escalating to Dev teams when the number of bugs increase over Xd

Escalating after Xh of error budget is burned

Correct

Yes, monitoring burn rate and setting a threshold for this is a good example of threshold criteria.

Paging when the SLO is violated

Correct

Yes, setting up the system to page an on-caller when the SLO has been violated is a good example of threshold set in an error budget policy

Paging when a bad push creates bugs

Commonly used SLIs

 

Congratulations! You passed!

Grade received 75%

To pass 75% or higher

1.

Question 1

What are some characteristics of SLIs? Select all that apply (2 correct responses).

1 / 1 point

A quantitative measurement of a user experience.

Correct

That’s correct! SLIs are quantitative measurements or metrics of a user experience and are best expressed as a proportion of all valid events that were good. For example, an SLI could be the proportion of HTTP requests that were served successfully.

Expressed as a proportion of all valid events that were good.

Correct

That’s correct! SLIs are quantitative measurements or metrics of a user experience and are best expressed as a proportion of all valid events that were good. For example, an SLI could be the proportion of HTTP requests that were served successfully.

They should never be used for setting SLOs.

Metrics that measure usage of an app.

2.

Question 2

Which of these is an example of an SLI?

1 / 1 point

95% of requests have low latency

Proportion of users that are happy

Proportion of HTTP requests served successfully

99% of HTTP requests are successful

Correct

Yes, that’s correct. Remember that SLIs are a measure of all good events divided by all valid events, while SLOs have reliability targets measured by SLIs.

3.

Question 3

One commonly used signifier of success or failure is the status code of an HTTP or RPC response. How can this be problematic?

0 / 1 point

You risk double counting events recorded in the application.

The response contents might not match the status code.

Your application frameworks might not give you enough control over the status code.

There are too many status codes, classifying them as good or bad can be difficult.

Incorrect

This is somewhat plausible. I mean, who can really say whether a "418 I'm a teapot" response is good or bad? But most services will only return a small subset of the available status codes, and at least for HTTP they are already grouped into different classes of success or failure.

4.

Question 4

Which of these scenarios would a quality SLI be appropriate for? Select all that apply (2 correct responses).

1 / 1 point

Returning results after searching only a subset of data to save CPU cycles when overloaded

Correct

Correct! Though the user is getting a response, as the subset of data searched gets smaller there's a larger chance that the result they were looking for is in the unsearched remainder. Not serving a user the result they want is bad for their experience, but we can only estimate the impact of this based on the size of the unsearched set.

Load balancers failing requests because they couldn't find a healthy backend

Serving stale data from cache because the database is overloaded

Correct

That's right! The user is still getting a response, but they are not seeing up-to-date data, which may degrade the quality of their experience when using the service.

Cancelling long-running operations because of a timeout