I don't think that having "things" in the mix extends troubleshooting.
My experience is that problems generally fall into 2 buckets:
1) Textbook ones (mistyped IP address, overload that's readily visible
if they had looked at the reports, or like you said full hard disk)
The time-suck in these are techs who aren't very experienced, or skilled
or organized (or all the above)
With these, adding more stuff seems like it extends troubleshooting -
but the real reason troubleshooting is extended is not because you added
more stuff it's because your troubleshooting staff isn't up to snuff.
Kind of like you drafted Billy Joe Bob from Hayseed to troubleshoot your
2015 Chevy Volt and it extended the time troubleshooting because he's
still looking for the carburetor.
People only blame the car for that because they don't want to face old
Billy Bob and say 'dude your incompetent, hit the books or get the F out
of the business"
We live in a complex world that's getting more complex every day. If
you want to be a tech, then deal with it, up your game. When your
spending the same effort hitting the books as you are playing Warcraft
then I'll have some sympathy. Otherwise go join the line of people
sucking off the social services.
2) really knotty ones that take a lot of time, like intermittent failures.
With those, it's very hard to draw correlations. I have seen some very
simple, basic, 1-protocol setups that had really oddball problems that
took a great while to track down.
Just my $0.02
Ted
On 3/27/2015 6:37 AM, Jens Link wrote:
Ted Mittelstaedt<[email protected]> writes:
But as for operations costs, I would say, zero
I don't agree. In a dual-stacked environment there is more work to do.
1. Setting up Servers (and Services)
You have at least two addresses to configure, which leads to two DNS
records, two services to be monitored, more firewall rules, ... And in
the end more things to document.
2. Troubleshooting
When looking for problems you always have to remember that there are now two
protocols and then the fun begins: Is this problem only v4? Or only
v6? Or do have a completely different problem.
3. Layer 8+9
People have little or no experience with IPv6. They need more time to
configure stuff and troubleshoot problems. And they will forget to
configure one thing or the other and they will forget that there are
two protocols to troubleshoot.And then there will always be people
who don't want IPv6 an will always blame it[1].
The reason is if you don't deploy sooner or later you will have a
problem related to IPv6.
Ack.
Then you will spends lots of time finding and correcting. That time
is roughly equal to the extremely small amount of additional time that
the techs deal with IPv6 on a network that has had it properly setup.
It will be worse. When you start implementing IPv6 because the latest
version of your critical application requires IPv6 and you need IPv6
tomorrow you'll have a real problem. You have to touch many things at
once, you may have to buy hardware and you'll be looking for qualified
external support. Problem is: Many other companies will do the same.
I'll have to remember to buy a big stash of T-Shirts with "Told you so!"
Jens
[1] Someone told me a story about a database server which stopped
working after IPv6 was deployed. The DB amdin blamed the IPv6
deployment. Of course it hat nothing to do with IPv6, the hard drive was
full.
