English for Infrastructure Engineers: Vocabulary for Storage, Networking, and Ops
Master the English vocabulary infrastructure engineers use for storage systems, networking, incident response, and operational documentation.
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:
- “Verify that the service is unreachable by running
curl -I https://api.example.com.” - “Check the load balancer health in the AWS console and confirm that at least two instances are healthy.”
- “If fewer than two instances are healthy, escalate to the infrastructure lead.”
- “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
- “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.”
- “BGP peering with our upstream provider was established successfully; we’re now announcing our /24 prefix from both data centre locations.”
- “Following the storage failover last Tuesday, we identified that the VLAN configuration on the secondary site was missing the correct routing rules.”
- “Our current MTTR for storage-related incidents is 45 minutes — the majority of this time is spent identifying the affected volume from the alert.”
- “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.comThis 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.