Automation Service Broker 정책이 처리되는 방식

정책은 정책 정의를 기반으로 처리됩니다. 특히, 단일 배포에 적용할 수 있는 정책이 여러 개인 경우에는 범위 및 적용 수준에 따라 어떤 정책이 유효한지 결정됩니다.

이 문서는 정책 처리에 대한 일반적인 정보를 제공하지만 다양한 정책 유형에 대한 세부 정보도 포함합니다.

조직 수준 및 적용 유형을 기반으로 정책 순위를 지정하는 방법

프로젝트의 멤버인 사용자가 배포를 생성하는 경우, 배포에 적용되는 정책이 둘 이상일 수 있습니다.


	정책 평가를 위해 시스템에서는 먼저 정책을 식별하고 순위를 지정합니다. 조직 및 프로젝트 수준에 하드 정책이 있는지 확인합니다. 하드 정책과 소프트 정책 모두 있으면 하드 정책만 고려되어 순위가 지정됩니다. 소프트 정책만 있으면 소프트 정책의 순위가 지정됩니다. 모든 하드 또는 소프트 정책의 순위가 범위를 기준으로 지정되며, 조직 정책이 프로젝트 정책보다 순위가 높습니다. 마지막 구분 특성은 생성 날짜이며, 오래된 날짜가 최근 날짜보다 순위가 높습니다.

정책 평가를 위해 시스템에서는 먼저 정책을 식별하고 순위를 지정합니다.

조직 및 프로젝트 수준에 하드 정책이 있는지 확인합니다. 하드 정책과 소프트 정책 모두 있으면 하드 정책만 고려되어 순위가 지정됩니다. 소프트 정책만 있으면 소프트 정책의 순위가 지정됩니다.
모든 하드 또는 소프트 정책의 순위가 범위를 기준으로 지정되며, 조직 정책이 프로젝트 정책보다 순위가 높습니다.
마지막 구분 특성은 생성 날짜이며, 오래된 날짜가 최근 날짜보다 순위가 높습니다.

조직 수준 및 적용 유형을 기반으로 정책이 처리되는 방식

정책은 효과적인 정책을 만들기 위해 평가되고 순위가 지정되며, 가능한 경우 병합됩니다. 효과적인 정책은 의도된 결과를 가져오지만 명명된 특정 정책은 아닐 수 있습니다.

이 섹션에는 다음 예시가 포함되어 있습니다.

리스 정책
2일차 작업 정책

다음 리스 정책 예시를 검토합니다.


	고려할 정책을 식별하고 순위를 지정한 후에는 병합 순서를 정하기 위해 정책이 평가됩니다. 순위가 가장 높은 정책이 기준선이 됩니다. 그 위에 두 번째 순위 정책이 적용되고, 이러한 방식으로 나머지 정책이 적용됩니다. 이전에 적용된 정책과 호환되지 않는 정책은 고려 대상에서 삭제됩니다. 예를 들어 값이 이전 정책의 값보다 높을 수 있습니다. 삭제된 정책은 무시됩니다. 어떤 정책이 적용되는지 보려면 컨텐츠 및 정책 > 정책 > 적용을 선택하고 배포를 찾아서 결정 사항을 검토합니다.
	정책 하나를 적용하고 그 위의 정책을 모두 제외하는 대신 정책이 병합되어 둘 이상의 개별 정책에 있는 값이 포함될 수 있습니다. 이 예시에서는 정책 2의 값이 정책 1의 값보다 높기 때문에 병합 프로세스에서 정책 2가 고려 대상에서 제외됩니다. 다음으로 정책 3이 정책 1을 기준으로 평가됩니다. 정책 3의 리스 및 총 리스 값은 정책 1보다 낮기 때문에 해당 값은 유예 기간 외에도 유효한 정책의 일부가 됩니다.

고려할 정책을 식별하고 순위를 지정한 후에는 병합 순서를 정하기 위해 정책이 평가됩니다.

순위가 가장 높은 정책이 기준선이 됩니다. 그 위에 두 번째 순위 정책이 적용되고, 이러한 방식으로 나머지 정책이 적용됩니다.
이전에 적용된 정책과 호환되지 않는 정책은 고려 대상에서 삭제됩니다. 예를 들어 값이 이전 정책의 값보다 높을 수 있습니다.
삭제된 정책은 무시됩니다. 어떤 정책이 적용되는지 보려면 컨텐츠 및 정책 > 정책 > 적용을 선택하고 배포를 찾아서 결정 사항을 검토합니다.

