Tech support done bad sure makes it hard to do tech support good
- Reference: 1704443290
- News link: https://www.theregister.co.uk/2024/01/05/on_call/
- Source link:
"About two years back I was working for an online trading company as IT support manager and was on call for the week," Stuart told On Call.
At 8:00PM one evening, the dreaded support line rang with news that a price information feed was down. That sort of outage meant traders couldn't make money, so Stuart rushed to his laptop and tested the connection to the price feed provider.
[1]
It was down, and no amount of troubleshooting could reveal the cause.
[2]
[3]
Stuart described the source of the price feed as "a really big name in the financial trading world" – the sort of outfit that prides itself on resilience and therefore operated a support service of its own that was also on call at all hours.
So Stuart called, and quickly learned that his employer had once subscribed to a private feed – but a couple of years previously had asked for it to be terminated. It had been left in place for reasons nobody could recall.
[4]
Which was no use to Stuart, who rightly demanded a fix – fast.
Thankfully there was good news: a public feed of the same information was available, and all Stuart needed to do was point his server at the IP address listed in a manual.
Which didn't work.
[5]
At this point, the feed provider escalated to its second-level support team which – after failing to diagnose the issue, referring to the manual and doing all the stuff Stuart had already tried and shown did not work – escalated to third-level support.
At this point, the clock had ticked well past midnight and nobody was their best self, nor enjoying things one jot.
[6]People power made payroll support in putrid places prodigiously perilous
[7]Superuser mostly helped IT, until a BSOD saw him invent a farcical fix
[8]'The computer was sitting in a puddle of mud, with water up to the motherboard'
[9]You don't get what you don't pay for, but nobody is paid enough to be abused
Stuart was particularly unhappy as at this point traders had been hobbled for several hours, and he was beginning to imagine how he would explain the outage to bosses the next day.
Third-level support then asked a crucial question: Which version of the manual was he looking at?
Suffice to say it was an old one that contained an incorrect IP address. And the storied org that provided the price feed had been shown to be shabby at documenting its own affairs.
Stuart eventually learned the cause of the incident: the public price feed was just a little cheaper than a private feed, so his employer shifted and saved a few bucks. But nobody had bothered to finish the job. For years.
So when the crunch came, only L3 support was able to do the job.
On Call is pretty sure this is not best practice IT management!
Stuart escaped the incident without censure.
"We got half a day off with no questions asked," he told On Call.
Has tech support made it hard for you to deliver tech support? If so, [10]click here to send On Call an email and we'll try to tell your tale in a future column. ®
Get our [11]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZZfhVs0SVtuT7XcQwnVCtAAAAQk&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZZfhVs0SVtuT7XcQwnVCtAAAAQk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZZfhVs0SVtuT7XcQwnVCtAAAAQk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZZfhVs0SVtuT7XcQwnVCtAAAAQk&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZZfhVs0SVtuT7XcQwnVCtAAAAQk&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2024/01/01/on_call/
[7] https://www.theregister.com/2023/12/22/on_call/
[8] https://www.theregister.com/2023/12/21/on_call/
[9] https://www.theregister.com/2023/12/15/on_call/
[10] mailto:oncall@theregister.com
[11] https://whitepapers.theregister.com/
Re: A penny saved and a pound lost
I don't think that was the issue here.
The issue was the previous tech only did half a job. Why didn't they finish it? Who knows. They may have decided they couldn't be arsed. They may have decided it was enough. They may have been called away for a family emergency and never returned to finish it.
Re: A penny saved and a pound lost
You are technically correct (the right kind of correct) , but you have to consider the consequences too. The downtime probably cost more than the difference between the cheap and expensive subscription over quite some time.
Looks like "Stuart" got more than his fair share of stress...
I hope he's now taken stock of the situation
And traded for a less stressful position
It's odd to see an exchange problem not caused by Microsoft...
He should certainly consider his options ....
The easiest way to make a small fortune on the Stock Market .....
..... is to start with a large fortune!
Re: The easiest way to make a small fortune on the Stock Market .....
As with in a gold rush you make money by selling mining equipment, you make money on the stock market by selling trading systems. I used to work for a data and trading equipment supplier for the HK Stock Exchange. They had so many data lines coming into the office that HK Telecom installed an exchange on the next floor for our exclusive use. ;)
Its always DNS except when its configured with an IP address :)
How much suffering could have been avoided if the ticker server(s) had been configured from a DNS entry?
eg ticker.themarkets.com.
One doesn't have to been in this game for as long as moi to realize names invariably outlive addresses.
Even after acquisitions and other skulduggery a vestigal CNAME to the new band of thieves usually persists (for decades in many cases.) (Musk and other lunatics excepted.)
Re: Its always DNS except when its configured with an IP address :)
The problem in this scenario is that they were using the IP equivalent of private123.ticker.com, but should have moved to public.ticker.com when they cancelled their sub to the private ticker.
In this case, it's likely the private123 domain would at some point be removed, rather than CNAMEd to the public domain, so issue would still occur.
Using domain name is also not infallible. I've had plenty of cases at multiple employers where outbound access was restricted in firewalls using IP addresses (layer 3), but apps were connecting outbound using domain names (layer 7). If the vendor of the service you are connecting to changes IP range without prior notice, that still leads to connection failures. These days layer 7 whitelisting in firewalls can resolve that, as can setting up special prices to manage outbound connections.
Prior to having access to firewalls with layer 7 capability, our best solution was to use a tool we had built for outbound throttling, but using it as a proxy for connections that were going to cloud based services that could not guarantee the IP range they would be using. It was usually anti DDoS measures (and then cloud) that meant we had to use it. We found it also provided a way for us to also lock down some of our servers, so we had less holes opened up in the main firewall
Many big words in title
Long much bad, short gooder.
Re: Many big words in title
Maybe Simon intended it to be typical El Reg irony - not so sure in this case...
Ah, the old forgotten bit ...
I'm sure all of us have had a moment when an alert pops up and no one has any idea (a) where it's coming from and (b) what it does.
Little tip: if you ensure you do a grown-up test of your UPSs by actually shutting things down (because as long as the mains is connected the battery remaining is a guesstimate you really don't want to rely on) you can winkle out some dinosaur processes.
Also restarting your comms to flush out DHCP reservation issues.
A penny saved and a pound lost
...the public price feed was just a little cheaper than a private feed, so his employer shifted and saved a few bucks.
Haven't we all seen the disasters of doing things on the cheap?