변화 관리란 무엇인가?

ITIL 4 변경 관리란 ITIL 재단에서 정한 일련의 지침을 말합니다. 이 지침은 조직이 디지털 제품 변경을 관리하는 데 도움이 됩니다. 최소한의 마찰이나 위험.

ITIL 4는 1989년에 첫 번째 버전이 발표된 이후, 이 지침의 네 번째 개정판입니다! 조직이 따라야 할 구체적인 프로세스를 정의했던 ITIL 3와 달리, ITIL 4는 유연한 지침을 제공하는 것을 목표로 합니다. 중요한 점은 조직이 ITIL 4 지침과 완벽하게 호환되는 동시에 ITIL 3에 설명된 특정 프로세스를 채택할 수 있다는 것입니다.

ITIL 4 변경 관리 권장 사항은 주로 IT 운영에서 발생하는 주요 개념과 역할에 대한 구체적인 정의를 제공합니다. 설명된 개념은 회사의 실제 구조와 관계없이 보편적으로 적용될 수 있도록 일반화되었습니다. 이는 조직이 ITIL 4에서 정립된 변경 관리 프레임워크를 염두에 두고 자체적인 프로세스와 관행을 개발하도록 하는 것을 목표로 합니다.

ITIL 4의 권장 사항을 함께 사용 변화 위험 예측 분석 제품 팀이 전반적으로 위험이 낮은 변경을 시작하도록 안내하는 동시에 출시 속도를 크게 높일 수 있습니다. 다음을 통해 위험을 미리 파악하세요. Digital.ai Intelligence.

변화 관리에 ITIL 4를 사용하는 이유는 무엇입니까?

변경은 어떤 범주에 속하든 일상적인 IT 운영의 표준적인 부분입니다. 수십 년 전에는 변경 사항이 1년에 몇 번 또는 그 이하로 발생하는 드문 패치 이벤트나 구성 업데이트로 분류되었습니다. 하지만 이제 세계에서 가장 인기 있는 애플리케이션, 서비스 및 플랫폼 중 일부는 매년 수천 건의 변경 업데이트를 받습니다. 구글은 2018년에 다음과 같은 유명한 보고서를 발표했습니다. 그 해에만 검색 엔진 알고리즘을 3,000개 이상 변경했습니다.하루 평균 9개 정도입니다.

이처럼 엄청난 변화가 빠른 속도로 일어나고 있는 상황에서, IT 조직은 서비스 중단 위험을 최소화하기 위해 변화를 통합하고 배포할 수 있는 체계적인 방법이 필요합니다. 동시에 IT 운영 책임자는 변화의 속도를 저해하는 모든 장애물을 제거해야 합니다. 불필요한 지연이나 게이트키핑은 가치 생산 사슬을 방해합니다.

이것은 역설을 제시합니다. 우리는 변화를 구현해야 합니다. safe 이전보다 훨씬 빠른 속도로.

최근 업데이트된 ITIL 변경 관리 프로세스는 이러한 난제를 해결하고자 합니다. ITIL 4 변경 관리의 주요 목표는 운영 지표 및 기타 변경 위험 관리 목표에 대한 효율적인 통제력을 유지하면서 변경 배포를 가로막는 모든 장벽을 제거하는 것입니다. 이러한 취지에서 ITIL 4는 규범적인 변경 관리 프로세스를 엄격하게 정의하는 대신, 변경 지원 프레임워크를 제안합니다.

ITIL 4의 이상을 채택하고 이를 현재 조직 환경에 가장 적합하도록 맞춤화함으로써 IT 운영팀은 비효율성과 파괴적 위협을 최소화하면서 변화의 속도를 높일 수 있습니다.

ITIL 4는 변경 관리를 덜 번거롭게 만드는 것을 목표로 합니다.

1980년대 후반에 처음 발표된 ITIL의 초기 버전은 조직의 IT 관련 활동에 예측 가능성과 체계성을 부여할 수 있는 프로세스를 엄격하게 매핑했습니다. 이 지침은 IT 요구 사항이 익숙하지 않거나 예측 불가능하게 이어지는 기업에 매우 중요했습니다. 새로운 기술에 익숙하지 않은 환경에서 탄생한 이 지침은 기업과 정부 기관 모두 이러한 수준의 구체적인 지침을 간절히 원했습니다.

그러나 2000년대 초, 소프트웨어 개발 방법론에 큰 변화가 일어났습니다. 바로 애자일(Agile)입니다. 애자일은 엄격한 "폭포개발 프로세스가 폐지되었습니다. 이를 통해 개별 개발팀은 최종 결과에 대한 자율성과 통제력을 더욱 강화할 수 있었으며, 이는 훨씬 짧은 기간 안에 달성될 수 있었습니다.

애자일은 애플리케이션과 기술 플랫폼이 최종 사용자에게 가치를 더하기 위해 각각의 새로운 변경 사항을 보장하기 위한 노력이 투입되는 한 지속적으로 진화할 수 있다는 아이디어를 대중화했습니다.

