

Systems and Processes that Aren’t in Code are Terrifying
source link: https://www.tuicool.com/articles/qyM3QfI
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.


The dreaded:
15 6 2 1 * /home/lane/backup.sh
You may recognize this as a unix cronjob, a job that is scheduled to run on a server periodically.
You may be thinking,
“Why is that scary? We use cronjobs all the time!”
If the code that manages the crontab is source controlled and exists within the organization’s central repositories, then I actually have very little to complain about. My beef is when an engineer hops into the server and starts up a cron job without that configuration existing anywhere in code.
You may say,
Well, the cron schedule may not exist in code, but the script/program it runs does!
I don’t care.

I want to be able to look at the code base and know if the program is long-running, should be run manually, or if it runs on a specific schedule. If it is going to be run using crontab that’s fine, just make sure that the CI/CD config file (or something similar that is source controlled) specifies how that is triggered.
Or even better, program in Go so that spinning up side processes within your app is simpler than using the crontab :wink:
Other Angst-y Things
Crontabs are just a common example of hard to discover processes. Others may include:
- Database processes that were added manually, instead of by the app that owns the DB
- .bash_profile or .bashrc files that kick off server startup jobs
- Third party apps that were installed on the server to take care of special tasks (I don’t know, defragging the disk maybe). Those processes should be documented in code, probably config files that your organization typically uses to start its apps.
Thanks
Internal documentation sucks, so document your processes in code instead. A config file that specifies how a process is started is much better than a PDF, because the config file can’t become outdated (if it does, things break).
Good luck out there.
By Lane Wagner @wagslane
Download Qvault:https://qvault.io
Star our Github: https://github.com/q-vault/qvault
Recommend
-
11
There are sysadmins who aren't systems programmers? I've received some feedback from a few people thanking me for talking about what life is like as a sysadmin. They apparently ha...
-
7
Why Ruby’s Timeout is dangerous (and Thread.raise is terrifying) This is already documented in Timeout: Ruby’s most dangerous API
-
13
ConversationThis is heartbreaking, and terrifying. Almost as scary as some of the ignorant idiots commenting that they'll ignore his pleas.Quote Tweet
-
9
2593 members Technology Technology on Digg: the best articles, videos, tweets, and original content that the web is talking about right now.
-
8
🔗 Dynamic type systems aren’t even simpler Alexis King just published a great blog post titled
-
6
NYPD sends terrifying robot dog back to the kennel after public backlashAOC said it targeted low income communities of color
-
8
Want more videos like this? Every day we send an email with the top videos from Digg. "Yet today, even with a tropical climate that allows farmers to grow food year-round,...
-
6
GLOBAL THREAT China fires hypersonic nuke...
-
3
Design Systems Aren't Cheap March 21, 2022 • 3 min read Buttons are one of my favorite components. On the surface they seem simple, but in practice, they tend to be much more involved....
-
6
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK