마지막 업데이트일: June 23, 2020
이 안내서는 ITIL에서의 변경관리의 기본을 이해하는 데 도움을 주고 잘 정의된 변경 프로세스를 사용하여 효과적인 변경을 실행하는 데 필요한 도구를 제공합니다.
ITIL 변경 관리 소개
비즈니스의 지평과 고객의 기대사항은 끊임없이 변화하며, 디지털 변혁은 산업계 전체에서 기업의 성공에 대한 핵심 기여요인이 되어 왔습니다. 디지털 변혁은 이용 가능한 기술을 활용하여 비즈니스의 문제를 해결하고 기회를 포착하는 것입니다. 좀 더 자세히 살펴보면, 디지털 변혁은 기본적으로 더 나은 IT 관리로 문제가 있는 부분을 제거하고 IT 인프라가 비즈니스 문제에 직면할 수 있도록 준비시키는 것입니다. 그리고 여기에는 귀하의 조직에 도움을 주는 IT 변화를 실행하여 기존의 비즈니스 및 IT 프로세스에 신기술을 적용하는 것이 포함됩니다.
이러한 변화는 아주 간단하게는 더 나은 운영 효율성을 위해 협업 앱을 클라우드로 이동시키는 것 되거나, 또는 더 나은 소비자 경험을 위해 모바일 우선의 접근방식을 취하는 것이 될 수 있습니다. 표면적으로 보이는 단순성에도 불구하고, 이러한 변경은 그 자체의 물류적인 어려움을 수반합니다. 변경을 적합하게 실행하지 못하면 조직에서 한 걸음 앞으로 나아갔다가 두 걸음 뒷걸음질치는 결과를 초래할 수 있습니다.
2018년 12월에 있었던 유명 은행의 모바일 앱 업그레이드 실패 사례는 어떻게 하면 변경 실행을 할 수 없는가에 대한 아주 적절한 예입니다. 새롭고 개선된 모바일 앱을 도입하려는 이 은행의 계획은 멋진 아이디어였고 매우 필요한 것이었습니다. 그러나 새로운 앱이 실행되는 순간, 문제가 발생했습니다. 이 은행은 이전의 앱을 폐지한 후에 새로운 앱을 도입했습니다. 새로운 앱의 작동이 멈추자, 수 천명의 고객들은 앱을 통해 은행계좌에 액세스할 수 없게 되었습니다. 설상가상으로, 새로운 앱에 대한 수정을 위한 커뮤니케이션도 잘 이루어지지 않아, 고객들은 좌절하게 되었습니다. 이 모바일 앱은 4일 동안 다운되었고 마침내 해당 은행은 이전 앱을 다시 살리기로 결정했습니다.
이 은행은 제안된 변경의 다양한 단계에서 실패를 거듭했습니다. 배치할 준비가 되어 있지 않은 상태에서 새로운 앱을 릴리스했고, 최종 사용자에게 업데이트와 관련된 다운타임을 전달하지 못했을 뿐 아니라 투명하지도 못했고, 실패한 경우에 대체 계획을 제시하지 못했습니다. 당연하게도 이 방법은 원하는 변경 실행 방법이 아닙니다.
바로 여기서 변경관리가 필요하게 됩니다. 변경관리는 조직 내 다양한 변경을 관리하는 데 도움을 주고 조직의 나머지 부분에 영향을 주지 않고 변경을 효율적으로 실행하기 위한 프로세스를 제공합니다. 변경관리는 위의 은행이 직면한 것과 유사한 혼란의 기회를 줄여줍니다.
이 안내서에서는 변경관리의 정의, 이유 및 방법을 다룰 것입니다. 효과적인 변경으로 조직에서 업계의 추세를 따르는 방법을 배우게 됩니다.
바로 들어가볼까요!
“무엇”
변경관리란?
ITIL은 변경관리를 시작부터 종결까지 변경의 전체 수명 주기를 통틀어 위험을 최소화하겠다는 목적과 함께 변경을 추적하고 관리하는 프로세스로 설명합니다.
체계적인 변경관리 프로세스를 수립하면 조직에서 높은 성공률로 사건이 없는 변경을 실행하는 데 도움이 됩니다.
변경이란?
ITIL에 의하면, 변경은 "서비스에 직간접적인 효과를 줄 수 있는 어떠한 것의 추가, 수정 또는 제거” 입니다.
가장 간단하게 말해서, 조직의 운영에 영향을 줄 수 있는 조직의 IT 인프라에 대한 모든 변경은 IT 변경이라고 불립니다. 여기에는 프린터, 프로젝터, 서버 등의 교체가 포함됩니다.
사건, 문제와 변경은 어떤 차이가 있습니까?
사건 | 문제 | 변경 | |
---|---|---|---|
정의 | ITIL에 의하면, 사건은 “계획되지 않은 서비스의 중단 또는 서비스 질의 감소”입니다. | ITIL에 의하면, 문제는 “하나 이상의 사건에 대한 원인 또는 잠재적인 원인"입니다. | ITIL에 의하면, 변경은 "서비스에 직간접적인 효과를 줄 수 있는 어떠한 것의 추가, 수정 또는 제거” 입니다. |
범위 | 가능한 신속하게 정상적인 서비스 운영을 복원 | 정상적인 서비스 운영에 대한 혼란의 근본 원인을 파악 | 근본 원인을 처리하는 변경을 실행하여 정상적인 서비스 운영에 대한 추가 혼란을 방지 |
속성 | 반응적 | 반응적 및 선제적 | 반응적 및 선제적 |
사례 | 사용자가 네트워크에 연결할 수 없습니다. 임시 해결책이 발급되어 해당 사건을 해결하고 사용자가 다시 네트워크를 이용할 수 있도록 합니다. | 문제 티켓이 생성되어 근본 원인 분석(RCA)을 수행합니다. 네트워크 스위치가 고장나, 사건으로 이어집니다. 스위치를 교체해야 합니다. | 변경 티켓이 생성되어 결함이 있는 스위치를 교체합니다. |
“왜”
왜 조직에 변경관리가 필요합니까?
이제 변경관리가 무엇인지 알았으므로, 왜 조직에 변경관리가 필요한지, 변경관리의 목적부터 시작하여 알아보겠습니다.
ITIL 변경 관리의 목적
조직에게 변경을 제어하고 관리할 수 있는 권한을 제공:
변경관리를 통해 변경 프로세스를 더 잘 제어할 수 있으며 최소한의 위험으로 변경을 실행할 수 있습니다. 표준 프로세스를 따름으로써, 변경관리는 계획, 위험 평가, 실행 추적과 같은 각 변경의 모든 측면이 효과적으로 관리될 수 있도록 해줍니다. 서비스 데스크 도구를 활용하여 처음부터 끝까지 변경을 추적하면 기적과도 같은 일이 일어나며 조직이 잘 계획되고 실행된 변경으로 IT 인프라를 더 잘 관리할 수 있게 됩니다.
조직이 변경을 더 잘 실행할 수 있게 지원:
전체 변경 프로세스를 추적함으로써, 조직은 변경관리로 모든 변경 요청을 완전히 파악할 수 있게 됩니다. 또한 다수의 무단 변경을 파악하여 제어하는 것이 더 손쉬워집니다. 사용자들에게 서비스 데스크 도구를 통해서만 변경 요청(RFC)을 제출하도록 허용함으로써, 조직은 시작단계에서 바로 해당 변경에 대해 필요한 모든 정보를 수집하고 그 변경을 실행해야 하는지 여부를 결정할 수 있습니다. 견고한 승인 메커니즘을 갖춤으로써 변경을 실행하기 전 필요한 모든 허가를 받을 수 있게 합니다.
지속적인 개선 실행:
변경관리가 만일의 경우를 대비하기 위한 것만은 아닙니다. 변경 관리는 조직이 지속적으로 자체 인프라와 프로세스를 개선할 뿐만 아니라, 현재의 서비스 운영에 영향을 주지 않고도 필요한 변경을 매끄럽게 개시할 수 있게 함으로써 업계의 추세를 따라갈 수 있게 도와주는 것이 목표입니다.
변경 관리의 장점
조직:
- 효과적인 변경 관리로 더 적은 변경 충돌.
- 운영에 영향을 주지 않고 업그레이드를 출시하는 능력.
- 더 적은 변경 실패.
- 정확한 변경 분류.
최종 사용자:
- 변경 일정을 알 수 있어 다운타임과 서비스의 이용 불능에 대해 더 잘 전달받게 됨.
- 열악한 변경 계획으로 유발되는 혼란이 적어짐에 따라 서비스 운영이 매끄러워짐.
“방법”
조직에서 변경관리를 수행하는 방법은?
이제 조직에서 변경 관리를 실행할 수 있는 방법을 살펴보겠습니다. 첫 번째로 할 일은 변경을 계획하고, 필요한 승인을 득하며, 변경을 실행할 수 있는 효과적인 변경 프로세스를 수립하는 것입니다. 다음은 변경을 효과적으로 취급하기 위해 따를 수 있는 변경관리 프로세스입니다.
변경관리 프로세스
1단계: 제출
첫 번째 단계는 변경을 개시하는 것입니다. 여기에는 변경 유형과 우선순위 같은 기본적인 변경 티켓 정보를 수집하는 것이 포함됩니다.
- 생성: 변경 티켓은 서비스 데스크 도구로 개시됩니다. 필요한 정보는 의무 작성 필드를 포함하는 변경 양식을 사용하여 처음부터 수집됩니다.
- 변경 역할 정의:조직은 변경 역할을 사용하여 다양한 이해관계자에게 변경 책임을 위임하고 각 변경 단계에 대해 각 역할이 갖는 액세스 레벨을 제어합니다.
2단계: 계획
다음 단계는 전체 변경의 계획이 수립되는 단계입니다. 잘 계획된 변경은 성공적인 변경 실행의 비결입니다. 또한 변경을 실행하는 데 필수적인 승인을 득하는 데 중요합니다. 영향, 출시계획, 철회계획 및 연계된 다운타임과 같은 세부사항을 문서화하여 변경 계획을 이해관계자들에게 명확하게 전달하고 이들에게 변경을 실행할 가치가 있는 것임을 설득합니다.
3단계: 승인
다음으로, 변경 자문 위원회(CAB), 긴급 변경 자문 위원회(ECAB) 및 변경에 대해 또는 변경에 의해 영향을 받는 조직의 인프라에 대해 이해관계가 있는 승인 부서로부터 변경 계획을 승인 받아야합니다. 맞춤형 CAB를 형성하면 조직 그룹의 관련이 있는 인원이 승인을 쉽게 관리하는 데 도움이 됩니다. 승인 프로세스를 자동화하면 전체 변경의 속도를 높일 수 있고 어떠한 승인 요청도 간과되는 일이 없도록 할 수 있습니다.
참고: CAB는 다양한 업무 역할과 팀의 조합입니다. 여기에는 변경의 중요도와 범위에 따라 C-레벨 임원, 팀장, 기술팀, 재무담당 직원 등이 포함될 수도 있습니다.
4단계: 실행
필요한 승인을 득하면, 변경을 실행할 수 있습니다. 조직에서 작업을 생성하거나 프로젝트를 사용하여 변경의 실행을 추적 및 관리할 수 있습니다.
- 작업을 통한 업무 위임:작업을 생성하여 다양한 팀으로부터 테크니션들에 이르기까지 할당함으로써 변경의 실행에 관여한 모든 사람들이 수행한 작업을 쉽게 관리할 수 있습니다. 상위 및 하위 작업을 사용하여 작업의 종속성을 설정하고 작업을 특정 순서대로 수행하도록 하고 누락되는 작업이 없도록 보장할 수 있습니다.
- 프로젝트 관리 활용:조직은 프로젝트를 사용하여 조직의 전체 인프라를 클라우드로 이전하는 것과 같은 대규모 변경을 처리할 수 있습니다. 프로젝트는 보다 큰 범위의 실행을 지원하며 더 많은 수의 작업, 인원 및 마일스톤을 더 잘 다룰 수 있습니다. 변경관리와 프로젝트 관리를 견고하게 통합할 경우 조직에 매우 큰 혜택이 될 수 있습니다.
5단계: 검토
다음으로, 실행 후 검토를 수행하여 실행에서 편차가 발생하지 않도록 하고 변경이 종결되기 전 모든 문제를 해결합니다.
6단계: 종결
이것이 변경관리 프로세스의 마지막 단계입니다. 완료된 변경은 성공, 실패 또는 미완료로 기록됩니다. 올바른 종결 코드를 기록함으로써 조직의 메트릭스가 더욱 정확하고 유용하게 됩니다.
ITIL에서 변경의 유형
모든 변경은 동일하지 않으며, 일부에는 다양한 요구사항이 있습니다. 어떤 변경은 가능한 신속하게 실행해야 하며, 어떤 변경은 조직의 상층 임원으로부터 승인을 받아야 하고, 어떤 변경은 주간 단위로 실행되는 그냥 평범한 변경입니다.
ITIL에 의하면, 변경은 대략적으로 표준, 통상적 및 긴급 변경의 세 가지 유형으로 나눌 수 있다고 합니다.
표준 변경:
이 유형들은 사전에 승인된 변경으로 영향이 적은, 잘 알려진 그리고 문서화된 변경들입니다. 표준 변경에는 최초 실행 시 위험 평가와 승인이 필요하지만, 이후 실행은 해당 변경이 수정되지 않는 한, 이러한 예방조치없이 수행될 수 있습니다.
예: 인쇄기 잉크 카트리지 교체
통상적 변경:
통상적 변경은 전체 변경 프로세스를 따라야 합니다. 이 변경에 대한 일정이 수립되어야 하고, 위험을 평가해야 하며, 승인을 받아야 합니다. 통상적 변경에는 사소한 변경(영향과 긴급성이 낮음에서 중간)과 중대 변경(높은 영향과 긴급성) 모두가 포함됩니다. 표준 변경이나 긴급 변경이 아닌 모든 변경은 통상적 변경으로 취급되어야 하며 변경 프로세스를 준수해야 합니다. 예: 온-프레미스 서비스를 클라우드로 이전
긴급 변경:
긴급 변경은 영향이 크고 긴급성이 높으며, 신속한 평가, 승인 및 실행을 요구하여 서비스를 가능한 신속하게 준비하고 실행해야 합니다. 비즈니스 운영에 영향을 주어 다운타임을 유발하는 구성 요소에 대한 수정이 긴급 변경으로 취급됩니다.
예: 주 서버 불능, 데이터 센터 장애, 보안 취약성에 대한 긴급 패치
변경관리 역할 및 책임
변경 소유자:
변경 소유자는 개선을 포함하여 전체 변경관리 프로세스에 대해 책임이 있습니다. 변경 소유자는 조직의 변경관리에 대한 책임이 있으므로, 보통 상위 레벨의 관계자들입니다.
변경 관리자:
변경 관리자는 변경과 그에 관련된 활동의 실행을 다룹니다. 또한 이들은 CAB와 다양한 팀 그리고 관련이 있는 이해관계자를 관리하고 이들과 조율합니다.
변경 개시자:
변경 개시자는 변경을 개시하고, 변경 계획, 실행 계획 및 기타 필수 세부사항을 추가하는 사람입니다. 이들은 또한 변경 실행 계획을 기획합니다. 변경 개시자는 테크니션 또는 최종 사용자가 될 수 있습니다.
CAB:
CAB는 다양한 팀과 업무 기능의 다양한 구성원들의 집합입니다. 이들은 함께 제안된 변경을 분석하고 그 변경과 실행에 대해 승인 및 권고사항을 제공합니다.
추가 역할:
일부 조직은 이러한 네 가지 주요 역할 이외에도 맞춤형 역할을 사용하여 업무를 위임하고 책임을 세분화합니다. 맞춤형 역할을 만듦으로써 변경 관리를 조직의 필요에 맞게 재단할 수 있습니다. 몇 가지 많이 사용되는 추가 역할은 다음과 같습니다.
- 변경 승인자
- 변경 실행자
- 변경 검토자
- 변경 기획자
프로세스/역할 | 변경 관리자 | 변경 개시자 | CAB | 변경 소유자 |
---|---|---|---|---|
제출 | C | R | - | A |
생성 | C | R | - | A |
변경 역할 정의 | C | R | - | A |
계획 | C | R | - | A |
승인 | R | I | C | A |
실행 | C | R | - | A |
작업을 통한 업무 위임 | C | R | - | A |
프로젝트 관리 활용 | C | R | - | A |
검토 | R | I | - | A |
종결 | C | R | - | A |
* R - 책임 있는, A - 의무가 있는, C - 상담하는, I - 정보에 입각한
4가지의 흔한 변경관리 문제
다음은 변경관리에 장애가 될 수 있는 네 가지 흔한 문제입니다.
실패한 변경:
변경을 계획하는 데 상당한 시간과 연구가 필요하기 때문에 변경에는 상당한 리소스가 소요됩니다. 상당한 수의 실패한 변경을 확인하지 않은 채 내버려두면 값비싼 비용이 바로 발생합니다. 인프라 변경의 경우, 실패율이 높으면 실행 중 또는 철회 계획 실행 중에 더 큰 문제가 발생할 수 있습니다. 또한 실패한 변경은 열악한 변경관리 프로세스의 지표이기도 합니다.
예: Zylker는 주 네트워크 인프라를 업그레이드하려고 계획했으며, 따라서 제3자 네트워크 제공사와 대체 네트워크를 설정하고, 주말에 변경을 실행하기로 계획했습니다. 실행 중, Zylker는 서비스가 다운되었다는 티켓을 접수했습니다. 이 회사는 대체 네트워크를 설정했기 때문에 이러한 사실은 예상 밖이었습니다. 밝혀진 사실에 따르면 해당 대체 네트워크 제공사 또한 해당 주말에 유지보수가 예정되어 있었습니다. 이는 곧 Zylker의 주 네트워크 및 대체 네트워크가 모두 다운되어, Zylker의 서비스를 이용할 수 없었다는 의미였습니다. 결국 변경이 적합하게 계획되지 않았으므로, 이 변경은 궁극적으로 실패했습니다.
무단 변경:
무단 변경은 모호한 승인 메커니즘과 승인 단계에 올바른 이해관계자를 포함시키지 않았을 때 나타나는 결과입니다. 이러한 변경은 필요한 허가를 우회하고 적기에 플래그 표시되지 않는 경우 실행이 종료될 수 있습니다. 무단 변경은 조직에서 필요로 하지 않거나 실행할 준비가 되어 있지 않은 변경으로 이어질 수 있습니다. 결국 무단 변경은 좋지 않으며 불필요한 비용을 유발합니다.
너무 많은 긴급 변경:
이전에 설명한 바와 같이, 긴급 변경에는 긴급 승인이 필요하므로 가능한 신속하게 실행될 수 있습니다. 너무 많은 변경을 긴급 변경으로 다룰 경우 실행해야 할 심각한 긴급 변경이 발생할 때 지연될 수 있습니다. 변경을 긴급 변경으로 분류할 때 주의를 하여 실행하는 것이 좋습니다.
참고: 늑대가 왔다고 큰소리로 알린 소년에 관한 이야기는 왜 너무 많은 변경을 긴급 변경으로 취급할 때 역효과가 발생하는지에 대한 이유를 설명해줍니다. 실제 긴급 상황이 발생할 때, 그에 상응하는 심각성을 가진 변경을 취하지 않을 수도 있으며, 그러한 긴급 상황을 처리할 리소스가 없을 수도 있습니다.변경 충돌:
계획이 잘못되면 변경 충돌을 유발할 수 있습니다. 변경 충돌은 두 가지 이상의 변경이 우연하게 동시에 실행되도록 계획되어, 어느 한 쪽의 변경 이행에 지장을 주는 경우입니다. 변경 캘린더를 활용하여 변경을 더 잘 계획하면 변경 충돌을 방지할 수 있습니다.
10가지 변경관리 모범 사례
다음은 변경관리에 접근하는 최고의 방법들입니다.
1. 변경의 유형 파악:
모든 변경이 다 같지는 않습니다. 변경의 유형 섹션에서 설명한 바와 같이, 변경에는 다양한 수준의 우선순위와 다양한 요구사항이 있습니다. 따라서, 귀하의 조직이 수행할 수 있는 변경의 종류를 먼저 파악한 다음, 다양한 변경 유형을 만들어 효과적으로 실행해야 합니다.
다양한 변경 유형에 대한 프로세스 설계:
변경 유형마다 각각의 고유한 요건이 있기 때문에, 그러한 필요를 충족시킬 수 있는 고유의 프로세스를 설계해야 합니다. 모든 변경 유형에 대해 동일한 변경 프로세스를 사용하면 불필요한 지연이 발생하고 변경 실행이 불완전해질 수 있습니다.
참고: 각 변경 유형에 대해 다양한 변경 워크플로를 만들 수 있습니다.
핵심 역할과 책임 정의:
역할을 정의함으로써 변경 관리자는 활동과 책임을 다른 사람에게 위임할 수 있습니다. 역할이 있으면 변경을 관리하기가 더욱 쉬워지므로, 각자가 수행할 수 있는 활동을 명확하게 정의하게 됩니다.
변경 제안을 기록, 관리하고 우선 순위를 정함:
정리된 방법으로 변경을 기록할 뿐 아니라, 하나의 장소에서 관리하고 우선순위를 정하는 것이 모범적인 실무입니다. 조직의 변경에 대해 더 나은 가시성을 확보함으로써, 어느 변경을 다른 변경보다 앞서 수행해야 하는지에 대한 우선순위를 정할 수 있습니다.
위험과 변경의 영향에 대한 명확한 통찰력 확보:
모든 변경에 대해 위험과 영향 분석을 수행하여 해당 변경을 더 잘 이해하고 필요한 리소스를 할당해야 합니다. 계획 단계에서 위험 및 영향에 대한 세부사항을 추가하여 CAB가 변경을 명확하게 파악하고 권고할 수 있도록 해야 합니다.
효과적인 승인 메커니즘 실행:
승인 프로세스를 정의하면 실행해야 하는 변경에 대한 필요한 허가를 받는 것이 더 쉬워집니다. 모든 이해관계자가 변경에 대해 알게 되고 변경이 실행되기 전 권고할 수 있게 됩니다. 이를 통해 무단 변경을 통제할 수 있습니다.
일정과 중단 시간을 이해관계자들에게 전달:
이해관계자들에게 예정된 변경에 대해 알리면 변경으로 유발되는 사건의 수를 줄일 수 있습니다. 즉각적인 정보를 제공함으로써 변경으로 인해 영향 받는 서비스가 없도록 할 수 있고 해당 변경을 효과적으로 수행할 수 있게 됩니다. 변경 수명 주기 내내 경영진에게 알릴 경우 경영진이 더욱 즐거워지는 것은 보너스입니다.
변경 실행의 진전과 효과성 측정:
변경의 전체 수명 주기 내내 변경을 관찰함으로써 어떠한 것도 잘못되는 일이 없도록 하고 변경 계획에 따라 변경이 실행되도록 할 수 있습니다. 핵심 메트릭스를 측정하여 변경 프로세스가 얼마나 효과적인지를 명확하게 알 수 있고 또한 개선할 수 있는 영역을 파악할 수 있습니다.
비상 대책 유지:
아무리 많은 대비를 해도 지나치지 않으므로, 최악의 시나리오에 항상 대비하고 변경 계획 단계에서 철회 계획을 제안하는 것이 좋습니다. 이처럼 심도 깊은 계획은 지극히 평범한 실패 변경과 IT 인프라에 대한 돌이킬 수 없는 피해 사이의 차이를 의미할 수 있습니다.
지속적인 서비스 개선 실행:
소방 기능이 변경관리의 중요한 기능은 아닐지라도, 조직에서의 변경은 훨씬 더 큰 범위를 갖습니다. 변경을 사용하여 기술과 프로세스를 개선함으로써, 더 나은 서비스를 제공하는 조직의 능력을 지속적으로 향상시키는 것이 변경관리의 중요한 기능이 되어가고 있습니다.
ServiceDesk Plus로 변경관리 프로세스의 고유한 모범 실무를 수립하세요
변경관리를 IT 서비스 관리의 더욱 큰 그림에 맞추는 방법은?
변경을 완료한다고 해서 변경관리가 끝나는 것이 아닙니다. 변경관리의 능력은 다른 ITSM 프로세스에서 수집한 정보로부터 크게 혜택을 받을 수 있는 그리고 그 반대의 경우도 가능한 변경을 효과적으로 출시하는 것입니다. IT 인프라의 변경을 기반으로 CMDB를 유발하거나 CMDB에 의해 유발되었거나 또는 CMDB를 업데이트하는 변경과 사건을 연계하는 능력은 함께 협력하여 조직을 더 잘 관리할 수 있게 도와주는 유익한 ITSM 실무를 만드는 작업의 시작입니다.
다음에서 변경관리가 어떻게 다른 ITSM 프로세스들과 함께 작동하는지를 볼 수 있습니다.
사건 관리:
변경을 유발하는 사건과 변경에 의해 유발되는 사건을 추적하게 되면 변경이 어떻게 조직에 영향을 미치는 지를 더 잘 알 수 있게 됩니다. 예를 들어, 라우터가 업데이트될 때, 인터넷이 다운되었다는 사건 티켓을 받게 될 수도 있습니다. 변경이 유발한 사건과 변경을 연계함으로써, 사건의 원인을 신속하게 파악할 수 있고, 리소스를 할당하여 특정 사건을 시정할 수 있습니다. 이는 변경이 완료되자마자 사건이 교정되기 때문입니다.
요청 이행:
큰 영향을 주는 서비스 요청에 대해 변경을 사용하여 IT 인프라의 업데이트를 유지하는 것이 중요합니다. 변경이 없는, 서버 업그레이드에 대한 서비스 요청이나 Azure 스토리지를 업그레이드하는 요청은 해당 서비스의 전달로 종료됩니다. 하지만 변경을 사용하여 서비스 요청을 실행하는 경우, 변경에 대한 이유와 실행 계획 등 더 많은 정보를 수집하고, 모든 이해관계자로부터 필요한 승인을 받아야 하며, 새로운 정보로 CMDB를 업데이트할 수 있습니다.
참고: 변경을 사용하여 요청 이행을 하는 것이 영향이 큰 서비스 요청과 CMDB에 대한 변경이 요구되는 모든 서비스 요청에 가장 좋습니다. 만약 CMDB를 업데이트해야 한다면, 변경이 필요한 것입니다!
문제 관리:
문제 관리에는 문제의 근본 원인을 시정하기 위한 변경 생성이 요구됩니다. 문제 티켓으로부터 바로 RFC를 만들 수 있게 되면 연계된 변경과 문제를 손쉽게 추적할 수 있습니다. 또한 왜 변경이 필요한지를 CAB가 더 잘 알 수 있게 되고, 해당 변경을 개시한 문제의 심각도를 나타낼 수 있습니다.
릴리스 및 배치 관리:
변경 프로세스가 가져다 주는 구조화된 접근으로부터의 업그레이드 혜택을 릴리스 및 배치합니다. 실행 계획, 출시계획 및 변경을 사용하는 릴리스와 배치의 실제 실행을 손쉽게 추적할 수 있습니다. 투명성과 가시성 변경 또한 모든 이해관계자가 계속 통보 받을 수 있도록 하는 데 도움이 됩니다.
CMDB:
CMDB에 대한 모든 업데이트는 항상 변경과 함께 수행되어야 합니다. 변경은 업데이트를 왜, 어떻게 그리고 언제 하는지에 대한 수 많은 유용한 정보를 제공합니다. 변경과 함께 수반되어 실행되는 영향 분석 또한 CMDB에 대한 모든 업데이트를 적절하게 분석하고, 해당 업데이트가 조직의 나머지 기능에 어떠한 혼란도 초래하지 않도록 할 수 있습니다. 변경 유형을 사용하여 다양한 우선순위로 CMDB 업데이트를 기록할 수 있습니다.
ITSM을 유익하게 만드세요
변경 관리 KPI
다음은 변경관리 프로세스의 효과성을 측정하는 중요한 메트릭스의 일부입니다.
KPI | 수식 | 의견 |
---|---|---|
무단 변경의 수 | 특정 기간에 파악된 무단 변경의 수 | 숫자가 적을 경우 승인 프로세스가 견고하면 모든 변경을 관리할 수 있음을 나타냅니다. |
변경 없이 수행되는 영향이 큰 서비스 요청의 수 | 특정 기간 동안 변경 없이 수행되는 영향이 큰 서비스 요청의 수 | 변경을 사용하여 영향도가 높은 서비스 요청을 이행해야 합니다. 높은 숫자는 인프라가 CMDB 업데이트 실패와 같은 문제에 취약함을 나타냅니다. |
철회된 변경의 퍼센트 | 실행 중의 문제 때문에 철회 계획이 사용된 변경의 퍼센트 | 숫자가 높게 나타날 경우 변경 계획이 열악함을 나타냅니다. |
변경 수락 비율 | CAB에서 승인한 변경의 퍼센트 | 이 수치는 변경 요청과 변경 계획의 효과성을 나타냅니다. 수치가 높으면 변경과 계획 수립이 견고하다는 의미입니다. |
예약 분산 | 소비된 시간과 추정 시간 사이의 편차 | 이것은 변경이 제 시간에 실행되었는지 그리고 변경 계획을 준수했는지 여부를 보여줍니다. |
변경에 의해 유발된 사건의 수 | 특정 변경에 의해 유발된 사건의 수 | 이것은 변경이 다른 서비스 운영에 영향을 주었는지 여부를 보여줍니다. 숫자가 높은 경우 변경을 더 잘 전달해야 함을 나타냅니다. |
제 시간에 완료된 변경의 퍼센트 | 제 시간에 완료된 변경의 퍼센트 | 이것은 변경 프로세스가 최적의 효율성으로 작동하고 있는지 여부를 보여줍니다. 퍼센트가 높을수록, 변경관리 프로세스가 잘 작동되고 있음을 알 수 있습니다. |
사용 사례
변경관리 프로세스를 어떻게 개선시킬 수 있는지를 알아보기 위해 변경에 대해 상세히 살펴보겠습니다.
원격 사용자가 굉장히 많은 기업인 Zylker는 클라우드 경로를 취하기로 결정합니다.
현재 이 기업의 모든 생산성 애플리케이션과 리소스는 사내에 있으므로, 원격 사용자들에게는 네트워크에 액세스하도록 VPN 액세스 권한이 주어집니다. 데이터에 대해 더욱 빠른 액세스를 제공하기 위해, Zylker는 클라우드 애플리케이션을 사용하기로 결정합니다. 생산성 제품군으로는 Zoho One을 이메일로는 Office 365를 선택합니다. 파일 서버와 데이터베이스 같은 리소스의 일부는 여전히 사내에 있으므로, 원격 사용자들은 이러한 리소스에도 액세스할 수 있어야 합니다.
이러한 요구사항을 충족하기 위해, IT 팀은 하이브리드 Azure Active Directory (AD) 환경을 설정합니다. 이들은 페더레이션 서버를 제공하여 클라우드 기반 Azure AD에 온-프레미스 AD를 복제합니다. 이제 최종 사용자는 원격 사용자라 할지라도, 자신의 AD 자격증명으로 클라우드 리소스에 액세스할 수 있습니다.
1단계: RFC 제기
첫 번째 단계는 변경 티켓을 제기하고 변경 유형, 변경의 영향, 긴급성과 변경 역할과 같은 필요한 정보를 수집하는 것입니다. 변경 개시자는 웹 포털을 사용하여 손쉽게 변경 티켓을 제기한 다음 타당한 변경 템플릿과 변경 유형을 고를 수 있습니다. 변경 템플릿은 필수 필드를 통해 필요한 모든 정보를 수집합니다. 여기서, 변경 개시자는 변경 유형을 통상적으로 설정한 다음, 적합한 변경 템플릿을 선택하고, 변경 역할을 할당한 후, 왜 해당 변경이 필요한지에 대한 이유를 설명합니다.
2단계: 변경 계획
다음으로, 변경 개시자는 변경에 대한 이유, 그 영향에 대한 상세 정보, 출시 및 철회 계획과 예정된 다운타임과 같은 변경 정보를 추가합니다. 또한 변경 개시자는 연계된 모든 사건과 문제를 추가하여 변경과 그 영향을 더 잘 추적할 수 있습니다. 다음은 변경 개시자가 제시할 수 있는 다양한 계획입니다.
출시계획:
- Azure AD와 Office 365 계정 확보
- ADFS (Active Directory Federation Services) 설정
- 온-프레미스 AD와 Azure AD 사이의 동기화 개시
- 싱글 사인온 구성
- 온-프레미스 Exchange와 Office 365 동기화
철회 계획:
기존의 구성이 온전하므로, 이전의 구성으로 복구하여 서비스를 재개합니다.
예정된 다운타임: 12시간
3단계: 올바른 승인 획득
변경 관리자는 CAB를 구성하여 변경 계획을 검토하고 변경 실행 여부 또는 계획 수정 여부에 대한 조언을 제공합니다. 이것은 대규모 변경이므로, 다양한 기능에 걸쳐 여러 업무 역할의 승인이 필요합니다. 다음은 승인 프로세스에 관여하는 CAB와 구성원의 목록입니다.
- 임원급 CAB:
- 최고정보책임자(CIO)
- 최고기술책임자(CTO)
- 최고재무책임자(CFO)
- 최고경영자(CEO)
- 기술 CAB:
- 서비스 전달 관리자
- 운영관리자
- 정보보안관리자
- 데이터 보호 사무관
- 비즈니스 CAB:
- 비즈니스 행정관리자
- 인적자원관리자
- 비즈니스 관계관리자
4단계: 변경을 바로 실행
Zylker는 작업을 활용하여 실행을 추적합니다. 작업은 다양한 테크니션들에게 할당되며, 그들이 완료해야 하는 주문은 작업 종속성을 사용하여 정의됩니다. 변경 소유자는 변경 실행의 진도를 쉽게 추적할 수 있고 한 장소에서 모든 작업을 관리합니다.
다음은 Zylker가 실행을 작업별로 세분하여 변경의 실행을 쉽게 추적하고 관리한 방법을 보여줍니다.
- Office 365 및 Azure AD 준비
- 인제스트 서버 설치
- 데이터 마이그레이션 개시
- Azure AD 프록시 구성
- 데이터 무결성 확인
5단계: 계획 준수
다음으로, 변경 소유자/관리자가 변경 실행을 검토하여 계획으로부터 편차가 있는지를 확인합니다. 변경을 성공적인 것으로 간주하기 전 모든 편차를 보고하고 수정합니다.
6단계: 변경 티켓 종결
마지막으로, 변경이 종결되며 변경 종결의 성격에 따라 종결 코드를 할당합니다.
7단계: 메트릭스 집합
변경 관리자는 특정 KPI를 측정하여 변경 프로세스가 얼마나 효율적인지를 확인하고 개선할 수 있는 영역을 파악합니다.
변경관리 기능 체크리스트
다음은 서비스 데스크 도구를 선택할 때 눈여겨 보아야 할 기능의 목록입니다. 이 기능을 확보함으로써 조직 내에서 효과적인 변경관리 프로세스를 실행하는 데 도움이 됩니다.
변경 관리
변경 생성 및 기록
- 사건과 문제로부터 변경을 생성하고, 필요한 정보를 이월합니다.
- 사용자 지정 변경 템플릿으로 필수 정보를 수집합니다.
- 다양한 변경 유형을 만들고 각 유형에 대해 고유의 워크플로를 수립합니다.
- 변경 역할을 사용하여 변경 소유자, 승인자, 라인 관리자 및 변경 검토자와 같은 올바른 이해관계자를 참여시킵니다.
변경 계획 및 평가
- 영향 분석과 출시, 철회 및 다운타임 계획을 특징으로 하는 정교한 변경 계획을 만듭니다.
- 완료해야 할 필수 단계의 체크리스트 유지.
변경 승인
- 다수의 CAB로부터.
- 다수의 승인 레벨 구성. RFC를 CAB의 모든 구성원 또는 한 명의 구성원이 승인해야 되는지 여부를 표시.
- 변경 관리자가 변경의 승인에 대해 최종 결론을 내리도록 허용.
- 모든 CAB 구성원이 권장할 때 해당 변경을 자동 승인함으로써 변경 관리자와 변경 승인자로부터 승인 패스.
- 최종 사용자를 서비스 요청 승인자로 표시.
변경 실행 조정
- 변경을 작업으로 세분하고, 작업 기록을 사용하여 변경 실행팀이 활동을 완료하는 데 얼마나 오래 걸릴 지를 추정함.
- 변경으로부터 프로젝트를 만들거나 변경을 기존 프로젝트에 연계시킴으로써 실행을 간결화.
- 변경을 유발하거나 변경으로 유발되는 모든 연계된 사건과 문제들을 추적함.
- 다운타임을 예약하고 이를 주요 이해관계자들에게 발표함.
- 이해관계자들이 정기 통보로 루프 내에 있게 함.
변경 검토 및 종결
- 실행 후 검토 (PIR) 문서화.
변경 워크플로
- 여러 수준의 복잡성과 기능으로 다양한 변경 유형 및 프로세스에 따라 구별되는 워크플로를 만듭니다.
- 단계 간의 이전 중에 조건, 스위치, 통보, 필드 업데이트 및 승인과 같은 다양한 동작을 구성합니다.
- 드래그 앤 드롭 캔버스에 변경 워크플로를 작성합니다.
효과적인 변경 관리에 대한 모든 상자에 체크 표시하십시오
용어집
변경:
서비스에 직간접적 영향을 줄 수 있는 것의 추가, 수정 또는 제거.
변경 권고 위원회(CAB):
변경에 관한 권고를 제공하고 변경 계획을 승인하는 다양한 이해관계자의 팀.
변경 충돌:
두 가지 이상의 변경이 우연하게 동시에 실행되도록 계획되어, 한 쪽의 변경 이행에 지장을 주는 경우.
변경 관리:
최소한의 혼란과 충돌로 변경을 완료하는 프로세스.
변경 역할:
조직 내 다른 구성원에게 변경의 다양한 측면에 대한 책임감을 위임하는 것.
종료 코드:
실패하거나 성공한 변경 종료의 성격을 기록하는 데 사용됨.
구성관리데이터베이스(CMDB):
모든 구성 항목과 그 관계의 저장소.
지속적인 서비스 개선:
서비스를 더 좋게 만들 수 있도록 개선할 수 있는 영역을 파악하고 교정하는 프로세스.
다운타임:
특정 서비스를 이용할 수 없는 기간.
사건:
IT 서비스에 대한 계획되지 않은 방해나 IT 서비스의 수준 감소. 서비스에 영향을 미치지 않는다 할지라도 항목 구성의 실패 또한 사건임(예: 미러 세트 중 하나의 디스크 오류).
문제:
하나 이상의 사건을 유발한 원인 또는 잠재적 원인.
구현 후 검토:
변경 계획이 편차 없이 준수되었는지 여부를 평가하고 변경이 필요한 것이 있는지를 알기 위해 실행을 조사하는 프로세스.
변경 요청(RFC):
타당한 이유로 변경을 개시하는 절차.
위험 평가:
변경에 관여된 잠재적인 위험을 평가하는 프로세스.
서비스 데스크:
서비스 제공사와 조직의 사용자 간의 커뮤니케이션 포인트.