Справочник

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

→Примените ограничения Organization Policy (например, `constraints/gcp.resourceLocations`, `constraints/iam.disableServiceAccountKeyCreation`) на уровне организации или папки.

Почему: Organization Policies наследуются и применяются на уровне API, предотвращая несовместимые действия до их возникновения. Это более эффективно, чем реактивное обнаружение и исправление.

Источник↗

Структурирование организации с несколькими отделами и средами для эффективного управления политиками и контролем доступа.

→Разработайте иерархию папок, обычно: Организация > Бизнес-подразделение (Папка) > Среда (например, prod, staging) (Подпапка) > Проекты.

Почему: Эта структура позволяет гранулированно наследовать политики. Общие политики устанавливаются на уровне бизнес-подразделения, тогда как политики, специфичные для среды (например, более строгие для `prod`), устанавливаются на уровне среды.

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

→Создайте агрегированный приемник логов на уровне организации. Направляйте логи в несколько мест назначения в зависимости от необходимости: BigQuery для анализа, Cloud Storage (Coldline/Archive) для долгосрочного/недорогого архивирования и Pub/Sub для потоковой передачи в реальном времени в SIEM.

Почему: Такой многоуровневый подход оптимизирует как затраты, так и возможности. BigQuery предоставляет мощные возможности запросов, тогда как Cloud Storage предлагает дешевое архивирование. Использование одного места назначения либо слишком дорого, либо недостаточно производительно для всех вариантов использования.

Источник↗

Предотвращение эксфильтрации данных из управляемых сервисов, таких как BigQuery и Cloud Storage, разрешая доступ только из авторизованных сетей или с авторизованными идентификаторами.

→Создайте периметр VPC Service Controls вокруг проектов, содержащих конфиденциальные данные. Определите уровни доступа для разрешения доступа из определенных диапазонов IP (корпоративная сеть) или устройств.

Почему: VPC Service Controls создает виртуальный периметр вокруг сервисов, основанных на API, снижая риски от украденных учетных данных или неправильно настроенных политик IAM, блокируя доступ извне периметра.

Установление мер безопасности, которые не могут быть отменены владельцами проектов, например, предотвращение предоставления определенной роли.

→Внедрите политики IAM Deny на уровне организации или папки. Эти политики явно запрещают разрешения и всегда переопределяют любые политики `allow`.

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

Обеспечение того, чтобы все новые проекты были предоставлены со стандартной базовой конфигурацией (сеть, IAM, логирование и т.д.).

→Используйте Infrastructure as Code (например, Terraform с Cloud Build) для создания "посадочной зоны". Автоматизируйте создание и конфигурацию проектов через пайплайн.

Почему: Автоматизация обеспечивает согласованность, уменьшает количество ручных ошибок и ускоряет предоставление проектов. Она кодифицирует лучшие практики, делая управление аудируемым и повторяемым.

Разрешение внешним системам (таким как GitHub Actions или локальный CI/CD) доступ к ресурсам GCP без использования долгоживущих ключей сервисных аккаунтов.

→Настройте Workload Identity Federation. Создайте провайдера, который доверяет внешнему IdP (например, GitHub OIDC) и сопоставьте внешние идентификаторы с сервисным аккаунтом GCP. Используйте условия атрибутов для ограничения доступа к определенным репозиториям/веткам.

Почему: Это устраняет необходимость управлять и ротировать ключи сервисных аккаунтов, что является серьезным риском безопасности. Он предоставляет краткосрочные учетные данные на основе идентификаторов.

Централизация сетевого администрирования (VPC, подсети, файрволы) при этом позволяя отдельным командам управлять своими собственными ресурсами проекта.

→Внедрите Shared VPC. Создайте "хост-проект" для сетевых ресурсов и "сервисные проекты" для рабочих нагрузок приложений. Предоставьте `roles/compute.networkUser` для идентификаторов сервисных проектов.

Почему: Shared VPC отделяет сетевое администрирование от администрирования проектов, обеспечивая централизованный контроль и безопасность, одновременно предоставляя командам автономию. Он лучше масштабируется и более безопасен, чем VPC Peering для данного варианта использования.

Декларативное управление конфигурациями кластеров GKE и приложениями из репозитория Git.

→Используйте репозиторий Git в качестве единого источника истины для манифестов. Установите Config Sync в кластеры GKE для непрерывного согласования состояния кластера с конфигурацией в репозитории.

Почему: GitOps предоставляет аудируемый, версионированный и автоматизированный способ управления Kubernetes. Он отделяет CI (создание артефактов) от CD (синхронизация состояния).

Предотвращение развертывания образов контейнеров с критическими уязвимостями.

