Английский B2 для IT: грамматика, лексика и техническое письмо в системном администрировании и кибербезопасности

Артикли (a, an, the) и предлоги (in, as) в IT-контексте: серверы, сети и облачная инфраструктура

Почему инженер с десятилетним стажем может написать в отчёте «We migrated database to new server» и получить замечание от технического редактора, хотя каждый технический специалист в команде прекрасно понимает, о чём речь? Потому что в английском языке пропущенный артикль — это не мелочь, а сигнал: либо вы не владеете языком на нужном уровне, либо вы не уделяете внимание деталям. А в системном администрировании и кибербезопасности детали решают всё. Давайте разберёмся, как правильно использовать артикли и предлоги в контексте IT-инфраструктуры, чтобы ваши отчёты, документация и переписка с коллегами выглядели профессионально.

Артикли a/an: когда речь идёт о «каком-то одном»

Артикль a (перед согласным звуком) или an (перед гласным звуком) используется, когда вы упоминаете объект впервые или говорите о чём-то неопределённом — «какой-то один, любой из категории». Важно ориентироваться именно на первый звук, а не на букву. Например: a user (звук [j] — согласный), an HTTP request (звук [eɪtʃ] — гласный), a university (звук [juː] — согласный), an SSL certificate (звук [es] — гласный).

Рассмотрим на практических примерах из системного администрирования:

> We need a load balancer to distribute traffic across the cluster. — Нам нужен какой-то балансировщик нагрузки (мы ещё не выбрали конкретную модель).

> The team deployed an Nginx reverse proxy on the edge node. — Команда развернула один обратный прокси Nginx на граничном узле.

> Configure a firewall rule to block inbound traffic on port 22. — Настройте правило межсетевого экрана для блокировки входящего трафика на порту 22.

Обратите внимание: если вы говорите о конкретном, уже известном собеседнику объекте, артикль a/an не подходит — здесь нужен the или вообще нулевой артикль.

Артикль the: конкретный объект, о котором известно

Артикль the указывает на конкретный, определённый предмет — тот, о котором уже упоминалось, который уникален в контексте или который можно однозначно идентифицировать. В IT это особенно важно, потому что инфраструктура полна уникальных и конкретных сущностей.

> The primary DNS server went offline at 03:14 UTC. — Конкретный основной DNS-сервер вышел из строя (мы знаем, какой именно).

> Update the firewall rules on the production cluster before the migration. — Обновите правила межсетевого экрана на конкретном продуктивном кластере перед миграцией.

> The security team identified the vulnerability during the quarterly audit. — Команда безопасности обнаружила уязвимость во время конкретного квартального аудита.

Когда речь идёт об уникальных в своём роде объектах — the Internet, the cloud, the kernel — артикль the практически всегда обязателен.

Нулевой артикль: обобщения и названия технологий

Артикль не используется, когда вы говорите о чём-то в целом, в обобщённом смысле, а также с названиями конкретных технологий, языков программирования, операционных систем и компаний.

> Docker simplifies container orchestration. — Docker упрощает оркестрацию контейнеров (название технологии — без артикля).

> Linux is widely used in server environments. — Linux широко используется в серверных средах.

> Cloud computing has transformed infrastructure management. — Облачные вычисления изменили управление инфраструктурой (обобщение).

> Firewalls protect networks from unauthorized access. — Межсетевые экраны защищают сети от несанкционированного доступа (обобщение — «межсетевые экраны вообще»).

Типичная ошибка русскоязычных инженеров — поставить артикль перед названием технологии: ❌ the Docker, ❌ a Python. Запомните: названия продуктов, компаний, языков и ОС в артиклях не нуждаются.

Предлог in: местоположение и контекст

Предлог in используется, когда речь идёт о нахождении чего-либо внутри чего-то — физически или логически. В IT это один из самых частых предлогов.

> The error is logged in the system journal. — Ошибка записана в системном журнале.

> The configuration file is stored in /etc/nginx/. — Файл конфигурации хранится в /etc/nginx/.

> We detected suspicious activity in the network traffic. — Мы обнаружили подозрительную активность в сетевом трафике.

> The vulnerability exists in versions 2.1 through 2.4. — Уязвимость существует в версиях с 2.1 по 2.4.

Но будьте внимательны: с некоторыми существительными используется предлог on, а не in. Как отмечают технические писатели, со словами server, computer, hard drive, Internet и названиями платформ принято использовать именно on: on the server, on the local machine, on the Internet, on AWS. Это устойчивое правило, которое нужно запомнить как идиому.

Предлог as: роль и функция

