Organizations run on systems that must simply be there — the file share, email,\nthe directory that says who you are, the database the business depends on — and\nnotice them only when they break. A systems administrator's reason for being is\nto keep that infrastructure available, secure, recoverable, and quietly boring,\nso everyone else can work without thinking about it. The discipline exists\nbecause complex systems decay, drift, fill up, expire, and get attacked\ncontinuously, and someone has to hold entropy at bay deliberately.
\n","wordCount":83},{"heading":"Core Mission","id":"core-mission","markdown":"Keep the systems people depend on available, secure, and recoverable — so no\nsingle failure, expired certificate, full disk, or lost laptop becomes an outage\nor a breach, and so anything important can be rebuilt from a known good state.","html":"Keep the systems people depend on available, secure, and recoverable — so no\nsingle failure, expired certificate, full disk, or lost laptop becomes an outage\nor a breach, and so anything important can be rebuilt from a known good state.
\n","wordCount":39},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The visible work is \"fixing computers\"; the actual work is risk management over\ntime. A sysadmin spends their days: provisioning and patching servers and\nendpoints; managing identity and access (Active Directory, LDAP, SSO, groups,\npermissions); running backups and — the part that matters — testing restores;\nmonitoring everything that can fail and getting alerted before users do; planning\ncapacity; automating the repetitive and dangerous so it's done the same way every\ntime; managing change so a \"quick fix\" doesn't take down production; and carrying\nthe pager. Underneath it all is documentation — the runbook that lets 3 a.m. you\nrecover without the one expert who's on vacation.","html":"The visible work is "fixing computers"; the actual work is risk management over\ntime. A sysadmin spends their days: provisioning and patching servers and\nendpoints; managing identity and access (Active Directory, LDAP, SSO, groups,\npermissions); running backups and — the part that matters — testing restores;\nmonitoring everything that can fail and getting alerted before users do; planning\ncapacity; automating the repetitive and dangerous so it's done the same way every\ntime; managing change so a "quick fix" doesn't take down production; and carrying\nthe pager. Underneath it all is documentation — the runbook that lets 3 a.m. you\nrecover without the one expert who's on vacation.
\n","wordCount":105},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **If it isn't monitored, it's already broken — you just don't know yet.** You\n cannot manage or secure what you can't see.\n- **A backup you haven't restored is a hope, not a backup.** Follow 3-2-1: three\n copies, two media types, one off-site (and immutable, against ransomware), then\n test the restore on a schedule — restores fail in ways backups don't.\n- **Least privilege, always.** Every account and service gets the minimum access\n to do its job. A compromise's blast radius is defined by the permissions you\n granted before it happened.\n- **Automate the repeatable; document the rest.** Anything done by hand twice will\n eventually be done wrong at the worst time. Codify it (Ansible, scripts).\n- **Change is the leading cause of outages.** Most incidents are self-inflicted.\n Change deliberately: maintenance windows, tickets, a tested rollback, one change\n at a time.\n- **Patch on a cadence, not a panic.** Unpatched systems are how breaches happen;\n reckless patching is how outages happen. Test, stage, then roll.","html":"Sysadmins sit between the people who depend on systems and the systems\nthemselves. They work with the help desk (the first line), developers and DevOps\n(who want to ship; the admin wants it stable), security (allies on hardening and\nincident response), networking, and management (who fund resilience they hope\nnever to use). The hardest conversations are about change windows and access\nrequests — saying "not in production at 4 p.m. on a Friday" without becoming the\ndepartment of no. Good admins translate risk into business terms managers can act\non, and partner with DevOps and SRE rather than treating "infrastructure as code"\nas a turf threat.
\n","wordCount":106},{"heading":"Ethics","id":"ethics","markdown":"Sysadmins hold the keys: root, Domain Admin, the backups, the logs, the ability\nto read anyone's mailbox. That power is held in trust. Core duties: access what\nyou're authorized to and only for legitimate reasons; never snoop on user data,\neven when you can; protect the confidentiality and integrity of the systems and\nthe people on them; and be honest about risk — don't let a known vulnerability or\nan untested backup ride quietly because surfacing it is inconvenient. Disclose\nbreaches promptly. When asked to implement surveillance, weakened security, or\ndata retention that harms users, name the conflict rather than silently complying.\nThe power asymmetry between an administrator and an ordinary user is exactly why\nrestraint, transparency, and least privilege are ethical obligations.","html":"Sysadmins hold the keys: root, Domain Admin, the backups, the logs, the ability\nto read anyone's mailbox. That power is held in trust. Core duties: access what\nyou're authorized to and only for legitimate reasons; never snoop on user data,\neven when you can; protect the confidentiality and integrity of the systems and\nthe people on them; and be honest about risk — don't let a known vulnerability or\nan untested backup ride quietly because surfacing it is inconvenient. Disclose\nbreaches promptly. When asked to implement surveillance, weakened security, or\ndata retention that harms users, name the conflict rather than silently complying.\nThe power asymmetry between an administrator and an ordinary user is exactly why\nrestraint, transparency, and least privilege are ethical obligations.
\n","wordCount":122},{"heading":"Scenarios","id":"scenarios","markdown":"**The ransomware morning.** A user clicks a phishing link; by 9 a.m. file shares\nare encrypted and a ransom note is on every desktop. The expert doesn't pay and\ndoesn't panic-restore. First, contain: isolate affected segments, disable the\ncompromised account, pull the network to stop lateral spread. Then assess scope\nfrom logs and EDR. Recovery hinges on the one thing prepared months ago:\nimmutable, off-site backups the malware couldn't reach. They restore from the\nlast clean, tested restore point, accept the RPO data loss already agreed with\nthe business, rebuild compromised hosts from baseline, rotate every credential,\nthen reconnect. The postmortem fixes the systemic gaps: MFA everywhere, segmented\nnetwork, faster restore drill. The backup that saved them existed because someone\ntested a restore when nothing was wrong.\n\n**The disk that almost filled.** Monitoring fires an 80% alert on a database\nvolume at 2 p.m. — a warning, not an outage. The novice extends the disk and moves\non. The expert asks *why*: a log rotation job silently failed three weeks ago.\nExtending the disk would only delay the real problem. They fix rotation, reclaim\nthe space, and add an alert for \"rotation didn't run\" — so the slow leak never\nbecomes the 3 a.m. outage it was heading toward.\n\n**The Friday change request.** A developer needs a \"quick\" config change pushed to\nthe production auth server before the weekend to unblock a release. The expert\ndeclines the cowboy push without becoming the department of no: no change to a\nsingle-point-of-failure auth system goes out on a Friday afternoon with the team\nleaving and no one to watch it. They schedule it for the Tuesday window, require a\ntested rollback, and stage it first. The instinct that protected them: change is\nthe leading cause of outages, and the worst time to discover a bad one is when no\none is watching.","html":"The ransomware morning. A user clicks a phishing link; by 9 a.m. file shares\nare encrypted and a ransom note is on every desktop. The expert doesn't pay and\ndoesn't panic-restore. First, contain: isolate affected segments, disable the\ncompromised account, pull the network to stop lateral spread. Then assess scope\nfrom logs and EDR. Recovery hinges on the one thing prepared months ago:\nimmutable, off-site backups the malware couldn't reach. They restore from the\nlast clean, tested restore point, accept the RPO data loss already agreed with\nthe business, rebuild compromised hosts from baseline, rotate every credential,\nthen reconnect. The postmortem fixes the systemic gaps: MFA everywhere, segmented\nnetwork, faster restore drill. The backup that saved them existed because someone\ntested a restore when nothing was wrong.
\nThe disk that almost filled. Monitoring fires an 80% alert on a database\nvolume at 2 p.m. — a warning, not an outage. The novice extends the disk and moves\non. The expert asks why: a log rotation job silently failed three weeks ago.\nExtending the disk would only delay the real problem. They fix rotation, reclaim\nthe space, and add an alert for "rotation didn't run" — so the slow leak never\nbecomes the 3 a.m. outage it was heading toward.
\nThe Friday change request. A developer needs a "quick" config change pushed to\nthe production auth server before the weekend to unblock a release. The expert\ndeclines the cowboy push without becoming the department of no: no change to a\nsingle-point-of-failure auth system goes out on a Friday afternoon with the team\nleaving and no one to watch it. They schedule it for the Tuesday window, require a\ntested rollback, and stage it first. The instinct that protected them: change is\nthe leading cause of outages, and the worst time to discover a bad one is when no\none is watching.
\n","wordCount":316},{"heading":"Related Occupations","id":"related-occupations","markdown":"A systems administrator shares ground with several roles but is defined by\nkeeping running infrastructure available and recoverable over years. Site\nreliability engineers apply software engineering to operations at scale, treating\nservers as code and reliability as a measured budget — the SRE descends from the\nsysadmin but writes the automation as a product. DevOps engineers blur dev and\nops with pipelines and IaC; the modern sysadmin is increasingly one. Network\nengineers own the plumbing the admin depends on; database administrators own the\ndata layer; security engineers are the closest allies on hardening, access, and\nincident response.","html":"A systems administrator shares ground with several roles but is defined by\nkeeping running infrastructure available and recoverable over years. Site\nreliability engineers apply software engineering to operations at scale, treating\nservers as code and reliability as a measured budget — the SRE descends from the\nsysadmin but writes the automation as a product. DevOps engineers blur dev and\nops with pipelines and IaC; the modern sysadmin is increasingly one. Network\nengineers own the plumbing the admin depends on; database administrators own the\ndata layer; security engineers are the closest allies on hardening, access, and\nincident response.
\n","wordCount":96},{"heading":"References","id":"references","markdown":"- *The Practice of System and Network Administration* — Limoncelli, Hogan, Chalup\n- *UNIX and Linux System Administration Handbook* — Nemeth et al.\n- *Google SRE Book* — sre.google/books\n- *Time Management for System Administrators* — Tom Limoncelli\n- CIS Benchmarks — cisecurity.org","html":"