This series covers sysadmin basics. The first article explains how to approach alerting and on-call rotations as a sysadmin. In the second article, I discuss how to automate yourself out of a job, and in the third, I explain why and how you should use tickets. The fourth article covers some of the fundamentals of patch management under Linux, and the fifth and final article describes the overall sysadmin career path and the attributes that might make you a “senior sysadmin” instead of a “sysadmin” or “junior sysadmin”, along with some tips on how to level up.
In this first article, I cover on-call alerting. Like with any job title, the responsibilities given to sysadmins, DevOps and Site Reliability Engineers may differ, and in some cases, they may not involve any kind of 24×7 on-call duties, if you’re lucky. For everyone else, though, there are many ways to organize on-call alerting, and there also are many ways to shoot yourself in the foot.
Here we cover systems administrator fundamentals. These days, DevOps has made even the job title “systems administrator” seem a bit archaic, much like the “systems analyst” title it replaced. These DevOps positions are rather different from sysadmin jobs in the past. They have a much larger emphasis on software development far beyond basic shell scripting, and as a result, they often are filled by people with software development backgrounds without much prior sysadmin experience. In the past, a sysadmin would enter the role at a junior level and be mentored by a senior sysadmin on the team, but in many cases currently, companies go quite a while with cloud outsourcing before their first DevOps hire. As a result, the DevOps engineer might be thrust into the role at a junior level with no mentor around apart from search engines and Stack Overflow posts.
By ticketing, I’m referring to systems that allow sysadmins to keep track of tasks both internally and those requested by their coworkers or customers. There are many ways to get ticketing wrong so that it becomes a drain on an organization, so many sysadmins avoid or it use it begrudgingly. Also, ticketing approaches that work well for developers may be horrible for sysadmins, and vice versa. If you don’t currently use a ticketing system, I hope by the end of this article, I’ve changed your mind. If you do use tickets, but you wish you didn’t, I hope I can share how to structure a ticketing system that makes everything easier, not more difficult.
Most Linux system administrators are no different from Windows sysadmins when it comes to patch management. Honestly, in some areas (in particular, uptime pride), some Linux sysadmins are even worse than Windows sysadmins regarding patch management. So in this article, I cover some of the fundamentals of patch management under Linux, including what a good patch management system looks like, the tools you will want to put in place and how the overall patching process should work.
In the past, a sysadmin would enter the role at a junior level and be mentored by a senior sysadmin on the team, but in many cases these days, companies go quite a while with cloud outsourcing before their first DevOps hire. As a result, the DevOps engineer might be thrust into the role at a junior level with no mentor around apart from search engines and Stack Overflow posts.
Kyle Rankin is the Chief Security Officer at Purism, the author of Linux Hardening in Hostile Networks, DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks, and Ubuntu Hacks; and a contributor to a number of other O’Reilly books. Rankin is a columnist for Linux Journal, has written for PC Magazine, TechTarget websites and other publications. He speaks frequently on Open Source software including at BsidesLV, O’Reilly Security Conference, OSCON, SCALE, CactusCon, Linux World Expo, and Penguicon. You can follow him at @kylerankin.
>> Source Link