Предлог as переводится как «в качестве» и используется, когда вы описываете роль, функцию или предназначение чего-либо. В IT это ключевой предлог при описании архитектурных решений и конфигураций.

> We use this VM as a staging environment. — Мы используем эту виртуальную машину в качестве промежуточной среды.

> The proxy server acts as an intermediary between the client and the backend. — Прокси-сервер выступает в качестве посредника между клиентом и бэкендом.

> Deploy the patch as a hotfix before the next release cycle. — Разверните патч в качестве срочного исправления перед следующим циклом релиза.

> The certificate functions as a trust anchor in the PKI hierarchy. — Сертификат функционирует в качестве доверенного центра в иерархии PKI.

Типичные ловушки и edge cases

Существуют ситуации, где выбор артикля или предлога неочевиден и зависит от контекста. Вот несколько распространённых случаев, с которыми сталкиваются инженеры.

Артикль с аббревиатурами. Если аббревиатура произносится по буквам и первая буква — гласный звук, нужен an: an API endpoint, an SQL query, an SSH key. Если произносится как слово — ориентируйтесь на первый звук слова: a SQL database (произносится «сикуэл» — [s] согласный), a URL (произносится «ю-ар-эл» — [j] согласный).

Предлоги с облачными сервисами. С облачными платформами используется on (on Azure, on Google Cloud), но с конкретными сервисами внутри — in (in AWS Lambda, in Azure Functions). Это различие важно для точности описания архитектуры.

Артикль the с уникальными инфраструктурными объектами. Когда в вашей компании есть единственный main database server или primary domain controller, вы используете the, потому что собеседник понимает, о каком именно объекте идёт речь: Check the primary domain controller for replication errors.

Правильное использование артиклей и предлогов — это не просто грамматическая корректность. Это точность коммуникации, которая в системном администрировании и кибербезопасности напрямую связана с корректностью настроек, безопасностью конфигураций и качеством документации. Когда вы пишете Configure the firewall on the DMZ server, каждый элемент предложения несёт конкретный смысл: какой firewall (the — конкретный), где (on — на сервере, а не в нём), на каком сервере (the DMZ — определённый). Ошибка в любом из этих элементов может привести к неправильной интерпретации инструкции.

Глагол to be (is/are) и формы множественного числа в системном администрировании

Когда вы пишете инцидент-репорт о падении сервера и вместо «The logs are corrupted» пишете «The logs is corrupted», вы не просто делаете грамматическую ошибку — вы снижаете доверие к своему отчёту. Представьте: вы отправляете escalation-письмо в вендору, а там сплошные ошибки согласования подлежащего и сказуемого. Вендор подсознательно решит: если инженер путает is и are, может, он путает и в диагностике? Давайте разберёмся, как правильно использовать глагол to be и формы множественного числа в контексте системного администрирования и кибербезопасности.

Базовый принцип: согласование подлежащего и сказуемого

Правило простое: is используется с подлежащим в единственном числе, are — с подлежащим во множественном числе. Но в IT-текстах подлежащее часто бывает сложным, составным или скрытым за аббревиатурами, и именно здесь начинаются ошибки.

> The server is running on Ubuntu 24.04. — Сервер работает на Ubuntu 24.04 (единственное число).

> The servers are running on Ubuntu 24.04. — Серверы работают на Ubuntu 24.04 (множественное число).

> The firewall rules are blocking all inbound traffic on port 3389. — Правила межсетевого экрана блокируют весь входящий трафик на порту 3389 (множественное число — rules).

> The firewall is blocking all inbound traffic on port 3389. — Межсетевой экран блокирует весь входящий трафик на порту 3389 (единственное число — firewall).

Обратите внимание на разницу: одно слово меняется — и смысл сдвигается. В первом случае речь идёт о конкретных правилах, во втором — о самом устройстве или сервисе в целом.

Сложные случаи: неисчисляемые существительные и коллективные понятия

В системном администрировании много существительных, которые не имеют множественного числа или наоборот — всегда используются во множественном. Это частый источник ошибок.

Неисчисляемые существительные (всегда с is):

> The network traffic is unusually high this morning. — Сетевой трафик необычно высок этим утром (traffic — неисчисляемое).

> The bandwidth is insufficient for the new deployment. — Пропускная способность недостаточна для нового развёртывания (bandwidth — неисчисляемое).

> The configuration is stored in /etc/nginx/nginx.conf. — Конфигурация хранится в /etc/nginx/nginx.conf (configuration — неисчисляемое в значении «настройки системы»).

> The documentation is outdated and needs a revision. — Документация устарела и нуждается в пересмотре (documentation — неисчисляемое).