정책 하나를 적용하고 그 위의 정책을 모두 제외하는 대신 정책이 병합되어 둘 이상의 개별 정책에 있는 값이 포함될 수 있습니다.

이 예시에서는 정책 2의 값이 정책 1의 값보다 높기 때문에 병합 프로세스에서 정책 2가 고려 대상에서 제외됩니다.

다음으로 정책 3이 정책 1을 기준으로 평가됩니다. 정책 3의 리스 및 총 리스 값은 정책 1보다 낮기 때문에 해당 값은 유예 기간 외에도 유효한 정책의 일부가 됩니다.

다음 2일차 작업 정책 예시를 검토합니다.


	고려할 정책을 식별하고 순위를 지정한 후에는 병합 순서를 정하기 위해 정책이 평가됩니다. 순위가 가장 높은 정책이 기준선이 됩니다. 그 위에 두 번째 순위 정책이 적용되고, 이러한 방식으로 나머지 정책이 적용됩니다. 이전 정책(예: 정책 3)에 의해 정책이 적용되면 고려 대상에서 제외됩니다. 삭제된 정책은 무시됩니다. 어떤 정책이 적용되는지 보려면 컨텐츠 및 정책 > 정책 > 적용을 선택하고 배포를 찾아서 결정 사항을 검토합니다.

고려할 정책을 식별하고 순위를 지정한 후에는 병합 순서를 정하기 위해 정책이 평가됩니다.

순위가 가장 높은 정책이 기준선이 됩니다. 그 위에 두 번째 순위 정책이 적용되고, 이러한 방식으로 나머지 정책이 적용됩니다.
이전 정책(예: 정책 3)에 의해 정책이 적용되면 고려 대상에서 제외됩니다.
삭제된 정책은 무시됩니다. 어떤 정책이 적용되는지 보려면 컨텐츠 및 정책 > 정책 > 적용을 선택하고 배포를 찾아서 결정 사항을 검토합니다.

리스 정책 관리 목표 고려 사항

리스 정책 처리 방법을 이해했으면 이제 정책 관리 목표를 파악할 차례입니다. 정책 처리 방법을 이해하면 관리할 수 없을 정도로 많은 수의 정책을 생성하지 않고도 관리 목표를 달성할 수 있습니다.

정책 구현 방법을 결정할 때 다음과 같은 시나리오를 고려해 볼 수 있습니다.

리스 정책 목표 및 적용 예시
2일차 정책 목표 및 적용 예

표 1. 리스 정책 목표 및 적용 예시
관리 목표	구성 예	동작
프로젝트 수준의 정책 값이 적용된 값에 영향을 줄 수 있도록 허용하는 조직 수준의 의미 있는 기본 정책	조직 정책 = 소프트 유예 기간: 10 리스: 100 총 리스: 100 프로젝트 1 정책 1= 소프트 리스: 20 총 리스: 50 프로젝트 2 정책 1= 소프트 리스: 10 총 리스: 30	프로젝트1의 멤버가 카탈로그 항목을 요청합니다. 프로젝트 2는 프로젝트 1 배포에 적용될 수 없기 때문에 고려되지 않습니다. 병합된 유효 정책: 유예 기간: 10 리스: 20 총 리스: 50
조직 수준 정책을 항상 기본으로 사용	조직 정책 = 하드 유예 기간: 10 리스: 100 총 리스: 100 프로젝트 1 정책 1= 소프트 리스: 20 총 리스: 50	프로젝트1의 멤버가 카탈로그 항목을 요청합니다. 하드 조직 수준 프로젝트의 순위가 더 높고 소프트 정책은 고려되지 않기 때문에 프로젝트 1 정책 1은 고려되지 않습니다. 유효한 정책: 유예 기간: 10 리스: 100 총 리스: 100
조직 수준의 기본 정책 없이 모든 정책을 프로젝트 수준에서 정의	프로젝트 1 정책 1= 소프트 유예 기간: 10 리스: 100 총 리스: 100 프로젝트 1 정책 2= 소프트 리스: 20	프로젝트1의 멤버가 카탈로그 항목을 요청합니다. 둘 모두 소프트 정책이고 프로젝트 1에 대한 정책입니다. 값이 병합됩니다. 유효한 정책: 유예 기간: 10 리스: 20 총 리스: 100

