The Technology Professionals of Today
One of the most frustrating things about being in technology is the amount of operators in the field. Let me elaborate on the term “operator”.
Ten years ago, majority of the information systems staff were operators. People who managed a system around the clock using commands that were supplied to them in hopes to keep the network up and running 24/7. This included making backups, verifying disk space, and also making sure they ran certain commands that needed to be run at off peak hours without fully understanding what the purpose was. It wasn’t their job to find out, it was their job to perform what was asked of them. Similar to my grandmother when she calls Dell support to find out what is wrong with her internet connectivity.
There are thousands of professionals out there who take what is provided to them to perform certain functions day in and day out. These could be network professionals or System Administrators. It is not solely their fault, this is what has become of the field due to vendors who advertise “IT for dummies” solutions. If you are one of those people who purchased a CCNA book, got CCNA certified, and wondered why your salary hasn’t broken the bank yet, you are one of these people.
I have never seen IT that way and I refuse to look at it that way . For every problem, there is a solution. Just because no one has provided a vendor solution, it doesn’t mean that it doesn’t exist.
Example:
I was working a Carrier VOIP project. The softswitch I was using supported SIP, so it was a SIP registrar. Every night at a certain time all SIP connections were going down and causing endpoints to re-register. This problem had been occurring for a long time and without the there were finger pointing without much proof.
I always travel with a linux (Ubuntu) laptop. So what I did was configure a Sip registrar (Asterisk) on my laptop and croned a nmap job as well to verify open ports to the endpoints. I used another script to register to the laptop so that a session was established to another registrar other than the Class 5 server. That night at 2am the same problem occurred. The client lost connectivity and nmap caught the ports that were closed.
The problem easily pointed to the firewall that was setup to detect and act upon attacks and there seemed to be a very mild DOS using port 5060 that cause the router to reject traffic to that port for a period of time. Simple automated approach.
I just used this example because tools aren’t purchased they are improvised. You can ask all of those idiots who purchased a flute years ago and are still trying to find everyday use for them.
People go out and purchase network management tools and utilities everyday all they are is a bunch of scripts running snmp get and set packaged in pretty java/html pages. When the same can be done on a regular linux platform with cron and referenced in man pages. Why wait for the vendor to upgrade the software to manage switches now, when you can walk the MIBS of the device and update your own scripting.
This is what is wrong with IT. If the paid “network engineers” and “system administrators” cannot develop tools of their own then what is their value add? You can pay the vendor to train a monkey to be an operator.
Three months ago I wrote a perl script for a client that enabled him to automate a packet trace to isolate a problem that was occurring off hours. Every night from 2 to 3 am the script took the trace and then ftp’d it to my ftp server so that I could review and take a look at what was occurring. Now the client is looking into 3rd party vendors that could do the same for them because they fell in love with the concept. I did not have the heart to tell them that it was only 5 mins of work, but this reinforces my view.
Technology is ever changing. Things you purchase today have been available for years. Just because Cisco or Microsoft offers it does not mean they invented it. There are always cheaper, more flexible and cost effective alternatives. Be an engineer, not an operator!