Существительные, которые всегда во множественном числе (всегда с are):

> The credentials are stored in the vault. — Учётные данные хранятся в хранилище (credentials — всегда множественное число).

> The logs are rotated daily by logrotate. — Журналы ротируются ежедневно с помощью logrotate (logs — множественное число от log).

> The binaries are located in /usr/local/bin. — Исполняемые файлы расположены в /usr/local/bin (binaries — множественное число от binary).

> The backups are verified every Sunday at 02:00. — Резервные копии проверяются каждое воскресенье в 02:00 (backups — множественное число от backup).

Аббревиатуры: как определить число

Аббревиатуры в IT — отдельная головная боль. Решающее значение имеет то, что скрывается за аббревиатурой. Если полная форма стоит в единственном числе — используйте is, если во множественном — are.

> The API is returning a 503 error. — API возвращает ошибку 503 (Application Programming Interface — единственное число, один интерфейс).

> The DNS records are propagated across all nameservers. — DNS-записи распространены по всем серверам имён (records — множественное число, явно указано).

> The VM is running out of disk space. — Виртуальной машине не хватает места на диске (Virtual Machine — единственное число).

> The VMs are running on different hypervisors. — Виртуальные машины работают на разных гипервизорах (VMs — множественное число, суффикс -s добавлен к аббревиатуре).

Составные подлежащие: and, or, along with

Когда подлежащее состоит из нескольких частей, соединённых союзами, правило согласования меняется.

Союз and — подлежащее становится множественным:

> The proxy server and the load balancer are configured to use round-robin. — Прокси-сервер и балансировщик нагрузки настроены на использование round-robin.

Союзы or / nor — глагол согласуется с ближайшим подлежащим:

> The firewall or the intrusion detection system is responsible for this alert. — За этот алерт отвечает межсетевой экран или система обнаружения вторжений (ближайшее подлежащее system — единственное число).

> Neither the logs nor the packet capture is showing any anomalies. — Ни журналы, ни захват пакетов не показывают аномалий (ближайшее capture — единственное число).

Конструкции с along with, together with, as well as — глагол согласуется с первым подлежащим:

> The database server, along with the application servers, is being migrated to the new data center. — Сервер базы данных вместе с серверами приложений мигрируется в новый дата-центр (главное подлежащее server — единственное число).

Формы множественного числа: правила и исключения

Правильное образование множественного числа критически важно для точности технических текстов. Вот основные правила с IT-примерами.

Стандартное правило: +s

| Единственное число | Множественное число | |---|---| | server | servers | | firewall | firewalls | | container | containers | | endpoint | endpoints | | snapshot | snapshots |

На -s, -ss, -sh, -ch, -x, -o: +es

| Единственное число | Множественное число | |---|---| | process | processes | | address | addresses | | proxy | proxies | | patch | patches | | box (сервер в сленге) | boxes |

На -y после согласной: -y → -ies

| Единственное число | Множественное число | |---|---| | policy | policies | | registry | registries | | entry | entries | | binary | binaries |

Исключения (неизменяемые формы):

| Единственное число | Множественное число | |---|---| | software | software | | hardware | hardware | | malware | malware | | traffic | traffic | | middleware | middleware |

Эти существительные неисчисляемые — они не принимают окончание -s и всегда требуют глагола в единственном числе: ❌ The softwares are installed → ✅ The software is installed.

Практический кейс: описание инцидента

Посмотрим, как все эти правила работают в связном тексте — описании реального инцидента.

> The monitoring system is alerting on high CPU usage across three nodes. The logs are showing repeated OOM kills in the container runtime. The credentials are still valid — we verified them against the vault. Neither the application server nor the database is responding to health checks. The network traffic is within normal parameters, so the issue is likely at the application layer. The binaries are intact — we compared checksums with the last known good build. The configuration is unchanged since the last deployment. The backups are available and verified.

Каждое использование is/are здесь логически обосновано: system is (единственное число), logs are (множественное), credentials are (всегда множественное), neither...nor...is (ближайшее подлежащее database — единственное), traffic is (неисчисляемое), issue is (единственное), binaries are (множественное), configuration is (неисчисляемое), backups are (множественное).

Заметьте: в этом абзаце нет ни одного случая, где выбор между is и are был бы произвольным. Каждый раз решение диктуется логикой подлежащего. Именно так и должно работать в ваших отчётах и документации.

