AWS prescriptive-guidance documentation change
Summary
Updated URL for Amazon Correction of Error (COE) process documentation
Security assessment
The change updates a documentation link to a more specific URL path but does not address security vulnerabilities or introduce security-related content.
Diff
diff --git a/prescriptive-guidance/latest/resilience-lifecycle-framework/stage-5.md b/prescriptive-guidance/latest/resilience-lifecycle-framework/stage-5.md index 7c874c5c6..f1bbb175a 100644 --- a//prescriptive-guidance/latest/resilience-lifecycle-framework/stage-5.md +++ b//prescriptive-guidance/latest/resilience-lifecycle-framework/stage-5.md @@ -21 +21 @@ It's critical to perform incident analysis without assigning any blame. Assume t -A good incident analysis report, like that documented in the [Amazon Correction of Error (COE) process](https://wa.aws.amazon.com/wat.concept.coe.en.html), follows a standardized format and tries to capture, in as much detail as possible, the conditions that led to an impairment of the application. The report details a time-stamped series of events and captures quantitative data (often metrics and screenshots from monitoring dashboards) that describe the measurable state of the application over the timeline. The report should capture the thought processes of operators and engineers who took action, and the information that led them to their conclusions. The report should also detail the performance of different indicators―for example, which alarms were raised, whether those alarms accurately reflected the state of the application, the time lag between events and the resulting alarms, and the time to resolve the incident. The timeline also captures the runbooks or automations that were initiated and how they helped the application regain a useful state. These elements of the timeline help your team understand the effectiveness of automated and operator responses, including how quickly they addressed the problem and how effective they were in mitigating the disruption. +A good incident analysis report, like that documented in the [Amazon Correction of Error (COE) process](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.coe.en.html), follows a standardized format and tries to capture, in as much detail as possible, the conditions that led to an impairment of the application. The report details a time-stamped series of events and captures quantitative data (often metrics and screenshots from monitoring dashboards) that describe the measurable state of the application over the timeline. The report should capture the thought processes of operators and engineers who took action, and the information that led them to their conclusions. The report should also detail the performance of different indicators―for example, which alarms were raised, whether those alarms accurately reflected the state of the application, the time lag between events and the resulting alarms, and the time to resolve the incident. The timeline also captures the runbooks or automations that were initiated and how they helped the application regain a useful state. These elements of the timeline help your team understand the effectiveness of automated and operator responses, including how quickly they addressed the problem and how effective they were in mitigating the disruption.