I recently moved into IT and now work as the sole sysadmin for a small company. I manage Microsoft 365, macOS devices, three locations with small Proxmox clusters of up to three nodes each, FortiGate firewalls, Synology storage, and a homelab.
I have learned a lot through hands-on work, vendor documentation, online research, certifications, and lab projects, but I still feel like I am missing the broader picture of infrastructure best practices. I am especially interested in practical guidance for Proxmox deployments, backups and restore testing, secure configurations, hardening, firewall rules, storage permissions, VM and LXC security, monitoring, alerting, logging, patch management, and general operational processes. I am looking more for infrastructure guidance than Microsoft 365 material.
Since I am the only IT person at the company, I do not have experienced colleagues to learn from or ask about things I may not even know exist. What books, courses, certifications, documentation, lab exercises, or working habits helped you become a stronger sysadmin?
4 Answers
Build a solid foundation in networking, routing, operating-system administration, and security. Certifications can help organize the fundamentals, but the biggest improvement usually comes from choosing a real project and implementing it repeatedly in your lab.
Model the project, document each step, deliberately tear it down, and rebuild it two or three times. Each pass exposes documentation you missed and makes the deployment, recovery process, and failure modes much clearer. Treat the lab as a safe place to test changes before applying them at work.
It is also important to learn the operational side of IT: risk management, communicating with stakeholders, and understanding what users are actually trying to accomplish. Instead of simply saying no to a request, try to find a way to achieve the goal while preserving security and stability. Becoming a reliable problem solver builds trust, which is one of the most valuable skills for an IT team.
Start with vendor documentation and recognized hardening guidance, then apply it in your lab instead of only reading about it. CIS Benchmarks are useful for systems such as Debian and Windows, and Fortinet's own security guidance is a good reference for the firewall.
I would prioritize backups first. Set up Proxmox Backup Server with retention rules you can explain, and regularly restore a VM into an isolated network to prove the backups actually work. Identity should come next: eliminate shared administrator accounts, enable MFA for Microsoft 365 administrators, use Conditional Access baselines, and keep separate everyday and administrative accounts for Proxmox and the firewall.
Write down a patching schedule for the Proxmox nodes, Synology DSM, and FortiGate firmware, including the vendor's recommended upgrade paths. For firewall rules, begin with a deny-by-default approach where appropriate and monitor blocked traffic before tightening things further. With a small environment, tools such as Uptime Kuma or Zabbix can cover basic monitoring. Alert on backup failures, storage health, and expiring certificates—those are common sources of unpleasant surprises.
Also create a short runbook for each system while you work. Documentation written during implementation is much more useful than trying to reconstruct everything later.
This is exactly the kind of practical checklist I was looking for. The restore-testing point and writing runbooks as I go are especially helpful.
For documentation, look into the Diátaxis framework. It separates documentation into tutorials, how-to guides, explanations, and reference material, which makes it easier to decide what type of document you are writing.
In day-to-day operations, keep concise runbooks for common tasks, diagrams for network and service dependencies, an inventory of systems and owners, backup and recovery procedures, and change notes for anything that affects production. The goal is not to write a huge manual—it is to make the next troubleshooting or recovery task predictable for someone who did not perform the original setup.
Use AI as an assistant for planning and troubleshooting, but verify every recommendation against vendor documentation and your own tests. It can miss important context or confidently suggest an unsafe configuration. A good workflow is to ask it for possible approaches, check those against official guides and security benchmarks, then validate the result in the lab before production.
I have been using a homelab and doing security training, but repeating complete projects and documenting the rebuilds is a good way to turn that into deeper operational knowledge.