AWS prescriptive-guidance documentation change
Summary
Updated breadcrumb navigation and modified URL for Amazon Correction of Error (COE) process documentation.
Security assessment
URL update appears to be a routine documentation maintenance change. The COE process relates to general incident management, not specific security vulnerabilities or security feature documentation.
Diff
diff --git a/prescriptive-guidance/latest/resilience-lifecycle-framework/stage-5.md b/prescriptive-guidance/latest/resilience-lifecycle-framework/stage-5.md index 6ae6d3ca1..466b30e73 100644 --- a//prescriptive-guidance/latest/resilience-lifecycle-framework/stage-5.md +++ b//prescriptive-guidance/latest/resilience-lifecycle-framework/stage-5.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Resilience lifecycle framework](introduction.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Resilience lifecycle framework: A continuous approach to resilience improvement](introduction.html) @@ -23 +23 @@ 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/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. +A good incident analysis report, like that documented in the [Amazon Correction of Error (COE) process](https://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.