CMDB란?

CMDB의 특징

CMDB가 하는 일, 구성 관리에서 CMDB의 역할, CMDB와 자산 관리의 관련성 및 차이점을 이해했습니다. 하지만 좀 더 실용적인 수준에서 CMDB 기능은 어떤 모습일까요?

CMDB의 핵심 기능적 특성은 다음과 같습니다.

CI 메트릭 및 분석이 포함된 원활한 대시보드를 통해 CI의 상태, 관계, 변경의 영향, 인시던트 또는 문제로 이어지는 패턴, 조직 내에서 각 서비스를 구축하고 유지 관리하는 비용(비용 및 리소스)을 쉽게 추적할 수 있습니다.

컴플라이언스 기능은 감사자에게 CI의 현재 상태뿐만 아니라 과거 변경 사항, 확인 및 균형, 인시던트 등에 대한 자세한 기록과 가시성을 제공합니다.

CI 만들기 및 데이터 적시에 채우기는 수동 입력, 통합(API 기반, SCCM) 및 검색 도구의 세 가지 방법으로 지원됩니다. 여기에는 조직 네트워크의 모든 IP 주소를 자동으로 검사하여 소프트웨어 및 하드웨어 정보를 효과적으로 수집하고 회사의 각 물리적 장치 및 가상 장치에 대한 인벤토리를 수집하는 것이 포함됩니다.

CI와 해당 데이터의 일반화 및 조정을 포함하여 페더레이션 데이터 세트를 지원합니다.

IT 서비스 매핑(일반적으로 관계 및 종속성을 그래픽으로 나타냄).

액세스 제어를 통해 필요에 따라 여러 직원이나 팀에 다양한 액세스 수준을 부여하고 질문 또는 인시던트가 발생하는 경우 변경 사항의 소스로 거슬러 추적할 수 있습니다.

CMDB 이점

CMDB가 해결하는 핵심 문제는 사일로화된 데이터와 오래된 정보입니다. CMDB를 구현하기 전 대부분의 조직은 소유자가 다양한 데이터가 여러 시스템에 분산되어 있어서 모든 CI와 해당하는 상호 종속성을 한눈에 확인할 수 없었으며, 어떤 것이 최근 정보인지 오래된 정보인지 파악하기가 더욱 어려웠습니다.

이러한 이유로 팀은 의사 결정을 내릴 때 중요한 컨텍스트를 이해하지 못하게 됩니다. 이는 위험 평가 및 보고에 영향을 미치고 의사 결정을 저해하며 이슈 해결이 느려지고 궁극적으로 재무 및 평판 측면에서 비즈니스에 손실을 줄 수 있습니다.

예를 들어 CI A의 데이터는 한 부서에 있고 CI B는 다른 부서에 있다고 가정해 보겠습니다. CI B는 제대로 작동하기 위해 CI A에 의존합니다. 그러나 CI A 부서에서는 유지 관리를 위해 오프라인으로 전환하기로 결정할 때 CI B에 미치는 영향을 알 방법이 없습니다.

팀 간에 혼란만 야기할 수 있습니다. 최악의 경우 주요 인시던트로 발전할 수 있습니다. 이러한 시나리오를 피하기 위해 필요한 것은 효과적인 CMDB뿐입니다.

Forrester는 오늘날 CMDB가 매우 중요한 세 가지 사용 사례를 식별했습니다.

계획수립

기술 관리자는 CMDB 데이터가 있어야만 엔터프라이즈 아키텍처 및 포트폴리오 관리를 통해 개괄적인 수준에서, 또 자산 및 작업 수용량 관리를 통해 보다 상세한 수준에서 계획을 수립할 수 있습니다.

회계

IT 재무 팀에서는 청구서를 할당하고 비즈니스 재무를 적절히 관리하기 위해 애플리케이션 또는 서비스 코드 기록이 필요합니다.

운영

CMDB는 변경 관리, 인시던트 관리 및 문제 관리를 비롯한 여러 핵심 ITSM 관행을 개선합니다.

