Systems and Network Administration

01Purpose and scope

• This manual supports the course Systems and Network Administration. It describes how the work is actually done in production environments where administrators keep servers, storage, directory services, network devices, and the connections between them running for users.
• The scope covers daily operations, planned changes, incident response, and the records that make those activities repeatable. It does not teach a single vendor product line. Commands and interface steps differ by platform, so treat any example here as a pattern to adapt to your own equipment and policies.
• Practice varies with organization size. A small office may run one firewall and a file server with a single administrator, while a multi-site operation may manage hypervisors, load balancers, directory replicas, and cloud network segments with separate teams for each. The underlying principles stay the same, but approval paths, tooling, staffing, and the cost of an outage change considerably.

02Core principles

• Least privilege governs accounts. Administrators hold separate privileged accounts, sign in with them only for administrative tasks, and use audited elevation where the platform supports it. Shared administrator logins make it impossible to tell who changed what.
• Changes should be small, reversible, and recorded. A change that cannot be rolled back within a known time is treated as higher risk and needs a tested backup or fallback plan before it proceeds. Large changes are split into stages so each stage can be checked on its own.
• Configuration is described in one place. Whether that place is a version-controlled repository, a configuration management tool, or a carefully maintained runbook, the goal is that the running state can be compared against the intended state. Drift between the two is the quiet cause of many later failures.
• Systems are designed to be observed. Logs, metrics, and alerts belong to the build itself, not to a list of things to add after the first outage. A host without time synchronization, central logging, or a health check is harder to trust no matter how well it is configured.

03Planning and preparation

• Start with an inventory. Know which hosts, switches, routers, firewalls, certificates, DNS zones, and service accounts exist, who owns each one, and what depends on it. An asset record that is wrong is often worse than none because it misleads the next person who plans a change.
• Establish baselines before changing anything. Record operating system versions, interface configurations, routing tables, patch levels, certificate expiration, and typical CPU, memory, and disk use. Baselines make it possible to tell whether a problem began with a change or was already present when you arrived.
• Define the service levels that matter. Stakeholders usually care about availability during business hours, the time allowed to restore service after an outage, and how much data may be lost in a failure. Write these as targets with named owners so they can be checked and argued over in a useful way.
• Common frameworks help with the structure. The ITIL change enablement practice describes how changes are classified, assessed, and approved, and the CIS Benchmarks publish hardening baselines for many operating systems and network devices. Use these as starting points and adapt them, because a hardening baseline can break a legacy application that depends on an old protocol. Document every deviation with a reason and a review interval.

04Recommended workflow

1. 1
   : Confirm the request and classify it as standard, normal, or emergency according to the local change policy. Classification decides who must approve the work and how much testing is expected.
2. 2
   : Write the change record with the purpose, affected systems, owner, expected duration, rollback steps, and the test evidence you have gathered. A vague record makes approval slow and makes later review nearly impossible.
3. 3
   : Test in a lab or staging environment that resembles production in the parts that matter, such as operating system version, network path, authentication source, and volume of traffic. A lab that differs only in the parts you did not check will pass changes that fail later.
4. 4
   : Obtain approval from the change authority. Emergency changes may proceed under a faster path, but they still need a documented reason and a review afterward so that the process does not quietly become the normal route.
5. 5
   : Take a verified backup or configuration snapshot immediately before the change, and confirm that a restore has been tested for that system. A backup file that exists but has never been restored is only a hope.
6. 6
   : Execute during the agreed window, one step at a time, and check the result of each step against the baseline. Keep a running log of commands or interface actions so the sequence can be reproduced or reversed.
7. 7
   : Verify service health using the defined checks, then notify stakeholders that the change is complete or that a rollback occurred. Confirm from the user side, for example by testing a login or a file transfer, rather than relying only on a device status light.
8. 8
   : Close the record with observed results, any deviations from the plan, and follow-up tasks such as updating documentation or removing temporary access. Open follow-up tasks should have an owner and a due point, not just a note.

