Learn How to be a Sysadmin with this One Weird Trick!

Sorry about the click-bait headline. I couldn't resist.

Last week's Hacker Newsletter had an interesting link in the "Ask HN" section to nstart asking "How do I learn how to become a good sysadmin?".

The first answer from protomyth pretty much nails it.

Start with two mantras:

  1. I will know exactly what every command or script I run on a system I control is supposed to do - no exceptions. If I don't and are just following instructions, I really need to learn what it means and why. If you need to setup a test system and snapshot before and after to see how things work.

  2. I will document a lot. Imagine some poor person showing up after you have won the lottery (think happy thoughts, but watch out for buses just the same). Don't just blindly put down step, put the why down. If I cannot write why I am doing something then I need to think about it more.

The rest just flow from those. Learn to program, be a tool builder, find the best way to learn and dive in, solve problems, and insist on consistent, repeatable, backedup, secure systems.

Do remember though: all your successes will be hidden in the darkness and all your failures will be shown in the full light of day. Its not a fun gig at times.

What I really want to emphasize here is part of his first "mantra":

I will know exactly what every command or script I run on a system I control is supposed to do - no exceptions.

Too often I'll find programmers asking for which command to run, but never digging into why we're running those commands or what the commands even do. When I was first learning Linux/Unix, I'd follow tutorials to the letter and I'd be clueless as things would fall apart. Now I can read a walkthrough for the intent and not the specific incantations needed to make the system work.

What's more is that almost every command you'll run into these days has great documentation if you'll just RTFM! Which isn't as scary as it sounds. Suppose you're running into trouble with the berks command while working with Berkshelf. Most commands respond to a --help flag so running berks --help rewards you with:

Commands:
  berks apply ENVIRONMENT     # Apply version locks from Berksfile.lock to a Chef environment
  berks contingent COOKBOOK   # List all cookbooks that depend on the given cookbook in your Berksfile
  berks cookbook NAME [PATH]  # Create a skeleton for a new cookbook
  berks help [COMMAND]        # Describe available commands or one specific command
  berks info [COOKBOOK]       # Display name, author, copyright, and dependency information about a cookbook
  berks init [PATH]           # Initialize Berkshelf in the given directory
  berks install               # Install the cookbooks specified in the Berksfile
  berks list                  # List cookbooks and their dependencies specified by your Berksfile
  berks outdated [COOKBOOKS]  # List dependencies that have new versions available that satisfy their constraints
  berks package [PATH]        # Vendor and archive the dependencies of a Berksfile
  berks search NAME           # Search the remote source for cookbooks matching the partial name
  berks shelf SUBCOMMAND      # Interact with the cookbook store
  berks show [COOKBOOK]       # Display the path to a cookbook on disk
  berks update [COOKBOOKS]    # Update the cookbooks (and dependencies) specified in the Berksfile
  berks upload [COOKBOOKS]    # Upload the cookbook specified in the Berksfile to the Chef Server
  berks vendor [PATH]         # Vendor the cookbooks specified by the Berksfile into a directory
  berks verify                # Perform a quick validation on the contents of your resolved cookbooks
  berks version               # Display version
  berks viz                   # Visualize the dependency graph

Options:
  -c, [--config=PATH]          # Path to Berkshelf configuration to use.
  -F, [--format=FORMAT]        # Output format to use.
                               # Default: human
  -q, [--quiet], [--no-quiet]  # Silence all informational output.
  -d, [--debug], [--no-debug]  # Output debug information

The more you get used to asking a command for its own help, the less scary the world becomes. It's easy and cheap to spin up a small VPS on DigitalOcean (referral link) that you can hack on to your heart's desire. And if you fuck it up, you can just wipe it and start over.

To sum up RTFM like you mean it!

I've written a book on deploying Rails applications which I'm working on updating now, but if you want more "DevOps" in your inbox on a terribly unscheduled basis, you can sign up with the form over on the right.

I'm Zach.

I wrote Fearless Rails Deployment.

Sometimes I write things on this website, but not as often as I'd like.