You support a service that recently had an outage. The outage was caused by a new release that exhausted the service memory resources. You rolled back the release successfully to mitigate the impact on users. You are now in charge of the post-mortem for the outage. You want to follow Site Reliability Engineering practices when developing the post-mortem. What should you do?

Question

Accepted Answer

B. Focus on identifying the contributing causes of the incident rather than the individual responsible Site Reliability Engineering (SRE) post-mortems emphasize a blameless culture to foster an environment where engineers can openly share what happened without fear of punishment. This approach encourages focusing on systemic improvements, process deficiencies, and contributing factors, which leads to more effective learning and prevention of future incidents.

Answer

A. Focus on developing new features rather than avoiding the outages from recurring. Focusing on new features instead of learning from outages contradicts the primary purpose of a post-mortem, which is to prevent recurrence and improve reliability.

Answer

C. Plan individual meetings with all the engineers involved. Determine who approved and pushed Planning individual meetings to determine who approved and pushed the release is an approach centered on assigning individual blame, directly opposing the blameless culture fundamental to SRE post-mortems.

Answer

D. Use the Git history to find the related code commit. Prevent the engineer who made that commit Preventing an engineer from committing code based on a single incident is punitive and counterproductive to a blameless culture, hindering learning and trust within the team.

You support a service that recently had an outage. The outage was caused by a new release that exhausted the service memory resources. You rolled back the release successfully to mitigate the impact…

Question

Options

How the community answered

Why each option

Topics

Community Discussion