New Year's Resolutions For Linux Admins: Automate More, Learn New Languages (networkworld.com)

An anonymous reader writes: A long-time Unix sys-admin is suggesting 18 different New Year's resolutions for Linux systems adminstrators. And #1 is to automate more of your boring stuff. "There are several good reasons to turn tedious tasks into scripts. The first is to make them less annoying. The second is to make them less error-prone. And the last is to make them easier to turn over to new team members who haven't been around long enough to be bored. Add a small dose of meaningful comments to your scripts and you have a better chance of passing on some of your wisdom about how things should be done."

Along with that, they suggest learning a new scripting language. "It's easy to keep using the same tools you've been using for decades (I should know), but you might have more fun and more relevance in the long run if you teach yourself a new scripting language. If you've got bash and Perl down pat, consider adding Python or Ruby or some other new language to your mix of skills."

Other suggestions include trying a new distro -- many of which can now be run in "live mode" on a USB drive -- and investigating the security procedures of cloud services (described in the article as "trusting an outside organization with our data").

"And don't forget... There are now only 20 years until 2038 -- The Unix/Linux clockpocalypse."

Comments

Or perhaps not.

[gallondr00nk]

"And the last is to make them easier to turn over to new team members who haven't been around long enough to be bored."

Or in other words, automate yourself out of your own job and get replaced by someone cheaper, using your scripts. Never make your job look easy.

Re:Or perhaps not.

[DamonHD]

I disagree; that's a bad way to look at things from your point of view and your employer's.

I have always considered myself to be on a day's notice whenever contracting/consulting, and always work to make myself expendable.

And guess what:
  1) The person paying you appreciates that you aren't trying to lock them in.
  2) There's usually better, more interesting and more valuable stuff to be done once you have the previous rounds of tedium scripted.
  3) False heroics, ie manually doing things that could easily be automated, makes for cockups and unhappiness. I've seen friends I otherwise respect and admire do this.

For this I got to be one of the better paid IT guys in my field, and always had interesting stuff to tackle.

Rgds

Damon

Re:Or perhaps not.

[Anonymous Coward]

I'm with Damon on this one. That effort being provincial and guarded is better spent learning. Let junior staff take over the work, there is always more interesting and challenging work to be had. This is better for both the employee's career and the employer's business. I've done that for 25 years and quite happy with what I'm doing now.

Ironically, it's a moot point. Automating work doesn't make a job unnecessary. Automation usually fails. If it's too sophisticated to fail, it's too brittle and needs an expert to fix it when the system needs changing, and it makes the whole system rigid. If it's simple, it fails occasionally. So either way the expertise is still required to be on hand.

What automation does is free up time.

Re:Or perhaps not.

[aqui]

Its time to stop treating systems like pets, rather treat them like cattle. This is what's needed to manage growth / and scale without more staff. A cornerstone of this is automation. Its just the next skill set for admins to build out. Automation is part of commoditization and standardization, the next steps in the evolution of a service or product.

The assumption that automation requires less staff is only valid if nothing is changing. The reality is that IT use is growing rapidly, where I work the number of applications and servers we're managing has more than doubled in less than 5 years. Most of the servers are now virtual and the only reason we've

If you're scared of automation, then your current job description is probably so simple that it will be automated, or you don't understand automation.

At that point you have two choices:
1) Wait until someone else automates things without you or outsources it to a company that has already built and automation library / skills and lose your job.
or
2) Become the local automation expert. Or if not local be ready for a job market that will be asking for admins with automation skills.

The reality is autiomation will happen with or without you, the business case for it is there. For the windows admins: Powershell is here to stay and if you don't learn it someone else will. Beyond that automated deployment, or even self provisioning are quickly becoming the norm.

I'm currently working on 2). When you start to look at automation you'll find that:
(a) automation isn't trivial and requires lots of set up work and maintenance when done right...
(b) when not done right it just scales up the screw ups... (aka wrong command as a domain admin with two broad a target)... Just ask the guy that formated all machines on campus ( https://it.slashdot.org/story/... )
(b) over time it frees you from the mundane tasks to actually start tackling real IT issues in the organization, and get to the projects you never had time for before.
(c) it scales, it improves your productivity, and it makes you harder to replace, not easier.

Automation will happen with or without you. The cool thing is that there are tools out there that once you learn them enable your productivity as an admin to offer better quality service, and shift from reactive to proactive management off your environment.

Re:Useless advice

[arth1]

Why would you need to do exact same stuff ... with a new tool?

You don't. But it's useful to learn new scripting languages because some devop or other will surely use it, very badly, in an installer or maintenance script, which you will have to fix to get it working.

So that resolution isn't all bad. #16, on the other hand, truly is.
"It's hard to break old habits, but get used to the newer commands. Maybe it's time to use ip instead of ifconfig and ss instead of netstat. Look into the newer commands and try to roll them into your daily work."
No, no and no. Compatibility is key. You will still maintain 20 year old systems that cannot be upgraded, and needs more than your department's resources to replace. So you will be stuck using the old commands anyhow. Then what is better, to be able to use the same script snippets everywhere, and know what they do, or to use different commands, some of which change APIs more often than you change your underwear?
Learn the new commands, but don't use them. Much as you avoid bashisms when there's not a particular reason to use them, you also avoid new commands when there's not a particular reason to use them.

If you only have a homogenous set of servers, sure, do whatever you like, but then you're not much of a sysadmin either.