빠른 속도의 팀을 위한 ITSM
팀이 변경 관리 역할 및 책임을 공유하는 방법
변경 관리 관행의 핵심 목표는 고객을 만족시키고 경쟁에서 앞서 나갈 수 있도록 업데이트를 제공할 때 인시던트를 줄이는 것입니다. 따라서 이 관행은 매우 중요합니다. 오늘날 고객들은 성능이 뛰어나고 상시 가동되는 서비스에 대한 높은 기대치를 가지고 있습니다. 점점 더 역동적인 환경에서 서비스를 신중하게 관리하고 개선 사항을 자주 제공하는 것이 중요합니다. 최신 팀은 위험을 완화하는 동시에 고객에게 최대한 간소화되고 애자일한 방식으로 가치를 제공하는 관행을 도입했습니다.
이러한 목표를 달성하기 위해 조직은 변경 관리와 관련된 다양한 역할과 책임을 지정했습니다. 대규모 엔터프라이즈에서는 다양한 직무 설명 및 팀 간에 이를 공유할 수 있습니다.
소규모 조직에서는 한 직원이 자신의 업무와 더불어 변경 관리 책임까지 맡을 수 있으며 개발자 또는 팀 리더가 변경 관리 책임을 맡을 수도 있습니다. 다른 경우에는 프로세스가 기존 팀 간에 느리게 구축되고 공유될 수 있습니다.
변경 관리 책임을 할당하는 데 적합한 하나의 모델은 없습니다. 조직은 요구 사항에 가장 적합한 설정을 마련해야 합니다. 즉, 모든 팀은 자신이 검토하는 프로젝트와 종종 거리가 먼 특정 직책을 가진 직원에게 변경 관리 책임을 위임하는 접근 방식을 다시 생각해 보는 것이 좋습니다.
기존 워크플로에 대한 관행을 자동화하고 간소화하는 새로운 기회를 받아들여 변경 관리에 관련된 직원들이 보다 전략적인 역할을 맡게 하고, 팀은 가장 중요한 우선 순위에 집중할 수 있는 시간을 확보할 수 있습니다.
일반적인 변경 관리 역할
변경 관리와 관련된 역할은 IT 조직의 규모 및 유형을 비롯한 다양한 요인에 따라 달라집니다. 가장 일반적인 직책은 다음과 같습니다.
변경 관리자/코디네이터
변경 관리자(변경 코디네이터라고도 함)는 일반적으로 IT 변경의 모든 측면을 관리하는 책임을 맡고 있습니다. 변경 요청의 우선 순위를 지정하고 그 영향을 평가하며 변경을 수락하거나 거부합니다. 또한 변경 관리 프로세스 및 변경 계획을 문서화합니다. 중요하게는 CAB 회의를 준비하고 구성하며 의장 역할을 합니다. 변경 관리자의 성공은 일반적으로 일정 및 예산 목표를 충족하는지 여부에 따라 평가됩니다.
변경 관리자/코디네이터
변경 관리자(변경 코디네이터라고도 함)는 일반적으로 IT 변경의 모든 측면을 관리하는 책임을 맡고 있습니다. 변경 요청의 우선 순위를 지정하고 그 영향을 평가하며 변경을 수락하거나 거부합니다. 또한 변경 관리 프로세스 및 변경 계획을 문서화합니다. 중요하게는 CAB 회의를 준비하고 구성하며 의장 역할을 합니다. 변경 관리자의 성공은 일반적으로 일정 및 예산 목표를 충족하는지 여부에 따라 평가됩니다.
변경 관리자/코디네이터
변경 관리자(변경 코디네이터라고도 함)는 일반적으로 IT 변경의 모든 측면을 관리하는 책임을 맡고 있습니다. 변경 요청의 우선 순위를 지정하고 그 영향을 평가하며 변경을 수락하거나 거부합니다. 또한 변경 관리 프로세스 및 변경 계획을 문서화합니다. 중요하게는 CAB 회의를 준비하고 구성하며 의장 역할을 합니다. 변경 관리자의 성공은 일반적으로 일정 및 예산 목표를 충족하는지 여부에 따라 평가됩니다.
변경 권한자/승인자
변경 권한자는 변경을 승인할지 여부를 결정하는 직원입니다. 관리자 또는 경영진과 같은 한 명의 직원인 경우가 있으며 때로는 변경 자문 위원회의 여러 직원이거나 동료 검토자가 될 수도 있습니다. ITIL 4에 따르면 “빠른 속도의 조직에서는 변경 승인을 분산시켜 동료 검토를 고성과를 예측하는 최고의 인자로 만드는 것이 일반적입니다.”
변경 관리자는 일반적으로 변경 권한자와 긴밀하게 협력하여 변경을 승인하고 조직 내에서 변경을 진행합니다. 일부 경우 특히 소규모 조직에서는 변경 관리자가 변경 권한자이며, 추가 인력이나 팀의 개입 없이 이러한 결정을 내릴 권한을 갖습니다.
비즈니스 이해 관계자
비즈니스 이해 관계자는 종종 변경 관리에 관여하며 승인 프로세스에 참여할 수 있습니다. 대부분의 엔터프라이즈에서 소프트웨어 서비스의 중요성을 감안할 때 이는 점점 더 보편화되고 있습니다.
예를 들어 변경이 재무 팀의 결제 추적 소프트웨어와 영업 팀의 CRM 간의 연결에 영향을 미치는 경우 재무 팀 및 영업 팀의 이해 관계자가 CAB 회의 및 변경에 대한 최종 결정에 관여해야 할 수 있습니다.
엔지니어/개발자
개발 팀은 일반적으로 승인을 받기 위해 변경을 제출하고 필요에 따라 사례를 문서화합니다. 직접 구축하고 직접 운영한다는 접근 방식을 취하는 회사에서는 변경이 승인되면 개발 팀이 변경 사항을 배포하고 모니터링하며 변경과 관련된 모든 인시던트 또는 문제에 응답하는 경우가 많습니다. 다른 경우에는 변경으로 인해 발생한 인시던트를 담당하는 인시던트 관리 팀이 변경 사항을 구현하는 개발자와 구분될 수 있습니다.
서비스 데스크 에이전트
서비스 데스크 에이전트는 변경으로 인해 발생할 수 있는 인시던트 및 일반적인 서비스 이슈에 대해 고유한 최전선 관점을 제시할 수 있습니다.
운영 관리자
운영 관리자는 매일 시스템을 계속 운영해야 할 책임이 있으므로 위험과 종속성을 고려합니다.
고객 관계 관리자
고객 관계 관리자는 고객의 목소리를 대변하기 위해 고객의 사고 방식, 불만 사항을 비롯해 끊임없이 변화하는 요구 사항에 대한 정보를 제공할 수 있습니다.
정보 보안 책임자 및 네트워크 엔지니어
네트워크 보안 및 클라우드 인프라 전문가는 위협과 취약성에 대한 중요한 인사이트를 제공합니다.
CAB(변경 자문 위원회)의 역할 변화
Change advisory boards have historically played a crucial role in assessing the risks associated with change requests and approving or rejecting them. Traditional CABs often acted as gatekeepers controlling the release of proposed changes.
However, they have been criticized for poor time management skills, lengthy change request backlogs, and their detachment from the actual work. Fortunately, CABs are evolving to become more strategic advisors, transforming their role in the change management process.
CAB의 당면 문제
효과적이지 않은 회의를 둘러싼 진부한 표현도 CAB에 적용됩니다. 시간을 낭비하고, 충분히 성과를 내지 못하고, 너무 많은 직원을 무작위로 참여시키며, "이메일로 대신 진행할 수도 있는 부분"이라고 CAB를 비판하지만 이는 타당한 의견입니다. 부분적인 이유는 기존 CAB가 맡은 책임으로 인해 과중한 부담을 겪었기 때문입니다.
비행기에 비유하여 이 문제를 설명해 보겠습니다. CAB를 공항의 관제탑이라고 생각할 수 있습니다. 이 관제탑에는 한 가지 임무가 있습니다. 비행기가 착륙할 수 있는 시점이 언제인지 알리는 것입니다. 비행기가 구조적으로 안전한지 또는 조종사가 올바른 자격증을 보유하고 있는지 평가하는 임무는 없습니다. 이러한 요소는 FAA 및 다른 책임자들이 이미 확인했기 때문입니다.
한편, 너무 많은 CAB가 다양한 이해 관계자를 모으고 모든 종류의 다양한 변경에 대해 광범위하고 안전한 의사 결정을 내리는 임무를 맡고 있습니다. 게다가 피로에 지친 직원들은 주말에 휴식을 취하고 싶어 하지만 CAB 회의는 주말에 진행되는 경우가 많습니다. CAB가 성공할 수 있는 환경이 전혀 마련되지 않았습니다.
또한 CAB는 인시던트를 유발하는 변경의 위험에 주로 관심을 갖습니다. 물론 이것도 중요하지만 중요한 변경이 지연되는 위험도 고려해야 합니다. 너무 느리게 진행하면 고객에게 피해를 줄 수 있으며 경쟁이 치열한 SaaS(Software as a Service) 세계에서 조직은 침몰할 수밖에 없습니다.
CAB의 역할에 초점을 맞춰 개선할 수 있습니다. 올바른 관행만 마련되면 많은 변경을 자동화할 수 있습니다. 이러한 방식으로 CAB는 추세를 추적하고 고객에게 이익이 되는 더 빠른 변경을 가능하게 하는 방법에 대해 팀과 협력하는 중요한 자문가가 될 수 있습니다.
CAB를 전략적 자문가로 포지셔닝하는 방법
CAB를 다시 포지셔닝하는 첫 번째 단계는 과도한 변경 관리가 긍정적인 결과를 가져온다는 개념을 없애는 것입니다. 2019년 State of DevOps 보고서의 데이터에 따르면 CAB 승인이 필요한 프로세스는 소프트웨어 제공 성능에 부정적인 영향을 미쳤으며 이러한 프로세스를 따르는 응답자는 성과가 낮을 가능성이 2.6배 더 높았습니다. 또한 공식 승인 프로세스가 변경 실패율 감소와 관련이 있다는 증거도 없었습니다!
이러한 이유로 최신 팀은 CAB를 개선하기 위해 다음과 같은 조치를 취하고 있습니다.
조직의 변경 관리 관행에 대한 책임 할당
변경 관리 관행에서 역할과 책임을 정의할 때는 모든 상황에 맞는 단 하나의 해결책은 없다는 사실부터 이해해야 합니다. 회사의 문화, 팀 구조, 사용 가능한 기술, 규제 요구 사항 등을 고려해야 합니다.
비즈니스에 필요한 역할과 책임에 대한 진정한 지지를 얻으려면 역할 및 책임 플레이를 실행하는 것이 좋습니다. 여기에는 모든 직원이 함께 모여 팀에 대한 각 팀원의 기여도를 이해하고 성공하기 위해 필요한 것이 무엇인지 모든 직원이 파악하는 과정이 포함됩니다.
변경 관리의 컨텍스트에서 역할과 책임을 개선하려면 먼저 팀을 한데 모아 아래 질문에 대해 논의하는 것이 좋습니다.
- 다양한 프레임워크가 우리 팀에 어떤 의미가 있습니까? DevOps, CI/CD, ITIL 등
- 프레임워크를 전체적으로 수용했습니까? 우리의 이해가 자동화와 같은 전술적인 요소에만 국한되어 있습니까?
- 이러한 프레임워크, 특히 DevOps 및 ITIL은 변경 및 릴리스 관행에 어떤 영향을 미치며 어떻게 함께 작용하고 있습니까?
- 현재의 변경 프로세스는 무엇입니까?
- 누가 참여합니까?
- 어떻게 개선할 수 있습니까?
- 더 많은 일반 변경을 표준 또는 사전 승인으로 전환하려면 어떻게 해야 합니까?
- 가장 일반적인 변경은 무엇입니까?
- “표준 변경”은 어떤 변경입니까?
- 어떤 서비스에 영향을 미칩니까?
- 어떤 변경이 성공적이었습니까?
변경 관리는 중요한 관행이며 앞으로도 계속 필요할 것입니다. 변경 관리 관행의 상태에 관계없이 개선의 여지는 항상 있습니다. 변경을 추적하여 시작할 수도 있고, 위험 평가 및 자동화 시스템을 구현하여 시작할 수도 있습니다. Jira Service Management의 변경 관리 기능이 어떻게 IT 운영 팀에 권한을 부여하는지 알아보세요.
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
백서 읽기Knowledge Management Explained | Atlassian
Knowledge management processes create, curate, share, use, and manage knowledge across an organization and even across industries. Learn more here.
게시물 읽기배포를 중단하지 마세요: 불확실한 시기의 변경 관리
일부 회사는 높은 부담의 변경 관리 프로세스로 되돌아가고 있습니다. 컨트롤을 추가하지 않고도 관행을 개선할 수 있는 방법을 설명해 드립니다.