서비스 지원 측정 기준

서비스 지원 측정 기준

릴리스 관리

제8장

릴리스 관리는 ITIL의 핵심 구성요소이며 수정된 ITIL 간행물의 최근판에서 완전히 내용이 바뀌었습니다. 예전에는 릴리스 관리가 IT 환경에 소프트웨어 릴리스를 관리하는 것과 관련이 있었습니다. 지금은 릴리스 관리의 범위는 훨씬 넓어져서 서비스 지원 서적의 릴리스 관리 장에서 발췌한 내용을 보면 다음과 같이 되어 있습니다.

대부분의 서비스 제공 업체들은 배포 환경에서 하드웨어 및 소프트웨어 릴리스에 연관되어 있다. 좋은 자원 계획 및 관리는 고객에게 성공적으로 릴리스를 패키지 및 배포하는 데 있어서 필수적이다. 릴리스 관리는 IT 서비스의 변화를 전체론적 관점에서 바라보며 릴리스의 모든 측면(기술적 및 비기술적)이 함께 고려되도록 보증한다. (9.1. 릴리스 관리의 목표)

‘릴리스’라는 용어는 IT 서비스에 공인된 변화 모음을 설명하는 것이다. 릴리스는 자신이 제기하는 RFC(변화 요청)에 의해 정의됩니다. 릴리스는 일반적으로 많은 문제 해결 및 서비스에 대한 보완책으로 구성된다. 또한 인가된 변화를 실행하는 데 필요한 신규 혹은 변경된 소프트웨어 및 하드웨어로 구성된다. (9.3.1. 릴리스)

릴리스 관리는 이제 ITIL의 핵심 구성 요소입니다. 기타 ITIL 과정과 마찬가지로 릴리스 관리에는 두 가지 종류의 측정치가 있습니다: 주요 수행능력 지표(KPI) 및 관리 보고 모니터링. 먼저 ITIL이 요약하는 대로 KPI를 논의해보겠습니다.

  • 스케줄에 맞춰 제작 및 실행되며 예산 내에서 자원을 활용한 릴리스(응용프로그램 개발 지연 등과 같은 제어 및 책임 한계를 넘어서는 문제들은 분리될 수 있도록 주의해야 함).
  • 용인하기 어려운 오류(소프트웨어 릴리스가 100% 완벽해야 할 필요는 없으며 오류가 존재함에도 릴리스를 진행하기로 결정할 수 있슴, 단 그리 크지 않은 오류이며 허용된 오류 범위 내에 있음을 전제로 함)로 인해 취소되어야 하는 발생률이 극히 낮은(없는 것이 이상적) 릴리스.
  • 낮은 장애 발생률.
  • DSL(표준 소프트웨어 라이브러리)에 대한 안정적이고 정확한 관리.
  • DSL의 소프트웨어가 품질 검사를 통과하지 못했다는 증거 및 네트워크상에 DSL에서 추출된 소프트웨어가 없다는 증거 모두 없음.
  • DSL의 크기가 요구하는 공간에 딱 맞으며 시기적절하고 정확한 DSL 관리.
  • 구입 소프트웨어와 관련하여 법적 한계사항을 모두 준수.
  • 원격지 전체에 릴리스를 정확하게 배포함.
  • 적절한 시기에 원격지를 포함한 전체 현장에 릴리스 배포.
  • 허가 없이 이전 버전으로 회귀하는 증거가 어느 현장에도 없음.
  • 허가 받지 않은 소프트웨어를 사용했다는 증거가 어느 현장에도 없음.
  • 어디에서도 실제로 사용하지 않는 소프트웨어에 라이센스 비용 혹은 쓸모없는 유지 비용 노력이 소모되었다는 증거가 없음.
  • 릴리스 제작에 쓸모없는 중복이 존재한다는 증거 없음(단일 빌드로 충분한 상황에서 원격지에 다중 빌드 존재)
  • CMDB(구성 관리 데이터베이스) 내의 모든 빌드, 배포 및 실행 활동을 정확하고 적시에 기록.
  • 모든 릴리스 활동에 대하여 과정 개선을 포함한 사후 분석 및 필요한 교정/후속 조치 실시
  • 실제 구성과 맞아 들어가는 릴리스 구성 계획(이 덕분에 릴리스 계획이 우수함이 드러남)
  • 릴리스 관리에서 필요한 IT 및 인력 자원이 우수한 예상 계획에 따름.

예상하신 것과 같이 이 KPI 가운데 일부는 변경 관리에서 나타난 측정치와 유사한 것을 포함하고 있습니다. 이것은 릴리스 관리와 변경 관리의 관계가 밀접하기 때문에 발생하는 어쩔 수 없는 현상입니다. 하지만 둘 사이에는 주요한 차이점이 있다는 점도 곧 보게 되실 것입니다.

스케줄대로 제작 및 실행되며 예산 내에서 자원을 활용한 릴리스(응용프로그램 개발 지연 등과 같은 릴리스 관리의 제어 및 책임 한계를 넘어서는 문제를 분리시키도록 주의해야 함). 이 KPI를 실용적으로 만들려면 이 말을 “지난 달에 예산범위 내에서 예정대로 제작되어 실행된 릴리스의 숫자”로 바꿔야 합니다.