변경 관리에서 CMDB는 영향을 받을 수 있는 사용자, 시스템 및 기타 CI를 예측하여 위험 평가를 개선할 수 있습니다. 또한 규제 대상 산업에서는 컴플라이언스를 지원하여 팀이 제어를 관리하도록 지원하고 명확한 감사 추적을 제공합니다.

인시던트 관리에서 CMDB는 인시던트를 유발한 변경 사항을 식별하고 더 빠르게 해결하도록 지원할 수 있습니다. 인시던트 기록을 관련 CI와 연결할 수 있으므로 팀은 영향을 받는 자산과 더불어 시간 경과에 따른 인시던트를 추적할 수 있습니다.

문제 관리에서 CMDB는 근본 원인 분석을 지원하기 때문에 팀은 문제의 핵심을 더 빠르게 파악할 수 있습니다. 또한 팀이 서비스 비용과 예상치 못한 가동 중지 시간을 줄이기 위해 업그레이드가 필요한 자산을 식별하도록 지원하여 사전 예방적인 문제 관리를 지원할 수도 있습니다.

결국 CMDB는 복잡성을 줄이고 오류를 방지하며 보안을 강화하고 변경 및 인시던트 관리와 같은 ITSM 관행이 원활하게 실행되도록 지원합니다.

CMDB의 당면 문제

업계 통계에 따르면 조직의 25%만이 CMDB 투자를 통해 의미 있는 가치를 얻고 있다고 합니다. 이렇게 높은 실패율로 인해 이 기술은 평판에 다소 문제가 있습니다.

좋은 소식은 실패의 원인을 예방할 수 있으며 예측 가능한 여섯 가지 범주로 분류되는 경향이 있다는 사실입니다.

문화

조직의 모든 것과 마찬가지로 문화와 팀의 이행 약속은 새로운 기술 및 프로세스의 성공 여부를 결정짓는 가장 중요한 요소 중 하나입니다. Harvard Business Review의 최근 연구에 따르면 경영진의 93%는 데이터 기반 디지털 혁신에서 가장 큰 문제는 인력과 프로세스라고 답했습니다. CMDB 프로젝트의 경우에도 마찬가지입니다.

관련성

CMDB는 종종 “단일 정보 소스”라고 불리며, 이로 인해 조직은 요구 사항과 관련된 사용 사례를 고려하지 않고 모든 데이터를 하나로 통합하려고 할 수 있습니다.

다른 데이터 리포지토리와 마찬가지로 CMDB는 변경 관리와 같은 내부 프로세스를 지원하는 집중적이고 유용한 데이터를 포함해야 합니다. CMDB에 가치 목표, 소유자 및 모든 변경 사항을 반영하도록 데이터를 업데이트하는 방법이 명확하게 정의되어 있는지 확인하세요.

중앙 집중식

CMDB가 자산 데이터를 볼 수 있는 중앙 집중식 위치라고 해서 모든 자산 데이터가 CMDB에만 있어야 한다는 것은 아닙니다. 이러한 일반적인 오해 때문에 팀이 모든 데이터를 이 "단일 정보 소스"로 옮기려고 할 때 너무 많은 작업으로 이어질 수 있습니다. 여기에서 가장 적합한 모범 사례는 각 사용 사례를 가장 잘 지원하는 도구가 사용되도록 다른 도구의 데이터를 페더레이션하는 것입니다.

예를 들어 ITFM(IT 재무 관리) 도구에 재무 데이터를 보관하고 SAM(소프트웨어 자산 관리) 도구를 사용하여 소프트웨어 라이선스 정보를 보관하는 것이 더 합리적입니다. CMDB가 기본 스토리지 공간이 아니더라도 CMDB에서 데이터를 가져오고 미러링할 수 있습니다.

정확도