2일차 작업 정책은 다음 예시에서 사용됩니다.

표 2. 2일차 정책 목표 및 적용 예
관리 목표	구성 예	동작
프로젝트 수준의 정책 값이 적용된 값에 영향을 줄 수 있도록 허용하는 조직 수준의 의미 있는 기본 정책	조직 정책 = 소프트 Actions : Deployment.* 프로젝트 1 정책 1= 소프트 Actions: Cloud.vSphere.Machine.* 프로젝트 2 정책 1= 소프트 Actions: Cloud.Azure.Machine.*	프로젝트1의 멤버가 카탈로그 항목을 요청합니다. 프로젝트 2는 프로젝트 1 배포에 적용될 수 없기 때문에 고려되지 않습니다. 병합된 유효 정책: Action : {Deployment.* ,Cloud.vSphere.Machine.*}
조직 수준 정책을 항상 기본으로 사용	조직 정책 = 하드 Action : Deployment.* 프로젝트 1 정책 1= 소프트 Action : Cloud.vSphere.Machine.*	프로젝트1의 멤버가 카탈로그 항목을 요청합니다. 하드 조직 수준 프로젝트의 순위가 더 높고 소프트 정책은 고려되지 않기 때문에 프로젝트 1 정책 1은 고려되지 않습니다. 유효한 정책: Action : {Deployment.* }
조직 수준의 기본 정책 없이 모든 정책을 프로젝트 수준에서 정의	프로젝트 1 정책 1= 소프트 Actions : Deployment.ChangeLease 프로젝트 1 정책 2= 소프트 Action : Deployment.Delete	프로젝트1의 멤버가 카탈로그 항목을 요청합니다. 둘 모두 소프트 정책이고 프로젝트 1에 대한 정책입니다. 값이 병합됩니다. 유효한 정책: Action : {Deployment.ChangeLease , Deployment.Delete}

승인 정책 목표 및 적용 예시

승인 정책 평가는 이 프로세스를 따릅니다.

배포 또는 2일차 작업에 대한 요청이 제출됩니다.
승인 서비스는 카탈로그 항목을 요청하거나 배포된 항목을 변경하는 프로젝트에 적용되는 정책을 쿼리합니다.
적용 가능한 모든 프로젝트 및 조직 수준 범위 정책이 반환됩니다.
승인 정책은 배포 기준에 따라 필터링됩니다. 배포 기준은 배포 및 2일차 작업에 적용됩니다.
일치하는 정책을 찾을 수 없는 경우 승인이 필요하지 않으며 배포 프로세스가 진행됩니다.
일치하는 정책이 있는 경우(예: AP1, AP2, APn) 승인 항목은 다음과 같이 생성됩니다.
- 적용되는 정책 = AP1, AP2, APn.
- 승인자 = 적용된 모든 정책의 모든 승인자의 결합입니다.
- 자동 만료 = 정책에 거부 값이 있는 경우 거부, 그렇지 않으면 승인.
- 만료 = 적용된 정책의 최소 일 수입니다.

다음 표에는 여러 정책의 샘플이 나와 있습니다. 처리되는 방법에 대한 설명은 표 아래에 있습니다.

정책	구성 예
AP1	범위 = 조직 자동 만료 = 승인 만료 = 7일
AP2	범위 = 프로젝트 1 자동 만료 - 승인 만료 = 3일
AP3	범위 = 프로젝트 1 자동 만료 = 거부 만료 = 4일
AP4	범위 = 프로젝트 2 자동 만료 = 승인 만료 = 5일

위의 정책 및 구성 예에 따라 다음 정보는 프로젝트 1 요청이 처리되는 방법을 설명합니다.

범위 평가가 AP1, AP2 및 AP3을 반환합니다. AP4는 프로젝트 2 정책이므로 포함되지 않습니다.
AP1, AP2 및 AP3이 배포 및 작업 조건을 충족한다고 가정하면 승인 항목에 다음 값이 포함됩니다.
- 승인자 = AP1, AP2 및 AP3의 임의의 승인자 또는 모든 승인자가 승인자로 추가됩니다.
- 자동 만료 = 거부. AP3은 더 제한적인 동작을 제공합니다.
- 만료 = 3일. AP2는 가장 낮은 값을 제공합니다.