원래 말에는 KPI가 다뤄지는 시간 범위가 나타나 있지 않습니다. “개월”이라는 용어는 측정이 진행되는 기간에 대해 좀더 구체적이어야 함을 나타내는 실례일 뿐입니다. “릴리스 관리의 제어 및 책임 한계를 넘어서는”이라는 부분도 정의를 명확하게 하여 정확성을 보장하고 혼란을 줄이도록 해야 합니다.

사실상 이 KPI는 주어진 시간 범위에서 성공적인 릴리스를 위한 간단한 체크리스트를 제공하는 역할을 합니다. 그러므로 이것은 중요한 KPI지만 보고의 내용은 성공적인 릴리스마다 한 줄씩으로 한정해야 합니다. 일반적으로 보고서에는 릴리스의 예정 시간 및 일자, 실제 시간 및 일자, 릴리스 참조 번호, 릴리스 보유자 및 통제 외 범위에 대한 코멘트 등이 포함됩니다. 이 보고서를 100% 활용하려면 실패한 릴리스를 나열하는 다음 보고서와 비교해 보십시오. 이 KPI를 활용하면 성공률이 높아질수록 더 좋은 상황이 됩니다.

  • 비즈니스 조정 지표 – 이것은 비즈니스 관리자가 “반드시 봐야 하는” 보고서이며 특히 주어진 기간 내에 릴리스를 받았다면 더욱 그렇습니다. “릴리스 관리의 통제 및 책임 범위를 벗어나는” 것으로 간주되는 릴리스에서 나타나는 문제에 대해 비즈니스 관리자들과 의견을 나누되 릴리스가 성공적인지 여부에 대해서는 의견차이가 있을 것을 예상하십시오.

용인하기 어려운 오류(단 소프트웨어 릴리스가 100% 에러가 없어야 할 필요는 없음에 주목하십시오. 에러가 존재함에도 불구하고 릴리스를 계속 진행하기로 할 수도 있습니다. 단 오류가 사소한 것이며 허가된 오류 범위 내에 있음을 전제로 합니다.)로 인해 취소되어야 하는 발생률이 극히 낮은(없는 것이 이상적) 릴리스. 이 KPI가 낮을수록 이전 KPI는 높아지므로 전반적인 수행능력은 더욱 좋아집니다. 알려진 오류(우회책이 있거나 근원이 파악된 것)와 아무리 사소하더라도 예상치 못한 인시던트를 발생시키는 오류를 차별화하십시오. 예상치 못한 인시던트를 발생시키는 오류는 문제 관리 과정을 통해 처리해야 합니다. 항상 용인될 수 없는 오류로 인한 실패를 분석하고 각 경우에 대한 보고서를 작성하여 동일한 오류가 향후 릴리스에서 반복되지 않도록 취한 조치를 설명하십시오.

  • 비즈니스 조정 지표 – 이 KPI가 공개되기 전부터 이미 모든 실패한 릴리스는 알려지면서 논의의 대상이 되어 왔을 가능성이 있습니다. 하지만 그렇다 해도 이 KPI는 예상치 못한 오류가 비즈니스에 미치는 영향에 대해 세부적인 내용을 제공할 수 있는 비즈니스 관리자 간에 공유할 수 있는 핵심 보고입니다. 비난을 줄여보려는 방책보다는 이 보고서를 더 나은 미래를 위한 수단으로 간주하는 것이 중요합니다.

낮은 빌드 실패 발생률. 이 KPI를 측정하기 전에 “낮은”의 목표 수준을 정할 필요가 있습니다. 0이 될 수도 있으며 100 중의 1을 넘지 않을 수도 있습니다. 이상적인 KPI 목표는 0이지만 KPI를 어떻게 설정하든 간에 모든 빌드 실패를 완전히 조사해야 합니다. “예상치 못한 오류”를 다룬 이전 KPI에서 설명한 기준의 대부분은 여기서도 적용할 수 있습니다.

  • 비즈니스 조정 지표 – “예상치 못한 오류”와 관련한 이전 KPI에 대한 논의도 여기에 적용될 수 있습니다.

DSL(표준 소프트웨어 라이브러리)에 대한 안정적이고 정확한 관리. 이 KPI는 앞서 논의한 것들과는 완전히 다릅니다. 기준 데이터만을 바탕으로 습득할 수 없으며 DSL에 대한 조사, 평가 및 감사가 필요합니다. 사실 DSL에 대한 정확한 관리는 감사, 평가 및 DSL의 소프트웨어 릴리스와 인프라의 장비에 설치된 소프트웨어간에 비교를 통해서만 가능합니다.