→Включите автоматическое сканирование уязвимостей в Artifact Registry. В пайплайне Cloud Build добавьте шаг, который использует Container Analysis API для проверки уязвимостей и завершает сборку с ошибкой, если найдены критические проблемы.

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

Принудительное применение во время выполнения правила, согласно которому только доверенные, подписанные образы контейнеров могут быть развернуты в GKE или Cloud Run.

→Внедрите Binary Authorization. Создайте аттестаторов (например, для прохождения сканирования уязвимостей, одобрения QA). Настройте пайплайн CI для создания аттестаций. Примените политику в GKE/Cloud Run, которая требует определенных аттестаций для развертывания.

Почему: Binary Authorization обеспечивает сильное, основанное на политиках принуждение во время развертывания. Оно защищает от развертывания скомпрометированных или непроверенных образов, даже если они попадают в реестр.

Источник↗

Доступ к конфиденциальной информации, такой как ключи API или пароли, во время выполнения Cloud Build без их раскрытия в логах или исходном коде.

→Храните секреты в Secret Manager. В `cloudbuild.yaml` используйте поле `availableSecrets` для монтирования секрета в качестве переменной среды или файла.

Почему: Это нативная, безопасная интеграция. Cloud Build обрабатывает аутентификацию и автоматически скрывает значения секретов из логов, предотвращая случайное раскрытие.

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

→Используйте Cloud Build для генерации аттестаций происхождения, соответствующих SLSA. Храните эти аттестации в Artifact Registry вместе с образами. Используйте Binary Authorization для проверки происхождения перед развертыванием.

Почему: SLSA предоставляет основу для усиления безопасности цепочки поставок программного обеспечения. Эта комбинация инструментов обеспечивает сквозную, проверяемую цепочку доверия от исходного кода до продакшна.

Выполнение заданий CI/CD, которым требуется доступ к ресурсам в частном VPC, таким как частный Artifact Registry или база данных Cloud SQL.

→Создайте частный пул Cloud Build и настройте VPC peering между сетью пула и вашим целевым VPC. Настройте сборки для запуска в этом пуле.

Почему: Частные пулы обеспечивают сетевую изоляцию и позволяют сборкам безопасно получать доступ к ресурсам в частной сети без их выставления в интернет.

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

→Настройте политики очистки Artifact Registry. Используйте политику `keep` для тегов, таких как `production` и `latest`. Используйте политики `delete` на основе возраста, шаблонов тегов и количества версий для других образов.

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

Автоматизация многоэтапного развертывания от разработки до стейджинга и продакшна с утверждениями и различными стратегиями для каждой среды.

→Определите единый конвейер доставки Cloud Deploy с последовательностью целей (dev, staging, prod). Настройте `requireApproval: true` для целевого объекта продакшна и укажите различные стратегии развертывания (например, canary) для каждого целевого объекта.

Почему: Cloud Deploy предоставляет управляемый, аудируемый сервис непрерывной доставки. Он упрощает паттерны прогрессивной доставки, такие как canary и blue-green развертывания, с интегрированными утверждениями и откатами.

Определение метрик для измерения надежности сервиса с точки зрения пользователя.

→Определите Service Level Indicators (SLI) на основе проблем, с которыми сталкиваются пользователи: доступность (процент успешных запросов), задержка (процент запросов быстрее порогового значения) и корректность/актуальность (процент данных, обработанных правильно или актуальных).

Почему: SLI должны измерять удовлетворенность пользователей, а не внутреннее состояние сервера. Метрики, такие как загрузка CPU, являются причинами, тогда как высокая задержка является симптомом. SRE фокусируется на мониторинге и управлении симптомами.

Получение уведомлений о нарушениях SLO достаточно рано для реакции, без перегрузки оповещениями о мелких, временных проблемах.

→Настройте оповещения на основе скорости исчерпания SLO (скорости потребления бюджета ошибок). Используйте оповещения с несколькими окнами: высокая скорость исчерпания в коротком окне для критических случаев и более низкая скорость исчерпания в длинном окне для несрочных задач.

Почему: Оповещение по скорости исчерпания является предиктивным. Оно оповещает о *скорости* отказов, что указывает на реальную проблему, а не на один неудачный запрос, уменьшая усталость от оповещений и фокусируясь на том, что действительно важно.

Источник↗

Диагностика проблем с задержкой в микросервисной архитектуре путем понимания полного жизненного цикла запроса.

→Инструментируйте сервисы с помощью OpenTelemetry SDK и экспортируйте трассировки в Cloud Trace. Убедитесь, что контекст трассировки распространяется между вызовами сервисов (включая через очереди сообщений, такие как Pub/Sub).

