technology, networking, virtualization and IP telephony
If you have been under a rock for the past 6+ months you might need to take notice.
On July 12th this blog will be participating in an “INTERNET-WIDE DAY OF ACTION TO SAVE NET NEUTRALITY” in order to help raise awareness and spur action on a part of the masses.
Cheers!
I recently read Tom Hollingsworth’s post titled “Is It Really Always The Network?” and immediately thought, I need to find time to post a reply. I’ve been in this industry for more than 20 years now and it has been a constant struggle to educate and train those around me to perform their due diligence before issuing the knee-jerk response that “it must be the network.” If you don’t understand the problem then ask for help, don’t pretend to understand the problem and then assign blame when you have no idea what you are talking about. I suspect people are getting worse and not better, although I almost wonder if people are getting lazier and just want someone else to fix their problems. Last week I had two examples of people throwing sh*t over the wall without the even performing the most basic troubleshooting steps and as you can already guess I was pissed.
In the first example, a SOAP/XML interface to a third-party wasn’t accepting transactions. Well that’s proof positive that it’s a network problem, right? A simple “telnet” test to the IP address and port from the origin server was successful. Yet the response from the team reporting the problem? “If it’s not the network we don’t know what to-do next” which left me speechless. After a 15 minute conference call, I had the third-party restart their back-end service and magically transactions started flowing again.
“If it’s not the network we don’t know what to-do next” 15 minutes later “oh, we restarted the back-end service and it’s working now”. Doh!
— Michael McNamara (@mfMcNamara) January 17, 2017
In another example, I was notified that a SOAP/XML interface that we host on the public Internet was inaccessible – must be a network issue. I verified that I was unable to connect to that specific host from the internal network on the TCP port specified and advised that they should check the specific host in question, I was rebuked by the application analyst telling me, “Nginx is up and running”. A co-worker remotely connected to the specific server and found Nginx prompting for the passphrase (password) for the SSL certificate that Nginx was trying to load. The team in question had never even checked the server.
It’s one thing to say ‘I don’t know what’s going on here and can you help me”. It’s a completely different thing to say “it’s a network problem, you need to fix it”, especially when it becomes abundantly clear that the team/person making this statement has done zero troubleshooting or due diligence and doesn’t even understand the details of the problem.
Occasionally we run into a genuine problem, yes they do occur. Unfortunately I’ve heard too many crying wolf stories that I almost never trust what I hear until I verify all the details myself.
How about this, I’ll take your credit card (Visa, Mastercard, Discover, no Amex) and if it’s a network problem I won’t bill you. However, if it’s not a network problem I’ll be sure to make it painful enough that the next time you’ll definitely do your homework before you come calling.
I’ll close this post out with the following line,
Cheers!
In a previous podcast, Network Broadcast Storm Episode 5 – Network Monitoring, I talked very briefly about technical debt but after listening to the show I thought I really didn’t do the topic any favors so I thought I’d write about it here briefly. I see technical debt as anything you do in taking a shortcut that could jeopardize the operation of your solution or its underlying design. The term technical debt is often referred to in software coding but it applies equally to networking and systems administration. I’ve occasionally heard the term “skeletons in the closet” used to describe the same. Often we have both timeline and budget constraints that push technical debt upon us, shortcuts here and there that eventually catch up with all of us and ultimately can bring the house of cards crumbling down around us. In my day to day I’m usually fighting either the clock or the budget, struggling to find the time and resources to-do the proper research and then test the configurations or trying to figure out how to get by with some budget $$$ amount that someone else came up with and really leaves some significant shortfalls in the design. Technical debt can be as simple as failing to-do the redundancy and failover testing or it can be more material such as having a single power supply in your only domain controller or having both power supplies in your only domain controller connecting to a single PDU. I often have discussions, I would occasionally call them negotiations, with my management team trying to convince them where we can be frugal and where we just can’t afford to cut corners.
It’s our jobs as the technical experts in our various fields to help educate and advise our employers or clients when determining timelines and project budgets. The goal is to strike a balance, if our employer or client is only worried about 99% uptime then we can reduce the design appropriately. If they are willing to accept 802.11n instead of 802.11ac, or 100Mbps to the desktop instead of 1Gbps to the desktop, or 1Gbps uplinks instead of 10Gbps uplinks those are all compromises that directly impact the design requirements and ultimately the costs. In my opinion the key is striking a good balance between cost, time, features and requirements.
I’m usually pretty passionate about technical debt because if the solution doesn’t work who do you think the users will be coming back to? Who is the help desk going to be calling at 2AM on a long holiday weekend?
What do you think? Any stories to share?
Cheers!
Image Credit: Pierre Amerlynck
I just recently finished listening to, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr and George Spafford. It was both a confirmation of the day to day struggles for those of us working in Information Technology and an enlightening book. I’m currently working in the retail vertical so the fictional Parts Unlimited story had many similarities to my current day responsibilities and struggles. In my personal career I’m currently challenged with making the leap from being a “Brent” type resource to trying to figure out how to best manage a large infrastructure and a medium sized team all while trying to be a force multiplier for the organization as a whole. It’s not enough that you can quickly identify a problem and correct it, you really need to disseminate that skillset to your entire team thereby being a force multiplier.
Almost every aspect of the book matched some experience I’ve had over the past 20+ years working in IT. All too often IT is viewed as just a cost center or a road block when IT should be an integral part of the business. In the end of the book everything worked out for Bill and his team, unfortunately the real world isn’t all that easy, in some cases there’s no convincing the captain that he/she should change course until the ship literally hits the rocks and sinks, and then you can say “I told you so”.
If you’ve read the book let me know what you thought? If you haven’t read or listened to the book I would highly recommend it.
Cheers!
In 2011 I wrote about Mayor Michael Nutter of Philadelphia trying to pass a soda tax in an article entitled, Philadelphia Soda Tax: You’re not serious? Fast forward five years later and Mayor Jim Kenney is trying his hand at the soda tax as well. As I said back in 2011, I support funding our schools and parks but we need government to make better decisions with the tax money they are already receiving. I’m not a big soda drinker and while the tax won’t impact me too much personally, I’m objecting more on principle. Who’s to say they’ll stop at taxing just soda. You want a candy bar, that will be an additional tax. You want your steak rare, that will be an additional tax.
I was about to add liquor tax, but that’s already taxed in Philadelphia at 10% of retail sales. The soda tax is only a few pennies right? In the current proposal, Philadelphia’s proposed tax could add 36 cents to the cost of a 12-ounce can of soda – and 54 cents to the cost of a fountain drink of the same size.
In November 2014 Berkeley, Calif., became the first U.S. city to pass a law taxing soda. In 2013 New York Mayor Michael Bloomberg attempted to ban large size fountain drinks but was blocked by the courts. From the reports in the local newspapers it appears that Mayor Kenney has the votes needed to pass his soda tax.
I’m just concerned what other taxes will potentially follow. How long before they raise the tax to make up additional shortfalls?
What do you think? Is taxing soda the approach to getting America healthier? What do you think could be next?
Cheers!