보안을 평가하기란 더욱 어렵습니다. 그럼에도 불구하고 DSL에 대한 모든 접근은 패스워드로 제어해야 합니다. 보안 평가는 IT 분석가 보다는 독립 보안 분석가가 수행하는 편이 좋습니다. 이 평가는 주로 IT 관리자의 요청에 의해 불규칙적으로 수행됩니다. 보안 문제 혹은 비정확성이 파악되면 즉시 조치를 취하여 이 약점들을 릴리스 관리에서 제거하고 재발을 방지해야 합니다.

  • 비즈니스 조정 지표 – 이 KPI는 비즈니스 커뮤니티가 DSL에 얼마나 깊은 관계를 맺고 있느냐에 전적으로 달려 있습니다. 비즈니스 관리자가 DSL에서 소프트웨어를 하나라도 “보유”하고 있다면 이를 평가에 포함시키십시오. 또한 비즈니스 관리자와 의견을 교환하여 소프트웨어 버전을 검증하는 데 직접 방문할 필요가 있는지도 반드시 알아보십시오.

DSL의 소프트웨어가 품질 검사를 통과하지 못했다는 증거 및 네트워크상에 DSL에서 추출된 소프트웨어가 없다는 증거 모두 없음. 이전 KPI와 마찬가지로 이 측정치는 기준 데이터만으로는 얻을 수 없습니다. DSL에 대한 조사, 평가 및 감사가 수행되어야 합니다. 품질 및 무결성을 증명하려면 감사, 평가 및 DSL에 설치된 소프트웨어 릴리스와 인프라의 장비에 설치된 소프트웨어를 비교하는 방법 외에는 없습니다. 감사 평가는 DSL “관리자”가 수행하기보다 독립 분석가가 하는 편이 좋습니다. 이 평가는 IT 관리자의 요청에 의해 불규칙적으로 수행됩니다. 품질 및 무결성 문제가 발견되면 즉각 조치를 위하여 릴리스 관리에서 이 약점들을 제거하고 향후 재발을 방지해야 합니다.

  • 비즈니스 조정 지표 – 역시 이 KPI도 비즈니스 커뮤니티가 DSL에 얼마나 깊은 관계를 맺고 있느냐에 전적으로 달려 있습니다. 비즈니스 관리자가 DSL에서 소프트웨어를 하나라도 “보유”하고 있다면 이를 평가에 포함시키십시오. 또한 비즈니스 관리자와 의견을 교환하여 소프트웨어 버전을 검증하는 데 직접 방문할 필요가 있는지도 반드시 알아보십시오.

DSL의 크기가 요구하는 공간에 딱 맞으며 시기적절하고 정확한 DSL 관리. 이 KPI는 중요성이 높으며 입력 및 지원에 있어서 ITIL 과정 “용량 관리”에 의존합니다. 현재 데이터베이스의 크기를 현재 소프트웨어를 업그레이드하는데 필요한 추가 공간에 더하여 DSL의 공간 요구량을 측정하되 신규로 계획된 소프트웨어 추가도 포함하십시오. 그런 다음 이 공간을 DSL에 남아있는 공간과 비교하십시오. 신규 소프트웨어를 설치할 공간이 충분치 못할 경우에는 DSL의 공간을 늘리거나 예전 및 불필요한 소프트웨어를 제거하는 조치를 취해야 합니다. 공간이 부족해서 소프트웨어를 추가할 수 없다면 이 KPI를 만족시킬 수 없습니다.

시기적절하고 정확하게 DSL을 관리하는 작업은 정기적으로 수행해야 하며 모든 관련 조치는 트랜잭션 기록에 남겨야 합니다. 이 KPI에는 트랜잭션 기록 뿐만 아니라 DSL의 감사도 필요합니다. 제대로 관리가 되지 않았거나 부정확하다는 증거가 나타나게 되면 이 KPI가 만족되지 못했다는 뜻입니다. 타이밍 또는 부정확성 문제가 있다는 증거가 나타나면 즉시 조치를 취하여 이 약점들을 제거하고 향후 재발하지 않도록 방지해야 합니다.

  • 비즈니스 조정 지표 – 이 KPI도 비즈니스 커뮤니티가 DSL에 얼마나 깊은 관계를 맺고 있느냐에 전적으로 달려 있습니다. 비즈니스 관리자가 DSL에서 소프트웨어를 하나라도 “보유”하고 있다면 이를 평가에 포함시키십시오. 또한 비즈니스 관리자와 의견을 교환하여 소프트웨어 버전을 검증하는 데 직접 방문할 필요가 있는지도 반드시 알아보십시오.

구입 소프트웨어와 관련하여 법적 한계사항을 모두 준수. 이는 매우 중요한 KPI입니다. 이 KPI가 만족되지 못할 경우 법적 대응을 당할 수도 있습니다. 일반적으로 이 KPI는 소프트웨어 라이센스 관련 제한사항, 소프트웨어 갱신, 소프트웨어 만기일자 등과 연관이 있습니다. 모든 소프트웨어의 계약 동의서를 항목으로 구분하고 모든 법적 요구사항이 만족되었는지 확인할 수 있게끔 검사와 제한사항을 도입시켜야 합니다. 기존 소프트웨어에 신규 사용자를 추가하거나 업그레이드를 수행할 때 특히 중요합니다.

  • 비즈니스 조정 지표 – 특히 비즈니스 관리자들 자신이 규칙을 위반하고 있을 경우(아마도 무의식중에), 비즈니스 관리자들이 위반중인 법적 제한사항에 대해 인식하고 있도록 확인하십시오. 예를 들어, 비즈니스 관리자가 워크스테이션 10대에서 사용할 소프트웨어 제품에 라이센스 비용을 지불하기로 동의할 경우가 있습니다. 그러나 동시에 10명이 넘는 인원이 이 소프트웨어를 사용하는 상황이 있습니다. 이 상황에서는 비즈니스 관리자에게 소프트웨어가 불법적으로 사용되고 있음을 알려야 합니다. 또한 계약 관리 및 구매 등 IT와 관련되지 않은 부서와도 협조해야 할 수 있습니다.

