You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/devops-methodology/root-cause-analysis-postmortem/postmortem-example.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,8 +74,8 @@ The site experienced the classic cascading failure that affected all components
74
74
75
75
## Unexplained problems
76
76
77
-
- During the rollout, API keys for the `amazon-associates-link-builder` plugin got cleared 
78
-
- During the rollout, TablePress options got cleared 
77
+
- During the rollout, API keys for the `amazon-associates-link-builder` plugin got cleared 
78
+
- During the rollout, TablePress options got cleared 
79
79
80
80
## Remediations
81
81
@@ -92,7 +92,7 @@ List of actions performed to resolve the problem:
92
92
93
93
### Short term
94
94
95
-
- Varnish health probe should ping synthetic URI (e.g. /healthcheck) that only tests varnish, [not backends](https://github.com/gadgetreview/wordpress/blob/master/.ebextensions/80-monit.config#L174)
95
+
- Varnish health probe should ping synthetic URI (e.g. /healthcheck) that only tests varnish, not backends
96
96
- PHP-FPM should not use persistent mysqli connections
97
97
- Ensure wp-plugins are all explicitly activated/deactivated as part of deployment
98
98
- Investigate what happens if wordpress plugin activated before all servers upgraded
@@ -126,7 +126,7 @@ Prior to rollout, all 3 production instances indicated high memory pressure (90%
126
126
127
127
### Elastic Beanstalk
128
128
129
-
ElasticBeanstalk saw a massive increase in requests which manifested as a Denial of Service Attack. This was triggered probably by mod_pagespeed generating pages for webp assets which could not be served by upgraded servers. Varnish does not cache 404s.
129
+
ElasticBeanstalk saw a massive increase in requests which manifested as a Denial of Service Attack. This was triggered probably by mod_pagespeed generating pages for webp assets which could not be served by upgraded servers. Varnish does not cache 404s.
0 commit comments