#2. Service Management Practices (17가지)
-조직 환경에서 개발, 배포, 제공 및 지원되는 특정 서비스에 적용할 수 있는 Practices (SLA 관련)
-모든 서비스에 대해 고려되며 구체적으로 서비스에 적용 가능
-프로덕트 및 서비스를 관리하면서 전체적으로 실시해야 할 견해 제공
- 가용성 관리 (Availability Management)
- 비즈니스 요구사항을 충족하도록 보장하도록 보증하는 활동
- 서비스 자산의 가용성, 신뢰성, 효과성, 효율성의 결과
- 서비스 가용성 요건을 이해하고 그에 따라 서비스 정의, 설계, 배치 필요
- 가용성 정의 및 합의
- 인프라 및 서비스 설계
- 가용성 측정 데이터 식별 및 수집
- 가용성 분석 및 평가
- 지속적인 측정 및 보고
- 서비스 가용성 개선
- 비즈니스 분석 (Business Analysis)
- 비즈니스 및 비즈니스 요소를 분석하고 비즈니스에 적합한 해법을 찾아 솔루션 추천을 보증하는 활동
- 사람, 프로세스, 정책, 기술, 조직, 정보 등 전체적인 관점 고려
- 특정 영역이나 수준보다 전반적인 사업 기여도 고려
- 비즈니스 분석 활동
- 서비스, 서비스 아키텍처, 시스템, 프로세스 분석
- SVS의 구성요소 모두 고려
- 혁신 기회 파악
- 지속적인 모니터링, 측정, 보고, 문서화 수행
- 업무 수행이 비즈니스 요구사항에 부합하는지 점검
- 이해관계자와 성과 검증
- 분석을 통해 지속적인 해결 방안 마련 및 추진
- 비즈니스 및 비즈니스 요소를 분석하고 비즈니스에 적합한 해법을 찾아 솔루션 추천을 보증하는 활동
- 용량 및 성능 관리 (Capacity and Performance Management)
- 서비스가 충분한 용량을 이용 가능하고, 서비스가 요구하는 목표를 비용 효율적인 방법으로 달성하고 있음을 보장하는 활동
- 용량 및 성능 관리 활동
- 서비스 성능 확인, 용량 분석
- 서비스 성능 모니터링
- 지속적으로 용량 요구사항 조사, 분석, 예측
- 용량 계획 및 구현
- 용량 식별 및 개선
- 변경 촉진 (Change Enablement) **
- Change Control에서 Change Enablement로 변경 (ITIL 4의 방향성에 맞도록 변경됨)
- 리더가 아닌 직원이 변경에 대한 오너쉽을 가지고 변경을 구현
- Change Control은 결정권자를 개인이나 그룹으로부터 Top Down 으로 결정하는 구조 (변경의 필요성이나 의도를 인진하지 못하고 기계적으로 수행)
- 기계적 측면 강조
- Change Enablement는 폭넓은 커뮤니케이션에 중점을 두어 변경에 대한 전체 그림 제공 및 필요성 등 공유
- 사람 우선 (전체 팀이 적극 참여하도록 권장, 변경사항을 적용할 권한을 개인에게 부여)
- CAB이 Change Authority로 대체 (병목 구간 해소)
- 변경에 대한 자율성 제공 (변경 일정표를 수립하여 개별 변경 간 일정과 자원 조율, 이해관계자들과 원활한 커뮤니케이션 수행, 변경 이력 제공)
- 변경의 결정을 내릴 수 있는 자율성을 개인/팀에게 부여하여 CAB이 아닌 동료검토와 자동화를 통해 변경사항 검토하고 이를 통해 신속한 변경 가능 (CI/CD 같은 DevOps 개념 및 자동화 도구 도입)
- 변경 결과에 대한 책임은 소수 개인에게 집중되지 않고 그 영향을 받는 모든 사람에게 분산
- (OLD) Change Control
- 모든 변경에 대한 적절한 평가, 분석, 권한 부여를 통해 서비스 환경에서 실행되는 변경의 성공률 극대화
- 서비스 및 서비스 구성요소(하드웨어, 소프트웨어, 제품, 문서 등)에 대한 기능 추가, 변경, 개선, 제거 등 활동 의미
- 구현된 모든 변경 사항은 배포되기 전에 공식적인 승인 획득 필요 (시스템/서비스에 대한 무결성 보장 목적)
- 충분한 검토, 분석, 승인 활동 수행
- 모든 관련된 이해관계자 참여 통해 통제 수행
- 변경 유형
- 표준 변경 (Standard Changes) : 서비스 영향 및 위험이 적은 변경사항
- 일반 변경 (Normal Changes) : 비즈니스에 중대한 영향을 미치는 변경사항 (승인자의 검토 및 승인 필요)
- 긴급 변경 (Emergency Changes) : 장애 해결, 사후 대응적 문제관리 등 긴급 상황에서 발생하는 변경사항 (승인자의 승인이 필요하지만 이해관계자에 따라 다르게 적용 가능)
- Change Control에서 Change Enablement로 변경 (ITIL 4의 방향성에 맞도록 변경됨)
- 사고 관리 (Incident Management) **
- Incident : 계획되지 않은 IT 서비스 품질에 부정적인 영향을 미치는 중단 또는 성능 저하 등
- Incident 발생에 대해 빠른 해결 및 서비스 복원을 진행하여 Incident로 인해 발생되는 업무에 미치는 영향을 최소화하여 서비스를 정상 상태로 복원 (즉시적인 해결 목표)
- 신속한 서비스 복원을 목표로 하며 합의된 서비스 기준 내에서 가용성을 보장 필요
- 모든 Incident 기록/분류, 우선 순위 지정, 영향도 및 긴급도 등에 기반한 서비스 복구
- 다양한 유형의 Incident에 대해 리소스 할당 및 제공 필요
- Incident 관리 생명주기
- 인시던트 식별
- 인시던트 기록
- 인시던트 분류
- 우선순위 지정 = 영향도 * 시급성 (Response SLA, Resolution SLA)
- 진단 및 조치
- 해결 및 복구
- 인시던트 종료
- IT 자산 관리 (IT Asset Management) **
- IT 자산의 전체 수명주기(취득, 활용, 폐기)를 계획 및 관리하고, 가치 극대화, 비용 제어, 위험 관리, 자산 조달/활용/폐기와 관련된 의사결정 지원, 계약 및 규제 요구사항을 충족하도록 보증하는 활동
- ITIL 프레임워크에서 실행되는 산업의 자산관리를 의미 -> 서비스 관리 프랙티스
- IT 자산 : IT 제품이나 서비스 제공에 기여하며 재정적인 가치가 있는 구성요소 (소프트웨어, 하드웨어 등)
- 프로세스, 정책, 프레임워크 등은 IT 자산에 속하지 않음 (IT 자산과 생명주기가 다름)
- 자산관리 분류
- 하드웨어 자산 관리
- 소프트웨어 자산 관리
- 클라이언트 자산 관리
- 클라우드 기반 자산 관리
- 가치를 극대화하고, 비용을 통제하며, 리스크 관리, 자산의 구매, 재사용, 사용종료, 폐기에 대한 의사결정, 계약 및 규제 요구사항 충족 관리
- 정기적으로 정보를 업데이트하고 IT 자산은 무결성을 유지 필요
- 모니터링 및 이벤트 관리 (Monitoring and Event Management) **
- 서비스 및 서비스 구성요소가 안정적으로 운영되도록 서비스, 서비스 성과, 비즈니스 상태 변화를 감시 보고하는 활동
- 비즈니스에 대한 부정적인 영향을 방지하거나 제거하기 위해 수명주기 동안 이벤트 관리
- 각 CI를 일일이 다 모니터링하는 것이 아니라 서비스 작동에 직접적으로 관여하는 중요 CI 중심으로 모니터링 수행
- 장애 발생 시 취해야 하는 행동의 우선순위를 정해야 함
- Event : 서비스 또는 서비스 구성요소에 중요한 영향을 미치는 상태 변화 (Information, Warning, Exception)
- Information : 서비스에 심각한 영향을 미치지 않지만 발생 시 담당자에게 전달되어야 하는 이벤트
- 사용자 접속 시도, 응용 프로그램 일괄 작업 수행, 시스템 관리자의 데이터 센터 내 출입 등
- Warning : IT 서비스 장애로 진행될 수 있는 이벤트
- 메모리 사용량 임계치 접근, 어플리케이션 처리 지연, 시스템 및 시설의 온도 상승 등
- Exception : 서비스 또는 서비스 구성요소의 장애로 인해 비즈니스에 영향을 미치는 상황 (담당자 해결/복구 필요)
- 서비스 접속 불가, 잘못된 관리자 비밀번호 접속 시도, PC 악성코드 발견 등
- Information : 서비스에 심각한 영향을 미치지 않지만 발생 시 담당자에게 전달되어야 하는 이벤트
- 모니터링 및 이벤트 관리 프랙티스의 주요 활동
- 모니터링 전략 : 중요도 및 비즈니스 영향도에 따라 모니터링 대상을 선별
- 모니터링 설계 : 이벤트 유형을 식별, 예외/경고 이벤트에 대한 임계값 정의 및 조치 방안 정의
- 정책 관리 : 이벤트 발생 시 알림 발생 또는 담당자 할당 등 결정
- 모니터링 도구 구현 : Passive or Active 모니터링
- 프로세스 구현 : 프로세스의 역할과 책임을 식별, 접근권한 분류
- 문제 관리 (Problem Management) **
- 발생되는 Incident, Failure의 잠재적 또는 실질적 근본원인(Root Case)을 식별(가시성 제공)하고 영향을 줄이는 활동(해결책 제공)
- Incident Management는 조치 및 수정과 신속성에 중점을 두며 Problem Management는 예방과 정확성에 중점을 둠
- Problem : 하나 이상의 Incident의 근본 원인 또는 잠재적인 원인
- Root Case : 어떤 Event의 근본적인 원인
- Root Case Analysis (RCA) : 근본원인 분석 활동을 통해 근본원인을 식별흐는 과정
- Permanent Solution : 근본원인을 영구적으로 제거하는 방법 및 기술
- Workaround : 인시던트의 영향도와 발생 가능성을 감소시키는 임시 방법
- Known Error : 인시던트를 유발할 수 있는 분석이 완료되었지만 아직 해결은 되지 않은 상태의 문제
- KEDB (Known Error Database) : 모든 KE가 등록된 데이터베이스
- 인시던트의 근본원인을 알 수 없을 경우 문제로 등록하고 근본원인이 식별되면 문제 관리 프로세스에 따라 관리
- 이러한 원인을 식별하고 해결방법을 제공하여 문제를 해결하도록 지원 (Identification, Problem Control, Error Control)
- Problem Identification : 문제 식별/로깅 (Incident 추이 분석, 중복 장애 분석, 주요 장애 상황과 관련된 Problem 식별)
- Problem Control : 문제 분석, 해결방법 식별, 조치 (Known error에 대한 해결 솔루션 제공)
- Error Control : 정기적으로 식별되는 모든 오류를 평가, 분석 (근본적인 조치 및 해결방법 식별 및 조치 지원)
- 릴리즈 관리 (Release Management) **
- 신규/변경 서비스를 소비자들이 적시에 이용할 수 있도록 하는 보증하는 활동
- 서비스 변경에 대한 전체 관리를 수행하고 서비스 또는 서비스 구성요소인 기술적, 비기술적 릴리즈 측면 함께 고려
- Release : 고객, 사용자가 이용할 수 있도록 만들어 놓은 특정 버전의 항목들
- 소프트웨어, 하드웨어 등 성공적인 롤 아웃 보장 (프로덕트 환경에서의 변경을 최소화)
- 릴리즈 관리와 배포 관리는 밀접하게 동작서비스 운영환경에 릴리즈, 배포하기 위해 주어진 환경에 필요한 접근방식에 따라 다르게 구현
- 릴리즈 관리 기법
- PoC 및 Pilot
- Blue-Green 릴리즈
- 기능 플래그 : 기능 사용 여부를 간단히 토글하는 방식 (적용되어 있는 기능을 오픈하는 방식)
- 서비스 카탈로그 관리 (Service Catalog Management)
- 합의된 모든 서비스에 대한 일관성 있는 정보 제공을 하기 위해 허용된 모든 사람들이 접근 가능하도록 서비스 카탈로그를 생성, 유지하는 활동
- 모든 운영 서비스에 대한 정확한 정보가 저장되도록 주기적으로 업데이트, 수정, 유지 관리 필요
- 카탈로그에 있는 서비스가 운영되도록 준비
- 서비스 정의
- 서비스 카탈로그 작성 및 유지
- 서비스 카탈로그와 서비스 포트폴리오 간의 인터페이스, 상호 의존 관계, 일관성 설정
- 서비스 카탈로그와 CMS에서 모든 서비스와 지원 서비스 간 인터페이스, 상호 의존 관계 및 일관성 설정
- 서비스 구성 관리 (Service Configuration Management) **
- 서비스 구성 및 구성항목(CI)들을 서비스를 형성 또는 사용하기 위해 필요할 경우 언제 어디서나 사용할 수 있도록 가용성을 보장하는 활동
- 모든 구성항목(CI) 및 관계에 대한 정보를 저장하는 구성 데이터베이스를 식별, 캡쳐, 관리하는 활동 수행
- 구성항목(CI) : 모든 소프트웨어, 하드웨어, 사람, 문서, 건물 등 서비스를 제공하기 위해 관리해야 하는 모든 구성요소
- 구성정보의 스냅 샷, 구성정보 간의 관계 등에 대해 무결성, 최신성 등 제공 (Identify, Update, Verify, Audit)
- CMDB : CI와 이들의 관계정보를 저장하고 있는 레파지토리
- CMS : CMDB를 포함한 상위 데이터베이스 (KEDB, 인시던트, 문제, 서비스요청, 변경, 릴리즈 등 모든 정보 포함)
- Service Model : CMDB에서 CI간의 연결 관계를 그래픽하게 보여주는 것
- 서비스 연속성 관리 (Service Continuity Management)
- 재해(홍수, 허리케인, 지진 등) 발생 시 비즈니스 및 서비스가 지속될 수 있도록 충분한 서비스 가용성을 보장하는 활동
- 조직 및 브랜드의 명성, 이해관계자의 이익 보호, 가치를 창출
- 서비스 연속성에 필요한 복원력을 구축하는데 필요한 프레임 워크를 제공하는 것 목표
- 최소한의 비즈니스 유지, 필요한 서비스 가용성 보장
- BIA(Business Impact Analysis)를 실시하고 재해 복구 계획을 수립, RTO 및 RPO를 정의
- 서비스 설계 (Service Design)
- 고객의 목표 달성이 가능하도록 효율적이고 효과적인 서비스 및 프로세스를 설계 개발하는 활동
- 서비스 개발을 위해 활동 수행
- 급변하는 비즈니스 환경에 맞춰 균형 잡힌 설계가 필요 (Resource, Schedule, Functionality)
- 5가지 주요 관점
- 서비스 : 서비스 요구사항에 집중하기 위한 서비스 그 자체 (service itself)
- 서비스 관리 시스템 : 서비스를 지원하기 위해 필요한 시스템 및 도구
- 기술 아키텍처 : 서비스에 활용되거나 참고되는 기술 아키텍처
- 서비스 관리 프로세스 : 서비스를 지원하기 위한 프로세스
- 평가시스템 : 서비스 성능 확인을 위해 필요한 사항
- The 4P of Service Design
- People : 서비스를 위한 인적 자원 및 조직 구조
- Process : 서비스를 위한 서비스 관리 프로세스
- Product : 서비스를 위한 기술 및 인프라 환경
- Partner : 서비스를 위해 필요한 3rd Party
- 서비스 데스크 (Service Desk) **
- 서비스 중단, 서비스 문의 등 사용자가 연락할 수 있는 단일 연락 창구 운영을 보장하는 활동
- 서비스 요청과 인시던트에 대한 해결요청을 적시에 효과적으로 처리하는 활동
- 사람 주도형 프랙티스
- Help Desk (Incident 처리) < Service Desk(Incident+Service Request)
- 방문, 전화, 이메일, 채팅, Portal, 메시지, SNS 등 채널 활용
- 어플리케이션 지원 조직은 1선, 2선, 3선으로 구분
- 사용자에게 단일 접점을 제공하여 사용자의 향상된 접근성 제공, 만족도 향상, 빠른 회신, 비용 최적화 등 가능
- 서비스 데스크 목적
- 서비스 제공자를 대표하여 사용자 요구사항을 이해하고 불만 및 불안을 처리
- 인시던트 및 서비스 요청을 접수하고 기록하는 창구 역할
- 서비스 데스크 유형
- 로컬 서비스 데스크 : 특정 지역, 위치, 사무실에 국한된 서비스 데스크
- 통합 서비스 데스크 : 사업장별로 존재하지 않고 통합된 서비스 데스크 하나 존재
- 가상 서비스 데스크 : 분산되어 있지만 커뮤니케이션 기술을 통해 통합 구현
- follow the sun : 해가 떠 있는 지역에서 순차적으로 서비스 데스크 운영
- specialized service desk : 각 분야의 전문가들로 구성된 서비스 데스크로 전세계에 흩어져 있는 분야별 전문가들을 하나로 묶어 제공
- 서비스 수준 관리 (Service Level Management) **
- 서비스 수준에 대한 명확한 비즈니스 목표를 설정하고, 목표에 부합하도록 서비스가 제대로 제공되고 있는지 평가, 모니터링, 관리하는 활동
- 고객과 서비스 제공자가 서비스 수준을 합의하고 추적 관리하는 활동
- 해관계자와의 운영상의 관계에 초점
- Service Level : 서비스 품질의 기대치를 정의한 메트릭
- Service Level Agreement : 필요한 서비스들과 서비스 기대 수준을 기록한 서비스 제공자와 고객 간의 문서화된 계약
- Service Level은 서비스를 구성하는 각각의 개별요소(서버 등)의 가용성은 이에 해당하지 않음
- SLA는 정리되어 고객과 서비스 제공자 간의 계약 문서에 첨부
- SLA 구성요소
- 서비스 카탈로그
- 서비스 수준
- 당사자 동의
- 서비스 수준에 대한 명확한 비즈니스 목표를 설정하고, 목표에 부합하도록 서비스가 제대로 제공되고 있는지 평가, 모니터링, 관리하는 활동
- 서비스 요청 관리 (Service Request Management)
- 고객과 서비스 제공자가 미리 합의한 서비스 수준을 기반으로 서비스 요청이 이행되도록 하는 활동
- 사전에 합의한 서비스 수준은 서비스 카탈로그에 명시되어 있어야 함
- 사용자의 요청을 전문적이고 친숙한 방식으로 처리하여
- 합의된 서비스 품질을 지원하는 활동
- 서비스 요청 유형
- Service Action : PC 또는 S/W 설치
- Information Request : 사용방법 문의, 회의실 사용 문의
- Resource Access : 개발 서버 접근, 시스템 사용 권한 요청
- Feedback : 서비스에 대한 칭찬, 불만
- 서비스 검증 및 테스트 (Service Validation and Testing)
- 신규 또는 변경된 서비스 및 제품의 품질과 에러를 통제하여, 고객에게 서비스 품질을 보장하고 요구를 충족시키는 활동
- 관련 활동
- 서비스 수준 테스트 : 가용성, 용량, 연속성등의 목적에 부합하는지 확인
- 계약 및 규정 테스트 : 계약 조건 및 서비스 규정을 만족하는지 확인
- 운영 테스트 : 배포 이후 원활하게 서비스 운영이 가능한지 확인
'ICT 관련 동향 > ITIL 4' 카테고리의 다른 글
| CMDB 소프트웨어 (0) | 2023.08.07 |
|---|---|
| ITIL 4 SVS의 Continual Improvement (0) | 2023.03.26 |
| ITIL v4 Practices (I) - General management practices(14) (0) | 2023.03.17 |
| ITIL(Information Technology Infrastructure Library)v4의 개요(1) (1) | 2023.03.15 |
| Technical Management Practice (0) | 2023.01.04 |
댓글