원격지 전체에 릴리스를 정확하게 배포함. 이 KPI는 감사를 통해 측정할 수 있습니다. 그러나 인시던트 및 문제 데이터베이스 양쪽에 정기 평가를 수행하여 부정확한 소프트웨어 배포의 증거를 찾아내는 것이 더 일반적입니다. 또한 변경 관리의 RFC도 살펴보십시오. 변화를 요구하는 RFC를 부정확한 소프트웨어 릴리스로 인한 것으로 볼 수 있습니다. 예를 들어, 사용자가 이미 설치되었어야 할 업그레이드 및 기능을 요청하는 경우가 있습니다. 소프트웨어가 부정확하게 배포되었다는 증거를 발견하게 되면 이 KPI를 만족시키지 못한 것입니다.

  • 비즈니스 조정 지표 – 비즈니스 관리자들은 자신들의 부서에서 설치되어야 하는 소프트웨어(버전/릴리스 레벨)에 대해 잘 모르는 경우도 있습니다. 소프트웨어 릴리스 과정의 일부로 비즈니스 관리자들에게 관련 정보를 완전히 전달하도록 하십시오.

적절한 시기에 원격지를 포함한 전체 현장에 릴리스 배포. 릴리스가 적기에 이루어지기도 하고 늦기도 하기 때문에 이 KPI는 모니터링이 쉽습니다. 릴리스가 늦었다는 사실은 이 KPI를 지키지 못했다는 증거입니다. 하지만 릴리스가 늦어진 이유를 파악해야 하며 같은 이유로 향후 릴리스가 다시 늦어지는 일이 없도록 조치를 취해야 합니다. 한달 등의 기간을 두고 정기적으로 “릴리스 지연” 보고서를 발행하여 전체 IT 관리자에게 보여주고 평가와 코멘트를 받아야 합니다.

  • 비즈니스 조정 지표 – 비즈니스 관리자들은 “릴리스 지연” 보고서를 하나 받아보고 싶어할 것입니다. 또한 릴리스가 늦어지면 먼저 통보를 해 올 것이므로 릴리스 진행상황에 대해 최신 정보를 관리자들에게 제공하도록 하십시오.

허가 없이 이전 버전으로 회귀하는 증거가 어느 현장에도 없음. 이 KPI에는 감사 및 평가가 필요합니다. “검색 및 발견” 유틸리티를 사용하여 소프트웨어 버전이 하위로 내려갔는지 탐지할 수 있습니다. 또는 인시던트 및 문제 데이터베이스를 살펴보면서도 탐지가 가능합니다. 변경 관리의 RFC를 살펴봐서 소프트웨어 릴리스 순서가 바뀐 덕분에 사용자가 변화를 요청했는지 알아보아야 합니다. 예를 들어, 사용자가 이미 설치되었어야 할 업그레이드 및 기능을 요청하는 경우가 있습니다. 허가 없이 수정이 이루어졌다는 증거가 나타나면 KPI를 준수하지 않았다는 뜻입니다.

  • 비즈니스 조정 지표 – 비즈니스 관리자에게 자신의 책임 영역 내에서 실패가 발생했는지 알아보십시오. 보안 담당 및 해당 부서에 발견된 실패를 보고할 필요도 있습니다.

허가 받지 않은 소프트웨어를 사용했다는 증거가 어느 현장에도 없음. 이 KPI에는 감사 및 평가가 필요합니다. 먼저 “허가 받지 않은 소프트웨어”라는 요건이 어떻게 구성되는지, 그리고 이를 사용 및 도입함으로써 받게 될 처벌은 어떤 것이 있는지 정확히 파악하십시오. 그리고 전체 IT 및 비즈니스 관리자가 “허가 받지 않은 소프트웨어” 및 관련 처벌의 개념을 완전히 이해하도록 하십시오. “검색 및 발견” 유틸리티를 사용하거나 인시던트 또는 문제 데이터베이스에서 무단으로 사용된 소프트웨어를 탐지할 수도 있습니다. 무단으로 소프트웨어를 사용했다는 증거를 발견하게 되면 이 KPI를 만족시키지 못한 것입니다.

  • 비즈니스 조정 지표 – 비즈니스 관리자의 책임 영역 내에서 무단으로 소프트웨어가 사용되었다는 것을 확인하면 반드시 관리자들과 의견을 나누도록 하십시오. 허가 받지 않은 소프트웨어는 다른 소프트웨어의 새 버전을 설치할 때 심각한 문제를 일으킬 수 있습니다. 가장 중요한 것은 무단으로 사용되는 소프트웨어를 통해 바이러스 및 기타 컴퓨터 소프트웨어가 침입해올 가능성이 있다는 사실입니다. 결과적으로 무단으로 소프트웨어를 사용하는 것은 보안 부서 및 기업 감사관에게 보고할 필요가 있습니다.

