IT 지원 워크플로를 개선하는 방법
IT 변경 관리의 진화
변경 관리(변경 인에이블먼트라고도 함)는 중요한 시스템 및 서비스를 변경하는 동시에 IT 서비스에 대한 중단을 최소화하도록 설계된 IT 관행입니다.
변경은 서비스에 직간접적인 영향을 미칠 수 있는 항목을 추가, 수정 또는 제거하는 것입니다.
변경 관리 관행은 인시던트를 줄이고 규제 표준을 충족하도록 설계되었습니다. 이러한 관행을 통해 IT 인프라 및 코드에 대한 변경 사항을 효율적이고 신속하게 처리할 수 있습니다. 새로운 서비스를 롤아웃하든, 기존 서비스를 관리하든, 코드의 문제를 해결하든, 최신 변경 관리 접근 방식은 사일로를 허물고, 컨텍스트와 투명성을 제공하며, 병목 현상을 방지하고, 위험을 최소화합니다.
위험 관리는 “조직이 위험을 파악하고 효과적으로 처리”하도록 하는 ITIL 4 관행과 관련이 있습니다. 변경 및 위험 관리 모두 감사 가능한 기록을 제공할 수 있도록 변경을 추적하고 연결해야 합니다. 이전 변경 사항 및 성공률에 대한 데이터를 활용하는 기능을 통해 조직은 위험과 속도의 균형을 현명하게 조정하는 방식으로 관행을 조정할 수 있습니다.
조정 가능한 데이터 기반 관행은 종종 불필요하게 느리고 프로세스가 무거우며, 과중한 부담이 될 수 있는 기존 변경 관리와 달리 효율성을 추구하기 위해 노력합니다. 변경 관리는 위험 및 컴플라이언스, 감사 가능성 및 교차 팀 조정과 관련된 문제를 다루기 때문에 마찬가지로 너무 복잡하고 관료적이며 어려울 수 있습니다.
그러나 꼭 그런 식일 필요는 없습니다. 변경 관리를 ITSM의 “채소 먹기” 버전이라고 생각하세요. 항상 식욕을 돋우는 음식은 아니지만 매우 중요합니다. 올바른 관행과 문화를 갖춘 변경 관리는 인시던트 및 팀의 스트레스를 줄이며 고객에게 가치를 제공하는 데 더 많은 시간을 할애할 수 있도록 합니다.
변경 관리 정의
변경 관리에 대해 생각할 때 기술, 직원 및 프로세스에서 고객 및 시스템에 미치는 영향에 이르기까지 변경의 모든 측면을 정의할 수 있습니다. ITSM의 컨텍스트에서 명확성을 제공하기 위해 ITIL 4는 IT 변경 관리와 조직 변경 관리 관행을 구분했습니다.
- 조직 변경 관리는 “조직의 변경 사항이 원활하고 성공적으로 구현되고 변경의 인간적 측면을 관리하여 지속적인 이익을 얻을 수 있도록 하는 관행”입니다.
그런 다음 ITIL 4는 이전의 변경 관리 프로세스를 “변경 제어” 관행으로 다시 정의했습니다.
- 변경 제어 관행은 “성공적인 서비스 및 제품 변경 횟수를 극대화하기 위해 위험을 적절하게 평가하고 변경을 진행하도록 승인하며 변경 일정을 관리"하도록 합니다.
이 새로운 명칭은 많은 IT 팀이 “제어”와의 연관성을 부인하면서 논란을 불러일으켰습니다. 누군가에게는 "제어"가 기존의 변경 관리가 만들어낸 것으로 악명 높은 관료주의, 병목 현상 및 불필요한 단계를 연상시키는 부적절한 단어입니다.
Axelos는 이러한 피드백을 듣고 응답했습니다. “ITIL 4 Foundation이 릴리스된 후 전 세계 여러 이해 관계자들로부터 “관행이 '변경의 속도를 제어'하는 것이 아닌 '변경 제어' 또는 '팀 제어'에 초점을 맞춘 것으로 잘못 해석되거나 오해되고 있다”는 의견을 들었습니다.
ITIL은 결국 이 관행을 “변경 인에이블먼트”라고 부르기로 했습니다. 이 새로운 명칭은 팀을 지원하여 변경을 진행할 수 있는 능력과 자율성을 제공하는 관행을 의미합니다.
결국 사용하는 용어가 특별히 중요하다고 생각하지는 않습니다. (이 문서와 Atlassian에서는 이를 변경 관리라고 합니다.) 중요한 것은 접근 방식입니다. 우수한 팀과 적합한 문화로 시작한다면 조직은 효과적인 변경 관리 관행을 만들기 위한 올바른 방향으로 나아갈 수 있습니다.
변경 관리와 릴리스 관리 간의 관계
릴리스 관리는 변경 관리에 관해 이야기할 때 중요한 또 다른 관행입니다. ITIL 4에 따르면 “릴리스 관리의 목적은 새롭고 변경된 서비스와 기능을 사용할 수 있도록 하는 것”입니다. 릴리스에는 소프트웨어 기능 변경부터 설명서 및 교육 업데이트에 이르기까지 모든 것이 포함될 수 있습니다.
지금까지 릴리스 관리는 변경 사항을 함께 번들로 묶어 고객에게 패키지로 제공했습니다. 기존 릴리스 관리는 엄격한 프로젝트 관리 표준을 유지하며 고객에게 중요한 업데이트를 제공하는 데 마찰을 일으켜 애자일 원칙을 준수하는 팀 사이에 불만을 초래할 수 있습니다.
DevOps 컨텍스트에 맞게 릴리스 관리를 다시 구상할 수 있습니다. 릴리스 관리는 기존의 프로젝트 관리 기능에서 벗어나 통합과 자동화가 중심이 되어야 합니다. 가능한 경우 자동화된 검토를 통합하고 추적 및 감독을 제공하는 보안 시스템에 코드 파이프라인을 도입하는 것으로 시작합니다. 이를 통해 과거의 사일로화된 접근 방식을 허물고 원활한 프로덕션 경로를 제공할 수 있습니다. 릴리스 관리는 그 어느 때보다 쉽게 지속적으로 가치를 제공하고 “직접 구축, 직접 소유”라는 원칙을 적용하는 것입니다.
IT 변경 관리가 중요한 이유는 무엇입니까?
최신 조직은 IT 팀에 대해 몇 가지 중요하고 경쟁적인 기대치를 가지고 있습니다. 첫째, 조직의 생산성과 최종 사용자의 기대치를 충족할 수 있는 안정적이고 신뢰할 수 있는 서비스를 기대합니다. 둘째, IT 팀은 조직이 지속적으로 변화하는 보안, 비용 및 비즈니스 요구 사항에 적응할 수 있도록 정기적인 서비스 업데이트를 구현해야 합니다.
둘 중 하나라도 수행하지 않으면 심각한 결과를 초래할 수 있습니다. 신뢰할 수 있는 서비스를 유지하지 못하면 생산성과 비용에 막대한 피해를 줄 수 있습니다. Gartner에 따르면 많은 조직에서 가동 중지 시간 비용이 시간당 30만 달러를 넘는다고 보고했습니다. 일부 웹 기반 서비스의 경우 이 수치가 훨씬 더 높을 수 있습니다.
동시에 미래에 적응하지 못하는 조직은 비즈니스 속도를 따라가지 못하고 경쟁에서 뒤처지게 될 것입니다. 변경 사항을 너무 느리게 배포하면 직원은 시스템이 덜 복잡한 곳에서 일하려고 이직하거나, 고객은 더 많은 가치를 제공하는 다른 조직에 지원하고 투자하게 될 수 있습니다.
그렇다면 이렇게 상충하는 요구 사항을 어떻게 관리해야 할까요? 조직은 변경 관리 관행을 통해 안정성을 보장하고 위험을 완화하면서 업데이트를 제공할 수 있습니다. 변경 관리는 다음과 같은 방법으로 변경을 수행하는 데 도움이 됩니다.
- 변경 프로세스를 관리하기 위한 프레임워크 구축
- 리소스를 적절히 할당하기 위해 필요한 변경의 우선 순위 지정
- 더 현명한 의사 결정을 위한 관련 정보 통합
- 승인을 위해 개발 및 IT 팀의 필수 이해 관계자 참여
- 인시던트 방지를 위해 변경 테스트 통합
- 보다 신속하게 가치를 제공하기 위해 변경 흐름 간소화 및 개선
변경 유형
ITIL은 변경을 세 가지 유형으로 정의합니다.
표준 변경
표준 변경은 위험이 적고 일반적으로 반복되며 사전 승인된 변경입니다. 자주 수행되며 문서화되어 승인된 프로세스를 따릅니다.
예를 들어 메모리 또는 스토리지 추가가 표준 변경에 해당합니다. 장애가 발생한 라우터를 동일한 정상 작동 라우터로 교체하는 것, 데이터베이스의 새 인스턴스를 만드는 것도 표준 변경입니다.
이러한 모든 변경은 일반적이며 잘 정의된 프로세스를 따릅니다. 그리고 이 프로세스는 이미 변경 관리의 위험 평가 및 승인 프로세스를 한 번 거쳤기 때문에 라우터를 교체해야 할 때마다 프로세스를 다시 진행할 필요가 없습니다.
많은 회사에서 표준 변경은 자동화를 위한 최고의 기회입니다. 일부 회사에서는 표준 변경의 최대 70%를 자동화할 수 있으며 이를 통해 팀이 일반 및 긴급 변경에 집중할 수 있다고 보고합니다.
일반 변경
일반 변경은 정의된 및 사전 승인된 프로세스가 없는 긴급하지 않은 변경입니다.
예를 들어 새 콘텐츠 관리 시스템으로 업그레이드하는 것은 일반 변경입니다. 새 데이터 센터로 마이그레이션하는 것, 그리고 성능 개선도 일반 변경에 해당합니다. 이러한 변경은 표준이 아니며 반복 가능하지 않습니다. 위험이 수반되지만 긴급하지는 않습니다. 즉, 위험 평가 및 승인을 위해 일반적인 변경 관리 큐로 이동할 수 있습니다.
데이터 센터 전환과 같은 일부 일반 변경에 대한 위험은 높으며 위험 평가 및 CAB(변경 자문 위원회)의 승인이 필요할 수 있습니다. 웹 사이트 변경과 같은 기타 변경은 위험이 낮을 수 있으며 지정된 변경 권한자 또는 자동 확인 및 동료 검토를 통해 더 빠른 일정에 따라 승인받을 수 있습니다.
긴급 변경
이러한 변경은 예상치 못한 오류나 위협으로 인해 발생하며, 일반적으로 고객 또는 직원을 위한 서비스를 복원하거나 위협으로부터 시스템을 보호하기 위해 즉시 해결해야 합니다.
예를 들어, 보안 패치를 구현하는 것은 긴급 변경입니다. 서버 중단에 대처하는 것, 그리고 주요 인시던트를 해결하는 것도 긴급 변경입니다.
긴급 변경의 긴급성으로 인해 이슈를 빠르게 해결하는 데 따르는 위험보다 긴 검토 프로세스에 따른 위험이 더 높기 때문에 훨씬 더 촉박한 일정으로 처리해야 합니다.
변경을 분류하는 방법은 조직, 프로세스 및 위험 허용 범위 등의 요소에 따라 다릅니다. Atlassian은 천편일률적인 접근 방식을 버리고 위험 평가에 따라 각 변경을 다르게 처리할 것으로 주장합니다. 조직에서 이전 인시던트, 특정 시스템에 대해 자세히 알아보고 기타 관련 데이터를 통합하면 더 많은 변경을 표준으로 지정하고 사전 승인할 수 있습니다. 최신 변경 관리를 사용하면 변경 요청을 최대한 간소화하여 간단하게 만들 수 있습니다.
CAB(변경 자문 위원회)란 무엇입니까?
대부분의 기존 IT 조직에서 CAB(변경 자문 위원회)는 각 변경의 위험을 평가하고 승인 또는 승인하지 않는 임무를 맡고 있습니다. 일반적으로 CAB는 예정된 모든 변경을 검토하기 위해 정기적으로 회의를 열고 필요에 따라 전문가를 초빙하여 변경에 대해 설명, 변호 또는 평가합니다.
한편으로 변경 자문 위원회는 변경이 회사에 도움이 되지 않을 때 위험을 줄이고 알림을 제기하는 데 도움이 될 수 있습니다. 반면에 병목 현상을 불러일으킬 수도 있습니다. 특히 배포할 변경 사항에 관해 잘 모르는 직원들로 구성된 경우 더욱 그렇습니다. 많은 엔터프라이즈에서 CAB(변경 자문 위원회) 승인 프로세스는 복잡하고 시간이 많이 걸리므로 변경 프로세스가 느려집니다.
많은 IT 팀이 기존의 CAB 회의에서 벗어나거나 범위를 가장 위험한 변경 및 중요한 조직 문제로 제한하고 있습니다. 이 패러다임에서 CAB는 추세를 모니터링하고, 관행이 해결할 수 있는 방법에 대해 조언하며, 팀과 요구 사항 간의 조정을 담당하는 신뢰할 수 있는 자문가가 될 수 있습니다.
ITIL 4는 또한 변경 권한을 비즈니스 이해 관계자 또는 동료 수준으로 분산하도록 권장합니다. 별도의 위원회를 사용하는 대신 변경 관리를 관련 이해 관계자와 함께하는 일반적인 워크플로로 구축하세요. 병목 현상을 방지하려면 자동화, 가상 체크리스트 및 동료 검토를 보다 민첩하고 협업적인 대안으로 활용하세요.
변경 관리 프로세스
변경 관리 프로세스는 민첩하고 빠른 속도의 팀을 위해 긴 검토 및 기술 팀 이외의 이해 관계자 승인에서 벗어나, 애질리티를 높이는 동시에 위험의 균형을 유지해 주는 IT 팀과 개발 팀 간의 자동화된 협업 프로세스로 전환합니다.
다음은 가치 제공 속도를 높이기 위한 몇 가지 권장 사항을 포함하여 변경 관리 프로세스에 대한 기본 개요입니다.
변경 관리 모범 사례
앞서 언급했듯이 변경 관리는 잎이 많은 채소를 먹는 것에 대해 느끼는 것과 비슷한 두려움을 불러일으킵니다. 채소 요리를 항상 기대하는 것은 아니지만 얼마나 중요한지는 알고 있습니다. 이 두 가지를 모두 더 매력적으로 만들기 위한 조치를 취할 수 있습니다.
최신 변경 관리를 위한 몇 가지 모범 사례는 다음과 같습니다.
- 조직의 위험 허용 범위 및 규제 의무 파악
- 가능한 경우 변경 관리 프로세스 간소화 및 자동화
- CAB에 보다 전략적인 초점 제공
- 표준 변경을 새로운 일반 변경으로 만들기 위한 관행 수용
- ITIL 및 DevOps와 같은 다양한 프레임워크를 살펴보고 조직에 가장 적합한 가이드라인 찾기
- 협업에 우선 순위 두기
- 카오스 엔지니어링을 사용하여 위험 감소
- IT 및 개발자 팀의 변경 요청 접수 간소화
- 변경 메트릭 및 KPI로 학습 활용
- 릴리스 관리에 대한 DevOps 기반 접근 방식 수용
변경 관리의 문제 해결
개발자는 수동적인 문서화에 추가 시간과 노력을 들이지 않고 코드를 빠르게 배포하기를 원합니다. IT 운영 팀은 위험을 줄이고 감사를 위한 세부 기록을 유지하며 인시던트를 방지하기 위해 노력합니다. 개발자에게 프로세스에 단계를 추가하고, 문서화하며, 출퇴근 시간을 기록하도록 요청하면 그들은 업무의 궁극적인 목표에서 벗어났다고 느낄 수도 있습니다. 운영 팀에 기존 프로세스를 점검하여 승인 확인 절차를 없애고 더 많은 것을 자동화하도록 요청하는 것은 쉽지 않으며 더 많은 위험을 초래하는 것처럼 느껴질 수 있습니다.
한편, 위험성은 그 어느 때보다 높습니다. 소프트웨어 기반 서비스의 등장으로 고객의 기대치가 높아졌고 상시 연결되는 높은 성능의 서비스에 대한 수요도 늘어났습니다. 점점 더 역동적인 환경에서 서비스를 관리하는 데 필요한 작업은 계속 증가하고 있습니다.
그렇다면 이러한 문제를 어떻게 극복할 수 있을까요? 프로세스가 무거울수록 위험을 줄인다는 오해부터 바로잡는 것이 좋습니다. 그런 다음 팀이 협업하고 제공하는 데 도움이 되는 문화, 적절한 관행 및 도구를 수용합니다. 마지막으로 정보를 지속적으로 통합하여 이전 단계의 가치를 입증하고 계속해서 개선하려고 노력해야 합니다.
Jira Service Management가 변경 관리 프로세스를 어떻게 혁신할 수 있는지 알아보시겠습니까?