Google PCNE: Наблюдаемость сети, надежность и устранение неполадок — Руководство по подготовке

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Часть Google Professional Cloud Network Engineer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

Сетевая наблюдаемость в Google Cloud — это дисциплинированный сбор, корреляция и анализ сетевых сигналов, описывающих достижимость, производительность и корректность работы VPC, балансировщиков нагрузки, гибридных подключений и сервисов. Надёжность достигается за счёт проектирования с учётом обнаружения сбоев и безопасного их устранения: внедряйте первоклассную телеметрию, проверяйте плоскость управления перед внесением изменений в плоскость данных, при необходимости углубляйтесь в анализ пакетов и автоматизируйте откат изменений. В этом разделе объясняется, как использовать инструменты и шаблоны Google Cloud для обнаружения, диагностики и предотвращения проблем, минимизируя риски при внесении изменений.

Журналы потоков, ведение журналов, мониторинг, метрики и SLO

VPC Flow Logs предоставляют выборочную, агрегированную телеметрию на уровне сетевого интерфейса ВМ после оценки правил брандмауэра VPC. Они не являются полным захватом пакетов и не заменяют ведение журналов правил брандмауэра для получения явных доказательств разрешающих/запрещающих действий. Ключевые параметры управления:

• Семплирование: 0.0–1.0. Более высокое значение улучшает точность за счёт увеличения объёма журналов и потенциальных затрат.
• Интервал агрегации: от 5 с до 30 мин. Короткие интервалы сокращают время обнаружения, но увеличивают количество записей.
• Метаданные: включение или исключение метаданных экземпляра и VPC. Включайте для более глубокой аналитики, исключайте для ограничения передачи конфиденциальных атрибутов.

Типичное включение для подсети:

undefined

Экспортируйте с помощью приёмников журналов (log sinks) для долговременного анализа и совместного использования между проектами:

• BigQuery для SQL-аналитики и анализа долгосрочных тенденций.
• Pub/Sub для конвейеров, работающих в режиме, близком к реальному времени, для отправки в SIEM/IDS.
• Cloud Storage для архивирования.

• Пример приёмника для BigQuery:

undefined

Ведение журналов правил брандмауэра дополняет журналы потоков, записывая решения о разрешении/запрете и сработавшие правила. Чтобы отслеживать заблокированный трафик, добавьте правило deny-all с включённым ведением журнала ближе к концу вашего набора правил:

undefined

Cloud Logging позволяет выполнять структурированные запросы, коррелировать данные с журналами запросов, журналами проверок состояния, журналами NAT и журналами балансировщиков нагрузки. Создавайте метрики на основе журналов для таких сигналов, как:

• Внезапное увеличение числа отклонённых подключений к бэкендам с определёнными тегами (возможна неверная конфигурация списков разрешений).
• Большое количество повторных передач SYN на порт (возможно насыщение или blackholing).
• События NAT «нет доступных портов» (исчерпание ресурсов Cloud NAT).

Cloud Monitoring агрегирует метрики и предоставляет дашборды, оповещения и SLO:

• Метрики для отслеживания: частота ошибок 5xx балансировщика нагрузки, задержка бэкенда, байты/пакеты на сетевом интерфейсе экземпляра, выделенные/используемые/переполненные порты Cloud NAT, статус сессии BGP в Cloud Router, потери пакетов в VPN-туннеле, утилизация канала Interconnect, потери пакетов и задержка.
• Дашборды: создавайте дашборды для каждого сервиса и каждого типа подключения, используя общие шаблоны для всех проектов для обеспечения единообразия операций.
• Оповещения: отдавайте предпочтение оповещениям о симптомах (частота ошибок, задержка, счётчики потерь) с быстрой обратной связью и оповещениям о причинах (сбои BGP, падение канала) с вызовом дежурного, когда вероятно влияние на пользователей.
• SLO: определяйте ориентированные на пользователя SLO (например, глобальный процент успешных HTTP-запросов и задержка) и оповещения о скорости сгорания бюджета ошибок (burn-rate alerts) для выявления быстрых и медленных «сгораний». Используйте журналы запросов в качестве числителя/знаменателя через метрики на основе журналов для точной оценки SLO.