어디에서도 실제로 사용하지 않는 소프트웨어에 라이센스 비용 혹은 쓸모없는 유지 비용 노력이 소모되었다는 증거가 없음. 이 KPI는 “우수한 관리”라고 볼 수 있습니다. 정기적인 감사를 계획하여 어떤 소프트웨어가 어느 위치에서 사용되는지 파악하십시오. 이것은 소프트웨어가 사용되는지 여부를 파악하는 것이 아니라 소프트웨어의 사용에 라이센스가 얼마나 필요한 지를 파악하기 위한 것입니다.

예를 들어, 직원이 40명 있는 부서의 전체 워크스테이션에 동일한 소프트웨어가 사용 허가된 경우가 있습니다. 부서 정책이 바뀐 관계로 사실상 이 소프트웨어를 사용하는 인원은 10명에 불과합니다. 이 경우 라이센스의 수를 줄이고 소프트웨어를 사용되지 않는 워크스테이션에서 삭제하여 라이센스 및 유지 보수 비용을 절감할 수 있습니다.

사용하지 않는 소프트웨어는 소프트웨어 사용량 유틸리티로 탐지할 수 있으며 또는 인시던트 및 문제 데이터베이스를 통해 파악할 수도 있습니다. 이 KPI는 위의 예와 같이 상황이 바뀔 수도 있으므로 다른 KPI와 다소 다른 부분이 있습니다.

  • 비즈니스 조정 지표 – 소프트웨어 사용량(또는 비사용)을 파악하는데 기술을 사용할 수도 있지만 비즈니스 관리자들이 라이센스 수를 감축한다는 데 동의해야만 합니다. 그러므로 사용하지 않는 라이센스를 발견하게 될 때마다 라이센스 수를 줄이기 전에 해당하는 비즈니스 관리자에게 의견을 구하도록 하십시오. 또한 직원들이 사용하는 소프트웨어 라이센스에 대해 1년 기준으로 평가를 하여 그만큼의 라이센스가 계속 필요한지 여부를 파악하십시오.

릴리스 제작에 쓸모없는 중복이 존재한다는 증거 없음(단일 빌드로 충분한 상황에서 원격지에 다중 빌드 존재). 이 KPI는 릴리스 작업을 진행하던 IT 직원들을 쓸모없는 중복 파악 및 보고 작업으로 돌려야 하기 때문에 측정이 어려운 것 중에 하나입니다. 간혹 릴리스가 설치될 때까지 중복의 증거가 분명치 않은 경우도 있습니다. 직원들로 하여금 향후 릴리스에서 보다 효율성을 추구할 수 있도록 중복 사례를 모두 보고하도록 하십시오. 릴리스가 예상보다 오래 걸리거나 도입 비용이 많이 들어가는 경우가 쓸모없는 중복 설치를 나타낼 수 있습니다.

이 KPI에 정기 감사 및 평가가 필요하진 않지만 불필요한 중복을 파악하는 것은 릴리스가 완료된 후 평가의 일부로 포함되어야 합니다. 불필요한 중복이 파악될 경우 릴리스 관리 과정을 개선하기 위한 조치를 취해 재발을 방지해야 합니다. 불필요한 중복이 있다는 사실은 이 KPI를 만족시키지 못했음을 의미합니다.

  • 비즈니스 조정 지표 – 엔드 유저들이 릴리스에 깊이 관여할수록 중복을 파악할 확률이 높아집니다. 엔드 유저들과 비즈니스 관리자들은 쓸모없는 중복을 파악 및 보고함으로써 도움을 줄 수 있습니다. 예를 들어, 동일한 작업을 여러 번 반복 수행하게 되는 경우가 있습니다. 경우를 막론하고 중복된 릴리스가 나타나면 비즈니스 관리자에게 통보하십시오.

CMDB(구성 관리 데이터베이스) 내의 모든 빌드, 배포 및 실행 활동을 정확하고 적시에 기록. 먼저 “정확성”과 “적시”의 개념을 정의하고 문서화하지 않으면 이 KPI를 측정할 수 없습니다. 그런 다음에야 실패를 파악할 수 있게 됩니다. “정확성”과 관련하여 구성 관리 팀은 CMDB를 감사할 책임이 있으며 릴리스 관리로 인한 오류 때문에 부정확성이 나타나면 보고해야 합니다. “적시”라는 개념을 측정하는 것은 이보다 어렵습니다. 적시라 함은 릴리스로 인해 변경사항이 생긴 후 CMDB 항목을 업데이트하는데 걸리는 시간과 관련이 있습니다. CMDB 감사에서 적시 실패 사례를 찾아볼 수도 있습니다. 기타 적시 실패의 경우는 문제 및 인시던트 데이터베이스 혹은 서비스 데스크를 살펴보면서 알아내기도 합니다. 예를 들어, 서비스 데스크가 인시던트를 처리하지만 릴리스 관리가 주기적으로 업데이트 되지 않음으로 인하여 CMDB는 고객의 위치에서만 실제 구성과 일치하는 경우가 있습니다.

