제안된 Change Management

  • 릴리스 버전: Xanadu
  • 업데이트 날짜 2024년 08월 01일
  • 소요 시간: 9분
  • 제안된 변경 기능으로 구성 항목과 이에 관련된 관계에 대한 변경을 미리 구성할 수 있습니다. 이러한 사전 구성된 변경은 구현할 준비는 되지만 나중에 적용될 때까지 실제로 변경되지는 않습니다.

    CI를 볼 때 제안된 변경이 표시되므로 이를 통해 계획된 것이 무엇인지 볼 수 있습니다.

    이 기능은 변경 프로세스가 승인 단계에 있는 동안 수정하려고 할 때, 승인이 완료된 후의 변경을 구현하려고 할 때 유용합니다. 변경이 승인되지 않으면 기록 변경을 되돌릴 필요가 없습니다. 변경이 승인되면 빠른 명령으로 제안된 모든 변경을 적용할 수 있습니다.

    다음과 같이 제안된 CI 변경을 수행할 수 있습니다.

    • CI 양식의 모든 필드를 수정합니다.
    • 이 CI와의 관계를 추가하거나 삭제합니다.

    관계를 수정하려면 현재 관계를 삭제하고 새로운 관계를 추가해야 합니다. 제안된 변경을 삭제할 수는 없습니다.

    CI 이력 보기

    목록, 달력 또는 일정 형식으로 CI의 변경 이력을 볼 수 있습니다.

    CI의 제안된 변경 보기

    제안된 변경 내용을 보고 CI에 계획된 것이 무엇인지 볼 수 있습니다.

    시작하기 전에

    필요한 역할: personalize_form

    이 태스크 정보

    제안된 변경 내용을 보려면 CMDB 예약된 변경 필드를 표시하도록 CI 양식 레이아웃을 구성합니다. 제안된 변경 사항은 기본적으로 CI 양식에 표시되지 않습니다.

    프로시저

    1. 다음으로 이동 모두 > 변경 > 오픈 을 클릭하고 변경 요청을 엽니다.
    2. 영향을 받는 CI 관련 목록에서 구성 항목을 엽니다.
      CI 양식으로 직접 이동할 수도 있습니다.
    3. 양식 헤더 바를 오른쪽 버튼으로 클릭합니다.
    4. 선택 구성 > 양식 레이아웃.
    5. CMDB 예약된 변경 필드를 선택됨 창으로 이동합니다.
    6. 저장을 클릭합니다.
      CI 양식은 예약된 변경 영역에서 제안된 변경에 대한 상세 정보를 보여줍니다.

    CI에 제안된 변경 추가

    CI에 대해 제안된 변경은 변경 요청 또는 작업 관련 기록을 보는 동안 수행할 수 있습니다.

    시작하기 전에

    필요한 역할: itil

    프로시저

    1. 변경 요청 양식에서 영향을 받는 CI 관련 목록으로 이동합니다.
      영향을 받는 CI 목록에 CI가 없는 경우 편집 을 클릭하여 이 변경 요청의 영향을 받는 CI를 추가합니다.
    2. 제안된 변경에 대해 구성할 CI를 마우스 오른쪽 버튼으로 클릭하고 제안된 변경을 선택합니다.
    3. 제안된 변경 사항을 작성하기 위한 양식을 작성하고 제안된 변경 저장을 클릭합니다.
      업데이트를 클릭하여 변경 사항을 즉시 적용합니다. 삭제를 클릭하여 CI를 삭제합니다.
    4. CI 관계의 추가 또는 제거를 제안하는 방법:
      1. 관련 항목 섹션에서 더하기 아이콘을 클릭합니다.
      2. 관계 섹션에서 관계를 추가하거나 삭제합니다.
        관계 편집기 사용에 대한 자세한 내용은 다음 단원을 참조하십시오 CI 관계 생성 또는 편집.
      3. Save Propose Change(변경 제안 저장)를 클릭합니다.
      4. 제안된 변경 저장을 확인합니다.
      Update(업데이트) 또는 Delete(삭제)를 클릭하여 변경 사항을 즉시 커밋합니다.
      주:
      CI 관계에만 사용하십시오. 사용자 관계 및 그룹 관계에는 관계 추가 또는 제거 제안이 유효하지 않습니다.

    다음에 수행할 작업

    제안된 변경이 저장되면 변경 요청 양식에 제안된 변경 적용 단추가 나타납니다. 이 버튼을 사용하면 사용자가 제안된 변경 사항을 CI에 커밋할 수 있습니다. 비즈니스 프로세스에서 변경 내용을 커밋할 적절한 시간을 결정합니다. CI는 제안된 변경 내용이 커밋될 때까지 기존 데이터를 유지합니다. 그러나 사용자는 변경 내용이 제안되었음을 알 수 있습니다.

    CI에 제안된 변경 적용

    제안된 변경 내용을 적용하면 해당 변경 요청에 대해 제안된 모든 변경이 구성 항목에 적용됩니다. 검증 없이 또는 제안된 변경사항의 검증 테스트가 실패한 경우 제안된 변경사항을 적용할 수 있습니다.

    시작하기 전에

    필요한 역할: itil

    이 태스크 정보

    제안된 변경 내용을 적용하면 양식의 예약된 변경 부분에 예약된 변경 내용을 찾을 수 없음이 표시됩니다. 변경 내용을 적용하기 전에 제안된 변경을 확인하는 데 사용할 수 있는 제안된 변경 확인 규칙을 구성할 수 있습니다.

    프로시저

    1. 변경 요청 양식으로 이동합니다.
    2. 제안된 변경 사항 적용 버튼을 클릭합니다.
      양식 헤더를 마우스 오른쪽 버튼으로 클릭하고 양식 다시 로드 옵션을 선택하여 변경 내용을 확인해야 할 수 있습니다.

    제안된 변경 검증 규칙 생성 또는 편집

    제안된 변경 사항이 비즈니스 요구 사항을 충족하고 CMDB에 잘못된 데이터를 도입하지 않는지 확인한 다음, 제안된 변경 내용을 확인하는 스크립트를 포함하는 규칙을 생성합니다.

    시작하기 전에

    필요한 역할: asset 또는 itil

    이 태스크 정보

    CI에 대해 제안된 변경 검증 규칙을 구성할 때 제안된 변경이 규칙의 검증 테스트 스크립트를 통과하는지 확인할 수 있는 옵션이 있습니다. 검증 테스트 결과는 통과 또는 실패로 기록되며 결과를 볼 수 있습니다. 확인 테스트 실행은 필수가 아니며 확인 테스트에 실패하더라도 제안된 변경 내용을 적용할 수 없습니다.

    프로시저

    1. 다음으로 이동 모두 > 구성 > 변경 검증 > 제안된 변경 검증 규칙.
    2. New(새로 만들기)를 클릭하거나 편집할 기존 규칙을 선택합니다.
    3. 필드에 적절히 입력합니다.
      표 1. 제안된 변경 검증 규칙 양식
      필드 설명
      규칙 이름 이 규칙의 이름입니다.
      테이블 이름 규칙이 적용되는 테이블입니다.
      필터 조건 이 규칙을 특정 CI에 적용하기 위한 조건입니다.
      활성 이 규칙을 활성화하는 확인란입니다.
      규칙 스크립트

      true 또는 false를 반환해야 하는 확인 Java 스크립트입니다. 예:

      validateRule()
       {
       var os = current.getValue("os");
       var cpu = current.getValue("cpu_count");
      
          //Use current.getValue(fieldName) to get the proposed change value, eg. var os = current.getValue("os");
          //Your verification code
      
       if (os != "SunOS" || cpu < 2)
       return false;
           //Return true to pass the verification and false if the verification failed
       return true;
       }
    4. 제출 또는 업데이트를 클릭합니다.

    결과

    변경 요청 양식에서 제안된 변경 확인을 클릭하여 영향을 받는 CI에 대해 제안된 변경을 확인할 수 있습니다.

    제안된 변경 검증

    영향을 받는 CI에 제안된 변경을 적용하기 전에 제안된 변경 검증 규칙을 사용하여 변경 사항이 비즈니스 요구 사항을 충족하고 CMDB에 잘못된 데이터를 추가하지 않는지 확인하십시오.

    시작하기 전에

    제안된 변경을 확인하는 데 사용되는 규칙을 생성하거나 편집합니다. 자세한 내용은 제안된 변경 검증 규칙 생성 또는 편집를 참조하십시오.

    필요한 역할: 없음

    이 태스크 정보

    제안된 변경사항이 검증되지 않았거나 검증 테스트에 실패한 경우에도 적용할 수 있습니다.

    프로시저

    1. CI에 영향을 주는 변경 요청 양식을 엽니다.
    2. Verify Proposed Changes(제안된 변경 사항 확인)를 클릭합니다.
      제안된 변경 사항은 CI가 필터 조건 기준을 충족하는 제안된 변경 확인 규칙에 대해 검증됩니다.
    3. 검증 프로세스가 완료되면 양식 상단에 나타나는 메시지를 검토합니다.
      메시지에는 확인 테스트의 통과 또는 실패 여부가 명시되어 있습니다.

    다음에 수행할 작업

    지난 2일 동안 변경 요청에 대해 수행된 확인 테스트의 상세 정보를 보려면 제안된 변경 확인 로그 관련 링크를 클릭합니다.

    계획된 변경 확인 스크립트 생성 또는 편집

    클래스 변경이 비즈니스 요구 사항에 따라 유효한지 여부와 변경이 계획되었는지 여부를 확인하는 사용자 지정 스크립트를 만듭니다. 계획된 변경 확인 스크립트는 CI 타임라인 또는 변경 이력에서 CI 변경을 볼 때마다 사용됩니다.

    시작하기 전에

    필요한 역할: admin 또는 itil

    이 태스크 정보

    시스템은 다음과 같이 각 CI 변경의 유효성을 확인합니다.

    • CI 또는 CI 상위 중 하나에 대한 사용자 지정 스크립트가 있는 경우 스크립트가 실행되고 그 결과는 변경 내용을 유효하거나 유효하지 않음으로 플래그를 지정하는 데 사용됩니다. 상위 CI는 계층적 순서로 검사됩니다.
    • CI 또는 상위 CI에 대한 사용자 지정 스크립트가 없는 경우 미리 정의된 확인 스크립트가 사용됩니다. 변경된 CI와 관련된 변경 요청의 작업 시작 날짜와 작업 종료 날짜 사이에 변경이 발생한 경우 변경은 계획된 변경으로 결정됩니다.

      하지만 사용자가 작업 날짜 내에 CI를 수동으로 수정했을 수 있기 때문에 이 검사를 항상 신뢰할 수 있는 것은 아닙니다. 이 검사는 유효하지 않더라도 변경 플래그를 유효합니다.

    스크립트는 부울(예 또는 아니오)을 반환해야 하며, 이는 스크립트의 테스트 기준 충족 여부에 따라 달라집니다. 각 CI 클래스에 대해 별도의 스크립트를 정의할 수 있으며, 단일 클래스에 대해 계획된 여러 개의 변경 확인 스크립트를 정의할 수 있습니다. 예를 들어 다른 버전의 스크립트를 유지 관리합니다. CI 클래스에 대해 한 번에 하나의 스크립트만 활성화할 수 있습니다.

    다음은 변경을 고유하게 특징짓는 매개변수입니다.

    • 변경된 필드
    • 변경을 수행한 데이터 소스
    • 변경의 타임 스탬프

    변경의 유효성을 올바르게 확인하려면 매개변수를 검토하고 비즈니스 논리를 적용하여 유효성 검사 테스트가 충족되는지 평가합니다. 계획된 변경 확인 스크립트는 이러한 특성을 테스트하고 변경이 미리 설정된 기준을 충족하는 시기를 결정할 수 있습니다. 예를 들어, 사용자 지정 스크립트는 CI 모드가 운영 또는 유지관리인지 또는 누가 변경을 시작했는지 확인할 수 있습니다.

    프로시저

    1. 다음으로 이동 모두 > 구성 > 변경 검증 > 계획된 변경 확인 스크립트.
    2. 새로 만들기를 클릭하거나 편집할 유효성 검사 스크립트를 선택합니다.
    3. 양식을 작성하십시오.
      표 2. 계획된 변경 확인 스크립트 양식
      제어 설명
      활성 변경 내용의 유효성을 검사하기 위해 이 스크립트를 활성화하는 확인란입니다.
      적용 대상 이 스크립트가 적용되는 클래스입니다.
      스크립트 변경을 확인하기 위해 실행할 스크립트입니다. 스크립트가 부울 값을 반환하지 않으면 false로 구성됩니다.
      스크립트에는 스크립트의 입력 변수를 표시하는 템플릿이 있습니다.
      표 3. 템플릿 스크립트 입력 변수
      변수 유형 설명
      current GlideRecord 처리 중인 현재 기록입니다.
      updatedOn GlideDateTime 변경의 타임스탬프입니다.
      updatedBy 문자열 변경에 책임이 있는 엔터티입니다.
      fieldsChanged (필드변경됨) 문자열 변경된 모든 필드의 이름을 쉼표로 구분한 목록입니다.
      이 샘플 스크립트는 누가 레코드 업데이트를 시작했는지 확인합니다. 관리자가 기록 업데이트를 시작한 경우 true를 반환합니다. 그렇지 않으면 스크립트는 false를 반환합니다.
      isValidChange();
      
      function isValidChange(/*GlideRecord current, GlideDateTime updatedOn, String updatedBy, String changedFields*/) 
      { 
         //Return true if the user that updated the record has an admin role 
         return isUserAdmin(updatedBy); 
      }
      
      function isUserAdmin(userName)
      {
         var grUser = new GlideRecord("sys_user");
         grUser.addQuery('name', userName);
         grUser.query();
         if(grUser.next()) 
         {
             var roles = new GlideRecord ("sys_user_has_role");
             roles.addActiveQuery();
             roles.addQuery('user', grUser.sys_id);
             roles.query();
             while(roles.next()) 
             {
                if(roles.role.name == 'admin')
                   return true;
             }
         }
         return false;
      }
    4. 제출을 클릭합니다.