Slashdot Mirror
Required Practices for a Network Operations Center?
hayduke.com asks: "I've recently been assigned to a program that is designing a 'Network Operation Center (NOC)'. I started to look for books, online material and other sources to help define a baseline for the Services Level Agreement for our intended customers. Not having any customers yet we are trying to incorporate the design elements that will provide the best possible level of service to the largest number of customers. A search on my favorite search engine brings up a lot of articles that have companies boasting that they have been recognized for being 'Best Practice' leaders in their respective fields but there are no references as to what those practices are. As this will be a NOC (pro-active) as opposed to a Call Center (reactive), I would like to know what other people think that NOC should be at bare minimum or if there are 'standards' that all NOCs should be held to."
There are a couple of ideas that I believe any NOC engineer should hold close if he or she wants to keep it together: 1. When trying to resolve an outage, don't believe any piece of information that anyone (vendor, peer, SA department) gives you until you can prove it to yourself. People make assumptions, which are often wrong. 2. Don't close a trouble ticket until you know the problem is fixed and it isn't coming back. If your NOC has three or four tickets on the same outage within a week or two, then you've got two problems: one with your gear, and one with your process. 3. Stay away from red bull. That crap is evil. 4. Find your own niche, a particular set of NOC duties that you excel in. Find some subject matter on which you can be an expert. 5. Just like they say you should check your problems at the door when you come to work, check your work at the door when you go home. 6. Be nice to people. There is no reason to be a jerk or ugly with people whether they are a vendor or a phone monkey in the call center. Sometimes it is harder to be nice when there's a high-profile outage going on and you aren't getting instant results, but it will pay off when that vendor or TS supe or whoever pulls your hiney out of the fire later on. 7. CSM aka head of lettuce is a pimp. :)
I should have picked out the nickname Demosthenes!Tecumseh.
1. Simplicity - if you can't streamline all of your core operations you spend more time figuring it out when something breaks.
2. Consistent Documentation/Knowledge Transfer among your technicians.
3. Consistent equipment, stick with one vendor and develop excellent relations with that vendor. (Example, I stuck with dell on a big purchase, got my servers and 2 extra computers, a box of posters, shirts, and other dell junk and 16 switches for free just for "being cool")
4. Adaquate troubleshooting database. Find a help desk software suite that fits the nature of your user/clients needs. Make sure it is scalable, and intuitive. Having a web based self-help package is also recommended... The more your clients can help themselves, the less your phone will ring.
5. Document everything such as set up procedures to password databases. (don't post it on the web interface of your help desk software lol!)
6. Have security a priority on every direction your NOC has a presence.
7. Set up your equipment to talk to YOU. Most management software (openview, webtrends, help dest software, etc) can send you emails if not text messaging and whatnot... possabilities are endless, but its nice to know something is broke before your users/clients.
Thats it. I can go on and on.