ITIL은 정확한 CMDB야말로 IT 서비스 관리에서 핵심적인 구성요소라고 밝히고 있습니다. 이 KPI를 준수하지 못하게 되면 심각한 결과가 나타날 수 있으므로 정확한 CMDB를 유지하도록 조치를 취해야 합니다.

  • 비즈니스 조정 지표 – 비즈니스 관리자에게 CMDB가 부정확함을 밝히되 특히 재무, 계약 및 구매 분야 등과 같이 CMDB를 사용하는 관리자에게 알리도록 하십시오. CMDB를 사용하지 않는 비즈니스 관리자들도 좋지 않은 서비스, 부정확하고 낡은 CMDB로 인해 좋지 않은 서비스로 인시던트 우선순위를 잘못 설정하는 등 영향을 받을 수 있으므로 이들에게도 부정확성을 알릴 필요가 있습니다. CMDB 부정확성과 관련하여 피드백이 필요한 사람을 파악하려면 비즈니스 관리자와 의견을 교환하십시오.

모든 릴리스 활동에 대하여 과정 개선을 포함한 사후 분석 및 필요한 교정/후속 조치 실시. 이 KPI는 다소 명확하지 못한 점이 있습니다. 사후 분석이 수행되었다는 것인지 아니면 전체 사후 분석 결과에서 릴리스 문제가 전혀 없었다는 뜻인지 명확하지 못합니다. 확실히 릴리스마다 사후 분석을 해야 할 필요는 있습니다. 이것이 어렵다면 최소한 문제가 있었거나 실패한 릴리스에 대해서만이라도 사후 분석을 하십시오. 사후 분석을 하지 않으면 이 KPI를 준수하지 못한 것이 됩니다. 또한 과정 향상은 물론 요구되는 교정과 후속 조치가 수행되었는지도 확인하십시오. 이러한 확인을 해야 이 KPI를 준수한 것이 됩니다. 사후 분석은 본 섹션에서 설명한 기타 다양한 KPI에도 유용한 데이터를 제공합니다.

  • 비즈니스 조정 지표 – 비즈니스 관리자가 사후 분석 결과를 모두 받아볼 필요는 없습니다. 그러나 이들의 관련 영역에서 설치된 릴리스에 문제가 있을 경우 이를 보여주는 사후 분석 보고를 보내주도록 하십시오.

실제 구성과 맞아 들어가는 릴리스 구성 계획(이 덕분에 릴리스 계획이 우수함이 드러남). 계획된 구성이 실제 구성과 맞도록 완벽한 계획을 하는 것이 이상적입니다. 하지만 예상치 못한 상황이 발생하는 경우도 있으며 이를 통해 계획을 향상시키는 법을 배우게 됩니다. 그러므로 이 KPI는 전략 도입 및 계획 향상 등을 언급하지 않음에도 중요성이 높다고 할 수 있습니다. 릴리스가 완료될 때마다 계획된 구성이 실제 구성과 맞는지 파악하십시오. 사후 분석에 포함시켜 함께 조사할 수도 있습니다. 계획된 릴리스 구성이 실제 구성과 맞지 않는다면 이 KPI를 준수하지 못한 것이 됩니다.

  • 비즈니스 조정 지표 – 변화 자문 이사진(CAB)에 비즈니스 관리자들도 있다면 특히 두 구성이 맞지 않을 경우에 이 KPI에 관심을 보일 것입니다. 자신의 분야에서 구성이 맞지 않은 경험을 해 본 비즈니스 관리자들도 보고 싶어할 것입니다.

릴리스 관리에서 필요한 IT 및 인력 자원이 우수한 예상 계획에 따름. 이것은 또 다른 “계획” 관련 KPI로 릴리스 관리 중에 필요 자원이 적절하게 배치되도록 하기 위한 것입니다. 이 KPI를 목표 “Good”과 같은 목표를 정해놓으면 측정하기가 쉽지 않으므로 “자원 부족으로 인해 릴리스가 5%이상 지연되지 않도록 한다”는 등의 목표를 설정해 보십시오. 어떻게 정하든 간에 이를 만족시키지 못하면 KPI도 준수하지 못하는 것입니다.

