Slashdot Mirror
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."
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."
Does shytstaind contain its own scripting language yet?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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
http://m.earth.org.uk/
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.
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.
----- "Profanity is the one language that all programmers understand."
Learn something. Way too many of my peers thought that once college was done they were done learning. College got them the job and there was no reason to continue learning.
Learn something completely unrelated to your job and bridge the gap.
Right now I'm a mechanical engineer that is trying to play the job of IT DevOps. Because our IT department doesn't understand or want to understand the specific needs of what my group does. "Throw RAM and CPU" at it hasn't worked as our entire toolchain is single threaded and my 8600k beats the pants off of the 16 core dual socket Xeons they give us.
If you don't do it someone else will.
And when the axe comes swinging that person will keep the job because they're the one that 'knows the system'.
Additionally how do you continue to work on the same thing year after year without getting bored? Automate my workflow, volunteer to take on additional work. Take on additional work. Rinse and repeat.
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.
You can potentially code solutions in fewer lines of Python compared to bash too
For complex things, certainly and at that point you should be using something more practical than BASH anyway.
If, however, I want to simply execute a shell command (that does not have a Python/Perl/whatever builtin analog), capture it's output to a variable, and check the exit status, BASH is pretty damn simple. Those last two requirements are the biggest killer of Python as that forces you to use subprocess which makes it much more complex than BASH (especially if you want to capture stdout and stderr).
It's not that things like that are hard or not well documented, but they are more complex to write and don't read as simply. Not only does simplicity serve when writing the code, it also serves when it has to be debugged at 4am due to a Production issue.
I've done my time as an Admin and much prefer writing real code (of which I happen to specialize in automation), but I recognize that the language I may choose to solve a problem might not really be the best option when all facets of it's deployment and support are taken into account.
Now what most admins leave out of their code which would do wonders regardless of the language is error checking. I've lost track of the number of messes I've had to cleanup that simply came down to scripts that blindly carry on assuming the world is perfect without bother to check... "if [ $? -ne 0 ] ; then" really isn't THAT complicated...
ifconfig has been depreceated
Many of us have to support operating systems that are still sold and supported, like Red Hat Enterprise Linux 6, where net-tools is still actively used and relied on by the system itself, or Red Hat Entprise Linux 7, where it is still provided and patched as needed.
If you have a choice to do otherwise, good for you, but in the mean time let us admins try to follow the Unix philosophies like multiple small tools that each do one thing well, have stable APIs, and provide the least amount of surprise.