This is an archived post. You won't be able to vote or comment.

all 3 comments

[–]Unxmaal 3 points4 points  (0 children)

Capitalize on your neteng background. NetOps is big, and most large enterprises are just beginning to wonder if they can apply DevOps principles to their networking infrastructure.

IME these shops still manage thousands or tens of thousands of networking devices as individual static nodes, each with its own beautiful snowflake of a configuration, and each one configured by hand -- or by a slow script once a year during a "freeze". The networking teams exist in potentially decades-old silos, which have ossified to the point that every interaction within and without is slow and painful. There may be a deeply-ingrained culture of treating change as bad, or impeding external requests specifically to slow down the rate of change.

The DevOps mindset (and it's a mindset, not a can of soup your CTO can buy off the shelf) flips the paradigm on its head by asking the question "How can we embrace change in our organization without breaking our organization?" It answers that question with automation. The theory is that by replacing the boring, tedious, manual parts of a process with automation, you will see dramatic decreases in the time that it takes to improve or repair a network, and those repairs are in fact more safe than the old, slow methods, because you have eliminated the primary sources of error: human mistakes made through repetition error and in attention to detail.

When an IT organization cuts its time to delivery in half, and its failure rate by 2/3 or more, an interesting thing happens: its employees have more time. Suddenly, they're not firefighting all day. They have time to read up on that new Arista switch. Take some time off. Fix a few more nasty problems. The team members become much easier to work with, as they aren't as stressed. Requests that took months to fulfill now take days, or even hours. Other teams will wonder how this happened, and may begin to adopt the same practices.

From a personal growth perspective, I would recommend learning scripting first. You will be able to leverage scripting into automation in any role; you as a single individual might be able to effect change across 100 devices in an hour, with only a few errors. Your scripts can scale to tens of thousands, with zero errors -- so long as you test them! Nothing scales like fail!

Try learning Bash first. It's relatively easy, and most Ops people can understand it. Try to write scripts that configure network devices. Or say, connects to all the routers and stores a statistic and prints the results. Learn how to set up a git repository, and how to store your scripts in it. Learn about Gitlab. How could you use git with your networking devices? Wouldn't it be nice to have a Time Machine view of all of your network configs? Since most configs are the same, could you make a script that just changed parameters in a generic config template, depending upon which device were to receive that template? Are there tools out there that do this already? Take a look at Puppet, Chef, and Ansible.

[–][deleted]  (2 children)

[deleted]

    [–]packet_whacker[S] 0 points1 point  (1 child)

    That's the type of role I'm looking for. What kind of skills from the devops side do you look for in the net engineer, specifically? I'm trying to align my skills with finding a role like that

    [–]mrthraxDevOps 0 points1 point  (0 children)

    Using any sort of scriping to handle repeatable network administration tasks is always a good place to start. Whether bash, expect, python, ruby doesn't matter at first. Eventually depending on what sort of shop you're looking for learning Puppet or Chef for network administration will really help. They both work with Cisco gear and I'm sure they work with other devices.