Компромиссы и режимы отказа:

• Низкая частота семплирования или длительный интервал агрегации скрывают микровсплески и кратковременные сбои.
• В VPC Flow Logs отсутствует видимость потерь пакетов до брандмауэра; для получения доказательств запрета используйте ведение журналов правил брандмауэра.
• Чрезмерное ведение журналов без фильтрации увеличивает затраты и может замедлить расследование; экспортируйте и разделяйте данные разумно.

Network Intelligence Center и расширенная диагностика

Network Intelligence Center (NIC) предоставляет проактивную и структурированную диагностику:

Connectivity Tests:

• Проверяет достижимость на уровне плоскости управления через маршруты, правила брандмауэра (включая иерархические политики), сервисные аккаунты/теги, балансировщики нагрузки, Cloud NAT и гибридные подключения.
• Диагностика маршрутов вычисляет выбранный следующий хоп и сообщает о неверных конфигурациях, таких как отсутствующие маршруты или асимметричные пути.
• Используйте до и после любого изменения сети для обнаружения непреднамеренной зоны влияния. Этот инструмент моделирует плоскость управления и не гарантирует качество плоскости данных; используйте его в паре с анализом пакетов/метрик.

Performance Dashboard:

• Управляемое Google представление потерь пакетов и задержек между регионами и до точек наблюдения в интернете. Полезно для обнаружения макрособытий (перегрузка в регионе или на всём пути) в отличие от локальных проблем сервиса.

Network Topology:

• Визуализирует межпроектные, межсетевые (inter-VPC) и гибридные подключения, а также объёмы трафика (используя журналы), чтобы выявить горячие точки, неожиданные пути пиринга и непреднамеренное транзитное поведение.

Firewall Insights:

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

Network Analyzer:

• Статические и динамические проверки конфигурации в разных проектах для выявления таких состояний, как:
  • Проверки состояния, заблокированные брандмауэром (не забудьте разрешить диапазоны IP-адресов источников проверок состояния Google).
  • Бэкенды балансировщика нагрузки в неправильных регионах или с отсутствующими именованными портами.
  • Подсети с отключённым Private Google Access, блокирующие доступ к API для экземпляров без внешних IP-адресов.
  • Маршруты, которые приводят к blackholing важных префиксов, или асимметричная маршрутизация через VPN/Interconnect.

Руководство по эксплуатации:

• Встраивайте проверки NIC в CI/CD для сетевых изменений и запускайте их по расписанию. Рассматривайте найденные проблемы как долг по надёжности и приоритизируйте исправления, влияющие на снижение рисков.

Зеркалирование пакетов, балансировщики нагрузки и гибридная телеметрия

Зеркалирование пакетов:

• Зеркалирует трафик ВМ на коллектор (устройство или управляемый IDS) для глубокой инспекции. Область действия определяется подсетью, сетевыми тегами или сервисными аккаунтами; ограничивайте протоколы до необходимых, чтобы контролировать затраты.
• Накладные расходы и компромиссы: исходящий зеркалированный трафик влечет за собой расходы; избыточное зеркалирование может перегрузить коллекторы; не зеркалируйте без разбора в производственной среде. Используйте ограниченные по времени и узкоспециализированные сессии для расследования инцидентов.
• Интеграция с IDS:
  • Cloud IDS обеспечивает управляемое обнаружение угроз вне основного канала (out-of-band) с использованием Packet Mirroring. Предпочтительно использовать его для быстрой активации и сокращения обслуживания.
  • Сторонние устройства IDS остаются жизнеспособным вариантом, когда требуются специфические сигнатуры или экосистемы поставщиков.