Притяжательный падеж ('s) и множественные числа в кибербезопасности

В отчёте о киберинциденте вы пишете: «The attacker compromised the admin's credentials and accessed the servers logs». Коллега-носитель языка морщится. Не потому что не понял — понял. А потому что «servers logs» режет глаз так же, как опечатка в IP-адресе режет глаз системному администратору. Притяжательный падеж и множественное число — две грамматические конструкции, которые в английском выглядят почти одинаково, но работают совершенно по-разному. В кибербезопасности, где точность формулировок может повлиять на классификацию инцидента, это различие критично.

Базовое правило: 's для притяжательного падежа

Притяжательный падеж (possessive case) показывает принадлежность: чей-то пароль, чей-то сертификат, чей-то лог. Формируется добавлением 's к существительному в единственном числе.

> The admin's password was found in a public paste site. — Пароль администратора был найден на публичном сайте для вставок.

> The company's firewall rules were last updated in January. — Правила межсетевого экрана компании последний раз обновлялись в январе.

> The server's SSL certificate expired three days ago. — SSL-сертификат сервера истёк три дня назад.

> The analyst's report confirmed the presence of a backdoor. — Отчёт аналитика подтвердил наличие бэкдора.

Важно: 's — это не множественное число. Это показатель принадлежности. Сравните: the admin's password (пароль администратора — один администратор, один пароль) и the admins (администраторы — множественное число, несколько человек).

Множественное число: когда нужен просто -s

Множественное число образуется добавлением -s (или -es, -ies по правилам из предыдущей статьи) и показывает, что предметов несколько. Никакого апострофа здесь быть не должно.

> The admins changed their passwords after the breach. — Администраторы сменили свои пароли после взлома.

> All servers in the DMZ were patched within 24 hours. — Все серверы в DMZ были пропатчены в течение 24 часов.

> The certificates need to be renewed before the end of the quarter. — Сертификаты необходимо обновить до конца квартала.

> Multiple firewalls are protecting the perimeter network. — Несколько межсетевых экранов защищают периметровую сеть.

Типичная ошибка — поставить апостроф там, где нужно просто множественное число: ❌ The firewall's are blocking traffic → ✅ The firewalls are blocking traffic. Апостроф в английском не используется для образования множественного числа существительных — никогда.

Притяжательный падеж множественного числа: admins'

Когда нужно показать принадлежность и при этом существительное стоит во множественном числе, апостроф ставится после окончания -s: admins', servers', analysts'.

> The admins' credentials were compromised in the phishing attack. — Учётные данные администраторов были скомпрометированы в результате фишинговой атаки.

> The servers' operating systems were all running outdated kernel versions. — Операционные системы серверов все работали на устаревших версиях ядра.

> The analysts' findings were presented to the CISO on Friday. — Находки аналитиков были представлены CISO в пятницу.

> The attackers' infrastructure was traced back to three IP ranges. — Инфраструктура атакующих была отслежена до трёх IP-диапазонов.

Сравните три формы на одном примере:

| Форма | Пример | Значение | |---|---|---| | Единственное число + 's | the analyst's report | отчёт одного аналитика | | Множественное число (просто -s) | the analysts presented findings | аналитики представили находки | | Множественное число + ' (после -s) | the analysts' reports | отчёты нескольких аналитиков |

Это различие — ключевое. Ошибка в одном апострофе может изменить смысл: the analyst's report (один отчёт, один аналитик) против the analysts' reports (несколько отчётов, несколько аналитиков).

Исключения: нерегулярные формы множественного числа

Существительные с нерегулярным множественным числом образуют притяжательный падеж по тем же правилам, но с нестандартной основой.

> The children's accounts on the school network had elevated privileges. — Детские аккаунты в школьной сети имели повышенные привилегии (children — нерегулярное множественное число от child).

> The men's credentials were stored in plaintext. — Мужские учётные данные хранились в открытом тексте (men — нерегулярное множественное число от man).

В IT-контексте такие формы встречаются редко, но знать о них нужно — особенно при анализе социальной инженерии и фишинговых атак, где описываются действия людей.

Альтернатива: конструкция of

Притяжательный падеж с 's — не единственный способ выразить принадлежность. Конструкция noun + of + noun используется, когда владелец — неодушевлённый предмет или абстрактное понятие. В кибербезопасности это особенно распространено.

> The compromise of the certificate authority led to a mass revocation of TLS certificates. — Компрометация удостоверяющего центра привела к массовому отзыву TLS-сертификатов.

> The analysis of the network traffic revealed a covert C2 channel. — Анализ сетевого трафика выявил скрытый канал управления (C2).

> The rotation of the encryption keys happens every 90 days. — Ротация ключей шифрования происходит каждые 90 дней.

> The integrity of the backup files was verified using SHA-256 checksums. — Целостность файлов резервных копий была проверена с помощью контрольных сумм SHA-256.

Как правило, 's используется с одушевлёнными существительными и короткими фразами (the admin's password, the attacker's IP), а of — с неодушевлёнными и длинными конструкциями (the integrity of the backup files, the compromise of the certificate authority). Но это не абсолютное правило — бывают исключения в обе стороны.

Сложные случаи: совмещение притяжательного падежа и множественного числа

В реальных отчётах о киберинцидентах часто встречаются конструкции, где нужно одновременно использовать и множественное число, и притяжательный падеж, и при этом не запутаться.

> The attackers' C2 servers' SSL certificates were issued by a compromised CA. — SSL-сертификаты C2-серверов атакующих были выпущены скомпрометированным УЦ.

Разберём по частям: attackers' — множественное число + притяжательный падеж (принадлежность атакующим), servers' — множественное число + притяжательный падеж (принадлежность серверам), certificates — просто множественное число (сертификаты — подлежащее).

> The companies' security teams' response times improved after the tabletop exercise. — Время реагирования команд безопасности компаний улучшилось после настольных учений.

Здесь companies' — множественное число + притяжательный падеж (принадлежность компаниям), teams' — множественное число + притяжательный падеж (принадлежность командам), response times — просто множественное число.

Такие длинные цепочки лучше раскрывать через конструкцию of для читаемости: The response times of the security teams of the companies improved... — грамматически менее элегантно, но понятнее.

Когда 's — это не притяжательный падеж

Не путайте притяжательный падеж с сокращением глагола to be: it's = it is или it has, а не it (притяжательное). Это одна из самых частых ошибок даже у носителей языка.

> ❌ The server lost it's connection to the database. → ✅ The server lost its connection to the database.

> ❌ It's configuration was modified by an unauthorized user. → ✅ Its configuration was modified by an unauthorized user.

Запомните: its (без апострофа) — притяжательное местоимение (его/её), it's (с апострофом) — сокращение от it is или it has. В технических текстах это различие критично, потому что ошибка может исказить смысл: it's running (оно работает) против its running (его работа — бессмысленная конструкция).

Структурирование технических отчётов и документации в профессиональном стиле

Вы обнаружили уязвимость нулевого дня в корпоративном VPN-шлюзе. Вы написали подробный отчёт на 1500 слов — описали вектор атаки, затронутые хосты, временну́ю шкалу и рекомендации. Но менеджер по безопасности вернул его обратно с пометкой: «Restructure — I can't find the timeline in this mess». Проблема не в содержании — проблема в структуре. Технический отчёт — это не блог-пост и не личный дневник. У него есть жёсткие конвенции, которые инженеры и менеджеры ожидают увидеть. Если вы их нарушаете, читатель тратит время на поиск нужной информации вместо того, чтобы действовать. В кибербезопасности это время может стоить дорого.

Принцип перевёрнутой пирамиды: главное — сначала

Профессиональные технические тексты строятся по принципу inverted pyramid (перевёрнутая пирамида): самая важная информация идёт в начале, детали — дальше, а контекст и справочные данные — в конце. Это не академический стиль, где вы ведёте читателя от гипотезы к выводу. В инженерном письме читатель хочет сразу понять: что произошло, что это значит, что нужно сделать.

Рассмотрим на примере отчёта об инциденте.

Плохо (академический стиль): > In recent years, the number of cyberattacks targeting enterprise VPN solutions has increased significantly. According to industry reports, VPN vulnerabilities accounted for 29% of initial access vectors in 2025. This report examines a specific incident involving...

Хорошо (инженерный стиль): > On March 15, 2026, the SOC detected unauthorized access to the corporate VPN gateway (vpn-gw-01.prod). The attacker exploited CVE-2026-1042 to gain initial access. Three internal servers were compromised. Containment was achieved within 47 minutes. This report details the timeline, impact, and remediation steps.

Второй вариант за первые два предложения даёт читателю: когда (When), что (What), где (Where) и какой масштаб (Impact). Детали — дальше. Именно так структурируются отчёты в SOC-командах и у вендоров безопасности.

Структура технического отчёта об инциденте

Типовой отчёт о киберинциденте (Incident Report) содержит следующие секции, каждая из которых решает конкретную задачу.

Executive Summary — краткое резюме для руководства. Два-четыре предложения, без технического жаргона. Руководитель должен понять суть за 30 секунд.

> A critical vulnerability in the VPN gateway was exploited on March 15, resulting in unauthorized access to three internal servers. The incident was contained within 47 minutes. No customer data was exfiltrated. Full remediation was completed within 72 hours.

Timeline — хронология событий. Каждая запись: дата/время (в UTC), описание события, источник данных. Без интерпретаций — только факты.

> 2026-03-15 02:14 UTC — IDS alert: anomalous authentication pattern on vpn-gw-01 (source: Suricata, rule SID 20261042) > 2026-03-15 02:16 UTC — SOC analyst confirmed unauthorized session from IP 203.0.113.47 > 2026-03-15 02:31 UTC — VPN gateway isolated from the network > 2026-03-15 03:01 UTC — Affected servers (app-03, db-02, file-01) isolated and forensic images captured

Technical Analysis — детальное описание вектора атаки, использованных техник, затронутых систем. Здесь допустим технический жарго́н и ссылки на CVE, MITRE ATT&CK и т. д.

Impact Assessment — оценка ущерба: какие данные затронуты, какие системы недоступны, какой бизнес-процесс пострадал.

Remediation and Recommendations — что уже сделано (containment, eradication) и что рекомендуется сделать (long-term fixes, policy changes).

Абзац как единица структуры

Каждый абзац в техническом тексте должен содержать одну идею. Первое предложение абзаца — topic sentence (тематическое предложение) — формулирует эту идею. Остальные предложения развивают, поясняют или иллюстрируют её.

> The firewall rules on the perimeter network were misconfigured during the last maintenance window. Specifically, the rule allowing inbound HTTPS traffic (TCP/443) was duplicated with a broader source range, permitting connections from 0.0.0.0/0 instead of the intended 10.0.0.0/8. This misconfiguration was introduced on March 10 during a routine policy update and went undetected for five days because the change management process did not trigger a peer review for rule modifications affecting fewer than three rules.

Первое предложение — тезис. Второе — конкретизация. Третье — контекст и причина. Читатель может прочитать только первое предложение и получить основной смысл, а может углубиться в детали.

Типичная ошибка — писать абзацы-монолиты на 10–15 строк без внутренней логической структуры. Если абзац длиннее 5–6 строк, проверьте: не содержит ли он две идеи? Если да — разделите.

Согласование времён и стилистическое единство

Технический отчёт пишется в прошедшем времени (Past Simple, Past Perfect), когда описываются произошедшие события, и в настоящем времени (Present Simple), когда формулируются рекомендации и общие истины.

> The attacker exploited the vulnerability at 02:14 UTC. The SOC detected the intrusion two minutes later. The team isolated the affected systems by 03:01 UTC. (Past Simple — хронология событий)

> The vulnerability has been patched in version 4.2.1. All affected certificates have been revoked. (Present Perfect — результат к моменту написания отчёта)

> We recommend enabling multi-factor authentication on all VPN endpoints. The organization should implement a mandatory peer review process for firewall rule changes. (Present Simple — рекомендации)

Не смешивайте времена в одном абзаце без логической необходимости. Если вы описываете хронологию — держитесь Past Simple. Если переходите к рекомендациям — переходите явно, лучше через отдельный абзац или подзаголовок.

Формальные маркеры структуры

Профессиональные отчёты используют визуальные и текстовые маркеры, которые помогают читателю ориентироваться.

Подзаголовки — обязательны в документах длиннее одной страницы. Они должны быть конкретными и информативными: не «Analysis», а «Attack Vector: Exploitation of CVE-2026-1042 via VPN Gateway».

Нумерованные списки — для пошаговых инструкций и хронологии. Каждый пункт — законченное предложение или фрагмент, параллельный по структуре остальным пунктам.

Маркированные списки — для перечислений без строгого порядка: затронутые хосты, использованные инструменты, рекомендации.

Таблицы — для сравнения «до/после», описания затронутых систем, маппинга на MITRE ATT&CK.

| Host | Role | Status | Compromised | |---|---|---|---| | vpn-gw-01 | VPN Gateway | Isolated | Yes | | app-03 | Application Server | Isolated | Yes | | db-02 | Database Server | Isolated | Yes | | file-01 | File Server | Isolated | Yes | | dc-01 | Domain Controller | Monitored | No |

Жирный шрифт — для выделения ключевых терминов, номеров CVE, критических выводов. Не злоупотребляйте: если выделено всё — не выделено ничего.

Тон и регистр: как говорят инженеры в 2026 году

Современный технический английский в кибербезопасности — это direct (прямой), concise (сжатый) и impersonal (безличный) стиль. Вот основные конвенции.

Избегайте пассивного залога там, где можно использовать активный, если агент действия известен и важен.

> ❌ The vulnerability was exploited by the attacker. → ✅ The attacker exploited the vulnerability.

> ❌ The systems were isolated by the SOC team. → ✅ The SOC team isolated the systems.

Но пассивный залог уместен, когда агент неизвестен или неважен: The credentials were found in a public repository (кто нашёл — не так важно, важно что нашли).

Избегайте клише и «воды»: It should be noted that..., It is important to mention..., In order to.... Просто пишите суть: вместо In order to prevent future incidents → To prevent future incidents или To block this attack vector.

Используйте точную терминологию: не the bad guy got into the system, а the threat actor gained initial access; не we fixed the problem, а we patched the vulnerability and rotated all affected credentials.

Пишите короткими предложениями. Если предложение длиннее 25 слов — проверьте, можно ли его разделить. Длинные предложения в технических текстах — источник недопонимания.

Практика: поиск и исправление грамматических ошибок в инженерных текстах о нарушениях сетевой безопасности

Теория без практики — это конфигурационный файл, который никто не применял. Вы изучили артикли, предлоги, глагол to be, множественное число и притяжательный падеж. Теперь пришло время проверить эти знания на реальном инженерном тексте. Ниже приведён отчёт о нарушении сетевой безопасности, написанный в профессиональном стиле. В нём содержится 8 намеренных грамматических ошибок, связанных с темами всех предыдущих статей курса. Ваша задача — найти каждую ошибку, объяснить, почему это ошибка, и записать исправленный вариант.

Текст отчёта: Incident Report — Unauthorized Access to Internal Network

> Executive Summary > > On March 22, 2026, the Security Operations Center detected a unauthorized access attempt targeting the corporate VPN gateway. The attacker exploited an known vulnerability in the SSL-VPN module to gain initial foothold. The incident was contained within 38 minutes. No customer data was exfiltrated. This report details the timeline, technical analysis, and remediation steps. > > Timeline > > 2026-03-22 01:47 UTC — IDS alert triggered on the perimeter firewall. The alert indicated a brute-force authentication pattern targeting vpn-gw-02. > 2026-03-22 01:49 UTC — SOC analyst confirmed that the attacker's IP address was originating from a Tor exit node. The analyst escalated the incident as a Severity 1 event. > 2026-03-22 01:53 UTC — The attacker successfully authenticated using a compromised service account. The credentials is were found in a public paste site three weeks prior, but the rotation process had not been completed. > 2026-03-22 02:01 UTC — The attacker moved laterally to two application servers: app-05 and app-07. The server's logs showed the execution of a PowerShell reverse shell payload. > 2026-03-22 02:12 UTC — The SOC team isolated the affected hosts and revoked all active sessions on the VPN gateway. > 2026-03-22 02:25 UTC — Containment confirmed. The firewall rules in the DMZ was updated to block the attacker's IP range. > > Technical Analysis > > The attacker used CVE-2026-2187, an authentication bypass vulnerability in the SSL-VPN module, as a initial access vector. The vulnerability allows an unauthenticated remote attacker to craft a specially formatted request that bypasses the multi-factor authentication check. The exploit was publicly available on GitHub since February 2026. > > After gaining access, the attacker enumerated the internal network using standard Active Directory reconnaissance tools. The lateral movement to app-05 and app-07 was achieved by abusing the service account's elevated privileges. The attacker's objective appeared to be the exfiltration of source code repositories stored on the file server. > > The logs from the endpoint detection platform shows that the PowerShell payload established a reverse connection to a command-and-control server at 198.51.100.23. The connection was encrypted using a self-signed certificate, which the EDP flagged as anomalous but did not block due to a permissive policy in the endpoint firewall. > > Impact Assessment > > The compromise affected three hosts: vpn-gw-02, app-05, and app-07. The attacker had read access to the application source code and the staging database credentials. The production database was not accessed. The company's incident response team confirmed that no data was exfiltrated based on the network traffic analysis and the short duration of the compromise. > > Remediation > > The SSL-VPN module was patched to version 4.3.1, which addresses CVE-2026-2187. All service accounts credentials were rotated. The endpoint firewall policy was hardened to block self-signed certificates on outbound connections. The SOC implemented a new detection rule for the specific PowerShell payload observed in this incident. We recommend to enforce mandatory credential rotation every 30 days for all service accounts.

Разбор ошибок

Ошибка 1: «a unauthorized access attempt»

Проблема: Неправильный выбор артикля. Слово unauthorized начинается с гласного звука [ʌ], поэтому нужен артикль an, а не a.

Исправление: an unauthorized access attempt

Правило: Выбор между a и an определяется первым звуком слова, а не буквой. Здесь [ʌ] — гласный звук, значит — an.

Ошибка 2: «an known vulnerability»

Проблема: Обратная ситуация — слово known начинается с согласного звука [n], поэтому нужен артикль a, а не an.

Исправление: a known vulnerability

Правило: Буква k не произносится, но первым звуком является [n] — согласный. Значит — a.

Ошибка 3: «The credentials is were found»

Проблема: Смешаны формы единственного и множественного числа глагола to be. Слово credentials — существительное, которое всегда используется во множественном числе (как scissors, trousers), поэтому нужен глагол were, а не is.

Исправление: The credentials were found

Правило: Некоторые существительные в английском не имеют формы единственного числа и всегда требуют глагола во множественном числе: credentials, logs, binaries, backups.

Ошибка 4: «The server's logs»

Проблема: Здесь подразумевается множественное число — логи нескольких серверов (app-05 и app-07). Конструкция server's logs означает «логи одного сервера» (притяжательный падеж единственного числа). Нужен притяжательный падеж множественного числа: servers'.

Исправление: The servers' logs

Правило: Притяжательный падеж множественного числа: существительное + s + апостроф после s → servers'. Если речь об одном сервере — server's (апостроф перед s).

Ошибка 5: «The firewall rules in the DMZ was updated»

Проблема: Нарушено согласование подлежащего и сказуемого. Подлежащее — firewall rules (множественное число), поэтому нужен глагол were, а не was.

Исправление: The firewall rules in the DMZ were updated

Правило: Глагол to be согласуется с подлежащим. Если подлежащее во множественном числе — используйте were. Не путайте с ближайшим существительным (DMZ — единственное число), ориентируйтесь на главное подлежащее (rules).

Ошибка 6: «as a initial access vector»

Проблема: Слово initial начинается с гласного звука [ɪ], поэтому нужен артикль an, а не a.

Исправление: as an initial access vector

Правило: [ɪ] — гласный звук, значит — an. Это та же ошибка, что и в первом примере, но в другом контексте — в описании вектора атаки.

Ошибка 7: «The logs from the endpoint detection platform shows»

Проблема: Подлежащее — logs (множественное число), поэтому глагол должен быть в форме show, а не shows.

Исправление: The logs from the endpoint detection platform show

Правило: С подлежащим во множественном числе глагол в Present Simple не получает окончания -s. Окончание -s используется только с подлежащим в третьем лице единственного числа (he/she/it shows).

Ошибка 8: «We recommend to enforce»

Проблема: Глагол recommend не используется с инфинитивом (to + глагол). После recommend используется герундий (recommend doing) или that-клауза (recommend that...).

Исправление: We recommend enforcing или We recommend that the organization enforce

Правило: Как отмечают технические писатели, многие глаголы в английском имеют фиксированные конструкции с предлогами и формами. Глагол recommend требует: recommend + герундий или recommend + that + подлежащее + глагол в базовой форме.

Исправленный текст (фрагменты с ошибками)

> On March 22, 2026, the Security Operations Center detected an unauthorized access attempt targeting the corporate VPN gateway. The attacker exploited a known vulnerability in the SSL-VPN module to gain initial foothold.

> The attacker successfully authenticated using a compromised service account. The credentials were found in a public paste site three weeks prior, but the rotation process had not been completed.

> The servers' logs showed the execution of a PowerShell reverse shell payload.

> The firewall rules in the DMZ were updated to block the attacker's IP range.

> The attacker used CVE-2026-2187, an authentication bypass vulnerability in the SSL-VPN module, as an initial access vector.

> The logs from the endpoint detection platform show that the PowerShell payload established a reverse connection to a command-and-control server.

> We recommend enforcing mandatory credential rotation every 30 days for all service accounts.

Как использовать этот навык

Когда вы пишете собственные отчёты, документацию или даже сообщения в рабочий чат, применяйте следующий алгоритм самопроверки. Первое: проверьте каждое использование a/an — произнесите слово вслух и определите первый звук. Второе: найдите все существительные и определите, единственное они или множественное число, затем проверьте согласование с глаголом. Третье: при каждом использовании апострофа задайте вопрос — это притяжательный падеж или сокращение? Если притяжательный — один предмет или несколько? Четвёртое: проверьте конструкции после глаголов — recommend, suggest, discuss и другие глаголы имеют фиксированные паттерны, которые нельзя нарушать.

Эти четыре шага займут две-три минуты, но значительно повысят качество ваших текстов. В системном администрировании и кибербезопасности точность формулировок — это не про грамматику. Это про безопасность.