삶은달걀노른자

ITIL Foundation 시험 수준에서 변경과 관련된 프랙티스는 두 가지이다. • 서비스 요청 관리 Service request management • 변경 통제 Change Enable (Change control) 이 중 먼저 서비스 요청 관리에 대해 알아보기로 한다. 서비스 요청 관리는 고객과 서비스 제공자 양자가 미리 합의된 서비스 수준을 기반으로 서비스 요청이 이행되도록 하는 것으로, 일반적으로 이러한 요청은 사전 합의된 활동을 말한다. 서비스 요청 "A request from a user or a user’s authorized representative that initiates a service action that has been agreed as a normal part of ser..

인시던트 관리가 문제사항에 대해 즉시적인 해결을 하는 게 목적이라면, 문제 관리의 목적은 인시던트의 원인을 파고들어 근본 원인(root cause)을 밝혀냄으로써 해당 원인과 관련된 인시던트가 반복되지 않도록 하는 것이다. 즉, 인시던트 관리 프랙티스가 조치 및 수정을 다룬다면, 문제 관리 프랙티스는 예방에 중점을 둔다고 할 수 있다. 또한 인시던트 관리는 신속성이, 문제 관리는 정확성이 핵심이다. ITIL에서 정의하는 문제(Problem)란 다음과 같다. ITIL 문제 정의 "A cause, or potential cause, of one or more incidents" "한 개 이상 인시던트의 실재하는 원인이나 잠재적 원인" 인시던트의 근본원인을 알 수 없을 때에만 문제로 등록이 되며, 근본원인이 ..

ITIL의 핵심은 사실 운영(operation)이다. 운영은 제품과 서비스가 종료되지 않고 살아있는 한 그리고 고객에게 계속 제공되는 한 계속 활성화 상태이다. 또한 고객과의 상호작용이 주로 운영의 영역에서 발생하기 때문에 고객은 다른 어떤 프랙티스보다도 이 운영에서의 서비스를 기억할 수밖에 없다. 운영 프랙티스는 서비스의 전체 시간 중 가장 많은 시간을 차지하며, 인력 면에서도 보통 가장 규모가 크다. 그리고 앞서 언급한대로 고객은 운영 단계의 성과를 통해 서비스에 대한 인식(perception)을 형성하는 경향이 있다. 운영의 이전 단계인 전략 수립, 설계, 구현, 전환이 모두 완벽하다면 사실 운영 역시 문제가 없을 것이다. 하지만 현실적으로 그런 일은 결코 있을 수 없다. 전략은 시간에 따라 변하고..

ITIL 4에서의 가장 큰 변화는 기존 Process와 Function 체계를 Practice 로 바꾼 것이라 할 수 있다. Process 체계가 큰 문제가 있었던 건 아니지만 이를 적용하고 사용하기 위한 러닝커브가 크다는 단점이 있었다. 또한 이 변화는 ITIL이 Agile이나 DevOps와 통합하기 위한 해결책이기도 하다. ITIL에서 프로세스는 입력을 출력으로 바꾸는 일련의 활동과 workflow 이며, 기능(Function)이란 이런 프로세스 활동을 수행하기 위해 리소스를 제공하는 팀 이라고 정의할 수 있다. 그러니깐 우리가 일반적으로 일고 있는 팀이란 것이 바로 Function으로서 프로세스 수행을 위해 만들어진 기능인 것이다. ITIL 4에서 practice는 프로세스와 기능이 통합된 형태로 ..

ITIL 4 Foundation의 덤프 문제는 아니지만 학습에 되움이 되므로 출처를 밝히고 정리하여 올린다. 출처 : Become ITIL® 4 Foundation Certified in 7 Days Understand and Prepare for the ITIL Foundation Exam with Real-life Examples 아래 문제들은 Service Value System의 한 파트인 Guiding Principle (가이드 원칙)에 해당하는 것들이다. (정답은 하단에) 6-1. You are a service management consultant hired by a company to investigate the reasons for their customer’s dissatisfacti..

