Sysadmin Career Guide — MyAdminDesk

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

The work is the record, not the heroics

A system administrator keeps hosts understandable. The skills are the guides on this desk: permissions, services, storage, backups, and a calm patch window. The habit that makes those skills a career is writing down what you did so another person can do it. A host that only you can fix is a risk, not a job description.

A lab you can break is worth more than a certificate you cannot demonstrate. Use the lab host from the fundamentals guide. Break one thing from a specialist guide, fix it with the rollback you wrote, and keep the note. That note is the portfolio. Do not break a production system to get a story.

On-call is a rota, a way to reach you, and a page that says how to look at the service before how to wake the next person. It is not a contest to stay up. After an incident, the useful artefact is the timeline and the next change, not a speech. The patch guide and the backup guide are the two that shorten the worst nights.

This pillar does not name a calculator. The tools sit on the neighbouring guides. Nobody is hired because they clicked a generator. They are hired because they can say what the generator must not be allowed to change.

A practice week you can repeat

Pick one guide you have not operated, such as scheduling or backups. In the lab, do the worked example and the checks. Write a page that has the before, the change, the proof, and the rollback. Take out every secret. If the page would teach a stranger, it is good enough to keep.

Then read one real ticket from your environment, or invent a realistic one if you are studying, and mark which guide it belongs to. If it belongs to several, split it. The mistake the other guides keep naming is two changes in one window. Practise splitting.

Shadow an on-call hour or a maintenance window if you have that job. If you do not, rehearse the lab failure at a set time and write who you would have called. The point is the clock and the note, not the adrenaline.

Review the note a week later. If you cannot follow it, it was not finished. Update the note, not your memory.

A change you can finish

Career practice does not change production. If the note describes a production improvement, it becomes a normal ticket with a ring and a rollback. Studying is not a change window.

The rollback of a bad lab is the lab rebuild from the provisioning guide. That is a fine outcome.

Choose one specialist guide.
Do its lab and write the before, change, proof, and rollback.
Remove secrets from the note.
Split a sample ticket into one change.
Rehearse who gets called and what they read first.
Reread the note after a week.
Turn a real improvement into a real ticket, or leave production alone.

Mistakes that outlive the command

a sysadmin career fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

A private hero habit with no notes.
Breaking production to learn.
A portfolio full of secrets, hostnames of real customers, or passwords.
Collecting tools without being able to say what they must not do.
An on-call rota with no first page to read.
Two changes in the practice ticket because the lab felt easy.
Skipping backups and patches because they are less interesting than a new installer.
A certificate used as a substitute for the lab note.

Decisions to write down before the window

One decision for a sysadmin career: Every practice change has a note a stranger could follow. The lab is the place that breaks. Production changes go through the matching guide's checks. Notes contain prompt-for-this or nothing, never a live secret. On-call has a first page: what the service is, where the log is, who the next person is. Patch and backup practice are on the list, not only the interesting install. A ticket with two changes gets split before it is called practice. Tools are checked against the guide, not trusted because they produced a file. A week later the note still makes sense, or it is rewritten. Shared admin passwords are not part of how you work. The fundamentals guide already forbids them. The next guide you study is named, so the week is not random. And a second person, even a future you, could perform the rollback from the note.

Practice checks before you call the note finished

Confirm this before you call the change done: The note has before, change, proof, and rollback. No secret, customer data, or live hostname you do not own is in it. The lab, not production, was the place you broke. The ticket you studied has one change. The on-call first page exists or is honestly marked missing. Backup or patch practice is scheduled if you have not done it. The generator output in the note was trimmed and explained. You reread the note, or you set the date to reread it. Rollback was actually used once in the lab. The next guide is named. A stranger could follow the rollback. The fundamentals page for the lab host is still true. No shared password was introduced to make the lab easier. The hostname in the prompt matches the hostname in the ticket for a sysadmin career. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for a sysadmin career happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

This pillar does not name a browser tool. The related pillar guides are where the calculators for the neighbouring work live.

Guides in this cluster

These supporting pages belong to this pillar.