05Quality checks, risk controls and compliance

• Verification should test the service, not only the device. A switch that shows its link as up may still be dropping traffic on a misconfigured VLAN, and a server that responds to ping may still be failing to authenticate users. Choose checks that match what people actually do with the system.
• Risk controls include change windows, peer review of configuration changes, separation between the person who builds a change and the person who approves it, and immutable or offline backups for critical systems. Patch deployment should follow a staged ring model, with a small pilot group receiving updates first and wider rollout waiting for a clean observation period.
• Compliance depends heavily on jurisdiction and sector. Requirements for data retention, log content, encryption, access reviews, and breach notification come from laws, contracts, and internal policy, and they differ by location and industry. Consult the current authoritative source for your jurisdiction and your legal or compliance team before setting retention periods or review cycles.
• This guidance does not replace qualified professional judgment, approved procedures, or required authorization. Administrators working on systems that hold regulated data, process payments, or support safety functions must follow their organization's approved change and access procedures, and should not extend their own privileges to complete a task.

06Collaboration and documentation

• Administrators work with application owners, security staff, help desk teams, facilities staff responsible for power and cooling, and sometimes external carriers or cloud providers. Agree on who speaks for a service during an incident before one happens, because unclear ownership slows every decision once the pressure is on.
• Runbooks should be written for the person on call at night who did not build the system. Include the normal state, how to check it, the common failure modes, the steps to take for each, and an escalation path with current contact methods. Review runbooks after each incident where they were used.
• Keep documentation close to the work. A network diagram stored in a file that no one opens will drift from reality within a few changes. Attach configuration exports and change records to the same ticket so the history can be searched, and link each monitored service to its runbook.

07Measures and continuous improvement

• Track a small set of indicators. Useful ones include the share of changes with a tested rollback plan, the number of incidents caused by changes, mean time to restore for priority services, the count of systems outside their baseline, and the share of critical patches applied within the agreed window. Targets depend on the environment, so set them with the service owners rather than copying a generic figure from elsewhere.
• Review incidents and failed changes in a blameless format. Focus on the conditions that allowed the failure, such as missing monitoring, an unclear runbook, a shared credential, or pressure to skip testing. Assign one owner to each corrective action and check whether it was completed.
• Restore tests are a measure too. A backup that has never been restored is an unverified assumption, so schedule periodic restore exercises for critical systems and record how long they took. The result often reveals missing dependencies, such as license servers or encryption keys that were stored only on the failed host.

08Common mistakes and how to prevent them

• Making changes directly on production without a record is the most common source of drift. Even when an emergency path allows a quick fix, the change should be entered afterward and the configuration brought back into version control so the next build does not undo it.
• Trusting a single check. A successful ping does not prove that an application works, and a green dashboard can hide an expired certificate on a secondary path. Combine a device check, a service check, and a user-side check for each important function.
• Leaving default credentials, open management interfaces, or broad firewall rules in place after a project ends. Include a decommissioning step in every project plan that removes temporary accounts, test rules, and old addresses.
• Skipping the rollback plan because the change looks simple. Simple changes cause outages too, often through a forgotten dependency such as a DNS record, a scheduled job, or a monitoring threshold tied to the old setting. Write the rollback plan anyway and keep it short.

09Practical checklist

• Confirm the asset inventory entry and named owner for every system in scope.
• Record the baseline configuration, versions, and resource use before editing anything.
• Classify the change and obtain the approval required by local policy.
• Write the rollback procedure and test it in a nonproduction environment.
• Take and verify a backup or snapshot immediately before execution.
• Run the agreed service checks from the user side after each major step.
• Update documentation, the configuration repository, and monitoring thresholds.
• Close the change record with results, deviations, and follow-up actions with owners.

★Learning sources

• Micro Degree: Systems and Network Administration
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics