1 IT Infrastructure Operations Foundations

Infrastructure operations and reliability

IT infrastructure operations keeps the technology supporting an organization’s services available, secure, and fit for purpose. It covers physical and cloud computing resources, operating systems, storage, networks, identity services, and the procedures used to operate them. Operations teams maintain systems day to day, respond to disruptions, and improve reliability over time.

Reliability is a service’s ability to work as users need it, including during expected demand and foreseeable failures. It can be described using measures that connect technical operations to user experience:

• A service level indicator (SLI) measures an aspect of service performance.

• A service level objective (SLO) sets a target for an SLI over a defined period.

• A service level agreement (SLA) is a commitment to customers and may specify consequences if service levels are not met.

For example, an SLO might target 99.9% of requests succeeding in a month. A server can appear healthy even when a critical service is unavailable, so reliability monitoring should include user-facing measures as well as infrastructure signals.

Operational roles and coordination

Responsibilities vary by organization, and one person may hold several in a small organization. Common responsibilities include:

• Service or operations owners coordinate service health, maintenance, capacity, and operational priorities.

• System, cloud, and network administrators or engineers configure and maintain platforms and connectivity.

• Service desk and support staff receive requests, record symptoms, and route work to the appropriate teams.

• Security and incident-response personnel investigate threats and coordinate response with technology teams.

• Managers and service owners set priorities, approve risk decisions, and communicate with affected stakeholders.

During a major incident, teams should make clear who coordinates the response, who performs technical work, and who communicates updates. Clear responsibility supports both day-to-day operation and coordinated response.

Monitoring and incident response

Monitoring collects and presents information about service health, performance, and resource use. Its sources may include metrics, logs, events, traces, and active checks. Useful monitoring helps teams detect problems affecting users, investigate causes, spot trends, and plan capacity. Alerts should be timely and actionable: an alert that a sign-in service is failing is more useful than a notification about a metric that requires no response.

An incident is an unplanned disruption or degradation of a service. A sound response process establishes severity, assigns responsibilities, records actions and decisions, communicates status, restores service, and reviews what can be improved. An incident record should capture a useful timeline, observed impact, investigation, changes made, and follow-up actions. These records support learning and help teams recognize recurring problems.

Documentation and configuration control

Operational documentation makes infrastructure understandable and supportable. Common examples include asset inventories, service and network diagrams, system dependencies, standard operating procedures, access and escalation contacts, backup details, and recovery runbooks. Documentation should have an owner and be updated when systems or procedures change. An accurate diagram can show that an application depends on a particular DNS service, firewall, and database.

Configuration management controls how systems are built, changed, and maintained. Teams establish known configurations; track important hardware and software; review proposed changes; record approvals and outcomes; and check for unintended differences from approved settings. A configuration baseline might specify an approved operating-system version, security settings, and network rules for a server role. Change records and current inventories help teams understand what is running and how a change may affect related services.

Documentation and configuration management reinforce each other. Inventories and diagrams describe the intended environment, while change records help keep those descriptions current. Monitoring can reveal when actual service behavior or configuration differs from expectations.

Managing network connectivity

Network management maintains the connectivity services that systems and users depend on. It includes managing network devices and links; addressing and name resolution; routing and switching; wireless access; firewalls; and network performance and availability. Operational work includes tracking network assets, documenting connections and dependencies, monitoring link and device health, managing approved changes, and troubleshooting connectivity problems.

When users cannot reach an application, responders can use monitoring and network diagrams to check whether the fault is in the application, name resolution, routing, a firewall rule, or an upstream connection. A current asset inventory and network map make these checks faster and can also support security and change reviews.

Disaster recovery and continuity

Disaster recovery (DR) is the planned restoration of IT systems and data after a serious disruption. It is part of broader continuity planning, which considers how the organization will sustain important work while systems are unavailable. Planning begins by identifying critical services and dependencies, estimating the impact of downtime, and selecting recovery approaches. Plans should name responsibilities, provide actionable procedures, and be exercised and maintained; an untested plan may not work as expected during an emergency.

Two measures help define recovery targets:

• A recovery time objective (RTO) is the target time within which a service should be restored.

• A recovery point objective (RPO) is the target limit for how much data loss, measured in time, is acceptable.

For example, a service with an RTO of four hours and an RPO of one hour should be restored within four hours, using data no more than one hour older than the disruption, if those targets are achievable with the chosen recovery design. Backups, alternate infrastructure, documented dependencies, and recovery tests all contribute to making a plan workable.

How operational practices work together

Consider an organization whose employees cannot access a business application. Monitoring identifies a rise in failed requests. The service desk records user reports, and the incident lead coordinates the response. Network diagrams and inventories show the application’s dependencies, while configuration and change records help identify a recent firewall change. After service is restored, the team documents the timeline, updates the runbook if needed, and assigns preventive work.

If the disruption is broader, such as the loss of a data center, the disaster-recovery plan guides restoration according to service priorities and recovery targets. Together, monitoring, documentation, configuration management, network management, and disaster recovery form a feedback loop: teams observe the service, understand its components, control changes, maintain connectivity, recover when necessary, and use operational evidence to improve reliability.