Burned by Eschewing Best Practices
-
@Dashrender said:
When you control all the pieces, local Exchange, ISP, Firewall, etc - you're able to more specifically understand the failure.
True, it assists in placing blame.
-
@scottalanmiller said:
@Dashrender said:
When you control all the pieces, local Exchange, ISP, Firewall, etc - you're able to more specifically understand the failure.
True, it assists in placing blame.
Not my fault!
-
@dafyre said:
@scottalanmiller said:
@Dashrender said:
I did this morning ask the question, why not just go to one single super awesome box... the answer 'HA.'
Pretty sure that HA was listed as a requirement. We definitely covered what I said above several times in stating that the NAS was not delivering any benefit and not meeting goals which is all it takes to get all that is stated above. Once the NAS is known to not have delivered HA, we know that all of the money around that was wasted.
The Problem that most people have with @scottalanmiller 's definition of HA, is that he uses a much more deeply defined idea of HA than what most folks do. Most people really mean Redundancy when they say HA.... To answer the question of "Will it stay up if Server A explodes?"
If their response is, "Yes, it will stay up, because it will automatically fail over with little-to-no downtime to Server B"
Then a lot of people think they have High Availability, when what they really have is Redundancy.
Even in the way that they use it, though, it's all about how you ask the question. They often state it as "if the server fails" but if you ask them "is it about keeping the services online" they would answer "yes." They all know what HA is, but they can't figure out how to get to it.
-
I think that it's more useful for even small shops to know that they have a "loss of Internet access" rather than "Exchange is down." Because in one, it makes it sound like Exchange has failed. Yes the service might not be available to the end users but it is still working to customers. Is that an outage? Is acting like it is an outage useful?
If Exchange is not accessible to end users, even if they can't tell that it is still up to others, it's far more useful to define an outage by what is actually down rather than what can't be accessed.
-
So with Exchange, you can kind of get this "but our users can't use it" perspective. Let's change that up and say your company website. If your ISP goes down and internal users cannot access the company website, do you say that your website is down or offline or has an outage? Of course not. If your customers looks, the site is up and normal. We all know that calling that an outage would be ridiculous and just being obnoxious.
But how would hosted web and hosted Exchange really be different in this case? What makes it okay to call Exchange down even when it is sending and receiving emails from the outside and not okay to call the website down under identical circumstances?
-
@scottalanmiller said:
@Dashrender said:
I did this morning ask the question, why not just go to one single super awesome box... the answer 'HA.'
Pretty sure that HA was listed as a requirement. We definitely covered what I said above several times in stating that the NAS was not delivering any benefit and not meeting goals which is all it takes to get all that is stated above. Once the NAS is known to not have delivered HA, we know that all of the money around that was wasted.
Sure you said that the NAS didn't provide HA, but you didn't spell out why - most of us, myself included when I go back 3 or so years would never read the reasons you say NAS didn't get us HA and poof we'd understand the rest automatically. You had to write that stuff out 3-5 times and me reading it before I really started to understand the situation.
-
In general, although I assume that there are exceptions, when a bunch of stuff is bought for one purpose and actually provide less of that purpose than if they had not been bought, all of the associated money was wasted
-
@scottalanmiller Again, that makes sense, but most of use don't see that just because you tell us the first part. We need time to get up to your speed.
In the case of the person in question, they have stated that they haven't been in IT all that long.
-
@scottalanmiller said:
So with Exchange, you can kind of get this "but our users can't use it" perspective. Let's change that up and say your company website. If your ISP goes down and internal users cannot access the company website, do you say that your website is down or offline or has an outage? Of course not. If your customers looks, the site is up and normal. We all know that calling that an outage would be ridiculous and just being obnoxious.
But how would hosted web and hosted Exchange really be different in this case? What makes it okay to call Exchange down even when it is sending and receiving emails from the outside and not okay to call the website down under identical circumstances?
You've lost me here.
If hosted Exchange is down then it's down. If my local ISP is down, I would never tell me users we were having an Exchange outage. -
@Dashrender said:
@scottalanmiller said:
So with Exchange, you can kind of get this "but our users can't use it" perspective. Let's change that up and say your company website. If your ISP goes down and internal users cannot access the company website, do you say that your website is down or offline or has an outage? Of course not. If your customers looks, the site is up and normal. We all know that calling that an outage would be ridiculous and just being obnoxious.
But how would hosted web and hosted Exchange really be different in this case? What makes it okay to call Exchange down even when it is sending and receiving emails from the outside and not okay to call the website down under identical circumstances?
You've lost me here.
If hosted Exchange is down then it's down. If my local ISP is down, I would never tell me users we were having an Exchange outage.But the whole question is... how do we define that the hosted Exchange is down?
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
So with Exchange, you can kind of get this "but our users can't use it" perspective. Let's change that up and say your company website. If your ISP goes down and internal users cannot access the company website, do you say that your website is down or offline or has an outage? Of course not. If your customers looks, the site is up and normal. We all know that calling that an outage would be ridiculous and just being obnoxious.
But how would hosted web and hosted Exchange really be different in this case? What makes it okay to call Exchange down even when it is sending and receiving emails from the outside and not okay to call the website down under identical circumstances?
You've lost me here.
If hosted Exchange is down then it's down. If my local ISP is down, I would never tell me users we were having an Exchange outage.But the whole question is... how do we define that the hosted Exchange is down?
How do I define it? how do 'we' define it?
Great question - I'm guessing that MS doesn't tell us the lowly users where the actual fault is, therefore the only thing we can say is... it's an Exchange outage if we can't use the service.
IF MS says.. hey our ISP is out, but Exchange itself is fine... OK great, I'm personally no longer pissed at MS (other than why don't you have 2+ ISPs with auto failover), I'm now pissed at their ISP.
Same goes if the outage is caused by Azure... I'm happy to put the blame where it belongs.. but rarely do cloud service providers tell us that information.
-
@Dashrender said:
Great question - I'm guessing that MS doesn't tell us the lowly users where the actual fault is, therefore the only thing we can say is... it's an Exchange outage if we can't use the service.
That's the issue, though, do we define it as "when Exchange is down"? Or "when the vendor encapsulated service is unavailable to everyone?" Or "when the vendor service is unavailable to an account, region, country, product?" Or "when it is down in a specific place?"
To me, you can call it an Office 365 outage when the customer does not have an option of a workaround. Which is why our Azure outage, to me, was as clear as any outage can be to being an outage. The fault was Azure, Azure was unavailable to people with whom there was on possible workaround. Only the Azure support team had any ability to bring it back up.
-
@Dashrender said:
Same goes if the outage is caused by Azure... I'm happy to put the blame where it belongs.. but rarely do cloud service providers tell us that information.
But we know when we can work around or when we cannot. At least generally speaking.
-
@scottalanmiller said:
@Dashrender said:
I did this morning ask the question, why not just go to one single super awesome box... the answer 'HA.'
Pretty sure that HA was listed as a requirement. We definitely covered what I said above several times in stating that the NAS was not delivering any benefit and not meeting goals which is all it takes to get all that is stated above. Once the NAS is known to not have delivered HA, we know that all of the money around that was wasted.
HA was listed by the OP, not necessarily by his boss. I say this because the OP indicated that his boss gets pissy every time there is an outage. Of course we can't just go guessing what's really needed, we do have to take some things at face value until we are shown that they were wrong, then change direction based on new information.
-
@scottalanmiller said:
@Dashrender said:
Same goes if the outage is caused by Azure... I'm happy to put the blame where it belongs.. but rarely do cloud service providers tell us that information.
But we know when we can work around or when we cannot. At least generally speaking.
In a cloud solution like O365, you do?
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Same goes if the outage is caused by Azure... I'm happy to put the blame where it belongs.. but rarely do cloud service providers tell us that information.
But we know when we can work around or when we cannot. At least generally speaking.
In a cloud solution like O365, you do?
Generally. While it is possible to not be the case, can you think of any circumstance where a cloud provider is not down but you cannot reach them to verify while also not knowing that you have a more significant outage?
-
You lost me again.
I think you're blending Cloud provider outages with my local onsite outages.
If O365 is having an outage - other than I can't access their services, it has nothing to do with my local services.
-
Perhaps you saying... I'm in the local helpdesk and I get a call - hey Exchange isn't responding.. is it down?
I tell them I have to look into it and get back to them.
I dig around and discover that my local ISP is down.
When I call the user back I'm not going to say, oh yeah. Exchange is down.. oh and yeah, everything else on the internet is also...
nah - instead I'm going to say - hey our connection to the internet is down. Anything we access through online services is inaccessible because of that.
-
@Dashrender said:
If O365 is having an outage - other than I can't access their services, it has nothing to do with my local services.
right, but you asked if I knew that or not. And I do, in nearly all cases.
-
@Dashrender said:
Perhaps you saying... I'm in the local helpdesk and I get a call - hey Exchange isn't responding.. is it down?
I tell them I have to look into it and get back to them.
I dig around and discover that my local ISP is down.
When I call the user back I'm not going to say, oh yeah. Exchange is down.. oh and yeah, everything else on the internet is also...
nah - instead I'm going to say - hey our connection to the internet is down. Anything we access through online services is inaccessible because of that.
Exactly. In a case like that you would know that you have no reason to suspect that Exchange is down. You can also hop on your phone and determine, almost certainly, that it is up.