Agile 방법론의 증가에 대응하여 (및 DevOps 이후), ITIL은 적응해야 했습니다. ITIL v3는 기존 ITIL 변경 프로세스를 기반으로 지속적인 변경 구현 모델을 개발했으며, 많은 조직이 다음 단계를 따랐습니다.

1. 변경 요청(RFC) 생성
2. RFC 검토
3. CAB(변경 자문 위원회)가 RFC를 평가하고 평가하도록 합니다.
4. RFC에 따라 변경 사항 승인
5. 계획 업데이트
6. 좌표 구현
7. Deploy/새로운 변경 사항 통합
8. 변경 사항을 검토하고 변경 기록을 닫습니다.

이 버전의 ITIL 변경 관리 프로세스는 신뢰성과 반복성이 뛰어나고, 변경 제안의 결과에 대해 상당한 통제력을 발휘했습니다. 하지만 일부 조직에서는 여전히 상당히 번거로웠습니다.

지속적인 CAB 검토는 변경을 지연시키고 상당한 비효율성을 초래할 수 있습니다. 결과적으로 각 변경으로 창출되는 가치가 저하됩니다.

이러한 단점을 해결하기 위해 새로운 ITIL 4 프레임워크는 비표준으로 간주되는 특정 변경 사항에 대해서만 엄격한 "제안 > 승인 > 구현 > 완료" 모델을 적용하도록 제안했습니다. 따라서 ITIL 4 프레임워크는 이전 버전에서 익숙한 "일반적인" 변경 관리 프로세스를 위한 여지를 남겨두는 동시에, IT 운영 책임자들이 가능한 한 많은 변경 사항을 다른 범주, 즉 표준 변경 사항으로 이전하도록 권장합니다.

ITIL의 표준 변경 모델을 사용하여 변경 속도 가속화

ITIL v3에는 "표준 변경"으로 설명된 제안된 변경 사항 범주가 있었습니다. 이러한 변경 사항은 위험도가 낮은 것으로 간주되었으며, 해당 IT 환경에서 자주 발생했습니다. 제공된 예 비밀번호 변경, 신규 채용 절차, 물리적 장비 이전 등이 포함되었습니다.

ITIL 4를 통해 ITSM 리더들은 조직이 표준 변경을 "정상적인 변경"에 대한 특별한 예외가 아닌 표준으로 삼도록 노력할 수 있음을 인식하게 되었습니다. 이 표준은 변경 범주 또는 특정 변경 유형을 모델링함으로써 많은 상황에서 공식적인 게이트키핑과 CAB 승인이 더 이상 필요하지 않다고 제안합니다.

따라서 어떤 변경 사항이 실제로 "정상적인"(즉, "저위험") 것인지 파악하면 민첩성을 저해하는 대부분의 병목 현상을 제거할 수 있습니다. 고위험 변경 사항이 공식 RFC 프로세스에 도입되면 IT 운영 책임자도 해당 위험을 수용, 완화 또는 거부하기 위한 작업을 시작할 수 있습니다.

일반적인 변경 사항을 구현하는 프로세스는 이제 대부분 자동화될 수 있습니다. 즉, 개발팀에서 변경 사항을 제안하는 즉시(대개 IT 운영팀의 데이터 피드백에 대한 응답으로) 프로덕션 환경에서 테스트, 통합, 배포한 다음 거의 또는 전혀 사람의 개입 없이 종료할 수 있습니다.

따라서 표준 변경 사항은 일반적인 변경 프로세스를 반영하지만 RFC는 공식화된 CAB 검토 대신 저지연 프로세스를 통해 검토 및 승인됩니다.

위험을 관리하면서 변경을 가속화하기 위해 ITIL 변경 관리 프로세스 적용

원래 ITIL 3 변경 관리 프로세스의 각 단계는 본질적으로 속도나 유연성을 희생하지 않고도 보존될 수 있습니다.

업데이트된 ITIL 4 프레임워크에서 제안된 제안 조직의 변화 관리 프로세스를 적응시키려면 다음이 포함됩니다.

• 반복되는 변경에 대한 변경 모델 생성
• 표준 변경에 대한 변경 승인 분산
• 더 큰 변화를 위험이 덜한 작은 부분으로 나누기
• 자동화된 검사, 테스트 및 배포 사용

보다 공식적인 ITIL 변경 관리 프로세스의 각 단계에 대한 적응이 어떻게 반영될 수 있는지 살펴보겠습니다.

변경 요청

개별적으로 제안된 "일반" 변경 사항은 먼저 표준 변경 모델과 비교하여 변경 사항이 실제로 승인 절차를 피할 수 있는지 확인해야 합니다. "저위험"이고 사전 모델링된 변경 사항의 일부 특성을 포함하는 변경 사항은 분할하여 새로운 제안만 공식적으로 검토하고 표준 구성 요소는 사전 승인되도록 할 수 있습니다.

