위치:
변경 관리자가 위험 점수 매기기를 사용하여 안전하게 변경 실행
변경 관리자가 위험을 평가하고, 예약 충돌 및 구성 항목과 관련된 충돌을 해결하고, 확인 가능한 구현 및 롤백 계획을 통해 변경 사항을 승인할 수 있도록 지원합니다.
사례 한눈에 사용
관객: IT 변경 사항 평가, 승인, 예약 및 종료를 담당하는 변경 관리자
목표: 제안된 변경 사항이 안전한지 여부를 확인하고 비즈니스 및 기술적 위험에 비례한 제어 조치를 적용합니다
시작 지점: 영향을 받는 서비스 또는 구성 항목, 예상 구현 기간, 책임 있는 소유자가 포함된 문서화된 변경 요청
성공된 결과: 변경 사항은 적절한 창에서 구현되고, 확인 기준을 충족하며, 알려진 충돌을 피하거나 해결하며, 결과 및 후속 조치가 문서화되어 있습니다.
위험 정보를 사용하여 요청을 진행, 수정, 다시 예약 또는 거부할지 여부를 결정합니다. 단계에 대한 관련 도움말 항목을 사용하여 설문지를 완료하고, 점수 매기기를 구성하고, 충돌을 해결하고, 승인을 관리하고, 요청을 닫습니다.
검토 가능한 변경 사항 설정
검토자가 변경 사항을 평가할 수 있는 충분한 세부 사항으로 시작합니다. 목적, 범위, 영향을 받는 서비스 및 구성 항목(CI), 구현 단계, 테스트 계획, 롤백 접근 방식, 소유자, 예상 시작 및 종료 시간을 확인합니다. 조직의 프로세스에 따라 요청을 표준, 정상 또는 비상으로 분류합니다.
| 증거 | 관리자 변경 질문 | 지원되는 결정 |
|---|---|---|
| 비즈니스 영향 | 구현이 실패하면 위험한 서비스 또는 비즈니스 결과는 무엇입니까? | 검토 깊이, 커뮤니케이션 요구 사항, 승인 권한을 설정합니다. |
| CI 및 종속성 범위 | 영향을 받을 수 있는 시스템, 서비스 및 사용자는 무엇입니까? | 필수 검토자, 잠재적인 충돌, 확인 범위를 식별합니다. |
| 구현 계획 | 창에서 단계를 순서가 지정하고 소유하고 실행할 수 있습니까? | 계획을 승인하거나 개정하도록 반환합니다. |
| 테스트 계획 | 배포 후 성공을 증명하는 증거는 무엇입니까? | 완료 및 모니터링 기준을 정의합니다. |
| 롤백 접근 방식 | 팀이 사용 가능한 기간 내에 서비스를 복원할 수 있습니까? | 진행, 경감 추가 또는 다른 구현 기간을 선택합니다. |
| 일정 | 제안된 일정은 충돌, 중단, 충분한 직원 배치가 없는 기간을 방지합니까? | 변경 사항을 유지하거나 다시 예약합니다. |
변경 유형 및 사용 목적에 대한 자세한 내용은 IT 서비스용 변경 요청 관리를 참조하십시오. 변경 요청을 생성, 연결, 예약 및 마감하는 단계는 IT 서비스에 대한 변경 요청 사용을 참조하십시오.
위험 정보를 사용하여 검토에 집중
두 가지 유형의 위험 정보가 표시될 수 있습니다. 규칙 기반 변경 위험 평가는 조직에 구성된 레코드 특성 및 설문지 응답을 사용합니다. 위험 수준은 낮음, 보통, 높음 또는 심각하며 정규화된 점수는 1~100입니다. 관리자가 구성한 질문 및 가중치를 사용합니다.
위험 수준 및 정규화된 점수를 사용하여 판단을 대체하지 않고 검토에 집중합니다. 위험 수준 또는 점수가 더 높으면 더 강력한 증거, 경감, 검토, 승인이 필요합니다. 위험 수준 또는 점수가 낮으면 완료되지 않은 계획이나 해결되지 않은 충돌이 안전하지 않습니다. 평가 및 워크플로에 대한 자세한 내용은 IT 서비스의 변경 위험 평가 및 IT 서비스의 변경 위험 평가 수행을 참조하십시오.
계산 및 임계값에 대한 자세한 내용은 변경 요청에 대한 위험 점수 계산 방법을 참조하십시오. 조직에서 사용자 정의된 평가 논리를 사용하는 경우 관리자에게 구성된 동작을 확인하십시오.
규칙 기반 평가를 선택적 기계 학습 예측과 구분합니다. 위험 점수 변경 예측 카드는 0~100 척도로 구현 실패 가능성을 추정합니다. 규칙 기반 위험 수준을 대체하거나 변경 요청에 새 위험 점수를 작성하지 않습니다. 두 가지 유형의 위험 정보가 모두 나타나면 승인 또는 변경 조합 결정에 정보를 제공한 정보를 기록합니다.
승인 전 충돌 해결
영향을 받는 CI 및 종속성을 검토한 다음, 예상 구현 기간을 다른 예약된 작업과 비교합니다. 변경 요청 충돌 감지가 활성화된 경우 겹치는 변경 요청이 같은 예약 기간 동안 동일한 구성 항목에 영향을 미칠 경우 충돌 레코드가 생성됩니다. 충돌 감지를 위해 영향을 받는 CI를 변경 요청과 연결해야 합니다. 별도로 IT 서비스 캘린더에 변경 요청, 릴리스 및 중단이 표시되므로 변경 관리자가 동결 상황에 대한 작업 일정을 다시 예약할 수 있습니다.
각 충돌에 대해 요청을 다시 예약할지, 범위를 변경할지, 작업을 조율할지 또는 충돌이 적용되지 않는 이유를 문서화할지 여부를 결정합니다. 충돌 수가 비어 있으면 IT 서비스 캘린더가 명확하지 않으므로 별도로 캘린더를 검토하십시오. 충돌 감지는 구현을 자동으로 차단하지 않습니다. 충돌 기준 및 사용 가능한 조치에 대한 자세한 내용은 IT 서비스에 대한 변경 충돌 검토 및 해결을 참조하십시오.
변경 권한 부여 및 실행
승인 강도를 증거 및 위험에 맞춥니다. 필수 검토자가 영향, 경감, 확인, 롤백, 커뮤니케이션 계획을 이해했는지 확인합니다. 위험이 높은 작업의 경우 구성된 승인 또는 상담원 변경 프로세스를 통해 요청을 라우팅하고 구현 전에 결정을 기록합니다.
구현 기간 동안 변경 처리자가 승인된 단계를 실행하고, 자료 편차를 기록하고, 결과를 테스트하고, 서비스 상태를 모니터링합니다. 확인에 실패하거나 위험이 허용된 경계를 초과할 경우 승인된 계획에 따라 중지하거나 롤백합니다. 위험 점수 매기기는 구현을 자동으로 차단하지 않습니다. 구성된 승인 및 변경 관리 워크플로는 결정을 적용합니다.
Change Advisory Board 개념 및 워크플로에 대한 자세한 내용은 IT 서비스용 Change Advisory Boards 관리를 참조하십시오.
확인, 알아보기, 닫기
마감 전에 테스트 계획과 결과를 비교하고 서비스 상태를 확인하고 구현 결과를 수집한 후 남아 있는 위험을 식별합니다. 마감 코드 및 요약을 기록하고 관련 문서를 업데이트하거나 구현이 부분적이거나 실패한 경우 수정 작업을 할당합니다.
프로세스 또는 위험에 따라 구현 후 검토를 수행합니다. 예상되는 영향 및 위험을 실제 결과와 비교하고 학습한 내용을 사용하여 템플릿, 평가 응답, 구현 관행 또는 롤백 계획을 개선합니다. 이 여정은 위험 설문지를 완료한 경우뿐만 아니라 결정 및 결과를 추적할 수 있는 경우에만 성공합니다.
변경 제어가 준비되었는지 확인
이 여정을 사용하여 채택을 평가하기 전에 변경 요청 관리, 위험 평가, 스테이지 관리, 변경 요청 충돌 감지, IT 서비스 일정 액세스 및 변경 프로세스에 필요한 승인이 구성되었는지 확인하십시오. 충돌 감지를 사용할 때 영향을 받는 CI가 변경 요청과 연결되어 있는지 확인하고 변경 관리자, 처리자, 평가자, 승인자에게 필요한 권한이 있는지 확인합니다.
