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
I really want to write stuff about basic troubleshooting theory because I don’t know who is teaching it.
I see endless “run this command” search results that establish nothing and have no tests for relevance to the issue.
There are themes that take so much experience to connect.
The big revelation for me, way back in the day, was this: users lie. Frequently. Not out of malice (usually) but because they don't understand, or don't think what you are suggesting will help or is really necessary, or they are sure the issue lies elsewhere. I can't tell you how many times when I used to do phone support (Quarterdeck Phone Techs Represent!) I'd have the following conversation:
Me: ok, I need you to reboot your computer.
Them (quickly): done!
Me: hmm that was very fast. Did you reboot?
Them (offended); of course i did!
Me: funny. I didn't hear the windows startup noise I heard when we rebooted before.
Them: ... oh, *reboot*. No, I just closed and re-opened the window.
Me: ಠ_ಠ
A co-worker of mine once told a customer that if he wasn't going to follow directions that was fine, he could call back later when he was ready to do so. Legend.
Point is - trust nothing. Re-verify what you're told. Even if they're smart. *Especially* if they're smart. Smart people like to assert what they believe is true as being verified truth, and often get offended you'd doubt them. Step on toes and confirm base assumptions.
