19 replies
by oldefar
I think it is human nature to create boundaries.
The flip side to managers restricting actions by department is workers responding with "not my job". I had a miserable quarter when help desk personnel would call me at all hours to validate whether the network was up or down because network was "not their job". What really hurt were the calls where they had identified a circuit outage by CSU indicator lights, but were afraid to call the carrier! Training on how to interpret available symptoms, how to call a carrier to report a circuit outage, and a difficult sales job to their manager on why this was not doing network but simply speeding the resolution process finally resolved the issue.
by jim-h
by mark.tindill
Personally, I've never subscribed to the whole "knowledge is power" mentality. It's a pathetic and insular way to conduct your life, working or otherwise
I welcome any genuine interest from helpdesk people in my organisation who are willing to learn. If they choose to use that knowledge in a negative "backbiting" way then ultimately I believe it will come back on them.
by oldefar
There are some legitimate reasons for limiting access to routers, particulary when access is for changes. A properly designed network, implemented with correct configurations, should only change in response to changing requirements. If routers arehaving configs changed in response to troubles, the design or its implementation was faulty. If services or ports are being routinely reset, it indicates a problem with the hardware or IOS.
Keep in mind that an "Oops" on a workstation impacts that workstation, or at worse a LAN segment. An "Oops" on a router can bring all communications on an intranet down.
Likewise, a security snafu on a workstation is still backed up by site security and worker integrity. A network security snafu canopen the intranet up to the world.
I would approach the issue from a what, rather than a how, approach. Let the network administrator know what information your PC support is looking for and why. Forget about pushing router access, let the network admin determine a solution that meets your requirements and leaves him comfortable.
by tomsal
I have to side with the Network Admin, I'll go a step further and say -- "Why does the PC support techs need access to the routers/switches anyway"?
I mean I've been a PC support tech for many years before I got interested in networking - I know what you need to support PCs, and I never needed to change router settings or fuss with a switch to provide PC tech support.
If you have network admins to take the networking problems/calls and the PC support techs to field the standard helpdesk calls -- AND the PC support techs are saying they need full access to the routers, it is, IMHO, that the PC support techs are the ones with the control issues not the Network guys.
The network guys are doing what they should do -- fighting to keep as few people as possible from messing with the network configs.
by turnerc
Just wait until one of the PC tech's decides to take a CCNA course....the routers will be all over the place within days !!
I would never permit PC techs access to routers, or other major network hardware. If they feel the need to control this equipment, they must become network techs.
Each job also needs a hard boundary. It's nice to work into the grey areas, but once you have a cock-up, you're screwed and you would find the network techs, and PC techs would slowly turn on each other.
There's also the knowledge required for network admin. It is very different to PC tech supp, and I would say that no matter how much you claim to know more than a N/W tech (not to say you are lying), there is something that makes them the N/W tech, and you the PC tech. It's probably experience with infrastructure communications.
by 5c's
by oldefar
I am going to assume that key focus of the PC team is customer service with an emphasis on the fastest possible time to restore. I am also going to assume that the key issue for network is risk rather than control, but that the discussion has movedoff the real issues to a focus on control.
My suggestion is a responsibility nuetral flow chart of problem resolution. Try to cover at least the top 80% of the reported problems in this effort. Try to identify the steps taken for problem identification and resolution.
Now focus the emphasis on actions and order to provide the best possible support to the users. Perhaps a first step on a trouble should be a switch port reset prior to tech dispatch, for example. As a side note, if port resets, or port changes and reconfigurations, are fixing many of the problems then your organization really needs to look at getting vendor support or changing switch manufacturer.
Once the focus is on what instead of who, you may find the networkmanager requesting certain routines to be moved to your team's responsibility.
by tomsal
Your logic is flawed. In your scenario you answer the question for yourself -- its its a port on a switch that is bad, why does the helpdesk dispatch PC support in the first place and not the network support techs?
This scenario is 100% network, hence PC support shouldn't be called.
by road-dog
The routers should not need reconfiguration often enough to justify desktop support access if tehre are designated network support staff on hand.
If the routing and addressing schemes are in place, network problems should be few and far between.
The probability of a router change being the fix for a desktop problem is low. Usually a network layer problem will affect large numbers of users at a time, and look like a network problem when a large number of similar trouble tickets arrive.
Off the cuff, I'd say this is an interdepartmental power grab, not a control issue.
by 5c's
by jim-h
by jim-h
Let me list some of the ?features? of this network that was designed little by little by a scattered team with different interests:
- Access Lists on every interface that have up to 300 lines when only 20 are being used. Imagine the poor routers having to analyze 280 lines of code that will NEVER be touched
- VLANs so badly scattered that you could take three layer 2 hops to an IP interface directly connected to you.
- Routes being learned from Edge machines(UNIX) just because they can and being preferred over the Backbone!
- Loops that I can count on two hands with only one device between the two clouds.
- A fully redundant network that can be isolated to the world in a single cable failure or mistyped command.
- IP address schemesthat waste every other 64 addresses.
I went through this network and it took me three months to fix it without affecting others too much at one time. Through my audit I learned that all of these crazy changes were made by huge handful of very smart people, if one would have been in charge the design would have been flawless.
Some of you are thinking that I am forgetting about troubleshooting and only focused on design. Agreeing with one of the responses outlining a troubleshooting flow chart it could cheaply and simply be done where as the PC technicians have adequate access to troubleshoot only and the network administrators still get to keep the integrity and consistency of the network. There are *multiple* ways to accomplish this and make everyone happy if the objectives are just laid out.
Good Luck on your (Network vs. PC)!
-Jim
by areets
Just read most of the comments and two key terms missing. Know what reaction times are necessary for the resolution process procedure (RPP). When bottom layer (tech.) acts, it is to achieve the SLA and use existing RP procedures. As appropriate to achieve your SLA, modify RP procedures. When a member leaves the team, it would not matter and RPP would be modified. Indeed, this is the job of the team managers, but I have meet a few that misses the mark. SLAs are not only for organisations; smallcompanies should also implement such performance milestones.
TheSourcePortal
In my last company there were 3 of us. (1 Network, 1 PC (me), and 1 DBA)
So we all needed to know a little bit about each others jobs to help with minor issues if one of us was busy, offsite, etc.
So aside from that I dont see any reason for PC techs to be messing with the routers very much. The question I would ask is, if you mess up the router, can you fix it? I know I could not, so I limit my actions on the routers/switches to cable management, rebooting, and other simple stuff.
by areets
In your 3-man show, this is actually achievable. 1. RPP could be verbal. PC tech can launch a DB admin script prepared by DBA
2. Router changes are not everyday tasks, but let's say a CSS device can see up to 25 changes in a day. Standard RPPs can allow Networking trivial for the network admin such as rule changes or an NT domain account clean-up to a techy.
3. Procedures clear and with specific objectives can make your team more effecttive and demonstrates efficiency. Even your three man team can assign SLAs and work together to achieve team objectives.
TheSourcePortal
by hal 9000
How much you trust your staff. In actuall fact the techs could gain access to anything on the network if they really wanted to but in most cases they are simply involved in repairing the things in a fast and efficent manner and aren't all that concerned on what they are actually working on or more precicely it's contents anyway.
Once upon a time I had the same trouble and this ceased when I draged something very important off the network and handed it to the Admin. Now I administer the network which is for a bank so the data fairly private and I trust all my staff with any part of the WAN as often we have to drop everything and race out to a remote branch to do a fix that requires what I term super Administrator access. We do this witha LT and floppy that contains the subroutine for the LT without each other the things are useless but together you have complete access to the entire network wich is necessary for repair work but a hinderance at any other time.
If the Admin doesn't trust the techs then there will be no way of changing their mind as they are parinoid about "security" but on the other hand if you can't trust your staff then they simply shouldn't be there in the first place.
We did not go so far as to offer SLA's we had been downsized from 11 to 3. And now its 2 ( I got laid off during a big riff ) But we worked pretty well as a three man team. The only thing that was annoying, was at first the network guy and I did not sit in the same area.
We were in different buidlings, and this caused some confusion as to who was helping who, since 95% of all customer issues came to the two of us.
Once I moved near him, we were able to hammer away issues, and more importantly exchange ideas on troubleshoooting issues.
This discussion is closed to new replies.
Trending Security posts
Sort by Trending