FYI, "down" has a lot of meanings which most people don't differentiate between when reporting the problem:
1) Site can't be connected to at all (connection timeout), due to one of the following:
a) DNS doesn't resolve to any IP
b) DNS resolves to the wrong IP
c) DNS resolves to the right IP, but the server is powered off or otherwise unreachable over the network
2) Site responds with a connection reset
3) Site responds with "connection refused"
4) Site responds, but is slow to load
5) Site responds but has invalid or misconfigured TLS settings, resulting in the browser showing a security error.
6) Site responds with a server error (HTTP code in the 5xx range)
7) Site responds with a 404 Object Not Found error
8) Site responds with a redirect loop, causing the browser to give a "too many redirects" error page
9) Site responds with little or no content. (Empty page)
10) Site responds with the right content, but it is abnormal:
a) Missing Images
b) Odd formatting (i.e. missing CSS)
c) Some dynamic behavior doesn't work (i.e missing JavaScript)
11) Site responds with other, unexpected content.
Saying a website is "down" is WAY too vague to be useful. Heck, at my old job I was told "Our dev site is down" and I'd have to ask "Which dev site?!" because we had several sites. Ugh.For example, "The website is down" vs "When I go to the website, I see the message 'This site can't be reached. some-invalid-website.com's server IP address could not be found.'"
All the data we are collecting is useful but seeing things directly is extremely useful. Seems the modern workplace is often becoming very abstract where everything is compartmentalized and people see only their little box.
I once got a report from a coworker that he couldn't import a text-based configuration file into an application. I was unable to reproduce the problem. It wasn't until I had a screen-sharing session with him that I saw the problem. The configuration file extension wasn't correct. It looked right at first, but then I realized that it had an extra .txt at the end of it that was being hidden by Windows. The application saw the .txt at the end of the filename and rejected the file.
Nothing wastes time like emailing/texting/chatting back and forth when a voice call and screen share are available.
Exactly. You take things for granted and suddenly all your analysis work is based on incomplete or wrong assumptions .
In the end, I think, people want their problem fixed ASAP. To that end, I make zero assumptions about what others know, especially over asynchronous communication (and it's frustrating when you're working with someone halfway around the world and only get to leave them one email per day, for example). I'm aware that it might come off a certain way, but in all honesty, more than feelings, I'm interested in getting issues fixed as quickly as possible and giving people all the info, techniques, tools, etc. they could possibly need to fix their problem now, fix a future problem, and maybe prevent this problem from happening again. I've gotten negative feedback once, and when I explained why, it seemed like they understood and there were no hard feelings.
I think of it like this, if the shoe was on the other foot, it's how I would want it to be handled. My feelings aren't hurt if someone is working from a script or dumps a set of five steps at me, four of which I already know, etc.
Strongbad's first techno song!
And "How to ask questions the smart way": http://www.catb.org/~esr/faqs/smart-questions.html
The important part is tailoring it to your environment.
Also ask yourself if your system makes issues observable and testable. If you're spending a lot of resources on support or testing, those may be features worth adding. This is hard to quantify and defend to management, so sometimes you may just wind up working on it for your own sanity.
---
What to include in your question:
ENVIRONMENT
EXCEPTION
WHAT YOU'VE DONE to localize or investigate the problem
SERVICE NAME
URL
Before you ask Is X Down? Please take a moment to ask yourself these questions:
Is the service up? (Check Cloud Provider X, Cloud Provider Y)
Is the server up?
Which environment am I asking about?
Have I checked the logs?
Have you googled the exception?
Have you looked for code related to the exception in the codebase?
BAD: The service is down.
GOOD: When I run service ms-random locally, I get the following error.
I used to support production at an automotive assembly plant. My IQ went up 10 points at least when I went to the plant floor to see the problem. People assume you don't know what you're talking about over the phone. When you show up, they believe you.
Now I'm a tech lead on an enterprise application. Daily I experience people talking past each other at all levels of expertise - architects not understanding architects, junior developers not understanding junior developers, so on forever. Nothing beats a quick demo of the issue.
I do think that this article will help people communicate better, but it's also up to people who can understand the article to take the lessons in it to their particular environment. I have a document ready for quick sharing title "The System is Down" because I've heard that particular phrase in one flavor or another WAAYYY too often with WAAYY too little context.
Oh, and calibrating the level of detail in technical conversation is very hard too, because it can lead to people feeling like they are being talked down to, or it can lead to people assuming the other person knows more than they do. It's a Hard Problem.