ITIL 4 Foundation의 덤프 문제는 아니지만 학습에 되움이 되므로 출처를 밝히고 정리하여 올린다. 출처 : Become ITIL® 4 Foundation Certified in 7 Days Understand and Prepare for the ITIL Foundation Exam with Real-life Examples 아래 문제들은 지금까지 포스팅한 범위까지에 해당하는 것들이다. (정답은 하단에) 3-1. Which definition is this referring to? A person or a group of people that has its own functions with responsibilities, authorities, and relationships to achieve..

ITSM의 서비스요청 프로세스는 고객의 요청사항을 접수하여 처리하는 것이므로 ITO 업무의 모든 요청이 포함된다. 이 중 서비스문의는 지난 포스팅에서 살펴 보았고, 이번에는 운영SR과 개발SR을 보겠다. 서비스문의 역시 넓게 보면 운영SR에 포함되지만 성격이 좀 다르고 프로세스가 상이하므로 별도로 구분한다. 보통 운영SR이라 함은 다음과 같다. - 자료요청 - 데이터변경요청 - 데이터검증요청 - 업무지원요청 - 상품정보변경 등 비즈니스 관련 처리 요청 단순히 자료를 요청하거나 특정 데이터의 변경을 요청하는 등 운영SR은 프로세스가 단순하다고 볼 수도 있으나 어느 수준까지 통제를 가하냐에 따라 복잡도가 달라진다. - 요청자가 SR 등록 후 부서장의 승인을 받을 것인가 - 요청하는 자료에 고객정보(개인정보)..

서비스요청 관리는 서비스문의, 업무지원요청, 개발요청, 인프라변경 요청 등 고객으로부터 접수되는 모든 유형의 요청을 관리하는 것을 말한다. 서비스요청 관리의 정책은 다음과 같다. ITO 고객에게 서비스 제공을 위한 접점을 마련한다. - ITO 고객이라 함은 서비스를 제공받는 고객사 임직원을 말하며, 대고객은 대상이 아니다. - 전화 접수 채널(ISC)에 대한 지원 범위는 별도의 ISC 계약을 따른다. - ITO 계약과 무관하게 수용되어야 하는 서비스는 전략적 의사결정을 통해 고객과 별도 협의한다. ITSM 서비스 딜리버리는 ITO 운영모델에 따라 도메인(Domain) 단위 관리를 원칙으로 한다. - 도메인 별 요청되는 SR을 관리하기 위한 역할자(BA)를 구성한다. - 도메인 별 SR Capacity는 ..

ITSM 시스템의 구현은 기업 내 IT서비스를 관리하는 목적이 있는데, 단일한 플랫폼의 서비스를 구현하여 여러 기업에 제공할 수 있다면 비용효율적일 것이다. A기업의 ITSM은 B사에서 구축하여 제공하고 있는데, A기업은 모기업 뿐 아니라 여러 그룹사들까지 있어서 이들을 모두 커버할 수 있는 ITSM 시스템이 필요했다. 따라서 멀티테넌시라고 하는 개념을 도입하여 단일 플랫폼 상에서 각 그룹사 간의 간섭 없이 서비스가 제공될 수 있도록 구현이 되었다. 위키백과에 정의된 멀티테넌시 출처소프트웨어 멀티테넌시(software multitenancy)라는 용어는 소프트웨어 아키텍처의 하나를 가리키며, 여기에서 하나의 소프트웨어 인스턴스가 한 대의 서버 위에서 동작하면서 여러 개의 테넌트(tenant)를 서비스한다..

모 기업의 IT 업무 구조는 다음과 같다. ● 도메인(Domain) : 기업의 ITO 업무 수행을 위한 기본 단위로서, ITO 운영비용 산정은 보통 도메인 단위로 이루어진다. 같은 도메인은 개발/운영 환경, 인력단가, 운영기준 등이 동일한 것으로 간주된다. ● 서비스(Service) - 표준서비스 - 단위서비스 : ITSM(ITIL)에서 서비스라는 용어로 정의되는 단위로 보통 필드에서는 시스템이라고 많이 말한다. 표준서비스와 단위서비스가 있는데 표준서비스는 보통의 시스템이고, 단위서비스는 서브시스템이라고 보면 된다. ● 파트(Part) : 쉽게 생각하면 위에서 말한 단위서비스라고 할 수 있으나 반드시 일치하지는 않는다. 단위서비스는 서브시스템의 개념이고 파트는 업무를 수행하는 조직(그룹)의 개념이 강하다..