Англійська для інженерів інфраструктури: словник для зберігання, мережі і операцій

Інженери інфраструктури управляють апаратним забезпеченням, мережами, системами зберігання і операційними процесами, які підтримують роботу служб. Словник охоплює декілька областей — від конфігурацій SAN до маршрутизації BGP до книг виконання подій. Цей підручник містить основні англійські терміни, які ви зустрінете і використовуватимете у ролях інфраструктури.

Словниковий запас

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

Складання на практиці

При обговоренні вимог до зберігання, інженери зазвичай вказують як IOPS (для завантажень, чутливих до затримки), так і прохідність (для великих послідовних читання/запису).

“База даних потребує як мінімум 10 000 IOPS з постійною пропускною здатністю 500 МБ/ с — поточний рівень SAN не може задовольнити цю вимогу під час пікового навантаження.”

Мережеві терміни

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 в простому англійською

BGP може бути залякуванням словника. Простий спосіб пояснити це:

• “BGP — це протокол, який повідомляє маршрутизаторам у мережі Інтернет, як дістатися до різних мереж. Коли ми оголошуємо наш діапазон IP через BGP, ми кажемо інтернету «трафику, призначеного для цих адрес, повинно прийти до нас». *

Інформаційний словник

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

У Runbooks використовуються ** імперативні дієслова ** і чіткі, пронумеровані кроки:

1. “Перевірте, що служба недоступна, запустивши curl -I https://api.example.com.”
2. “Перевірте стан балансування навантаження в консолі AWS і підтвердіть, що принаймні два екземпляри працюють нормально.”
3. • “Якщо менше двох екземплярів є здоровими, перейти до керування інфраструктурою.” *
4. • “Якщо проблема повністю стосується відключення, оголосіть про інцидент за допомогою інструменту керування інцидентами і повідомте про це менеджера з технічного обслуговування.” *

Обговорення інфраструктури на командних зустрічах

** Планування потужностей: **

• “За поточною тенденцією зростання, ми перевищимо нашу ємність зберігання приблизно за п’ять місяців — ми повинні планувати розширення зараз.”

Огляди подій:

• • “Відмовний перехід тривав 8 хвилин, що перевищило наш SLO. Runbook не покриває цей режим невдачі.”*

** Архітектурні обговорення: **

• “Ми повинні розглянути можливість додавання шару CDN перед статичними активами — це зменшить навантаження на сервер походження на 60%.”

Приклади висловлювань

1. «Рівень зберігання NVMe зарезервований для первинної бази даних — всі репліки читання використовують стандартний рівень SSD, який забезпечує достатню кількість IOPS для наших шаблонів запитів»
2. «BGP-парування з нашим провайдером було успішно встановлено; ми зараз оголошуємо наш префікс /24 з обох розташувань центрів даних»
3. “Після відключення зберігання минулого вівторка, ми встановили, що конфігурація VLAN на вторинному сайті не мала правильних правил маршрутизації.”
4. «Наш поточний MTTR для інцидентів, пов’язаних з зберіганням, становить 45 хвилин — більшість цього часу витрачається на ідентифікацію вражених томів з попередження»
5. «Книга для цього режиму несправності була застарілим; ми оновили її і додали автоматизовану перевірку перед польотом до конвеєра розгортання»

Розвиток мовлення: розуміння мовлення в процесі навчання

Ця стаття не має на меті просто навчити вас технічним термінам. Це стосується оснащення вас з можливістю * комунікувати * ефективно в інженерній команді - особливо при роботі зі складними інфраструктурними системами. Для людей, для яких англійська мова не є рідною, розуміння тонких відмінностей у фразуваннях і тоні може бути вирішальним для уникнення непорозумінь і забезпечення того, щоб ваші ідеї були чітко зрозумілі. Часто, це не що ви кажете, а як ви кажете це, що справді має значення. Розгляньте різницю між простою заявою про проблему проти її оформлення як впливу. Пряме твердження на зразок « Сервер не працює » може зустрітися з технічним запитанням про кореневу причину. Але додавання контексту - “Сервер не працює, що впливає на автентифікацію користувача і спричиняє періодичні невдачі при вході” - негайно переносить увагу на бізнес-наслідки і спонукає до більш стратегічної дискусії навколо розв’язання.

Інша область, де нюанс є критичним, це в коментарях перегляду коду. Отримати зворотній зв’ язок щодо вашого коду може бути дуже особистим, навіть якщо це чисто технічна реалізація. Фраза на кшталт «Це не ідеальне» може бути інтерпретована як критика всього вашого підходу. Однак більш конструктивний і конкретний коментар - “Розгляньте використання механізму повторних спроб тут для обробки перехідних помилок мережі; це уникає каскадних невдач” - демонструє розуміння і пропонує реальні рішення. Аналогічно, при написанні описів PR, уникайте нечітких тверджень. Замість « Виправлено ваду », спробуйте « Виправлено проблему з перервами у з’ єднанні з сервером бази даних, використовуючи параметри TCP keepalive для підтримки постійних з’ єднань ». Точність мови створює довіру і сприяє ефективній співпраці. Пам’ ятайте, ваша мета - зробити значний внесок у спільне розуміння команди, а не просто представити технічно правильний варіант.

Крім того, пам’ятайте про пасивний голос проти активного голосу. Хоча пасивний голос іноді може бути корисним для опису процесів без явного іменування актора, надмірна залежність від нього може затемнити відповідальність і ускладнити розуміння * того, хто * відповідає за певний результат. Активний голос – «Система автоматично масштабується під час пікових навантажень» – чітко ідентифікує систему як виконання дії.

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

Цю просту команду, якщо її описати у звіті або повідомленні Slack, можна сформулювати по- іншому, залежно від контексту. « Пінг сервера бази даних тричі зазнав невдачі » є фактом, але не має впливу. « Ми спостерігали періодичні проблеми з’ єднання з dbserver.example.com, що вказує на повторювані помилки ping, які, можливо, сигналізують про проблеми з мережею » — це більш інформаційне і активне твердження.