카테고리 없음

ITSM, ITIL ('20.04.08)

정상에서만납시다 2020. 4. 8. 20:45

ITIL에서는 서비스지원 (Service Support) 영역과 서비스공급 (Service Delivery) 영역을 합쳐 ITSM이라 정의하고 있다. 
   - 서비스지원 영역 : 서비스데스크, 서비스요청, 장애, 문제, 변경, 구성관리 등

즉, ITSM은 ITIL의 일부분인 것이다.

ITSM 시스템의 구성요소 : 통합 모니터링, 업무자동화, 현황 대시보드, 비즈니스 리스크관리 시스템

1. 통합 모니터링, 2. 업무 자동화, 3. 현황 대시보드, 4. 비즈니스 리스크 관리
   1.1 장애 이벤트, 1.2 성능 이벤트
   2.1 서비스데스크, 2.2 장애관리, 2.3 문제관리, 2.4 변경관리, 2.5 구성관리
   3.1 경영층 관점, 3.2 관리자 관점, 3.3 실무자 관점, 3.4 고객, 사용자 관점
   4.1 비즈니스리스크관리, 4.2 영업연속성계획, 4.3 재해복구계획

CMDB (Configuration Management Database)
CMDB는 IT거버넌스의 ITAM(IT Asset Management)에 대비 된다.

CDB(Capacity DB)는 Business Capacity, Service Capacity, Resource Capacity에 대해 정의하고 있다.   
   - 이러한 용량계획은 기존의 용량 실적 자료를 이용하여 예측을 하게 되는데, 이러한 용량 실적 자료들을 담는 용기가 CDB(Capacity DB) 즉, 용량 데이터베이스이다. CDB 구축은 개별 관리도구들에 저장된 성능(CPU, Memory, Transaction 등) 데이터베이스와 연계하여 CDB를 구축하게 된다.

ADB(Availability DB) 
   - ITIL의 가용성관리(Availability Management)에서는 서비스수준관리와 연계한 3가지 관점의 가용성을 관리할 것을 권장하고 있다. 즉, 고객에 대한 IT서비스 조직간의 서비스 가용성을 관리하는 SLA(Service Level Agreements), 내부 IT서비스 조직간의 책임 및 서비스수준을 관리하는 OLA(Operation Level Agreements), 외부 공급업체의 서비스 수준을 관리하는 UC(Underpinning Contracts) 등이 그것이다.

IT서비스 성숙도 판단 기준 (프로세스, 기술, 조직 및 인력)

비즈니스 리스크 관리
   - 비지니스 리스크 관리의 목적은 전산 장애로 인한 비즈니스 리스크를 줄이기 위하여 장애 발생 시 신속하게 감지하고, 장애가 미치는 비즈니스 영향 범위를 신속히 파악, 해당 조직에 장애 상황을 전파함으로써 비즈니스 조직이 장애에 신속히 대응할 수 있도록 하고, 아울러 비즈니스 영향도 분석에 기초한 장애 원인 활동을 지원함으로써 장애를 신속히 조치할 수 있도록 하는 것이다.

비즈니스 리스크관리의 개념은 재해복구계획(DR:Disaster Recovery Plan)과 업무연속성계획(BCP:Business Continuity Plan)의 개념과 유사하다. 재해복구계획이 재난 발생시의 업무 연속성을 보장하기 위하여 중요 시스템과 데이터에 대한 백업 체계를 마련하는 것이고, 업무연속성 계획은 재해복구계획에 추가하여 업무 기능, 수행 조직 및 업무대체 장소의 확보를 통해 업무의 연속적인 수행을 보장하는 것을 말한다.

하지만, 비즈니스 리스크 관리는 기존의 재해복구계획이나 업무 연속성 계획과는 근본적으로 큰 차이를 가진다. 그것은 기존의 재해복구계획과 업무연속성 계획이 비상시나 재난시의 리스크 관리 인데 반해 비즈니스 리스크 관리는 업무 수행중의 운영 리스크를 관리하는 데 중점을 둔다는 것이다. 즉, 업무연속성 계획이나 재해복구계획이 가동되기 전에 리스크를 사전 제거하여 업무연속성을 확보한다는 데 그 목적이 있는 것이다.

비즈니스 리스크 관리의 핵심 개념은 업무 중단 시간을 최소화하기 위해 장애시간 분석을 기초로 한 시간 낭비 요인을 최대한 제거하는 것이다. 즉, 장애의 감지, 인식, 전파, 원인분석 등 시간 지체 요인을 찾아 최대한 단축시기키는 방안을 찾아 이에 대한 해결방안을 제시하는 것이다.

업무중단시간 (MTTR : Mean Time to Repair) - 전산 장애로 인해 업무가 중단된 총 시간

ITSM을 도입하는 주된 목적은, 반복되는 장애를 검색하여 문제관리를 통해 원인을 해결하고, 현황 대시보드를 통해 제공되는 여러가지 분석 통계 결과로 수분 내에 멋드러진 보고서를 완성하고, 비즈니스 리스크 관리에서 제공되는 다양한 장애 원인 분석 기능을 통해 한결 수월하게 장애 원인을 찾아 내고, 현황 대시 보드나 상황판 모니터링을 통해 취약점을 찾아 내어 조치를 취하고, ITSM 업무자동화 시스템에 장애 조치 현황을 등록해 놓으면 별도의 장애 보고를 위해 불려 다니는 일도 없어지고 하는 즉, 사람들의 단순하고 반복되는 작업에서 해방시켜 주는 역할을 하는 것이다.

Microsoft에서도  Release Management를 개발조직과 운영조직이 공유하는 영역으로 정의하고 이들에 대해서는 양 조직의 협력을 언급하고 있다. 장애의 원인 분석 과정이나 변경 테스트작업 등 개발조직과 운영조직은  ITSM의 구축에 있어 공동보조를 맞추어 나가야 하는 것이다.

   - MSF (Microsoft Solution Framework) : Product Mgmt. - Program Mgmt. - Development - Test - Release Mgmt. - User Experience
   - MOF (Microsoft Operation Framework) : Operation - Release - Service - infrastructure - Partner - Security - Support

결과적으로 볼 때 ITSM 시스템 구축 목표는 기술력의 축적이 아니다. 외부의 기술력을 활용하여 IT서비스의 안정성을 최대한 빨리 확보하는 것이 목표가 되어야 한다.

고객 서비스 가용성 모니터링 및 통제 (BSM: Business Service Management)

전사 IT조직 및 자원에 대한 통제 (IT Governance)

IT 서비스에 대한 서비스 수준 계약 (SLA) 검토 및 체결

IT 서비스 성과 관리 (IT BSC: IT Balanced Score Card)

IT 서비스 요청 및 만족도 평가

품질보증팀(QA:Quality Assurance)

ITSM은 프로젝트 구축과정보다 구축 이후의 운영단계가 훨씬 중요하다. 효율적인 프로젝트 진행을 위해서는 프로젝트 관리자와 별개로 품질보증팀을 구성할 필요가 있다. 품질보증 필수활동은 다음과 같다.

   - 프로젝트 수행 계획 적정성 평가)일정, 인력 및 Resource 투입, 목표, 산출물 등)
   - 프로젝트 산출물 검토(산출물의 적정성, 산출물 Template 검토, 결과 검토)
   - 수행 단계별 활동 평가(일정 지연 여부, 활동 누락 여부 등)
   - 프로젝트 리스크 및 이슈 평가

