I have, a number of times now, joined a P1/P2 incident bridge, and helped fix it from curiosity.
I observe for a bit and gently push them to establish basic facts of their assumptions. I’m not even a party to the problem. Failure is interesting.
And suddenly things start moving…
Here’s a recent example.
If you are STUCK in an intractable problem, RE-ESTABLISH YOUR BASIC ASSUMED KNOWLEDGE. ~~GO BACK~~
What told you this was a problem? What does EVERY relevant log say in that timeframe and in general? Do the underlying protocol negotiations even work?
https://x.com/swiftonsecurity/status/1677483984438149120
@SwiftOnSecurity It's AMAZING how many times "but what does the error message SAY?" pointed to a resolution for a P1 outage. After multiple very smart people had spent an hour+ working on the issue.
I typically insist on a screenshot or at least cut-and-paste of the error message in context, and ideally with the command or activity they dud to trigger it. It can be stunning how often the issue is just a typo that was missed because they stared at it for too long - and I am guilty of that myself.
