I'm often asked which type of training and certifications I would recommend to someone who either wants to further their current career or who wants to break into information technology as a system administrator. My answer has changed over the years. Originally, I said to expand your knowledge base by getting into Linux because so many people were Windows-only types. Later, I said that you should explore mobile computing (e.g., phones, tablets, and other lightweight computing devices and services) to extend your employable skills and enhance your ability to serve a wider range of users. These days, my answer is that you should learn automation scripting in the forms of PowerShell, Bash, and a programming language such as Python or Ruby. Automation can mean a lot of different things, but for me, automation means scripting repetitive tasks. And most tasks are repetitive enough to be at least partially scripted.

I've written before about automation, but it's so important that I feel compelled to repeat my advice and some recommendations in this area.

Before I cast forth my pearls of wisdom, I want to offer a word of caution to you would-be automation system designers: The easier you make something on the front end, the more complex it's going to be on the back end. If you create a very easy-to-use system, program, or front-end interface, the back-end programming and timing are going to be equally complex. So, if you're into automation scripting and programming, be prepared to stretch your knowledge far beyond your current limits. Making something easy is really hard to do.

Notice that I included timing into the complexity equation? For most things, timing is very important, but for automation, timing is critical because of dependencies. Task A must complete before task B, task C cannot execute unless task B completes with an exit code of  , and so on. A lot of automation never happens because of timing fails. You must be a bit clever with your programming and add contingencies to your automated tasks. When everything goes as planned, each task occurs and fires off or allows the next task to occur. However, when something goes wrong, you have a cascading failure because of those failed dependencies. One such common point of failure is when your disk volume fills up unexpectedly. Each task after that will also fail. You must compensate and build safeguards for such occurrences. You can't anticipate every type of failure, but you should have some idea of the most likely fail points and scenarios so that you can build some logic or rudimentary intelligence around either avoiding them or compensating for them.

I hate creating flow diagrams, but it's a necessary evil, especially for complex systems with multiple points of failure. A flow diagram will allow you to inspect your failure points visually and build alternative routes and contingencies. I'm convinced that a visual layout is the key to automation success. A second or third pair of eyes on your flow diagram and logic is also a good idea. Others may see flaws in the process that you can't readily see as the designer. Sometimes the 10,000-foot view provides an amount of clarity that we in-the-trenches types often ignore or don't respect. It's better to gather multiple perspectives in a large, complex undertaking like a major automation project.

My best current advice to further your system administrator skills and career is to learn automation scripting. My favorite automation framework, if you need one, is Ansible. It is fun to use and is highly extensible and scalable. Additionally, its configuration and use can be made very secure. However, if you have a small environment, just set up your own automation system. Use Cron, Task Scheduler, PowerShell, Bash, Python, Ruby, CMD, PsExec, and any other tools you can find to get the job done. Don't worry, I've never heard of anyone who has automated themselves out of a job, but if you believe that you might, you should place yourself into that flow diagram as a critical component, if nothing else, as a subtle suggestion about your importance in the whole process.

Ken Hess * ADMIN Senior Editor