7 principles of a good sysadmin

This seems to be a common topic of conversation, so I figure I should put it on paper (so to speak) what I value as a systems administrator, or “sysadmin.”

  1. Keep it simple
  2. Ensure it can be reproduced
  3. Keep it close to stock
  4. Magic is bad
  5. No development tools on the server
  6. Prefer complexity at compile time over runtime
  7. Consume artifacts

What does this mean?

The fewer moving parts, the easier to diagnose

By keeping things simple, reproduceable, and close to their defaults, this sets a sysadmin up for success when things go wrong. More so, by keeping things close to the default settings you maximize the chance that your setup overlaps someone else’s. Bonus to finding info on Stack Overflow or that one forum post!

Know your tools

If you don’t understand how a thing works, fix that. Learn about it. Pull back that abstraction layer and look under the hood.

Why is magic bad? When you’re troubleshooting some error, how can you logically rule out the tool as a contributing factor?

This principle does not preclude you from using said magical tool, but it does mandate you dispel that magic by working to understand how it is implemented.

Compile time vs. runtime

In a sysadmin context, compile time can mean “the stuff done to configure and setup a service, system, or application before it is immediately needed.”

In contrast, runtime means “stuff being done as the application is being put into its ‘running’ state.”

Example: Docker

Some container images contain a shell script as an entrypoint (e.g., entrypoint.sh). These shift some compile time tasks to execute at runtime, then defer to running the underlying application.

Reasons for this design might be:

  • More in-depth configuration changes required to pivot between environments
  • Rapid action may be required to change credentials, so they’re only passed at runtime

Actions taken in a Dockerfile when docker build is run are considered “compile time.”

Actions taken when running docker exec/docker run are considered “runtime.”

Complexity costs at compile time need only be paid down once: when things are being setup.

If at runtime, cost of complexity is paid down every time the application is started.

Keep it simple. Pay down the cost as soon as possible.

Artifacts are like gold

Whether the application uses an interpreted language (e.g., python) or is statically compiled (e.g., golang), an artifact can be built to make rolling forward and reverting simple.

In the case of python, a wheel (my_pkg-0.1.0-py3-any.whl) is a well-formed package holding the python source code. In a venv, install it with pip install ./my_pkg-0.1.1-py3-any.whl to upgrade and pip install ./my_pkg-0.1.0-py3-any.whl to roll back.

With golang it’s even easier. Just drop the new binary in place and, if it doesn’t work, drop the old binary in that spot instead.

Some VCS providers, like GitHub.com, allow uploading binaries and other assets related to a release to a location that can be accessed later, perhaps even by shell scripts.

573 Words