REXNET/engineering-playbook
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: finalize matrix of 6 enterprise teams

Browse Source
This commit is contained in:
Security Lead
2026-06-16 16:22:50 +03:00
committed by REXNET AI Agent
parent 41fc6a8f1b
commit 2d581153e7
1 changed files with 23 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/beginner/00-teams-setup.md
+23 -15
View File
@@ -2,26 +2,34 @@
В корпоративных платформах безопасность базы кода (Codebase) базируется на концепциях **Zero Trust** (Нулевое доверие) и **Least Privilege** (Минимально необходимые права).
Ни один разработчик не получает прямой доступ к репозиториям. Все доступы выдаются исключительно через централизованное участие в Командах (Teams).
Ни один сотрудник не получает прямой доступ к репозиториям. Все доступы выдаются исключительно через централизованное участие в строго определённых Командах (Teams).
## Архитектура Команд (Team Structure)
В вашей Организации должна быть выстроена строгая иерархия групп:
В Организации REXNET утверждена следующая официальная иерархия из 6 команд:
1. **Owners (Владельцы)**
* **Права:** Полный административный доступ (Owner).
* **Описание:** Управление биллингом, глобальными настройками безопасности и правами всех других участников. В целях безопасности в этой команде должно быть максимум 1-2 человека (CTO, Lead DevOps).
### 1. Owners (Владельцы)
* **Уровень доступа:** Полный административный (Организация).
* **Описание:** Абсолютный контроль над платформой REXNET. Управление глобальными настройками безопасности, созданием репозиториев и распределением пользователей по командам. В целях безопасности в этой группе состоит минимум людей.
2. **DevOps / Tech-Leads**
* **Права:** Admin (Администраторы репозиториев).
* **Описание:** Старшие инженеры, ответственные за архитектуру, серверы и CI/CD пайплайны. Эта группа имеет право утверждать изменения в коде (Approve) и сливать ветки в Production.
### 2. DevOps (Инфраструктура)
* **Уровень доступа:** Admin (На уровне репозиториев).
* **Описание:** Инженеры, ответственные за настройку аппаратной защиты веток (Branch Protection), CI/CD пайплайны, Webhooks и серверную инфраструктуру. Они автоматизируют процессы и следят за тем, чтобы конвейер развёртывания работал без сбоев.
3. **Developers (Разработчики)**
* **Права:** Write (Запись).
* **Описание:** Основная рабочая сила компании. Разработчики могут создавать новые ветки, писать код и открывать Pull Requests. У них нет технической возможности удалить репозиторий, перезаписать историю коммитов или залить код в `main` напрямую.
### 3. Tech-Leads (Архитекторы и Хранители кода)
* **Уровень доступа:** Write / Maintainer.
* **Описание:** Главные ответственные за качество архитектуры продукта. Это единственная группа, которая наделена правом утверждать чужой код (Approve) в Pull Requests и выполнять слияние (Merge) в главную ветку `main`.
4. **QA / Viewers (Тестировщики / Наблюдатели)**
* **Права:** Read (Чтение) / Ограниченная запись для управления задачами (Issues).
* **Описание:** Сотрудники, которые читают документацию, проверяют работоспособность системы и заводят баг-репорты. Они не могут изменять исходный код.
### 4. Developers (Разработчики)
* **Уровень доступа:** Write (Запись).
* **Описание:** Основная движущая сила проектов. Разработчики создают изолированные ветки (`feature/`, `bugfix/`), пишут исходный код и открывают Pull Requests. Они не имеют технической возможности удалять репозитории, обходить Branch Protection или заливать код в `main` напрямую.
Правильная архитектура команд гарантирует: даже при компрометации (взломе) аккаунта одного из разработчиков, корневая инфраструктура компании и серверы останутся в абсолютной безопасности.
### 5. QA (Контроль качества)
* **Уровень доступа:** Read (Чтение кода) + Write (Управление задачами).
* **Описание:** Инженеры по качеству. Они тестируют собранный код на серверах `stage`, заводят баг-репорты (Issues) и отслеживают исправление ошибок. Доступ к исходному коду нужен им для написания автотестов.
### 6. Viewers (Наблюдатели)
* **Уровень доступа:** Strictly Read (Только чтение).
* **Описание:** Новые сотрудники на испытательном сроке, внешние аудиторы или временные подрядчики. Они могут только читать документацию и просматривать код, без малейшей возможности внести какие-либо изменения.
Правильная настройка этих 6 команд гарантирует: даже при компрометации (взломе) аккаунта рядового разработчика, корневая инфраструктура и история кода останутся в абсолютной безопасности.