Почему: OpenTelemetry предоставляет стандарт для инструментации, независимый от поставщика. Cloud Trace визуализирует сквозной поток запросов, что упрощает выявление того, какой сервис или операция является узким местом.

Обеспечение правильного парсинга, поиска и правильного уровня серьезности журналов приложений в GKE в Cloud Logging.

→Настройте приложения для записи журналов в `stdout`/`stderr` в формате JSON. Включите поле `severity`, которое соответствует ожидаемым значениям Google Cloud (например, "INFO", "ERROR").

Почему: Агент логирования GKE по умолчанию автоматически собирает и парсит журналы JSON из stdout, делая их структурированными и доступными для запросов в Cloud Logging без необходимости использования sidecar или пользовательского агента.

Отслеживание, визуализация и оповещение о соответствии SLO и потреблении бюджета ошибок для сервиса.

→Используйте функцию Service Monitoring в Cloud Monitoring. Определите сервис, создайте SLI (например, доступность из балансировщика нагрузки), установите целевые значения SLO и настройте политики оповещения о скорости исчерпания.

Почему: Эта нативная функция автоматизирует сложные расчеты соответствия SLO и бюджетов ошибок, предоставляет готовые дашборды и интегрируется с системой оповещений.

Быстрое нахождение первопричины проблемы путем связывания метрик, трассировок и журналов.

→Убедитесь, что идентификаторы трассировок включены в структурированные журналы. Используйте функции Cloud Monitoring, такие как образцы трассировок на диаграммах метрик, чтобы перейти к конкретной трассировке во время аномалии метрики, а затем из этой трассировки перейти к связанным журналам.

Почему: Возможность беспрепятственно переключаться между тремя столпами наблюдаемости (метрики, журналы, трассировки) является ключом к сокращению среднего времени до разрешения (MTTR).

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

→В Cloud Logging создайте метрику на основе журналов. Определите фильтр для соответствия соответствующим записям журнала и настройте тип метрики (счетчик или распределение). Используйте эту пользовательскую метрику в дашбордах и политиках оповещений.

Почему: Метрики на основе журналов позволяют преобразовывать неструктурированные или полуструктурированные данные журналов в структурированные временные ряды, что упрощает мониторинг и оповещение о бизнес-KPI без изменения кода приложения.

Диагностика проблем с производительностью базы данных, таких как медленные запросы, без дополнительной нагрузки на базу данных.

→Включите Cloud SQL Insights и Query Insights на экземпляре Cloud SQL. Используйте дашборд для выявления запросов с высокой нагрузкой, анализа планов выполнения и просмотра тенденций производительности.

Почему: Query Insights обеспечивает легкий, безагентный мониторинг производительности запросов. Он помогает DBA и разработчикам точно определять неэффективные запросы без накладных расходов традиционных инструментов профилирования.

Проактивный мониторинг критических пользовательских сценариев или доступности API с внешней точки зрения.

→Используйте проверки доступности Cloud Monitoring для простых проверок HTTP/TCP. Для многоэтапных пользовательских потоков (например, вход, добавление в корзину, оформление заказа) используйте Synthetic Monitors, которые выполняют пользовательские скрипты (например, Puppeteer) в управляемой среде.

Почему: Синтетический мониторинг имитирует реальные взаимодействия пользователей, позволяя обнаруживать проблемы до того, как это сделают пользователи. Он тестирует весь стек "снаружи внутрь".

Балансировка потребности в надежности сервиса с потребностью в выпуске новых функций.

→Определите Service Level Objective (SLO) (например, 99.9% доступности). Оставшийся 0.1% — это бюджет ошибок. Если бюджет в основном цел, выпускайте новые функции. Если бюджет исчерпан, приостановите выпуск функций и сосредоточьтесь на улучшении надежности.

Почему: Бюджет ошибок предоставляет основанную на данных основу для принятия решений о рисках, выравнивая команды инженеров, продуктов и бизнеса для достижения общей цели.

Изучение инцидентов для предотвращения их повторения, при этом содействуя культуре психологической безопасности.

→Проводите "безобвинительные" постмортемы после инцидентов. Сосредоточьте расследование на системных факторах, пробелах в процессах и отказах инструментов, а не на возложении вины на отдельных лиц. Результатом должен быть список практических пунктов для улучшения.

Почему: Культура без обвинений поощряет честное и открытое общение, что приводит к более точному пониманию первопричин инцидента и более эффективным превентивным действиям.

Эффективная координация реагирования на серьезный инцидент, избегая путаницы и дублирования усилий.