계획 단계에서 과대 평가를 하게 되면 과소 평가 못지 않은 위험한 결과가 나올 수 있음을 명심하십시오. 예를 들어, 어떤 작업에 100시간의 노력이 필요하다고 예상했지만 실제로는 25시간이 소모되었다고 한다면 직원 업무 부하에 대해 또다시 불필요한 요청을 하게 되는 결과가 나옵니다. 전체 주기에 걸쳐서 각 릴리스를 주의 깊게 모니터링하여 IT 관리자에게 최대한 빨리 자원 관련 문제를 보고해야 합니다. 이 계획을 각 릴리스 끝부분에 평가하여 자원 계획에 대비하여 실제 사용 자원을 평가해 보십시오. 릴리스가 지연되는 일반적인 원인이 잘못된 자원 계획이라는 점에서 이 KPI는 핵심적입니다. 자원이 부족하게 되면 어떤 경우든지 완전히 설명할 수 있어야 하며 동시에 향후 릴리스 계획이 향상되도록 가능한 모든 조치를 취해야 합니다.

  • 비즈니스 조정 지표 – 일반적으로 비즈니스 관리자들은 부적절한 자원 계획이 릴리스를 지연시킬 경우에 관심을 갖습니다. 하지만 릴리스를 실행하는 과정을 더 빠르게 하는 계획에는 보통 관심을 두지 않습니다. 대개 비즈니스 관리자들은 자원 계획을 완전히 이해하고 있으므로 이들이 질문을 많이 할 것에 대비하십시오. 또한 예정보다 일찍 완료되는 프로젝트에 대한 회의론에 대해서도 준비를 하십시오. 비유를 한다면, 계획보다 9개월 빨리 새 고속도로가 개통되었다는 표지판을 본다면 “계획을 잘 짰다”거나 “도로 건설업체가 정부를 속였나?” 중에서 어떤 반응을 먼저 보이시겠습니까? 어느 경우든 비즈니스 관리자에게 전체 자원과 관련된 모순을 분석해줘야 합니다.

이 KPI들을 살펴본 결과 두 가지 주제가 나타납니다. 감사와 사후 분석이 그것입니다. 양쪽 모두 릴리스 관리를 지속적으로 향상시키기 위한 핵심적인 조치입니다. 하지만 이 조치를 실행하는 데 있어서는 주의를 기울여야 합니다. 직원이나 이들의 행동에 대해 비판을 가할 목적으로 감사 및 사후 분석을 행한다면 이 도구들은 급속도로 효과를 상실할 것입니다. 마지막으로 “감사”는 정확성과 적시성에 대한 것이지, 비즈니스 혹은 법적 감사에 대한 것이 아님을 잊지 마십시오. (라이센스 분석은 이 말에 예외가 될 수 있습니다.)

이제 관리 정보 측정치로 넘어가겠습니다. 이 측정치들은 릴리스 관리의 전반적인 성과와 연관되어 있습니다. ITIL이 권장하는 관리 정보 측정치는 다음과 같습니다.

  • 매 보고 주기마다 실행된 주요 및 사소한 릴리스의 횟수.
  • 새로운 릴리스가 원인이 될 수 있는 현장 환경에서 발생한 문제의 수효 – 신규 릴리스가 실행된 후 몇 달 이내에만 측정할 필요가 있으며 ‘잘못된 파일 버전’ 혹은 ‘없는 파일’ 등의 근원적 문제로 분류됨.
  • 새로운 릴리스로 인해 추가 및 변경되거나 삭제된 객체 – 모듈 및 프로그램의 개수 등.
  • 합의된 시간대 내에 완료된 릴리스 수효: 중앙 릴리스 관리 기능이 소프트웨어 배포 및 기타 일반적 작업에 대해 사전에 정의된 목표(서비스 수준 또는 SLA)를 공개해줄 필요가 있음.

수많은 KPI를 살펴보았으니 관리 보고에 쓰이는 측정치 몇 개 때문에 놀라지는 않으실 겁니다.

매 보고 주기마다 실행된 주요 및 사소한 릴리스의 횟수. 이 측정치는 불행히도 보고 대상에 대한 정확한 정보를 그다지 많이 주지 않습니다. 기간 내에 완료된 릴리스일까요? 기간 내에 시작된 릴리스를 말하는 것일까요? 준비 중인 릴리스일까요? 아니면 이 모든 것을 통틀어 말하는 것일까요? 주기적 보고에 이 모든 것이 포함되는 것이 이상적이긴 합니다. 상태에 따라 이 보고는 완료, 시작 및 진행 중(준비 중)의 3개 섹션으로 나눌 수 있습니다. 그리고 각 섹션은 주요 및 사소한 것 등 2개의 하위 섹션으로 나뉩니다. 이 보고서는 IT 관리자 및 그 직원들이 연관된 전체 릴리스를 추적할 수 있게 해주므로 모든 IT 관리자에게 배포되어야 합니다.

  • 비즈니스 조정 지표 – 모든 비즈니스 관리자에게 중요한 보고서로 자신들의 분야에 영향을 미치는 릴리스를 추적하게 해 줍니다. 이 보고서를 배포함으로써 릴리스 현황에 대한 비즈니스 관리자의 질문을 줄일 수 있습니다. 늦어지는 릴리스에 대한 책임이 있는 경영진들로부터의 질문을 예상해 두십시오.