Логи балансировщика нагрузки и данные проверок состояния:

• Логи запросов балансировщика нагрузки HTTP(S) включают метод, URL, бэкенд, код ответа, задержку и IP-адреса клиентов через X-Forwarded-For. Используйте их для анализа пути клиента, так как traceroute останавливается на Google Front Ends (GFE).
• Включите логирование на бэкенд-сервисах и настройте выборку (sampling) для баланса между затратами и видимостью. Включите логирование проверок состояния, чтобы видеть результаты проб и причины сбоев.
• Ограничение доступа клиентов: применяйте на бэкендах, помечая инстансы тегами и создавая правила брандмауэра, которые разрешают только одобренные диапазоны IP-адресов клиентов и IP-адреса проверок состояния Google. Для смягчения угроз на уровне L7 и постепенного развертывания используйте правила Cloud Armor в режиме предварительного просмотра (preview mode) перед их принудительным применением.

Телеметрия VPN и Interconnect:

• Метрики Cloud VPN (HA VPN): байты, отброшенные пакеты (drops), ошибки шифрования, время безотказной работы туннеля и состояние сессии BGP. Настройте оповещения на отброшенные пакеты, частые события DPD и сбои (flaps) BGP.
• Масштабирование пропускной способности: добавляйте туннели к разным IP-адресам пиров и распределяйте трафик; отслеживайте запас производительности (headroom). Если вам нужна схема active/standby между Cloud Routers, используйте атрибут MED на стороне on-prem для смещения выбора пути.
• Метрики Interconnect: утилизация каждого канала, ошибки CRC и доступность; следите за устойчивой утилизацией >60–70% и всплесками ошибок. Поддерживайте запасную емкость и диверсифицированные каналы. Расследуйте увеличение задержки с помощью показателей повторных передач (retransmissions) и очередей.
• Сигналы насыщения на границах сети: рост повторных передач TCP, увеличение 99-го перцентиля задержки без изменений в коде, события переполнения портов NAT и оповещения о заполнении очередей являются ранними предупреждениями о надвигающихся проблемах.

Методология поиска и устранения неисправностей, обработка инцидентов и проактивное обеспечение надежности

Структурированный поиск неисправностей от DNS до приложения:

1. Определите сбойный пользовательский сценарий и временное окно; установите регион и путь (публичный через LB, частный через VPC или гибридный).
2. DNS:

• Проверьте разрешение имен с помощью логов Cloud DNS, вывода команды dig и поведения политик. Проверьте конфликты split-horizon и убедитесь, что политики пересылки (forwarding policies) действуют.
• Подтвердите значения TTL и недавние изменения; устаревшие кэши могут имитировать сбои.

3. Балансировщик нагрузки и периметр:

• Проанализируйте логи запросов и проверок состояния (health-check). Сопоставьте всплески 5xx-ошибок с состоянием бэкендов и событиями развертывания. Для L7 доверяйте логам запросов больше, чем traceroute.
• Проверьте списки разрешенных клиентов (allowlists) и IP-адреса проверок состояния Google в правилах брандмауэра, если доступ ограничен.

4. Маршрутизация и брандмауэр:

• Используйте Connectivity Tests для детерминированной оценки управляющего уровня (control-plane). Изучите действующие маршруты и иерархические политики брандмауэра. Ищите асимметричную маршрутизацию и затененные правила.
• Для заблокированных пакетов полагайтесь на логирование правил брандмауэра; во время расследования рассмотрите возможность добавления правила deny-all с логированием внизу стека приоритетов.

5. Исходящий трафик к Google API:

• Если у инстансов нет внешних IP-адресов, подтвердите наличие Private Google Access и/или Cloud NAT. Отсутствие любого из них приводит к периодическим сбоям и непонятным тайм-аутам.

6. Гибридная среда:

• Изучите метрики Cloud Router и VPN/Interconnect. Если BGP в состоянии up, но маршруты не установлены, это может отражать предпочтения атрибутов; проверьте MED/local-pref и ASN. Следите за потерями пакетов и проблемами с MTU пути.

7. Анализ пакетов:

• Если управляющий уровень (control-plane) выглядит корректно, но симптомы сохраняются, точечно используйте Packet Mirroring для сбора PCAP рядом с затронутой ВМ или уровнем; проверьте тайминги SYN/SYN-ACK, повторные передачи (retransmissions) и биты MSS/DF на предмет черных дыр MTU.

Обработка инцидентов:

• Безопасность изменений: внедряйте изменения поэтапно, ограничивая их область действия тегами/сервисными аккаунтами, используя более низкий приоритет и отключенные правила; включайте логирование и тестируйте с помощью канареечных развертываний. Используйте режим предварительного просмотра (preview) Cloud Armor для изменений политик L7.
• Откат изменений: заранее определите обратные изменения, храните предыдущие конфигурации в системе контроля версий и, где это применимо, используйте короткоживущие флаги функций (feature flags) на периметре приложения.
• Анализ после инцидента: составьте временную шкалу на основе логов и метрик, классифицируйте способствующие факторы (например, разрешающее правило, затененное запрещающим; исчерпание ресурсов NAT), зафиксируйте пробелы в обнаружении и добавьте защитные меры: оповещения, проверки NIC и ужесточение политик.

Планирование мощностей и проактивное обеспечение надежности:

• Отслеживайте целевые показатели запаса производительности: 30–50% на каналах VPN/Interconnect, использование портов NAT на уровне ниже 60% в течение длительного времени, загрузка CPU и QPS бэкендов балансировщика нагрузки значительно ниже порогов автомасштабирования.
• Создайте метрики на основе логов для ключевых рисков: всплески отказов (deny), переполнение NAT, количество сбоев BGP, частота 5xx-ошибок и ошибки подключения к бэкендам балансировщика. Используйте оповещения о скорости исчерпания бюджета ошибок (burn-rate alerts) с несколькими окнами для выявления как быстрых, так и медленных инцидентов.
• Синтетический мониторинг: используйте Uptime Checks из нескольких регионов для публичных эндпоинтов и частные зонды (probes) с тестовых ВМ для внутренних сервисов.
• Профилактические улучшения: уточняйте правила брандмауэра с помощью Firewall Insights, устраняйте проблемы, найденные Network Analyzer, сокращайте интервал агрегации Flow Log во время пиковых событий и экспортируйте логи в BigQuery для регулярного обнаружения аномалий.

Практический сценарий проблемы

Компания Contoso Games управляет глобальным игровым API с балансировкой нагрузки HTTP(S) в регионах us-east1 и europe-west1, а также использует HA VPN для подключения к локальному дата-центру. Пользователи в Европе сообщают о периодических тайм-аутах и повышенной задержке после недавнего изменения правил брандмауэра. У инстансов нет внешних IP-адресов, и они должны получать доступ к Google API в частном порядке.

Подход:

1. Установить временное окно и влияние на SLO

• Обоснование: Определение точного временного окна сужает область поиска до релевантных логов и связывает расследование с влиянием на пользовательские SLO. Оповещение о скорости исчерпания бюджета ошибок (burn-rate alert) подтверждает быстрое сжигание SLO в регионе europe-west1.

2. Проверить управляющий уровень (control plane) с помощью Connectivity Tests

• Обоснование: Создать тест от внешнего фронтенда HTTP(S) load balancer до бэкенд-сервиса в europe-west1 и от затронутых ВМ до VIP-адреса Private Google Access. Тест выявляет иерархическую политику брандмауэра, блокирующую проверки состояния для некоторых бэкендов, и отсутствие Private Google Access для одной из подсетей.

3. Подтвердить состояние периметра и бэкендов через логи

