Организации, проекты и команды
Иерархия
- Организация (org) — верхний уровень: биллинг/квоты, участники, команды, пробы, SSO. Всё остальное живёт внутри неё.
- Проект (project) — конкретное приложение или сервис: у него свой DSN, свои issues, свои мониторы и т.д.
- Команда (team) — группа участников организации внутри неё, которой можно точечно назначить доступ к части проектов, не выдавая роль в целом по организации.
Роли
Роль назначается на уровне организации и действует на все её проекты:
| Роль | Что может |
|---|---|
| owner (владелец) | Всё, что может admin, плюс: назначать/снимать роль owner у других, удалять owner’ов, видеть раздел SSO организации (саму настройку при этом разрешает не роль owner, а отдельная отметка «администратор инстанса» — её раздел виден и тому, кто ею помечен, даже не будучи owner’ом этой организации), выгрузка/удаление персональных данных субъектов (152-ФЗ), удаление организации целиком |
| admin (администратор) | Приглашать и удалять участников, менять роли admin/member (но не owner), управлять квотами приёма, создавать/удалять команды, управлять пробами и настройками проектов (мониторы, статус-страницы, окна обслуживания) |
| member (участник) | Работает внутри проектов, к которым у него есть доступ (issues, performance, метрики, аптайм и т.п.), без доступа к административным страницам организации |
Последнего owner’а организации нельзя понизить или удалить — система всегда защищает от того, чтобы организация осталась без владельца.
Администратор инстанса
Отдельно от ролей внутри организаций существует флаг администратор инстанса (users.is_instance_admin) — ровно один на весь инстанс, не связанный ни с одной ролью ни в одной организации. Назначается автоматически первому зарегистрированному пользователю инстанса.
Администратор инстанса настраивает и удаляет SSO организаций — эта возможность не выдаётся ролью owner, только этим флагом (см. таблицу ролей выше). Пока на инстансе есть другие пользователи, аккаунт администратора инстанса нельзя удалить, не передав роль одному из них — иначе SSO организаций осталась бы недоступна вообще всем. Если администратор инстанса — единственный пользователь инстанса, он может удалить свой аккаунт свободно: передавать роль некому, а первый следующий зарегистрировавшийся сам станет администратором.
Передать роль можно в разделе «Администратор инстанса» на странице /profile: укажите email существующего пользователя инстанса и подтвердите передачу. После подтверждения роль сразу переходит получателю, а прежний администратор теряет доступ к настройке SSO и возможность передать роль ещё раз.
Восстановление, если доступ к аккаунту администратора инстанса утрачен: если забыт только пароль — обычный сброс пароля восстанавливает доступ, а удалить аккаунт администратора всё равно нельзя, пока на инстансе есть другие пользователи. Если доступа к аккаунту нет совсем, оператор с доступом к БД инстанса назначает нового администратора напрямую, одной транзакцией — BEGIN/COMMIT обязательны: psql по умолчанию в autocommit, и без них опечатка в email после первого UPDATE молча оставит инстанс без администратора вовсе:
BEGIN;
UPDATE users SET is_instance_admin = false WHERE is_instance_admin;
UPDATE users SET is_instance_admin = true WHERE email = '<email>';
COMMIT;
Перед COMMIT убедитесь, что каждый UPDATE вернул UPDATE 1 — UPDATE 0 у второй команды означает опечатку в email, а COMMIT в этом состоянии оставит инстанс без администратора. Частичный уникальный индекс one_instance_admin не даст назначить администратором сразу двух пользователей.
Приглашение участников
Раздел «Настройки» → «Организация» → «Участники» (/orgs/{id}/settings, доступен owner/admin) содержит таблицу текущих участников (email, роль, смена роли, удаление) и форму приглашения:
- Введите email приглашаемого.
- Выберите роль — member или admin (роль owner через инвайт не выдаётся, её можно только сменить существующему участнику).
- Нажмите «Пригласить».
Если на сервере не настроен SMTP, приглашение всё равно создаётся, но письмо не уходит — вместо этого страница один раз покажет прямую ссылку-приглашение, которую нужно переслать человеку вручную (второй раз она не показывается).
Пока приглашение не принято, оно видно в списке «Ожидают принятия» на той же странице, и там же его можно отозвать — опечатались в адресе, и отзыв убьёт ссылку раньше, чем ей воспользуется посторонний. Принятие убирает приглашение из списка и добавляет участника.
Дальнейшее поведение регистрации по приглашению зависит от режима регистрации инсталляции (GOTCHA_REGISTRATION_MODE, см. Конфигурация):
- open — самостоятельная регистрация всегда открыта, приглашение — просто способ сразу добавить человека в организацию с нужной ролью;
- invite (по умолчанию) — самостоятельная регистрация закрыта после того, как на инстансе появился первый пользователь; попасть можно только по действующей ссылке-приглашению (или через OAuth/SSO при наличии соответствующего инвайта на email);
- closed — самостоятельная регистрация закрыта совсем, кроме самого первого пользователя инстанса.
Команды
Раздел «Настройки» → «Организация» → «Команды» (/orgs/{id}/teams, только owner/admin) позволяет группировать участников и точечно выдавать им доступ к проектам, не меняя их роль в организации.
Создание команды:
- Нажмите «+» рядом с заголовком — откроется модальная форма «Создать команду».
- Укажите Slug (короткий идентификатор, например
backend) и Название (отображаемое имя, например «Backend»). - Сохраните.
Для каждой созданной команды на странице отдельная карточка с двумя списками и формами под ними. В заголовке карточки — кнопка «Переименовать»: меняет отображаемое название, не трогая ни участников, ни привязанные проекты. Идентификатор (slug) при этом остаётся прежним — он участвует в адресах и в выдаче прав.
Внутри карточки:
- Участники — таблица уже добавленных, форма добавления через выпадающий список (в нём только участники организации, ещё не состоящие в этой команде), кнопка удаления у каждой строки.
- Проекты — таблица уже привязанных проектов, форма привязки через выпадающий список (только ещё не привязанные проекты организации), кнопка отвязки у каждой строки.
Участником команды может стать только тот, кто уже состоит в организации; привязка проекта к команде не меняет доступ владельцев/админов организации — они и так видят все проекты.
Роли и права
Членство в команде, привязанной к проекту, — это и есть оператор в таблице ниже: именно оно позволяет member реально вести мониторинг в проекте день за днём, не повышая его до admin и не открывая заодно доступ ко всем остальным проектам организации. Owner и admin организации автоматически считаются оператором на любом проекте — у них и так полный доступ.
| Действие | Зритель (доступ) | Оператор (участник команды) | Admin | Owner |
|---|---|---|---|---|
| Просмотр issues, производительности, аптайма, алертов и т. п. | ✓ | ✓ | ✓ | ✓ |
| Смена статуса issue или performance issue | ✓ | ✓ | ✓ | ✓ |
| Подтверждение (ack) открытого инцидента — любой из шести источников (хосты, метрики, трейсы, профили, SLO, аптайм) | — | ✓ | ✓ | ✓ |
| Мониторы: создание, правка, пауза/возобновление, удаление | — | ✓ | ✓ | ✓ |
| Heartbeat-монитор: перевыпуск токена пинга | — | ✓ | ✓ | ✓ |
| Окна обслуживания: создание, правка, удаление | — | ✓ | ✓ | ✓ |
| Контент статус-страниц: создание/правка страницы, выбор мониторов и подписей; удаление, пока страница не опубликована | — | ✓ (страница, созданная оператором, стартует неопубликованной) | ✓ | ✓ |
| Публикация статус-страниц: флажок «Опубликована», а также удаление уже опубликованной страницы | — | — | ✓ | ✓ |
| Правила алертов (новый issue / регрессия / всплеск) | — | ✓ | ✓ | ✓ |
| Эскалации: лесенки уведомлений по критичности («Критично»/«Предупреждение») | — | ✓ | ✓ | ✓ |
| Подавление шторма: рёбра зависимостей — создание, правка, удаление | — | ✓ | ✓ | ✓ |
| Каналы оповещений: создание, правка, удаление, «Проверить» | — | — (видит только тип канала и замаскированную цель — этого хватает, чтобы отличить каналы друг от друга при выборе в правиле) | ✓ | ✓ |
| Лог доставок | — | ✓ (цели замаскированы) | ✓ (полностью) | ✓ (полностью) |
| Оповещения по метрикам: создание, правка и выключение, удаление | — | ✓ | ✓ | ✓ |
| SLO: создание, удаление | — | ✓ | ✓ | ✓ |
| Рецепты: включение рекомендованных порогов сервиса | — | ✓ | ✓ | ✓ |
| Хосты: пороги проекта, группы по меткам окружения/роли, переопределение порога на конкретном хосте, удаление хоста | — | ✓ | ✓ | ✓ |
| Выгрузки: постановка и удаление заявки на выгрузку | — | ✓ (видит и скачивает только свои заявки) | ✓ (все заявки проекта) | ✓ (все заявки проекта) |
| Настройки проекта (переименование, ключи DSN, квоты, sample rate) | — | — | ✓ | ✓ |
| Создание нового проекта | — | — | ✓ | ✓ |
| Управление организацией (участники, роли, приглашения, команды, пробы) | — | — | ✓ | ✓ |
| Удаление проекта или организации | — | — | — | ✓ |
«Зритель» здесь — не отдельная роль, а то, что даёт CanAccessProject любому, кто и так видит проект (owner/admin организации либо обычный member из привязанной к проекту команды), ещё до предиката оператора. Иначе говоря, каждый оператор — это ещё и зритель, а каждый admin и owner — ещё и оператор: колонки складываются, а не образуют взаимоисключающие уровни.
Коротко о том, что даёт членство в команде обычному member: всё операционное управление мониторингом этого проекта — мониторы, окна обслуживания, статус-страницы, правила алертов, оповещения по метрикам — без роли уровня организации. Что по-прежнему требует admin (или owner): каналы оповещений — их цель и секрет (токен бота, адрес SMTP, URL вебхука) являются кредами и персональными данными, а не операционной настройкой; действительно ли статус-страница публична — это решение о том, что организация показывает миру, а не о том, как ведётся мониторинг; и настройки проекта, как и всё на уровне организации, — без изменений.
Что дальше
- SSO и вход через провайдеров — единый вход вместо пароля.
- Пробы — ещё одна owner/admin-страница организации.
- Конфигурация — режимы регистрации и другие серверные настройки.