Burned by Eschewing Best Practices
-
@DustinB3403 said in Burned by Eschewing Best Practices:
Burned by thinking money isn't an issue. Oh and IPOD.
And he know's he's burned by bad design.
yeah, he just gave too much in the OP so it was really confusing.
-
https://community.spiceworks.com/topic/2004966-dwell-poweredge-t110-raid-10-issue
Oh man. Pulled drives in a really bad way.
-
@scottalanmiller said in Burned by Eschewing Best Practices:
https://community.spiceworks.com/topic/2004966-dwell-poweredge-t110-raid-10-issue
Oh man. Pulled drives in a really bad way.
feels bad man -
As much as that thing was set up poorly, he prompted the disaster. He had time to ask what to do before he did it and didn't bother and did the one thing that you really never do, then he did the second thing that you never do. Had he Googled at all, he'd have been fine. Had he followed proper procedures, he would have been fine. If he would have called the vendor, he'd have been fine. So many ways to have not had this happen.
-
@scottalanmiller said in Burned by Eschewing Best Practices:
As much as that thing was set up poorly, he prompted the disaster. He had time to ask what to do before he did it and didn't bother and did the one thing that you really never do, then he did the second thing that you never do. Had he Googled at all, he'd have been fine. Had he followed proper procedures, he would have been fine. If he would have called the vendor, he'd have been fine. So many ways to have not had this happen.
He probably didn't want to tell the client "let me Google that"
-
@DustinB3403 said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
As much as that thing was set up poorly, he prompted the disaster. He had time to ask what to do before he did it and didn't bother and did the one thing that you really never do, then he did the second thing that you never do. Had he Googled at all, he'd have been fine. Had he followed proper procedures, he would have been fine. If he would have called the vendor, he'd have been fine. So many ways to have not had this happen.
He probably didn't want to tell the client "let me Google that"
We need to call the vendor is definitely good in this situation though
-
Really sounds like an IPOD issue here, but he has 3 NAS which are hosting his VM's, but for some reason no longer work with Hyper-V.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
As much as that thing was set up poorly, he prompted the disaster. He had time to ask what to do before he did it and didn't bother and did the one thing that you really never do, then he did the second thing that you never do. Had he Googled at all, he'd have been fine. Had he followed proper procedures, he would have been fine. If he would have called the vendor, he'd have been fine. So many ways to have not had this happen.
He probably didn't want to tell the client "let me Google that"
He didn't need to tell them, he needed to just do it.
-
Violated the "First Rule of VoIP"... he went to his ISP for his SIP trunk. Big time burned. Also, expected his ISP to inform him of the small print and tried to blame them for his mistakes.
https://community.spiceworks.com/topic/2005735-sip-redundancy
-
SSD RAID1 array for hypervisors and QNAP SAN configured for RAID 5 for VM storage.
And wonders why his system is running like crap for the past few days.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
SSD RAID1 array for hypervisors and QNAP SAN configured for RAID 5 for VM storage.
And wonders why his system is running like crap for the past few days.
Over a 1GB switch... I get that it's supported and should work but if they are pushing storage traffic over it they may hit a bottleneck...
Although I doubt that QNAP has enough throughput for this.
-
@coliver And he's stopped responding to the topic.
The last response was "No ISCSI target"
-
@scottalanmiller said in Burned by Eschewing Best Practices:
Violated the "First Rule of VoIP"... he went to his ISP for his SIP trunk. Big time burned
I've never heard of this rule. I've had the same ISP and SIP trunk provider for the last few years (BT). Can you expand, please?
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
Violated the "First Rule of VoIP"... he went to his ISP for his SIP trunk. Big time burned
I've never heard of this rule. I've had the same ISP and SIP trunk provider for the last few years (BT). Can you expand, please?
There is a full post on it yesterday. Scroll down your recent posts. The title is the same "First Rule of VoIP". That's got a good breakdown. I'm not in a spot to find the link.
It came up twice just yesterday on SW. Normally comes up once or twice a week. That is the top reason why people get burned with VoIP. And the one that we can't save people from. Everything else we can fix.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
Violated the "First Rule of VoIP"... he went to his ISP for his SIP trunk. Big time burned
I've never heard of this rule. I've had the same ISP and SIP trunk provider for the last few years (BT). Can you expand, please?
I'd really call these Scott Allan Miller rules - though there is credibility there.
Scott is of the opinion that you should use as few as possible services on a single vendor. This allows you to break from a given vendor more easily if they start acting in bad faith.
i.e. You get your internet connection from your ISP, you host a website locally (which you shouldn't do - but that's another thread). You should NOT use your ISP's DNS service to hot your public DNS services because you have artificial lock-in with the ISP now. Even worse, you should not purchase your Domain name from your ISP if they happen to resell them.
Another example,
You purchase hosting services for a WordPress site from a vendor. You should Not buy your Domain Name through them, nor should you use them to host your DNS. All of these services should be on separate services. -
@Dashrender said in Burned by Eschewing Best Practices:
I'd really call these Scott Allan Miller rules - though there is credibility there.
That could explain why I haven't heard it before
I've found and read the thread, but don't really get it. But phone systems aren't my area. I don't even know exactly what he means by "phone system". We have contract with BT for a leased line, and we have another contract with BT for SIP trunks, and we have another contract with BT for phonecalls (if that's the right term). The first two contracts are not related, and as far as I'm aware, there is nothing to stop us from dropping one contract but keeping the other. The phonecalls are related to the SIP trunks, as all our calls are free based on us renting the SIP trunks.
Obviously telecoms various work differently in different countries, so maybe there isn't a standard rule?
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
I'd really call these Scott Allan Miller rules - though there is credibility there.
That could explain why I haven't heard it before
I've found and read the thread, but don't really get it. But phone systems aren't my area. I don't even know exactly what he means by "phone system". We have contract with BT for a leased line, and we have another contract with BT for SIP trunks, and we have another contract with BT for phonecalls (if that's the right term). The first two contracts are not related, and as far as I'm aware, there is nothing to stop us from dropping one contract but keeping the other. The phonecalls are related to the SIP trunks, as all our calls are free based on us renting the SIP trunks.
Obviously telecoms various work differently in different countries, so maybe there isn't a standard rule?
I wonder what the difference between your SIP contract and your Phonecalls contract is? For most people it's one in the same.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
I'd really call these Scott Allan Miller rules - though there is credibility there.
That could explain why I haven't heard it before
I've found and read the thread, but don't really get it. But phone systems aren't my area. I don't even know exactly what he means by "phone system". We have contract with BT for a leased line, and we have another contract with BT for SIP trunks, and we have another contract with BT for phonecalls (if that's the right term). The first two contracts are not related, and as far as I'm aware, there is nothing to stop us from dropping one contract but keeping the other. The phonecalls are related to the SIP trunks, as all our calls are free based on us renting the SIP trunks.
Obviously telecoms various work differently in different countries, so maybe there isn't a standard rule?
Is BT also your internet provider?
-
Here is my setup, which is fairly unique.
cable modem connection to the internet 100/20 - no contract, pay month to month
SIP trunks, these are delivered over an onsite fiber connection between me and that same ISP. The ISP has a SIP Gateway device onsite that they connect to, then there is an ethernet connection on gateway device that connects to my PBX. I pay a flat fee for unlimited local calling, and a per/min fee for long distance. - no contract, pay month to month
-
A more normal SIP delivery solution is as follows:
You purchase Internet connection from and ISP.
You purchase SIP trunks from a SIP provider different from your ISP.
The SIP trunks are delivered over your ISP connection via the internet.
If your Internet connection goes down, you can use a different internet connection to bring the SIP trunks into your location, for example, your cell phone, and your calls could resume working.
This is a very simplistic explanation.