• Обоснование: Отфильтровать логи запросов балансировщика нагрузки для europe-west1 по response_code >= 500, чтобы изолировать ошибки бэкендов. Логи проверок состояния показывают сбои зондирования с известных исходных IP-адресов проверок состояния Google. Это свидетельствует о нестабильной работе бэкендов (flapping), вызванной брандмауэром, а не о регрессиях в приложении.

4. Восстановить работоспособность и обеспечить безопасность с помощью изменений с ограниченной областью действия

• Обоснование: Добавить разрешающее правило, нацеленное на теги бэкендов, которое разрешает трафик с диапазонов IP-адресов для проверок состояния. Включить логирование для этого правила. Поскольку доступ ограничен известными клиентами, убедиться, что разрешающее правило брандмауэра включает только конкретные диапазоны IP-адресов клиентов и диапазоны для проверок состояния. Изначально оставить новое правило отключенным, а затем включить его во время канареечного развертывания при низкой нагрузке, чтобы ограничить радиус поражения (blast radius).

5. Восстановить частный исходящий доступ к Google API

• Обоснование: Включить Private Google Access для затронутой подсети, чтобы инстансы без внешних IP-адресов могли обращаться к сервисам Google, избегая заворачивания трафика (hairpinning) через VPN или сторонние брандмауэры. Это снижает задержку и устраняет узкое место.

6. Проверить загруженность гибридного подключения и MTU

• Обоснование: Проанализировать метрики HA VPN на предмет потерь пакетов и утилизации. Один из туннелей показывает повышенное количество потерь. Увеличить пропускную способность, добавив второй туннель к другому пиринговому IP-адресу в локальном ЦОД, и распределить трафик. Проверить действующие значения MTU и MSS clamp, чтобы предотвратить черные дыры PMTU на пути через VPN.

7. Использовать режим предварительного просмотра Cloud Armor для предполагаемых злоумышленных клиентов

• Обоснование: Из логов запросов видно, что небольшая группа IP-адресов клиентов вызывает всплески трафика непосредственно перед сбоями зондирования. Добавить запрещающее правило в Cloud Armor в режиме предварительного просмотра (preview mode), чтобы убедиться, что блокировка снизит нагрузку на бэкенды, прежде чем применять правило принудительно, избегая случайного воздействия на легитимных пользователей.

8. Точечно использовать Packet Mirroring для подтверждения поведения на уровне данных (data plane)

• Обоснование: Зеркалировать трафик с одной неработоспособной ВМ бэкенда в Cloud IDS на 15 минут. PCAP показывает исчерпание очереди SYN (SYN backlog) во время всплесков трафика от злоумышленных IP-адресов, что подтверждает пользу политики Cloud Armor и необходимость ограничения частоты запросов (rate limiting).

9. Закрыть инцидент и усилить защиту

• Обоснование: После включения разрешающего правила для проверок состояния, подтверждения работы Private Google Access, масштабирования пропускной способности VPN и принудительного применения проверенной политики Cloud Armor, уровень ошибок вернулся к базовому. Добавить дашборды для отслеживания процента успешных проверок состояния, использования портов NAT, потерь в VPN и количества 5xx-ошибок по регионам. Создать оповещения на основе логов о запретах брандмауэра для тегов бэкендов и оповещения о скорости исчерпания бюджета SLO. Задокументировать инцидент, его коренные причины (изменение иерархического брандмауэра; злоумышленный трафик; перегрузка VPN) и добавить проверки с помощью NIC Analyzer и Firewall Insights в чек-лист перед внесением изменений.

Эта последовательность демонстрирует безопасный, основанный на фактических данных рабочий процесс: проверка управляющего уровня (control plane), наблюдение за уровнем данных (data plane), применение минимальных, обратимых изменений, а затем институционализация полученных уроков с помощью оповещений и автоматизированных проверок.

← GKE · Все домены · Автоматизация сети →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Google →