→Внедрите систему управления инцидентами (Incident Command System, ICS) с четко определенными ролями: Командир инцидента (общая координация), Руководитель операций (техническое расследование/исправление) и Руководитель по коммуникациям (обновления для заинтересованных сторон).

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

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

→Отслеживайте четыре ключевые метрики DORA: Частота развертывания (как часто), Время выполнения изменений (как быстро от коммита до развертывания), Процент неудачных изменений (какой процент развертываний вызывает сбой) и Время восстановления сервиса (MTTR).

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

Команда SRE тратит слишком много времени на рутинные, повторяющиеся операционные задачи (toil), не оставляя времени на инженерные проекты.

→Определите и количественно оцените наиболее трудоемкие рутинные задачи. Приоритизируйте и автоматизируйте эти задачи (например, внедрение автомасштабирования вместо ручного масштабирования, автоматическое устранение распространенных оповещений). Ограничьте рутинную работу < 50% времени инженера.

Почему: Рутинная работа снижает продуктивность и моральный дух. Систематическое сокращение ее с помощью автоматизации освобождает инженеров для работы над долгосрочными улучшениями надежности.

Точное распределение облачных затрат между различными командами, сервисами или средами в общей инфраструктуре.

→Внедрите последовательную стратегию маркировки/тегов. Используйте эти метки для фильтрации в отчетах Cloud Billing. Для GKE включите GKE cost allocation, чтобы разбивать затраты по пространству имен или рабочей нагрузке.

Почему: Точное распределение затрат обеспечивает прозрачность, что способствует подотчетности. Команды, которые могут видеть свои расходы, получают возможность их оптимизировать.

Оптимизация затрат на вычисления для разнообразного набора рабочих нагрузок (стабильных, прерываемых, разработки/тестирования).

→Сопоставьте рабочую нагрузку с моделью ценообразования. Используйте Committed Use Discounts (CUDs) для стабильных рабочих нагрузок 24/7. Используйте Spot VMs для отказоустойчивых, прерываемых заданий (например, пакетной обработки). Запланируйте отключение сред разработки/тестирования вне рабочих часов.

Почему: Универсальный подход к ценообразованию на вычисления неэффективен. Использование правильного инструмента для работы может привести к значительной экономии (>70%) без ущерба для производительности.

Оптимизация затрат и производительности GKE путем обеспечения того, чтобы поды запрашивали соответствующие объемы CPU и памяти.

→Разверните Vertical Pod Autoscaler (VPA) в режиме `recommendation`. Проанализируйте его предложения для корректировки `requests` ресурсов подов. После уверенности переключитесь в режим `auto` для непрерывного изменения размера.

Почему: Избыточное выделение ресурсов подам приводит к потере денег, тогда как недостаточное выделение вызывает проблемы с производительностью (throttling, OOMKilled). VPA использует фактические данные об использовании для точных рекомендаций по размеру, улучшая как эффективность, так и стабильность.

Сокращение задержки, вызванной холодными стартами для сервиса Cloud Run.

→Настройте значение `min-instances`, чтобы поддерживать некоторое количество "теплых" экземпляров. Кроме того, оптимизируйте образ контейнера (меньший базовый образ, меньше слоев) и код запуска приложения (ленивая инициализация).

Почему: `min-instances` — это самый прямой способ сократить холодные старты, но он имеет свою стоимость. Сочетание его с оптимизацией контейнеров и кода обеспечивает сбалансированный подход к производительности и стоимости.

Оптимизация затрат для крупномасштабной аналитической рабочей нагрузки BigQuery с переменными паттернами запросов.

→Переключитесь с ценообразования по требованию на BigQuery Editions (слоты). Приобретите базовый лимит слотов для предсказуемой нагрузки и включите автомасштабирование для пиков. Кроме того, оптимизируйте запросы, используя секционированные/кластеризованные таблицы и избегая `SELECT *`.

Почему: Для постоянных рабочих нагрузок ценообразование на основе слотов более экономично, чем по требованию. Автомасштабирование обеспечивает гибкость для пиков при контроле затрат. Оптимизация запросов и таблиц уменьшает объем обрабатываемых данных, напрямую снижая затраты.

Сокращение высоких затрат на исходящий сетевой трафик (egress) для глобально распределенного приложения.

→Используйте Cloud CDN для кэширования статического контента на периферии, ближе к пользователям. Для динамического трафика выберите соответствующий уровень сетевого сервиса (Premium для производительности, Standard для экономии затрат). Обрабатывайте данные регионально, чтобы минимизировать межрегиональный трафик.

Почему: Исходящий трафик является основным фактором затрат. CDN снимает нагрузку с источника, напрямую сокращая исходящий трафик. Продуманное использование сетевых уровней и региональная обработка данных могут значительно снизить затраты.