새로운 릴리스가 원인이 될 수 있는 현장 환경에서 발생한 문제의 수효 – 신규 릴리스가 실행된 후 몇 달 이내에만 측정할 필요가 있으며 ‘잘못된 파일 버전’ 혹은 ‘없는 파일’ 등의 근원적 문제로 분류됨. 이것은 명확한 측정치이며 사용자에 의해 보고된 또는 새로운 릴리스에 기인한 모든 새로운 인시던트를 포함하기 위해 확장될 수 있습니다. 이론적으로는, 새로운 문제나 인시던트가 없는 것이 이상적입니다. 하지만 현실적으로 성공적인 릴리스의 경우조차도 문제나 인시던트가 발생하곤 합니다. 이상적인 상태에 가깝게 향후 릴리스에서 재발되지 않도록 하는 유일한 길은 신규 문제 및 인시던트를 모두 조사하는 것입니다. 이 측정치는 “근원”을 문제의 한 종류로 제시합니다. 비슷하게 “카테고리”의 개념을 인시던트에 적용할 수도 있습니다. 문제 및 인시던트는 모두 적용되는 릴리스에 상호 참조되도록 릴리스 참조 번호 등을 사용해야 합니다. 마지막으로 정리된 각 문제 및 인시던트에 대해 향후 릴리스에서 재발되지 않도록 수정 조치를 취해야 합니다. 이 보고서는 주기적으로 정리하여 전체 IT 관리자에게 배포해야 합니다.

  • 비즈니스 조정 지표 – 이 수치는 비즈니스 관리자라면 “필수적인” 보고 자료입니다. 릴리스의 결과로 나타난 문제 및 인시던트를 모두 알고 싶어하기 때문입니다. 결국 비즈니스 관리자들은 결과로 나타나는 실패를 받아들여야 하는 입장에 있는 것입니다. 또한 동일한 문제 및 인시던트가 향후 다시 발생하지 않도록 취하는 모든 수정 조치에도 관심을 보일 것입니다.

새로운 릴리스로 인해 추가 및 변경되거나 삭제된 객체 – 모듈 및 프로그램의 개수 등. 이 수치는 일련의 단계별 카테고리로 나뉘어 크기를 나타내는 기능을 합니다. 추가, 변경 및 삭제된 객체는 어떠한 영향이나 업무 부하 데이터를 제공하지 않으므로 거의 쓸모가 없습니다. 하지만 이 측정치는 KPI 및 기타 관리 정보와 함께 사용되어 주어진 기간동안의 활동 분량을 나타냅니다. 수치와 함께 객체 목록을 제공하면 더욱 좋습니다. 그러므로 이 보고서는 모든 IT 관리자가 볼 수 있도록 해야 합니다.

  • 비즈니스 조정 지표 – 대부분의 비즈니스 관리자는 이 보고서에서 얻는 이득이 별로 없겠지만 비즈니스 개발, 계약, 구매 및 변화 자문 이사진(CAB)에 참여하는 사람 등 일부 전문 관리자에게는 도움이 될 수 있습니다.

합의된 시간대 내에 완료된 릴리스 수효: 중앙 릴리스 관리 기능이 소프트웨어 배포 및 기타 일반적 작업에 대해 사전에 정의된 목표(서비스 수준 또는 SLA)를 공개해줄 필요가 있음. 언뜻 보기에 이 관리 측정치와 본 섹션에서 처음으로 다룬 KPI “일정대로 제작 및 실행된 릴리스” 간의 차이를 찾아내기가 쉽지 않습니다. 사실 성공한 릴리스보다 실패한 릴리스에서 배우는 교훈이 더 많은 듯 합니다. 좀더 자세히 살펴보면 SLA를 도입함으로써 앞서 말한 KPI와의 차별화가 이루어짐을 알 수 있습니다. 예를 들어, SLA에 전체 릴리스의 95%가 합의된 시간대 내에 실행되어야 한다는 내용을 넣을 수 있습니다. 이 경우 보고서에서 릴리스 관리의 전반적인 성과가 나타나므로 보고서의 중요성이 커집니다. 요약하자면, 성공적인 릴리스 실행을 위한 목표를 설정하고 보고 주기를 결정한 다음 이 보고서를 전체 IT 관리자에게 배포하는 것입니다.

  • 비즈니스 조정 지표 – 성공적이고 적시에 실행되는 릴리스에 대해 합의된 SLA 목표가 있다면 이 보고서를 전체 비즈니스 관리자 또는 최소한 SLA에 서명한 관리자에게 배포해야 합니다.

이제 릴리스 관리를 위한 KPI 및 관리 정보를 풍부하게 갖추게 되었습니다. 매 보고 주기마다 모든 카테고리에 대해 보고하는 것이 어렵다거나 시간이 많이 소요된다고 생각할 수 있습니다. 하지만 ITIL은 구조임을 잊어서는 안됩니다. 자신의 조직에 가장 의미가 큰 KPI 및 측정치를 택하여 이에 대해서만 보고하면 됩니다. 마지막으로, IT의 성공은 효과적인 변경 관리 및 릴리스 관리에 달려 있음을 잊지 말고 측정치를 아낌없이 사용하며 변경 관리 및 릴리스 관리를 향상시킬 수 있는 방법을 새로이 찾아내도록 항상 노력하십시오.

> > 제9장 - 구성 관리