People, especially IT people from smaller organizations get confused when I say our expertise is networking and less than 80% of our work is strictly just networking. This is something that is usually configured just once and it’s done forever. How can it take so much time? Well today I’ll be showing you just that. Consider it a glimpse into the life of a network engineer.
The Obvious Stuff
There are two things that people know I do:
- Build Networks
- Fix Broken Networks
This may be surprising to some, but a building a brand new network from scratch is actually one of the quicker and easier things to do.
Fixing networks usually doesn’t take up that much time, either. A network built well isn’t exactly fragile. If we’re good at our jobs and build the network well, we don’t really need to react to the network going down that often.
We have redundancies in place that are able to prevent outages when things break. When things do break, it’s pretty routine and often goes unnoticed by the users. We usually have our junior engineers call the ISP or swap out power supplies and fans and such.
Overall, I’d say that’s about 20% of our time. The rest is where it really gets interesting.
There are two types of project work that we do. First, of course, is our own network projects. The second is helping other people with their project work.
Our Own Network Projects
Usually this means we’re swapping out hardware or changing the design somehow. We’re working with organizations so large that by the time we’re done updating one set of hardware, there’s already another set that needs replacing.
Going through change control and establishing change windows can be a lot more work compared to smaller organizations as well.
Going through a redesign requires a lot of non-technical and technical work. We need to make sure the new design aligns with the companies and all of their teams’ goals. There is a lot of risk inherent to such a change as well. On top of the work for the redesign, a lot of extra care is taken to mitigate all of that risk.
Other Peoples’ Projects
Every IT project usually touches the network. Depending on the situation, it’s usually in the way or suspected to be in the way of project completion. The below is a Venn Diagram illustrating the issue.
Project Support Changes
This may come as a surprise. It usually fluctuates, but about half of our time spent on projects is spent here. There are times something is actually our fault and network changes are required to move the project forward. This is usually port VLAN changes or firewall rule updates.
This may sound excessive, but at larger organizations, it isn’t uncommon to have extremely restrictive firewall rulesets. This means that in parts or all of the network, traffic is not allowed unless we’ve put a certain firewall rule in place to allow it. This means even changing protocols, ports, or IP addresses has to include the network team. With many IT teams all running their own projects this also takes some time.
Project Support Troubleshooting
It gets even more complicated when it’s not the fault of the network. How do you prove a negative? You really can’t. We end up doing a lot of due diligence and triple checking everything.
If the other team is still not satisfied with what’s been done, or it’s business-critical, you may end up troubleshooting the issue anyway, even if everyone knows it’s not a network issue. This is because as a network engineer, you’re in the unique position for that organization to understand how all the pieces fit together. Oftentimes your presence will expedite the mean time to resolution (MTTR).
Internal Network Operations
I’ve never been fortunate enough to have a dedicated NOC. That seems to be the stuff for ISPs and fairy tails. Usually it’s just me and the network monitoring system (NMS). A commonly used one is Solarwinds Orion. There is just so much to be done there that you can spend all day there, and I definitely do. I could write an entire article on everything I do here, so I’ll just leave it at that for now.
Thank you for checking this out. Hopefully this blog post helped you see into what the life of a network engineer is like (if you’re a new up and coming engineer), or if you’re already an engineer you were able to use this to compare to your day and see if it’s the same. If you had any comments, questions, or just wanted to share your thoughts on this article, you can contact me at email@example.com
e-Mayhem helps companies successfully deliver business projects. We also help companies avoid losses associated with IT disruptions and security threats. You can learn more about our services at e-mayhem.com or by emailing firstname.lastname@example.org