ITSM 프로젝트 주관조직은 어떤 조직이 적합할까?  
   - 국내의 경우를 보면 운영조직이 주관하는 경우와 기획조직이 주관하는 경우 등 두 가지 유형으로 분류된다. 개발조직이 주관하는 경우는 극히 드물다(이는 ITSM이 개발프로세스보다는 운영프로세스에 초점을 맞추고 있기 때문이다)

서비스데스트(Service Desk)
   - ITIL에서는 서비스데스크의 가장 중요한 기능으로 SPOC(Single Point Of Contract)이라고 하는 접수창구 단일화를 요구한다.

인시던트 관리(Incident Management)

문제관리(Problem Management)   
   - ITIL에서는 문제관리 프로세스에서 Error Control 기능과 장애기록 분석 등의 활동을 통해 Known Error(알려진 오류)를 도출하여 KEDB를 구축, 활용을 통해 장애 재발을 방지하여야 한다고 권장하고 있다.

변경관리(Change Management) 및 릴리즈관리(Release Management)     
   - 크게 운영조직의 변경관리와 개발조직의 변경관리로 구분된다.

구성관리(Configuration Management) 
   - ITSM 프로젝트에서 가장 중요한 하나를 꼽으라면 단연 CI(Configuration Item: 구성자원유형)를 들 수 있다. CI는 ITSM프로젝트의 방향성과 ITSM 시스템의 프로젝트 범위와 성공여부를 결정짓는 가장 중요한 잣대이다. 잘못 정의된 CI는 프로젝트 전체를 혼란에 빠뜨리기도 한다.

[참고도서] ITSM 구축 프로젝트