I was a guest on this week’s episode of the Packet Pushers Heavy Networking podcast. Of the many wonderful podcast series from the Packet Pushers, Heavy Networking is the original that started it all.
This episode is about the career progression from Junior to Senior Network Engineer and it was recorded about a month ago.
Please check it out here.
Everyone would love to have a network that is always up and available. The problem is that few people want to design it and absolutely no one wants to pay for it.
There are many ways to make your Network more resilient. Some are necessary for your organization, others would be nice to have and some are overkill. A difficult part is to know which solution goes into which bucket (necessary, nice-to-have or overkill). Then those pieces need to implemented, monitored and maintained.
One example that I have seen at dozens of companies is about the uninterruptible power supply (UPS). A UPS has a battery that is supposed to “kick in” when the normal power source goes out, kind of like a fancy generator. The goal is for the critical equipment to stay alive and the non-critical to power-down gracefully. Most companies have a UPS at their sites but they are not ready for two main reasons, the battery is dead and/or it isn’t cabled properly. Just like any other battery, over time it won’t hold as much of a charge so the battery needs to be replaced.
Another example is if a branch office invests in two ISPs for redundant internet, make sure everyone knows exactly how redundant it is. If both ISPs use the same physical path to the branch office, they aren’t as redundant because the same backhoe will still take them both out. Or if the network isn’t setup for proper failover and failback, then it isn’t as redundant as we thought.
A competent network designer should be able to tell with a high degree of certainty just how resilient the network is and in which ways. Probably the toughest part is to explain to upper management the pros and cons of the new proposal and get their buy-in. Management needs to listen and understand what all the scenarios are and their impact so everyone will be informed and aware of the possible situations. Those meetings are time consuming and can be very boring but they are necessary. The other option is for the engineer to write all this up and email it out but we all know that no one reads anymore.
A typical network engineer starts off in a NOC and does break / fix work and that doesn’t require them to know how to write code. But it would be great if they did AND it would help them advance.
Most other IT infrastructure engineers need to know either how to write basic scripts or at least edit or debug other’s scripts. Networking Engineering folks should learn about coding to expand their tool set and to better understand their Software Engineering brethren. Even better to work better with the programmers that we are supporting.
An example is Powershell.
Powershell is a necessary skill for folks who work on servers, Exchange, Active Directory and Office 365. Lots of networking folks who want to dabble in other disciplines will need to know Powershell and basic coding to keep up. Here is a link to Greg Farro from the PacketPushers.net talking more about this very scenario.
Here are a few examples off the top of my head that other IT infrastructure engineers routinely perform.
Server / Storage Admins
•Automated backups
•Datacenter failover script
•Automatically setup new VMs and resources
•Linux Linux Linux
Security Admins
•Writing Firewall rules
Voice Admins
•Phone tree scripting
Architects
•Switch failover rules
•Pings sweeps
•SDN
•Device auto-discovery script
The IT world is becoming more and more automated. That automation is done by scripting and coding. The networking world is far behind storage and servers in terms of automation. Better for you to automate your own job away before someone else does… and it will happen eventually. We’ll be examining automation in the IT world in general more in another post.
bk-tech.cloud 