많은 조직은 정확한 CMDB를 개발하고 유지 관리하는 데 어려움을 겪고 있습니다. 가장 일반적인 이슈는 검색 도구의 실행 빈도가 지나치게 낮거나 자동화 규칙이 없거나 수동 입력에 의존하는 경우입니다. 이러한 문제에 대한 일반적인 해답은 기존의 상향식 검색을 보완하는 이벤트 기반 검색입니다.

이러한 용어에 익숙하지 않은 사용자를 위해 설명하자면, 상향식 검색은 인프라에서 시작하여 고객 대상 CI로 확장되는 자산을 매핑하는 경우입니다. 이벤트 기반 검색이란 시스템 내부의 이벤트, 문제 등 시스템이 서로 통신하도록 하는 문제가 발생하는 경우를 말합니다. 그런 다음 시스템은 해당 이벤트를 기반으로 관련 CI와 연결을 매핑합니다.

모든 CI를 검색할 수 있는 것은 아닙니다. 예를 들어 팀에서 CMDB에 모니터를 매핑하려고 할 수 있습니다. 모니터는 자동화된 시스템으로는 검색할 수 없기 때문에 스프레드시트(또는 비슷한 방법)를 통해 수동으로 입력해야 합니다.

정확성의 핵심은 상향식 검색과 이벤트 기반 검색의 기능을 모두 활용하여 자산과 해당 연결을 가장 명확하게 파악하는 것입니다.

프로세스

일부 조직에서는 CMDB가 새로운 클라우드 및 소프트웨어 정의 인프라 스택과 여기에 호스팅되는 최신 워크플로가 아니라 레거시 인프라 및 소프트웨어를 모델링하기 위한 것이라는 인식을 가지고 있습니다.

사실 여기에서 중요한 것은 의미론에 대한 논쟁으로 인해 기술 에코시스템을 한눈에 파악할 수 있는 도구에서 레거시 CI 및 최신 CI를 추적하는 진정한 가치를 살펴보지 못하게 되어서는 안 된다는 사실입니다.

도구

위에 언급한 안타까운 실패적인 통계를 피하려면 올바른 도구를 선택하는 것이 가장 중요합니다. 일부 CMDB 도구는 물리적 레거시 인프라에 고정된 데이터 구조 및 변경 사항에 느리게 반응하는 검색 도구인 자산 리포지토리에 불과합니다. CMDB를 성공적으로 사용하려면 새로운 유형의 자산을 설명하고 신속한 변경이 가능한 CMDB가 필요합니다.

CMDB에서 관리할 항목 선택

CMDB 내에서 어떤 CI를 관리해야 하는지에 대한 만능 해결책은 없습니다. 각 조직의 사용 사례 및 목표에 따라 CMDB 설정에 적합한 범위와 깊이의 수준이 결정되어야 합니다. 일반적으로 높은 수준에서 시작하여 올바른 서비스를 포함한 다음 조직의 목표를 달성하는 데 필요한 경우에만 더 넓은 범위 또는 깊이 있게 진행하는 것이 좋습니다.

즉, CI는 기술 또는 기술 이외 엔터티로 광범위하게 그룹화할 수 있습니다.

기술 엔터티에는 비즈니스 서비스, 기술 서비스, 애플리케이션, 소프트웨어, 데이터베이스, 컨테이너, 가상 컴퓨터, 운영 체제, 하드웨어, 네트워크, 포트 등이 포함됩니다.

IT 서비스 매핑의 다른 자산에 영향을 받거나 종속되는 것으로 표현해야 하는 경우 기술 이외 엔터티도 CMDB에서 모델링할 수 있습니다. 기술 이외 엔터티에는 사용자, 고객, 조직, 위치, 서비스 계약, 문서 등이 포함될 수 있습니다.

마지막으로 CMDB 모델을 설계할 때 클라우드 서비스를 고려해야 합니다. SaaS 제품(예: Google 앱, Dropbox, Salesforce 등) 및 IaaS 제품(예: DigitalOcean, Linode, Rackspace, Amazon Web Services 등) 모두 필요에 따라 CI로 표현할 수 있습니다.