Кто владеет продакшеном? Почему границы привилегий между средами имеют значение

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

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

Проблема универсального доступа

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

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

Решение не в том, чтобы заблокировать все настолько жестко, чтобы никто не мог работать. Решение — создать четкие границы привилегий между средами.

Что такое граница привилегий?

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

Например, файл состояния для продакшена должен находиться в другом месте, чем файл состояния для разработки. Если вы используете Terraform, бэкенд состояния продакшена может быть отдельным S3-бакетом с более строгими политиками IAM. Только несколько человек в команде имеют доступ к этому бакету. Бэкенд состояния разработки может находиться в общем бакете, который вся команда может читать и записывать.

Принцип здесь — минимальные привилегии. Каждый человек или система получает только тот доступ, который необходим для выполнения их работы. Разработчику может понадобиться полный доступ к среде разработки. Ему может понадобиться доступ только для чтения к состоянию продакшена, чтобы понимать, что работает. Но если ему нужно внести изменение в продакшен, это изменение должно пройти через более формальный процесс: пул-реквест, проверенный другим членом команды, или пайплайн, требующий утверждения.

Владение делает границы конкретными

Границы привилегий работают лучше всего, когда у каждой среды есть четкий владелец. Владелец — это человек или команда, ответственные, когда что-то идет не так в этой среде. Владение — это не про контроль. Это про ответственность.

На практике владение часто выглядит так:

  • Команда платформенной инженерии владеет продакшеном. Она отвечает за его стабильность, производительность и безопасность.
  • Команда разработки приложений владеет стейджингом. Она использует его для проверки своих изменений перед запросом на развертывание в продакшен.
  • Отдельные разработчики владеют своими личными средами разработки. Они могут ломать их, перестраивать и свободно экспериментировать.

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

Как реализовать границы привилегий на практике

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

Структура репозитория

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

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

flowchart TD A[Запрос на изменение] --> B{Кто вносит изменение?} B -->|Разработчик| C{Целевая среда?} B -->|Оператор/Админ| D{Целевая среда?} C -->|Dev/Staging| E[Создать PR] C -->|Production| F[Заблокировано - передать владельцу] D -->|Dev/Staging| G[Создать PR] D -->|Production| H[Создать PR с проверкой владельца] E --> I[Шаг Plan] G --> I H --> J[Шаг Plan + одобрение владельца] I --> K[Применить к dev/staging] J --> L[Применить к production]

Конфигурация пайплайна

Ваш CI/CD-пайплайн — это место, где границы становятся операционными. Пайплайн для продакшена должен запускаться только при выполнении определенных условий. Например, он может запускаться только из защищенной ветки. Он может требовать ручного утверждения от назначенного лица. Он может выполнять дополнительные шаги валидации, которые пропускает пайплайн разработки.

Некоторые команды идут дальше. Они настраивают пайплайн продакшена так, чтобы он запускался только с определенного CI/CD-раннера, имеющего доступ к бэкенду состояния продакшена. Разработчики не могут запустить пайплайн продакшена со своих ноутбуков, потому что на их локальных машинах нет необходимых учетных данных.

Бэкенд состояния

Бэкенд состояния — это место, где инструменты "инфраструктура как код" хранят текущее состояние ваших сред. Если вы используете Terraform, файл состояния для продакшена должен находиться в отдельном бэкенде со строгими контролем доступа. Политика IAM для этого бэкенда должна разрешать операции только из пайплайна продакшена, а не с индивидуальных учетных записей разработчиков.

Например, вы можете настроить бэкенд состояния продакшена с политикой, которая гласит: "Только сервисная учетная запись CI/CD может записывать в этот файл состояния. Все остальные могут только читать его". Таким образом, даже если разработчик случайно запустит команду Terraform против продакшена, команда завершится ошибкой, потому что он не сможет получить блокировку состояния.

Вот политика IAM для Terraform, которая обеспечивает эту границу, разрешая запись только в файлы состояния dev и запрещая запись в файлы состояния prod:

data "aws_iam_policy_document" "state_access" {
  statement {
    sid    = "AllowDevWrite"
    effect = "Allow"
    actions = [
      "s3:PutObject",
      "s3:GetObject",
      "s3:DeleteObject"
    ]
    resources = [
      "arn:aws:s3:::my-tf-state-bucket/env:/dev/*"
    ]
  }

  statement {
    sid    = "DenyProdWrite"
    effect = "Deny"
    actions = [
      "s3:PutObject",
      "s3:DeleteObject"
    ]
    resources = [
      "arn:aws:s3:::my-tf-state-bucket/env:/prod/*"
    ]
  }
}

Границы — это не про недоверие

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

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

Границы также защищают людей, которые совершают ошибки. Разработчик, который случайно сломал продакшен из-за неограниченного доступа, чувствует себя ужасно. Он также тратит время команды, пока все расследуют инцидент. С четкими границами тот же разработчик был бы остановлен до того, как изменение достигло продакшена. Система ловит ошибку, а не человека.

Краткий чек-лист для настройки границ привилегий

Если вы проверяете свою текущую конфигурацию, вот несколько моментов, которые стоит проверить:

  • Отделен ли бэкенд состояния продакшена от разработки и стейджинга?
  • Могут ли разработчики записывать в состояние продакшена со своих ноутбуков?
  • Требует ли пайплайн продакшена ручного утверждения?
  • Есть ли четкий владелец для каждой среды?
  • Проверяются ли изменения конфигураций продакшена владельцем перед развертыванием?

Эти проверки не являются исчерпывающими, но они покрывают наиболее распространенные пробелы, которые приводят к инцидентам на продакшене.

Что дальше

Как только вы установите границы привилегий и владение, следующая задача — поддерживать точность состояния вашей инфраструктуры. Иногда изменения происходят вне ваших инструментов "инфраструктура как код". Кто-то изменяет конфигурацию сервера напрямую из облачной консоли. Член команды вручную применяет хотфикс во время инцидента. Эти изменения создают дрейф между вашим состоянием и реальностью. Дрейф подрывает надежность вашей инфраструктуры и делает будущие изменения непредсказуемыми. Это тема, которую стоит изучить отдельно, но пока важный шаг — сначала установить четкие границы. Без них обнаружение и устранение дрейфа становится гораздо сложнее.