English for Infrastructure Engineers: Vocabulary for Storage, Networking, and Ops

Infrastructure engineers manage the hardware, networks, storage systems, and operational processes that keep services running. The vocabulary spans multiple domains — from SAN configurations to BGP routing to incident runbooks. This guide covers the core English terms you’ll encounter and use in infrastructure roles.

Storage Vocabulary

Term	Definition
SAN	Storage Area Network — a dedicated high-speed network that provides block-level storage to servers
NAS	Network Attached Storage — a file-level storage device accessible over a network
NVMe	Non-Volatile Memory Express — a high-performance storage protocol designed for SSDs
Tiering	Automatically moving data between storage tiers (e.g. fast SSD, slower HDD, archive) based on access frequency
IOPS	Input/Output Operations Per Second — a measure of storage performance
Throughput	The volume of data transferred per unit of time (e.g. GB/s)
Snapshot	A point-in-time copy of a storage volume, used for backups and recovery
Replication	Copying data to a secondary location in real time for redundancy

Storage in Practice

When discussing storage requirements, engineers typically specify both IOPS (for latency-sensitive workloads) and throughput (for large sequential reads/writes).

“The database requires a minimum of 10,000 IOPS with sustained throughput of 500 MB/s — the current SAN tier cannot meet this requirement under peak load.”

Networking Terms

Term	Definition
BGP	Border Gateway Protocol — the routing protocol that manages how packets are routed across the internet
VLAN	Virtual Local Area Network — a logical segmentation of a network
Load balancer	A device or service that distributes incoming traffic across multiple servers
Failover	Automatically switching to a secondary system when the primary fails
CDN	Content Delivery Network — a globally distributed network of servers that caches content close to users
Peering	A direct network interconnection between two organisations
MTU	Maximum Transmission Unit — the largest packet size that can be transmitted on a network
Latency	The time for a packet to travel from source to destination

BGP in Plain English

BGP can be intimidating vocabulary. A simple way to explain it:

“BGP is the protocol that tells routers across the internet how to reach different networks. When we announce our IP range via BGP, we’re telling the internet ‘traffic destined for these addresses should come to us’.”

Incident Vocabulary

Term	Definition
MTTR	Mean Time to Recovery — average time to restore a service after an outage
Runbook	A documented set of procedures for responding to a known operational issue
On-call rotation	A schedule where engineers take turns being the primary responder to alerts
Escalation path	The sequence of people to contact if the on-call engineer cannot resolve the issue
SLA	Service Level Agreement — a commitment to a minimum level of service
SLO	Service Level Objective — an internal target for service performance
Error budget	The allowable amount of downtime defined by an SLO
Postmortem	A structured analysis of an incident after it is resolved

Runbook Writing Language

Runbooks use imperative verbs and clear, numbered steps:

1. “Verify that the service is unreachable by running curl -I https://api.example.com.”
2. “Check the load balancer health in the AWS console and confirm that at least two instances are healthy.”
3. “If fewer than two instances are healthy, escalate to the infrastructure lead.”
4. “If the issue is a full outage, declare an incident using the incident management tool and notify the engineering manager.”

Discussing Infrastructure in Team Meetings

Capacity planning:

• “Based on current growth trends, we’ll exceed our storage capacity in approximately five months — we should plan the expansion now.”

Incident reviews:

• “The failover took 8 minutes, which exceeded our SLO. The runbook didn’t cover this failure mode.”

Architecture discussions:

• “We should consider adding a CDN layer in front of the static assets — it would reduce origin server load by an estimated 60%.”

Example Sentences

1. “The NVMe storage tier is reserved for the database primary — all read replicas use the standard SSD tier, which provides sufficient IOPS for our query patterns.”
2. “BGP peering with our upstream provider was established successfully; we’re now announcing our /24 prefix from both data centre locations.”
3. “Following the storage failover last Tuesday, we identified that the VLAN configuration on the secondary site was missing the correct routing rules.”
4. “Our current MTTR for storage-related incidents is 45 minutes — the majority of this time is spent identifying the affected volume from the alert.”
5. “The runbook for this failure mode was out of date; we’ve updated it and added an automated pre-flight check to the deployment pipeline.”

Bridging the Gap: Understanding Nuance in Collaboration

The goal of this post isn’t just to teach you a list of technical terms. It’s about equipping you with the ability to communicate effectively within an engineering team – particularly when dealing with complex infrastructure systems. For non-native English speakers, grasping subtle differences in phrasing and tone can be crucial for avoiding misunderstandings and ensuring your ideas are clearly received. Often, it’s not what you say, but how you say it that truly matters. Consider the difference between stating a problem simply versus framing it as an impact. A direct statement like “The server is down” might be met with a technical question about root cause. But adding context – “The server is down, impacting user authentication and causing intermittent login failures” – immediately shifts the focus to the business consequence and prompts a more strategic discussion around resolution.

Another area where nuance is critical is in code review comments. Receiving feedback on your code can feel intensely personal, even if it’s purely about technical implementation. A phrase like “This isn’t ideal” could be interpreted as criticism of your entire approach. However, a more constructive and specific comment – “Consider using a retry mechanism here to handle transient network errors; this avoids cascading failures” – demonstrates understanding and offers a tangible solution. Similarly, when writing PR descriptions, avoid vague statements. Instead of “Fixed bug,” try “Resolved an intermittent connection loss issue with the database server, utilizing TCP keepalive settings to maintain persistent connections.” Precision in language builds trust and facilitates efficient collaboration. Remember, your goal is to contribute meaningfully to the team’s shared understanding, not just present a technically correct solution.

Furthermore, be mindful of passive voice versus active voice. While passive voice can sometimes be useful for describing processes without explicitly naming an actor, over-reliance on it can obscure responsibility and make it difficult to understand who is accountable for a particular outcome. Active voice – “The system automatically scales up during peak loads” – clearly identifies the system as performing the action.

# Example: Monitoring database connection health using `ping`
ping -c 3 dbserver.example.com

This simple command, when described in a report or Slack message, can be phrased differently depending on the context. “The ping to the database server failed three times” is factual but lacks impact. “We observed intermittent connectivity issues with dbserver.example.com, as indicated by repeated ping failures, potentially signaling underlying network problems.” – that’s a more informative and proactive statement.