Improving resiliency with correction of error processes
summary
A COE that finds and fixes the actual failure is shown end to end: a JSON upload app loses over 10,000 files because a Transformer Lambda error (invalid data type) never surfaced and no error metrics existed; detection comes from the contact center at 09:45 and the service team restores customers by 11:38:24. The demo builds post‑incident docs, adds metrics (Lambda error rate, DynamoDB updates), assigns owners and due dates, and records everything in Incident Manager so runbooks and automation can prevent recurrence.
AI-written summary · about
chapters (20)
- 0:00Intro
- 0:47Organizations around the world depend on architectural best practices to help them build workloads and applications
- 1:26Agenda 1. Why is the correction of error CoEl process important?
- 3:48The uptime flywheel
- 5:46Benefits of correction of error (COE) process
- 7:03Correction of error (COE) document
- 8:55When is a correction of error (COE) necessary?
- 10:44Who owns a correction of error (COE)?
- 12:51General tips for writing correction of error (COE)
- 14:38Anatomy of a COE
- 26:54The 5 (or more) whys Getting at the root cause of the problem
- 28:35Action Items Who's going to implement what fees and when?
- 31:05Example architecture before
- 31:42Example failure scenario
- 32:44Example Impact
- 33:17Example timeline
- 33:45Example metrics
- 34:11Example Incident questions
- 36:06Example 5 (or more) whys The application crashed
- 48:42Employ architecture best practices using AWS Well-Architected and AWS solutions
related talks
26mA proactive approach to resilience in modern apps
30mThe last in the line: a talk about DevOps and Disasters
34mToward continuous resilience
26mHow to survive a Lambda-induced data tsunami in AWS
55mEngineer application resilience with compliance in mind
40mSh... Fail Happens: Fail-aware Events Processing on AWS
36mObserving all the Serverless Things
31mPreparing for downtime when all you want is uptime