ITIL의 목표
Sponsors:
ITIL의 목표
구성 관리의 목표
제 4 장
많은 ITIL 전문가들은 구성 관리가 다른 ITIL "위성"들이 그 주변을 둘러싸고 도는 ITIL의 "태양"이라고 말합니다. 모든 다른 ITIL 프로세스는 구성 관리와 밀접하게 연결되어 있기 때문에 이것은 적절한 비유입니다. 결국 구성 관리의 목표를 달성하는 것이 ITIL을 구현할 때 성공을 위해 필수적입니다. 귀사는 ITIL 구성 관리의 목표를 달성하고 있습니까? 이제 그 목표에 대해 살펴보겠습니다.
구성 관리는 존재하는 구성 항목(CI)의 버전을 식별, 제어, 유지, 검증하여 인프라 또는 서비스의 논리 모델을 제공합니다.
구성 관리의 목표는 아래와 같이 하는 것입니다.
- 조직과 그 서비스의 모든 IT 자산과 구성을 고려
- 모든 다른 서비스 매니지먼트 프로세스를 지원하기 위해 구성에 대한 정확한 정보 및 해당 문서 자료 제공
- 인시던트 관리, 문제 관리, 변경 관리, 릴리스 관리의 견실한 기초 제공
- 인프라를 기준으로 구성 기록을 검증하고 예외가 있으면 시정
구성 관리의 목표를 기본 구성 요소들로 분류하고 ITIL을 정당화하는 데 도움이 되도록 식별할 수 있는 요소가 무엇인지 알아보겠습니다.
"구성 관리는 존재하는 구성 항목(CI)의 버전을 식별, 제어, 유지, 검증하여 인프라 또는 서비스의 논리 모델을 제공":
이 요소를 살펴보기 전에 구성 항목에 대한 ITIL의 정의를 이해해야 합니다.
구성 관리에 의해 제어되는(또는 제어될) 인프라 구성 요소 또는 항목 CI는 전체 시스템(모든 하드웨어, 소프트웨어 및 문서 자료 포함)에서 단일 모듈 또는 작은 하드웨어 구성 요소에 이르기까지 복잡성, 크기, 유형이 매우 다양합니다.
구성 항목은 인프라 구성 요소로서 IT 고객에게 합의된 서비스를 제공하는 데 필요한 서비스, 시스템, 애플리케이션을 제공하기 위해 요구됩니다. CI의 복잡성은 선택적입니다. 예를 들어, 워크스테이션을 하나의 CI로 결정하거나 워크스테이션을 구성 요소(프로세서, 키보드, 마우스, 모니터)로 나누거나 이러한 구성 요소 각각을 CI로 만들 수 있습니다. 구성 관리는 주로 CI 간의 관계를 대상으로 합니다. 즉, 하나의 CI를 보면 그것이 특정 시스템 또는 서비스를 처리하는 데 필요한 다른 CI와 어떻게 관련되는지를 알 수 있습니다. 서비스 데스크에서는 CI들 간의 관계를 사용하여 영향을 설정하고 우선순위를 결정합니다. 자산 관리는 특정 가치 이상의 자산, 소속 사업부, 설치 위치에 대한 정보를 유지 관리하는 데 비해, 구성 관리는 자산 관리에서 다루지 않는 자산 간의 관계도 유지 관리합니다.
이 목표 요소를 충족하는지 여부를 평가하려 할 때 첫 번째 질문은 CI 또는 자산 간의 관계를 나타내는 데이터베이스가 있는지 여부를 결정하는 것입니다. 만약 없다면 영향을 어떻게 식별할 수 있겠습니까? 원격 재난에서 어떻게 복구하겠습니까? 먼저, 중앙 자산 데이터베이스가 있는지 확인하십시오. 만약 있다면 항목 간의 관계를 나타내고 그에 따라 사례를 준비하고 있는지 확인하십시오. 중앙 자산 데이터베이스가 없으면 그 자체가 강력한 이유가 있음을 알 수 있습니다.
이 목표 요소는 구성 항목의 식별, 제어, 유지 관리, 검증에 관하여 구체적으로 기술합니다. 여기서는 개념에서 종료에 이르기까지 CI 라이프 사이클에 대한 표준 접근 방식을 가지고 있는지 여부를 결정해야 합니다. 만약 가지고 있으면 해당 접근 방식이 모든 CI를 다루고 있는지, 제대로 유지 관리되고 있는지 확인합니다. 부정확한 데이터에 관한 좋은 단서는 서비스 데스크가 구성 및 자산 데이터베이스에 없는 구성 요소에 관한 고객의 전화를 받는 것입니다. 예를 들어, 어떤 고객이 "제 스캐너가 작동하지 않습니다"라고 통지하면, 서비스 데스크에서는 "저희 기록에 따르면 현재 고객은 스캐너를 가지고 있지 않으므로 당연한 결과입니다."라고 답변하는 것입니다. (농담처럼 들리지만 포인트를 잘 말해주고 있습니다.) 요약하면 검사할 두 가지 사항은 CI를 식별 및 제어하는 프로세스 또는 절차가 있는지 여부와 해당 CI의 상태를 유지 관리하는 프로세스나 절차가 있는지 여부입니다. 검사 결과에 따라 이유를 준비하십시오.
"조직과 그 서비스의 모든 IT 자산과 구성을 고려": 모든 CI가 자산으로 나타나는 것은 아니기 때문에 이것은 중요한 목표입니다. 예를 들어, 일반적으로 사내에서 제작한 프로그램, 절차 문서 자료, 인력은 자산으로 나타나지 않지만 그것들은 모두 구성 항목입니다. 이 목표 요소는 모든 잠재적 CI가 구성 관리 데이터베이스(CMDB)에 포함되도록 보증하기 위한 검사를 수행한다는 것을 의미합니다. 이 목표 요소를 달성하는지 여부는 쉽게 결정할 수 있습니다. 즉, 검사했는지 여부만 확인하면 됩니다. 물론 CMDB가 없으면 어떤 방법으로도 검사할 것이 없습니다.
"모든 다른 서비스 매니지먼트 프로세스를 지원하기 위해 구성에 대한 정확한 정보 및 해당 문서 자료 제공": CMDB의 데이터가 정확하다고 가정하면 이런 질문이 가능합니다. 어떻게 그것을 다른 서비스 매니지먼트 프로세스에 사용할 수 있게 만듭니까? 서비스 매니지먼트 프로세스 간의 통합은 중요합니다. 예를 들어, 서비스 데스크가 인시던트 레코드에 데이터를 입력할 때 CI 데이터베이스는 해당 레코드를 구성 및 문서 자료 정보로 자동으로 채웁니까? 또는 서비스 데스크 상담원이 그 정보를 수동으로 입력해야 합니까? 더욱 나쁜 경우로, 사용할 수 있는 데이터가 없기 때문에 데이터가 전혀 입력되지 않습니까? 이 목표 요소를 달성하는지 여부를 검사하려면, 다른 서비스 매니지먼트 프로세스를 검토하여 CMDB 데이터가 사용할 수 있는데도 사용되지 않은 영역이 있는지 식별합니다. 물론 구성 데이터베이스가 없으면 어떤 방법으로도 검사할 것이 없습니다.
"인시던트 관리, 문제 관리, 변경 관리, 릴리스 관리의 견실한 기초 제공": 인시던트, 문제, 변경 관리는 정보 및 더욱 중요하게는 의사 결정 관리를 위해 CMDB를 사용하는 프로세스입니다. 정확하고 완벽한 CMDB가 있으면 완벽한 정보를 갖춘 의사결정이 이루어져서 문제 또는 인시던트의 영향을 식별할 수 있습니다. 또한 잠재적 변경에 대한 비용을 더 정확하게 계산할 수 있으며, 단계별 통보의 정확성이 개선됩니다.
서비스 매니지먼트의 지식 도구에 대해서는 많은 논란이 있습니다. 아마 가장 중요한 지식은 현재 가지고 있는 자산의 종류와 그 위치 및 자산들 간의 상관 관계에 대한 지식, 다시 말해서 CMDB에 포함된 정보일 것입니다. 그런데도 CMDB의 중요성이 간과되는 경우가 많습니다. 이 목표 요소는 CI에 포함된 속성에 초점을 맞춥니다. 단순히 CMDB가 있다는 것만으로는 부족합니다.
각 CI는 다른 서비스 매니지먼트 프로세스에 의미 있는 정보를 제공하기 위한 데이터를 포함하고 있어야 합니다. 속성 필드 또는 CI에 대한 필드를 검토하여 데이터가 다른 서비스 매니지먼트 프로세스에 유익한 정보를 제공하는지 여부를 결정하십시오. 다른 프로세스의 소유자에게 필요한 데이터를 얻고 있는지, 만약 얻지 못한다면 필요로 하는 추가 데이터가 무엇인지 물어보아야 합니다. 이것으로부터 이 목표 요소를 달성하는지 여부를 결정할 수 있습니다. 물론 CMDB가 없으면 어떤 방법으로도 검사할 것이 없습니다.
"인프라를 기준으로 구성 기록을 검증하고 예외가 있으면 시정": 앞에서 언급했듯이, 구성 관리는 모든 다른 프로세스에 정보와 데이터를 제공합니다. 이 목표 요소는 모든 CI가 CMDB에 제시될 것을 요구하지 않고 CI의 내용이 정확할 것을 요구한다는 점을 제외하고는 이전 요소와 관계가 있습니다. 이전 요소와 마찬가지로 이 목표 요소를 달성하고 있는지 여부는 쉽게 검증할 수 있습니다. 즉, 검사하고 있는지 여부만 확인하면 됩니다. 물론 CMDB가 없으면 어떤 방법으로도 검사할 것이 없습니다.
지금까지 "물론 ...가 없으면 어떤 방법으로도 검사할 것이 없다"는 표현을 여러 번 보았을 것입니다. 그 이유는 이 메시지를 간과하는 경우가 많기 때문에 특별히 강조한 것입니다. Y2K에 투입한 재원의 70%가 단지 자산과 자산들 간의 관계를 추적하는 데에 소요된 것으로 추정되었습니다. 중앙의 정확하고 완벽한 CMDB가 없으면 즉시 경고를 발송해야 합니다.