It's a Network Thing... They Don't Understand...

[killabee]

I'm starting to think the ITIL guys are the worst.  They seem to live and breath flow carts and diagrams. 

Supposedly every change warrants a change ticket, and even if you make a change to fix something that broke then it still requires a change ticket.  When I asked, "what if we turn into an environment where the paperwork presents huge roadblocks for even minor, insignificant, non-impaction changes?" I got back: "Then we become an environment with very few outages."  Talk about drinking the ITIL Kool-Aid....

Maybe the ITIL statistics are right, and maybe change tickets do help (I believe so to a point)...I still think in a perfect world we should have a middle ground where we can be trusted with minor changes.  At the moment, though, I'm not looking to champion that movement.

[deanwebb]

If you have to do a ticket every time you make a change, then you won't make changes. Increased uptime!

[wintermute000]

That's exactly what happens IRL. make the process hard and people will avoid it. Forget using initiative and cleaning up little mistakes or suboptimal configurations. 

[Seittit]

For me, the worst group of people in IT are people that only do enough to get by and have no desire to further themselves within their career. The same individuals that look at you crazy when you bring Cisco Press books to work for reading on your breaks; they also are the people sweating bullets when layoffs are on the outlook (hello fellow energy corridor peeps)

I used to make fun of server people until I became a member of a team with some OUTSTANDING server peeps.

With that said, my experience shows that VoIP peeps are the shakiest in their skill-sets.

[wintermute000]

Correction: VOIP guys who only know VOIP are shaky. Esp. bastard vendor-specific implementations that even when implementing SIP endpoints throw in non SIP signalling for various events and do not understand standard SIP parameters like a proxy *cough* Cisco *cough* and sell 'SBCs' that don't do endpoint proxy registration and use the world's worst number routing syntax (who the heck thought 'dial peers' was a good idea).

Us router guys who were forced to run call managers (betraying my age there... I lived through the manually patching Win2000 based CallManager 4.1 days) due to the whims of fate, we do understand that the network is our backplane LOL. Also, carrier SIP guys know their stuff.


I'd say in general i agree with devs being the worst. For some reason that probably requires more social demographic analysis, enteprise devs seem to be the bottom of the dev barrel. Their view of ALL infrastructure (not just network, they do the same to server and vmware guys as well) is that its a black box. Which astounds me as you would think a programmer would want to understand how things worked....


Dev: "the network is down my app doesn't work".
Network: "ok what server / where is your app hosted".
Dev: "what?"
Network: "OK fine I'll trawl some firewall logs, what port does your application use?"
Dev: "you tell me, you're the network guy"

[deanwebb]

I have "Fallacies of Distributed Computing" posted in my cube and I refer to it on occasion.
Here are the fallacies:

1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.

[LynK]

Developers are HANDS DOWN the worst.

Fun little story,

In our environment we have a VERY VERY OLD oracle 8i 32bit ERP system. Needless to say, CIO says she wants everything 64bit, and we need to get off of the old system and move on past the 90s. 2 Days before the deadline they come to her and say, we cannot get 64bit working, we are going to use a hacked 32bit client to make this work.

here we are on 32bit.



Or how about the:

we are implementing our F5s in our DMZ environment load-balancing our web servers.

I ask, do the web servers respond in anyway to the clients directly (or grab resources directly), answer is no. 2 months later here we are inserting in x-forward-for so web servers can handle client public IPs..... the list can go on and on.

[Seittit]

I have "Fallacies of Distributed Computing" posted in my cube and I refer to it on occasion.
Here are the fallacies:

1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.

9. There is no spoon

[Atrum]

I ask, do the web servers respond in anyway to the clients directly (or grab resources directly), answer is no. 2 months later here we are inserting in x-forward-for so web servers can handle client public

I deal with exactly that scenario at least 2-3x per week.

[wintermute000]

hmmm i have very limited LB experience but in a 'typical' 2 arm deployment doesn't a LB (typically) source NAT the incoming client IP? so the web server should see only the hide IP?

or do you mean that the web app/site uses IP addresses @ layer 7?

[Atrum]

hmmm i have very limited LB experience but in a 'typical' 2 arm deployment doesn't a LB (typically) source NAT the incoming client IP? so the web server should see only the hide IP?

or do you mean that the web app/site uses IP addresses @ layer 7?

Typical deployment would use SNAT of some type, changing the source IP.

A surprising amount of applications require the actual client IP address to work properly so you either need to implement X-Forwarded-For or adjust your routing so that SNAT isn't needed.

[SofaKing]

Developers make me want to 

[deanwebb]

Maybe I should make that display when someone types in ...

[Reggle]

Maybe I should make that display when someone types in ...

Don't hesitate. Do.

[deanwebb]

Done.



For those just joining in on the action, type in a colon, then developers, then a closing colon. Then you get the above graphic.