AWS prescriptive-guidance documentation change
Summary
Simplified incident learning processes for startups, emphasizing lightweight post-mortems and integration with existing workflows
Security assessment
Changes focus on operational resilience improvements through incident analysis processes, not specific security vulnerabilities or security feature implementations. While incident response can impact security posture, there's no direct evidence of addressing security vulnerabilities or weaknesses.
Diff
diff --git a/prescriptive-guidance/latest/startup-resiliency-baseline/stage-5.md b/prescriptive-guidance/latest/startup-resiliency-baseline/stage-5.md index 9fdbc2820..0c6120741 100644 --- a//prescriptive-guidance/latest/startup-resiliency-baseline/stage-5.md +++ b//prescriptive-guidance/latest/startup-resiliency-baseline/stage-5.md @@ -3 +3 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Startup Resiliency Baseline (AWS SRB)](introduction.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Startup Resiliency Baseline](introduction.html) @@ -7 +7 @@ -Even with all the above practices, events might occur that influence the overall resiliency of the application. It's is important to learn from these experiences when they occur. This stage focuses on implementing practices to respond and capture learnings from such disruptive events. Many startups have a team that works very closely and have limited resources for this phase. However, it's important to use standard mechanisms for a consistent and ongoing focus on resiliency. We recommend that you implement the following mechanisms: +When you're running a startup, complex post-mortem processes can slow down your team. This chapter explores how to learn from incidents without turning them into bureaucratic exercises. @@ -9 +9 @@ Even with all the above practices, events might occur that influence the overall - * **Incident analysis** – Use your existing ticketing systems or project management systems to capture important details. You don't need to set up a new tool or process to focus on post-event reporting. Capture details of the event, such as what lead to the impairment, screen captures of alarms or dashboards, what actions were taken to fix it, and what actions were taken to avoid it in future. +Integrate incident learning into your existing rhythms. If your team already has regular meetings, use ten minutes to discuss recent incidents. Focus on practical questions, such as: @@ -11 +11 @@ Even with all the above practices, events might occur that influence the overall - * **Conduct reviews** – Review follow-up actions from incidents in regular team discussions to track progress. This provides the whole team with an opportunity to learn from the event. Assign owners and clearly define next steps. + * Did the runbooks help? @@ -13 +13 @@ Even with all the above practices, events might occur that influence the overall - * **Incident knowledge base** – Capturing details as the event progresses saves time later. This helps create a searchable knowledge base as your team expands. Use lightweight tools, such as shared docs, chat tools, bug-tracking features in existing ticketing systems, or wikis. Create a standardized template to record details from incident analysis and reviews. + * Did the alerts happen at the right time? @@ -14,0 +15 @@ Even with all the above practices, events might occur that influence the overall + * Could AWS managed services have prevented this? @@ -17,0 +19,9 @@ Even with all the above practices, events might occur that influence the overall + +Stay focused on actions, not blame. In a startup, you're not building a perfect system; you're building one that gets better every time something goes wrong. + +You can use your ticketing system to track incidents; there's no need for specialized tools. Create a simple template that includes the incident timeline, customer impact, recovery steps taken, and lessons learned. This cam become institutional memory if you actively use it. Review past incidents during onboarding to bring new engineers up to speed. Reference them in architecture reviews when designing similar systems. Pull them into game days to create realistic failure scenarios based on actual events. The template captures what happened, and regular use transforms it into organizational learning. + +As startups grow, patterns emerge. Maybe certain components fail more often, or perhaps particular types of changes cause problems. Use these patterns to guide resilience investments. If database failovers cause issues, consider improving your multiple Availability Zone setup. If third-party service disruptions are a common theme, consider improving circuit breakers. + +The goal isn't to prevent every possible failure. That's impossible and would slow you down too much. The goal is to learn fast, adapt quickly, and keep the application reliable enough while you're growing rapidly. Use each incident as a chance to make your system a little more resilient, your team a little more knowledgeable, and your customers a little more confident in your service. For startups, speed and learning beat perfection. Create lightweight processes that help you learn from incidents without slowing innovation. The best resilience practices are the ones your team actually uses. + @@ -26 +36 @@ Stage 4: Operate -Conclusion +Next steps