| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| ongoing |
@lohrc
@alexpooley
|
@ayufan
|
@lohrc
| devops data stores | 2023-04-05 |
조직
이 문서는 진행 중인 작업이며 현재 조직 디자인의 현재 상태를 나타냅니다.
용어 사전
- 조직(Organization): 조직은 하나 이상의 최상위 그룹을 위한 우산 역할을 합니다. 조직은 기본적으로 서로 격리되어 있으며, 따라서 교차 네임스페이스 기능은 단일 조직 내에서만 존재하는 네임스페이스에서만 작동합니다.
- 최상위 그룹(Top-level Group): 최상위 그룹은 모든 다른 그룹의 최상위 그룹에 대한 이름입니다. 그룹 및 프로젝트는 최상위 그룹 아래에 중첩됩니다.
- 셀(Cell): 셀은 여러 조직을 포함하는 인프라 구성 요소의 세트입니다. 셀에 제공된 인프라 구성 요소는 조직 간에 공유되지만 다른 셀과는 공유되지 않습니다. 이러한 인프라 구성 요소의 격리로, 셀은 서로 독립적입니다.
- 사용자(User): 조직에는 많은 사용자가 있습니다. 조직에 가입하면 해당 조직의 사용자가 됩니다.
- 구성원(Member): 조직 내의 그룹 또는 프로젝트에 사용자를 추가하면 구성원이 됩니다. 구성원은 항상 사용자이지만 사용자가 조직 내의 그룹 또는 프로젝트의 구성원이 되는 것은 아닙니다. 예를 들어 사용자는 조직에 가입 초대를 수락했지만 해당 조직 내의 어떤 그룹 또는 프로젝트의 구성원이 아닐 수 있습니다.
- 비사용자(Non-User): 조직의 비사용자는 특정 조직의 일부가 아닌 사용자를 의미합니다. 비사용자는 해당 조직의 공개 그룹 및 프로젝트와 상호 작용할 수 있으며 이에 대해 문제를 제기하거나 코멘트를 남길 수 있습니다.
요약
조직은 다음과 같은 문제를 해결합니다.
- 최상위 그룹을 그룹화할 수 있습니다. 예를 들어, 다음 최상위 그룹은
GitLab조직에 속할 수 있습니다:https://gitlab.com/gitlab-org/https://gitlab.com/gitlab-com/
- 서로 다른 조직을 격리할 수 있습니다. 동일한 조직의 최상위 그룹은 서로 상호 작용할 수 있지만 다른 조직의 그룹과는 상호 작용할 수 없도록하여 조직에 명확한 경계를 제공합니다. 이는 자기관리형 인스턴스와 유사합니다. 격리는 사용자 대시보드와 같은 기능을 조직에 대해 범위 지정할 수 있으므로 성능 및 가용성에 긍정적인 영향을 미칠 것으로 예상됩니다.
- 셀과 통합할 수 있습니다. 조직을 격리함으로써 다른 셀에 할당하고 분산하는 것이 가능해집니다.
- 등급을 정의하는 필요성을 없앱니다. 조직은 의미 있는 계층/엔터티 세트(조직, 최상위 그룹 등)로 채울 수 있는 컨테이너입니다.
- 사용자 프로필을 중앙에서 제어할 수 있습니다. 조직별 사용자 프로필로 관리자는 회사의 사용자 역할을 제어하고 사용자 이메일을 강제하거나 사용자가 조직의 일부임을 그래픽으로 표시할 수 있습니다. 예를 들어, 코멘트에 “GitLab 직원” 스탬프를 추가할 수 있습니다.
- 조직은 GitLab.com에 자체 프레미엄 경험을 제공합니다. 조직 관리자는 대부분의 구성을 조직 수준에서 제어하는 인스턴스 동등한 관리 영역 설정에 액세스할 수 있습니다.
동기
목표
조직은 조직이 GitLab 경험을 관리하기 위한 더 나은 경험을 만들기에 중점을 두고 있습니다. 조직과 셀을 도입함으로써 GitLab.com의 신뢰성, 성능 및 가용성을 향상시킬 수 있습니다.
- 더 넓은 대상층: 많은 인스턴스 수준 기능은 관리자 전용입니다. 우리는 GitLab.com 사용자들이 이러한 방식으로 GitLab.com의 사용자들을 차단하고 싶지 않습니다. 이는 또한 오랜 기간 이전에 자기관리형 사용자만 사용할 수 있던 관리 기능을 GitLab.com 사용자도 사용할 수 있게 만듭니다. 오늘날 자기관리형 관리자가 수행할 수 있는 조치 중 GitLab.com 사용자가 GitLab.com 관리자에게 요청해야 하는 작업들이 있습니다. 예를 들면 악의적인 활동가를 차단하는 등의 작업입니다.
- 향상된 UX: 프로젝트 및 그룹 수준에서 사용 가능한 기능 사이의 일관성은 탐색 및 사용 편의성에 문제를 야기시킵니다. 무엇보다도, 조직 수준 기능을 위한 전용 장소가 존재하지 않습니다.
- 집계: 조직에 있는 모든 그룹 및 프로젝트의 데이터를 집계할 수 있습니다.
- 조직에는 동일한 소유자(개인 네임스페이스 포함)의 모든 그룹 및 프로젝트의 설정, 데이터 및 기능이 포함됩니다.
- 계층적인 동작: 조직은 모든 해당 조직이 소유한 프로젝트 및 그룹에 동작을 퍼뜨립니다. 조직 수준에서 하부 수준의 설정이 재정의될 수 있는지 여부가 결정될 수 있습니다.
- 고객에게 최소한의 부담: 조직 추가는 기존 그룹과 프로젝트 경로를 변경할 필요가 없도록 만들기 위해 노력해야 합니다.
비목표
셀의 선행 조건으로서의 조직 제공의 긴급성으로 인해, 현재는 네임스페이스 프레임워크에서 조직 기능을 구축하는 것이 목표가 아닙니다.
제안
우리는 조직을 새로운 가벼운 엔티티로 만들어, 필요한 기능과 워크플로우만을 갖추도록 합니다. 우리는 이미 그룹과 프로젝트에 많은 기능이 있으며, 그룹 자체가 사실상 이미 최상위 엔티티입니다. 적어도 GitLab.com에서 최상위 그룹은 계속해서 이러한 목적을 제공할 것으로 예상되므로, 우리는 조직 외에도 일부 중요한 설정 외에는 회사에서 큰 기능을 추가할 필요가 없을 것으로 생각됩니다. 인프라적인 관점에서, 클러스터 전체 공유 데이터는 최소(용량이 작음)하고 드물게 기록되어야 합니다.
모든 인스턴스에서 기본 조직을 설정합니다.
이점
- 최상위 그룹을 이동하는 경우 URL에 대한 변경 사항이 없으므로 최상위 그룹을 쉽게 이동할 수 있습니다.
- 기존 최상위 그룹에 대한 변환 프로세스가 없기 때문에 낮은 리스크 롤아웃 전략입니다.
- 조직은 성능과 명확성을 위해 별도의 테이블에 따로있는 것으로 식별하는 주요한 역할을 합니다.
Drawbacks
- 현재로서는 인스턴스(또는 조직이 아닌 것) 기능을 계속 구축하기 위해 어떻게 노력을 줄일 지 명확하지 않습니다. 특히 이것은 많은 부분의 보고에 해당됩니다. GitLab.com에서는 최상위 그룹이 이미 이 기능을 갖고 있기 때문에 문제가 되지 않지만, self-managed에서는 도전입니다. self-managed를 위해 내장 조직(또는 아예 미사용)을 도입하면 그룹에 추가하는 작업과 함께 무료로 이러한 작업을 얻지 못하게 되므로 인스턴스/조직 수준의 보고 기능을 계속해서 구축해야 할 것으로 보입니다.
- 청구는 최상위 그룹에서 조직 수준으로 이동해야 할 수도 있습니다.
데이터 탐색
초기 데이터 탐색에서 사용자 및 조직에 대한 다음 정보를 검색했습니다:
- 조직에 연결된 사용자 중 대다수(98%)는 단일 조직과만 연결되어 있습니다. 따라서 약 2%의 사용자가 여러 조직을 거치게 되리라고 예상됩니다.
- 대부분의 사용자(78%)는 단일 최상위 그룹의 구성원입니다.
- 현재의 최상위 그룹 중 25%는 조직과 일치시킬 수 있습니다.
- 이러한 최상위 그룹의 대부분(83%)은 두 개 이상의 최상위 그룹을 가진 조직과 연결되어 있습니다.
- 두 개 이상의 최상위 그룹을 가진 조직 중간 평균 최상위 그룹 수는 3입니다.
- 두 개 이상의 최상위 그룹을 가진 조직에 일치하는 대부분의 최상위 그룹은 하나의 조직으로 통합되기를 원한다고 가정됩니다(82%).
- 두 개 이상의 최상위 그룹을 가진 조직에 일치하는 대부분의 최상위 그룹은 하나의 가격 책정 계층만 사용합니다(59%).
- 현재의 대부분 최상위 그룹은 공개적으로 표시됩니다(85%).
- 0.5% 미만의 최상위 그룹만 다른 최상위 그룹과 그룹을 공유합니다. 그러나 이는 조직을 도입함으로써 기존 최상위 그룹 간 76,000개의 링크를 잠재적으로 분리할 수 있다는 것을 의미합니다.
이 분석 결과를 바탕으로 조직을 롤아웃할 때 유사한 동작을 예상할 것으로 기대됩니다.
디자인 및 구현 세부 정보
셀은 Cells 1.0, Cells 1.5 및 Cells 2.0으로 세 단계로 롤아웃될 것입니다. 각 단계에서 사용 가능한 조직 기능은 아래와 같습니다.
조직 MVC
Cells 1.0의 조직
Cells 1.0의 조직 MVC에는 다음 기능이 포함됩니다:
- 다중 조직 생성을 허용하는 인스턴스 설정. 기본적으로 GitLab.com에서는 활성화되고, self-managed GitLab에서는 비활성화됩니다.
- 모든 인스턴스에는 ‘기본 조직’이라는 기본 조직이 있습니다. 초기에 모든 사용자는 이 기본 조직에서 관리됩니다.
- 조직 소유자. 조직 생성은 해당 사용자를 조직 소유자로 지정합니다. 처음에는 조직 소유자가 다른 조직 소유자를 지정할 수 있습니다.
- 조직 사용자. Cells 1.0의 경우 사용자는 하나의 조직에만 속할 수 있습니다. 사용자가 속하려는 각 조직에 대해 새 계정을 만들어야 합니다.
- 설정 설정. 조직 이름, ID, 설명 및 아바타를 포함합니다. 조직 설정은 조직 소유자에 의해 편집 가능합니다.
- 설정 흐름. 신규 사용자는 새 조직을 만들 수 있습니다. 또한 조직 내에서 새 최상위 그룹을 만들 수 있습니다.
- 가시성. 초기에는 조직은 ‘비공개’일 수 있습니다. 비공개 조직은 해당 비공개 그룹 및 프로젝트에 속한 사용자만 볼 수 있습니다.
- 조직 설정 페이지에 조직을 삭제하는 기능 추가. 기본 조직을 삭제하는 것은 방지됩니다.
- 그룹. 최상위 그룹을 만들고, 편집하고, 삭제하는 기능 및 조직 소유자 및 사용자가 액세스할 수 있는 그룹 개요를 포함합니다.
- 프로젝트. 프로젝트를 만들고, 편집하고, 삭제하는 기능 및 조직 소유자 및 사용자가 액세스할 수 있는 프로젝트 개요를 포함합니다.
- 개인 네임스페이스. 사용자는 연결된 각 조직에 개인 네임스페이스를 받게 됩니다.
- 사용자 프로필. 각 사용자 프로필은 조직에 대해 범위가 지정됩니다.
Cells 1.5의 조직
Cells 1.5의 맥락에서 조직은 다음 기능을 포함할 것입니다:
Cells 2.0의 조직
Cells 2.0의 맥락에서 조직은 다음 기능을 포함할 것입니다:
조직 액세스
조직 사용자를 참조하십시오.
역할 및 권한
조직은 소유자 역할이 있을 것입니다. 사용자와 비교하여 다음 작업을 수행할 수 있습니다:
| 작업 | 소유자 | 사용자 |
|---|---|---|
| 조직 설정 보기 | ✓ | |
| 조직 설정 편집 | ✓ | |
| 조직 삭제 | ✓ | |
| 사용자 삭제 | ✓ | |
| 조직 메인 페이지 보기 | ✓ | ✓ |
| 그룹 개요 보기 | ✓ | ✓ (1) |
| 프로젝트 개요 보기 | ✓ | ✓ (1) |
| 사용자 개요 보기 | ✓ | ✓ (2) |
| 조직 활동 페이지 보기 | ✓ | ✓ (1) |
| 최상위 그룹 조직으로 이동하기 (둘 다 소유권이 있는 경우) | ✓ |
(1) 사용자는 자신의 액세스 권한이 있는 것만 볼 수 있습니다. (2) 사용자는 자신의 그룹과 프로젝트 액세스가 있는 사용자만 볼 수 있습니다.
그룹 및 프로젝트 수준의 역할은 현재와 동일하게 유지됩니다.
조직 소유자와 인스턴스 관리자 간의 관계
(인스턴스) 관리자 역할을 하는 사용자는 현재 자체 관리 GitLab 인스턴스를 관리할 수 있습니다. 기능이 조직 수준으로 이동됨에 따라 조직 소유자는 현재 관리자만 액세스할 수 있는 기능에 더 많은 액세스 권한을 얻을 수 있게 될 것입니다. 우리의 SaaS 플랫폼에서는 기업이 현재 GitLab 팀 구성원인 인스턴스 관리자에 의존하지 않고도 자체 조직을 더 효율적으로 관리할 수 있도록 돕습니다. SaaS에서는 기대하건대 인스턴스 관리자와 조직 소유자가 다른 사용자인 것이 일반적입니다. 자체 관리형 인스턴스는 일반적으로 단일 조직에 범위가 지정되므로 이 경우 두 역할을 동일한 사용자가 수행하는 것이 가능합니다. 사용자가 시스템을 남용하는 경우와 같이 몇 가지 상황에서 인스턴스 관리자의 개입이 필요할 수 있습니다. 그런 경우에는 인스턴스 관리자의 조치가 조직 소유자의 조치를 우선합니다. 예를 들어, 인스턴스 관리자는 조직 소유자를 대신하여 사용자를 차단하거나 삭제할 수 있습니다.
라우팅
현재 사용자, 프로젝트, 네임스페이스 및 컨테이너 이미지만이 https://gitlab.com/<path>/-/에서 전역적으로 유일해야 하는 라우팅 엔티티로 간주됩니다.
초기에는 조직 경로가 스코프가 적용되지 않은(unscoped) 상태일 것입니다.
조직은 기존 그룹 및 프로젝트 경로를 변경하지 않아야 하는 하나의 설계 목표로 https://gitlab.com/-/organizations/org-name/ 경로를 따를 것입니다.
다른 도메인에 미치는 조직의 영향
우리는 공유 데이터베이스에 빈도가 낮은 테이블의 최소한의 양을 원합니다. 공유 데이터베이스에 높은 쓰기 볼륨이나 대량의 데이터가 있다면 단일 병목 현상이 발생할 수 있으며 Cells의 수평 확장 목표를 잃게 될 수 있습니다. Cells가 작동하려면 격리가 필요한 주요 요구사항 중 하나이기 때문에 기존 기능은 주로 조직에 스코프가 지정될 것입니다. 이에 대한 예외는 사용자로, 사용자는 클러스터 전역의 공유 데이터베이스에 저장됩니다. 특정 기능에 미치는 영향에 대해 자세히 알아보려면 Cells에 영향을 받는 기능 목록을 참조하세요.
조직과 이행 간의 조정
이행은 최상위 그룹 이상의 엔터티를 지원합니다. 이들의 관점은 문제 #1138에서 개요되어 있습니다.
이행의 목표
- 이행은 최상위 그룹에서 라이선스를 조직 및 해당 최상위 그룹의 모든 부그룹에 적용하도록 오래된 계획이 있습니다.
- 이행은 청구에 대해 Zuora를 사용하고 있으며 라이선스를 단일 최상위 그룹에 바인딩하는 것에서 이탈하고자 합니다.
- 고객이 여러 조직이 필요한 경우, 각각에 별도의 BillingAccount가 필요합니다.
- 기본적으로 자체 관리형 인스턴스는 기본적으로 단일 조직을 가지며, 대부분의 고객에게 충분해야 합니다.
- 이행은 이상적으로는 하나의 추가적인 개체만을 선호합니다.
조직에서 오픈소스 기여
현재 오픈소스 워크플로우의 몇 가지 측면이 조직 도입에 영향을 받을 것으로 예상됩니다. 우리는 특정 문제에 대해 보다 심층적인 연구를 하고 있는 중입니다. issue 420804를 참조하세요.
이터레이션 계획
다음 이터레이션 계획은 조직 MVC에 도달하기 위한 우리의 의도를 개요하고 있습니다. 우리는 실험, 베타 및 일반적으로 사용 가능한 기능에 대한 지침을 따르고 있습니다.
이터레이션 1: 조직 프로토 타입 (FY24Q2-FY25Q1)
이터레이션 1에서는 최상위 그룹을 그룹화하는 방법으로서의 조직 개념을 소개합니다. 조직 지원은 Cells 작업을 필요로 하지 않지만 그러면 Cells의 모든 후속 이터레이션이 더 간단해질 것입니다. 이터레이션 1의 목표는 조직 내에서 기본적인 기능을 테스트하기 위해 GitLab 팀이 사용할 수 있는 프로토 타입을 생성하는 것입니다. 프로토 타입에는 다음과 같은 기능이 포함되어 있습니다.
- 새로운 조직을 생성할 수 있습니다.
- 조직에는 이름, ID, 설명 및 아바타가 포함되어 있습니다.
- 조직 만든이가 조직 소유자로 할당됩니다.
- 그룹은 조직 내에서 생성할 수 있습니다. 그룹은 그룹 개요에 나열됩니다. 모든 조직 사용자는 그룹 개요에 액세스하여 자신이 액세스 권한을 가진 그룹을 볼 수 있습니다.
- 프로젝트는 그룹 내에서 생성할 수 있습니다. 프로젝트는 프로젝트 개요에 나열됩니다. 모든 조직 사용자는 프로젝트 개요에 액세스하여 자신이 액세스 권한을 가진 프로젝트를 볼 수 있습니다.
- 사용자는 사용자 개요에 나열됩니다. 모든 조직 사용자는 자신이 액세스 권한을 가진 그룹과 프로젝트의 일부인 사용자를 볼 수 있습니다.
- 기업 및 비기업 사용자 모두가 조직의 일부가 될 수 있습니다.
- 기업 사용자는 여전히 최상위 그룹에서 관리됩니다.
- 사용자는 하나의 조직의 일부가 될 수 있습니다.
- 사용자는 자신이 속한 다른 조직 간을 탐색할 수 있습니다.
- 조직 내 및 외부의 모든 사용자는 조직에 포함된 그룹 및 프로젝트에 초대될 수 있습니다.
- 조직은 완전히 격리되지 않습니다. 우리는 조직 격리의 1단계를 완료하기를 목표로 하고 있으며,
define sharding_key및desired_sharding_key규칙을 정의하는 것이 목표입니다.
이터레이션 2: 조직 MVC 실험 (FY25Q2)
이터레이션 2에서는 조직 MVC 실험이 출시될 예정입니다. 우리는 일부 고객들과의 기능을 테스트하고, 이러한 배울점을 기반으로 MVC를 개선할 것입니다. MVC 실험에는 다음과 같은 기능이 포함되어 있습니다:
- 조직을 삭제할 수 있습니다.
- 조직 소유자는 조직의 활동 페이지에 액세스할 수 있습니다.
- 조직 간에 포킹이 정의됩니다.
- 조직 고립이 초기 고객 요구 사항을 충족합니다.
이터레이션 3: 조직 MVC 베타 (FY25Q3)
이터레이션 3에서는 조직 MVC 베타가 출시될 예정입니다.
- 다중 조직 소유자를 지정할 수 있습니다.
- 조직 아바타를 조직 설정에서 변경할 수 있습니다.
- 조직 소유자는 그룹 개요에서 그룹을 생성, 편집 및 삭제할 수 있습니다.
- 조직 소유자는 프로젝트 개요에서 프로젝트를 생성, 편집 및 삭제할 수 있습니다.
- 조직 URL 경로를 변경할 수 있습니다.
- 조직이 완전히 격리됩니다. 조직 격리의 단계 2를 완료하는 것이 목표로, 격리 제약 조건을 구현할 예정입니다.
이터레이션 4: 조직 MVC 일반 사용 가능 (FY25Q3)
이터레이션 4에서는 조직 MVC가 전개될 것입니다.
MVC 이후 이터레이션
조직의 초기 전개 이후에는 GitLab의 구현과 관련된 고객 요구를 해결하기 위해 다음 기능이 추가됩니다:
- 기존 최상위 그룹을 조직으로 이전할 수 있습니다.
- 조직이 사용자를 초대할 수 있습니다.
- 조직 고립의 단계 3을 완료하여 기존 네임스페이스를 기본 조직에서 새로운 조직으로 이동할 수 있도록 목표를 설정합니다.
- GitLab.com에 속한 조직에서 내부 가시성을 제공합니다.
- 조직 외부의 사용자 초대를 제한합니다.
- 기업 사용자가 조직 수준에서 사용할 수 있도록 합니다.
- 조직에서 사용자를 밴하고 삭제할 수 있게 합니다.
- 조직 수준에서 프로젝트를 생성할 수 있습니다.
- 조직 수준에서 그룹을 생성할 수 있습니다.
- 최상위 그룹에서 조직으로 빌링을 이전합니다.
- 조직 수준의 감사 이벤트를 설정합니다.
- 조직 수준에서 합병 요청 승인 규칙을 설정하고 모든 그룹 및 프로젝트에 적용합니다.
- 조직 수준에서 보안 정책을 설정합니다.
- 조직 수준에서 취약점 보고서 및 종속성 목록을 제공합니다.
- 보안 스캔을 강제로 실행하는 조직 설정을 연쇄적으로 적용합니다.
- 조직 수준에서 합병 요청 승인 정책을 설정합니다.
- 규정 준수 프레임워크를 적용합니다.
- 조직 수준에서 Kubernetes 공유를 위한 에이전트를 지원합니다.
조직 전개
우리는 조직을 성공적으로 전개하기 위해 다음 단계를 제안합니다:
- 단계 1: 전개
- 조직은 ‘기본 조직’ 개념을 사용하여 전개될 것입니다. GitLab.com의 모든 기존 최상위 그룹은 이미 이 ‘기본 조직’의 일부입니다. 조직 UI는 기능 플래그가 지정되며, 초기에 특정 사용자 집합 및 이 단계의 끝에서 전역 사용자 풀을 위해 활성화될 수 있습니다. 이렇게 함으로써 사용자들은 이미 조직 개념과 조직 UI에 익숙해질 것입니다. ‘기본 조직’ 활성화로 인해 기능에는 영향을 미치지 않습니다. 자세한 내용은 이슈 #418225를 참조하십시오.
- 단계 2: 임시 온보딩 변경
- 개인적인 네임스페이스와 포킹이 필요하지 않다고 확인된 새로운 고객은 처음부터 새로운 조직을 생성할 수 있습니다. 최상위 그룹은 아직 새로운 조직으로 마이그레이션될 수 없기 때문에 모든 콘텐츠는 조직 내에서 새롭게 생성되어야 합니다.
- 단계 3: 기존 고객의 마이그레이션
- GitLab, 조직은 따로 새로운 조직을 생성하여 최상위 그룹을 새로운 GitLab 조직으로 옮기게 될 것입니다. 우리는 GitLab에 속한 모든 최상위 그룹, 즉
gitLab-org및gitLab-com최상위 그룹을 새로운 GitLab 조직으로 이동합니다. 자세한 내용은 이슈 #418228를 참조하십시오. - 기본 조직에서 다른 조직으로 최상위 그룹 전송이 가능해지면, 기존 고객은 자체적으로 조직을 생성하고 최상위 그룹을 해당 조직으로 마이그레이션할 수 있습니다. 조직 생성은 선택 사항으로 유지됩니다.
- GitLab, 조직은 따로 새로운 조직을 생성하여 최상위 그룹을 새로운 GitLab 조직으로 옮기게 될 것입니다. 우리는 GitLab에 속한 모든 최상위 그룹, 즉
- 단계 4: 영구적인 온보딩 변경
- 모든 새로운 고객은 새로운 조직을 생성하는 옵션만 가질 수 있습니다.
- 단계 5: 대상 지향적 노력
- 조직이 증진됩니다. 예를 들어 배너 메시지, CSMs를 통한 대규모 고객과의 대화 등을 통해 조직을 증진시킵니다. 별도의 조직을 만드는 것은 여전히 자발적인 조치로 유지됩니다.
- 조직의 가치 제안이 증대됩니다. 예를 들어 빌링을 조직 수준으로 이동하여 더 많은 고객들이 별도의 조직으로 이동할 수 있는 인센티브를 제공합니다. 채택률은 모니터링될 것입니다.
셀들로 목표하는 부하 분산을 달성하지 못할 경우, 강제 옵션을 고려할 것입니다.
대체 솔루션
조직을 구축하는 대안적 접근법은 최상위 그룹을 조직으로 변환하는 것입니다. 이 접근법의 주요 장점은 기능을 Namespace 프레임워크 위에 구축할 수 있으며, 따라서 이미 그룹 수준에서 사용 가능한 기능을 활용할 수 있다는 것입니다. 이렇게 하면 동일한 기능을 여러 번 구축하는 것을 피할 수 있을 것입니다. 그러나 조직은 세포의 중요한 드라이버로 확인되어 왔습니다. 세포를 즉시 제공해야 하는 긴급성 때문에, 우리는 조직을 제공하기 위한 가장 빠르고 간단한 솔루션을 선택하기로 결정했습니다. 이것은 위에서 설명한 경량 디자인입니다. 두 가지 조직 제안을 비교한 자세한 내용은 여기에서 확인할 수 있습니다.
자주 묻는 질문
조직: 자주 묻는 질문 참조.
의사 결정 로그
- 2023-05-10: 청구서는 조직 MVC의 일부가 아닙니다
- 2023-05-15: 조직 경로 설정