가능한 경우, IT 운영에서 도출된 데이터 피드백을 기반으로 변경 필요성에 따라 RFC를 자동으로 생성할 수 있습니다. 자동 생성된 RFC는 제안된 변경/기능 포트폴리오에 통합될 수 있습니다. 자동화된 RFC는 위험을 사전에 파악하고 해당 위험을 해결하는 것을 목표로 하므로 긴급 변경의 필요성을 줄여줍니다. 특히 사전 모델링된 표준 변경 사항을 최대한 준수하는 것이 좋습니다.

변경 평가
ITIL 4에 따르면, CAB 회의는 미리 정해진 주기나 표준 변경 절차의 일부로 예정되는 것이 아니라 특수한 상황을 해결하기 위해 소집되어야 합니다. 단일 변경 관리자 역할만으로도 변경의 위험이나 영향을 평가하기에 충분할 수 있으며, 이러한 판단은 다음과 같은 요소들을 보완할 수 있습니다. AI 기반 분석표준 변경 사항은 대부분 또는 전체적으로 자동화된 프로세스를 통해 평가될 수 있으며, 이를 통해 검토해야 할 사항들이 쌓이는 것을 방지하고 지연 시간을 크게 줄일 수 있습니다. 공식적인 승인이 필요한 일반적인 변경 사항은 새로운 표준 변경 모델의 기반이 되거나, 기존 표준 변경 모델을 더 광범위한 범위에 맞게 업데이트하는 데 도움이 될 수 있습니다.

변경 권한
ITIL 4의 민첩성 중심 변경 지원 프레임워크의 주요 목표는 변경 승인의 필요성을 최대한 줄이는 것입니다. 변경 모델링을 통해 대부분의 경우 즉각적인 승인이 가능하며, 분석을 활용하여 변화 위험 평가 인간의 주도로 이루어지는 정상적인 변경 승인 과정을 덜 번거롭고 덜 연구적으로 만들 수 있습니다.

계획 변경
변경 분석을 활용하면 변경 일정 및 빌드 승인 과정을 획기적으로 간소화하여 거의 완전한 자동화 수준까지 구현할 수 있습니다. 수동 일정 및 변경 빌드 계획은 가능한 한 최소화해야 합니다. 다시 말해, 변경 모델링을 통해 특별한 주의가 필요한 변경과 신속하게 계획하여 향후 릴리스 배포에 반영할 수 있는 변경을 분리함으로써 불확실성을 제거할 수 있습니다.

Deploy/새로운 변경 사항 통합
덕분에 Release 관리 도구많은 기업에서 변경 사항 배포 및 통합이 대부분 자동화되었습니다. "일반적인" 저위험 변경 사항은 우선순위를 정해야 하므로 대부분의 변경 사항에 수동 배포나 통합이 필요하지 않습니다. 주의가 필요한 변경 사항은 배포 후에도 모니터링할 수 있으므로, 일부 위험한 변경 사항에 대해서는 직접적인 인적 감독이 필요하지 않습니다.

변경 사항을 검토하고 변경 기록을 닫습니다.
포괄적인 변경 완료의 중요성을 간과해서는 안 됩니다. 이는 예상치 못한 문제와 중단을 효과적으로 줄이는 것으로 나타났습니다. 그러나 이 원칙이 IT 조직이 각 변경 사항이 안정적이고 필요한 문서에 정확하게 반영되었는지 확인하기 위해 번거로운 수동 검토 프로세스를 도입해야 한다는 것을 의미하지는 않습니다.

변경 완료는 소규모 조직에서도 자동화에 가장 적합한 변경 관리 프로세스 단계 중 하나입니다. 자동화된 테스트 및 검토 "품질 보증" 역할을 수행하는 동시에, 자동화된 CMDB 업데이트 및 기타 변경 종결 작업을 통해 수동 변경 종결의 필요성을 줄여줍니다. 이러한 관행은 더욱 완전한 기록을 보장하고, 조직적 실수로 인해 CMDB 데이터 및 기타 주요 기록 시스템의 무결성에 영향을 미칠 위험을 줄여줍니다.

프로세스의 모든 단계에서 IT 분석을 통해 변경 배포를 가속화합니다.

인간은 창의적이며 뛰어난 문제 해결 능력을 갖추고 있지만, 컴퓨터만큼 수천 줄의 코드나 수백만 개의 데이터 항목을 빠르게 검토할 수는 없습니다. 분석은 이러한 기능을 제공하며, IT 생산성을 획기적으로 향상시키고 변경 검토 및 배포 프로세스의 민첩성을 높여줍니다.
AI와 ML 모델을 추가하면 인간의 눈으로는 볼 수 없는 데이터 패턴(예: 변경 위험 요소 또는 특정 변경으로 인해 성과에 파괴적인 영향이 발생할 가능성)을 자동으로 발견하여 IT 역량을 더욱 강화할 수 있습니다.

이러한 기능들은 우리가 매일 만들고 수정하는 기술을 관리하는 데 있어 기술이 얼마나 중요한 역할을 하는지를 보여줍니다. 변경 자동화는 현대의 변경 관리 관행에 본질적으로 필수적인 것은 아니지만, ITIL 지침에서는 이를 모범 사례로 간주하며, 속도가 몇 개월이 아닌 밀리초 단위로 측정되는 세상에서 필수적인 요소입니다.