ITSM 실무자 교육

Session 1

Page 2.

1. 인시던트

• 장애관리다.
• V3에서는 REQUEST에 대한 처리 프로세스가 따로 있다.장애도 마찬가지..
• KEYWORD는 ASAP이다. 서비스를 ASAP로 처리한다..
• 고객이 허용하는 범위의 서비스 정상화.
• REACTIVE

2. 문제(Problem)

• DB화 한다. KNOWN ERROR DB
• 원인파악이 되지 않은 하나 혹은 그 이상의 인시던트
• PROACTIVE

우리는 KDB를 이용하지 않으므로 인시던트에 대한 처리가 개인화 되어 있는 단점이 있다.
인시던트의 해결을 위해 체계화된 처리 프로세스가 없다(문제에 대한) 결국 DB화 한 프로세스의 부재.

Page 5.

 

1.릴리즈(Release)

•  LIVE환경으로 도입된다(반영)
• 실제 변경에 대한 이행, SW든 INFRA든  모두 동일하다.

2. 변경요청(Request for Change)

 

3. 서비스데스크(Service Desk)

• 선진 그룹에서는 80~85%는 1선에서 다 한다.
• 고객과 접촉하는 1선을 의미한다.
• 예전의 콜센터이 개념보다 더 구체적이고 ACTION이 들어가 있다.
• FUNCTION이다 (기능)

4. 서비스 수준합의서(Service level agreement)

• DEFINE, AGGRE,
• OLA : 내부조직, OPERATION LEVEL AGREEMENT
• ,UC UnDERFING CONTROL (협력업체)

 

Page 6
1. Corrective

 

2. Known error

• KDB로 제대로 활용하기 위해서는 해결책이 제대로 나와 있어야한다.
• KDB를 활용하지 않는것은 KDB내에 해결책이 없으므로 활용도가 떨어진다.
• 절대적으로 DB로 활용될 수 있는 형태로 바꿔야 한다.

3. Service

• 우리가 서비스 하고 있는것은 무엇인가.?
• 우리는 알고 있는가.?
• 고객 관점에서는 비지니스 단위고 우리는 App, Infra 단위이므로 이부분을 알고 있어야한다.

ISO 20000 Process

 

1. Delivery : SLM에 포함되고 카타로그, OLA, UC

• 가용성관리
• 연속성관리
  
  - 복구 및 재난관리 포함.(몇시간내로 복구하겠다.) IT적인 연속성이다.
  - 개념은 평상시 100을 제공하고 재난이 났다면 100인데 20을 제공하겠다는
   약속, 계획이다.
  - KEYWORD : 20을 위한 복구 방법은 무엇인가.? 모의 훈련은 어떻게 하는가?
• 보안관리
  
  - ISO20000에서는 크게 다루지 않음.
• 용량관리
  
  - 비즈니스적인 용량요구사항을 받아서 우리가 지원할 수 있는 RESOURCE등의 지원활동은 무엇이고 이것을 계획하기 위해 무엇이 필요한다.
  - ex) 식당에서 밥을 미리 준비해 놓지 못한 경우.
• 재무관리
  
  - 정량적인 데이터는 여기서 나와줘야한다.
  - A는 100억 , B는 20억에 하자라는 계획
  - 비용은 어떻게 할 것인지.

2. Service Support

• Incident 관리내에 서비스데스크 포함.
• ASAP로 대응하고 문제를 발생시킬 수 있다.
• 근본 원인 파악이 안될 경우 문제로 이관
• 문제관리에서 KDB를 만든다.
• 문제 관리에서 RFC를 발행한다.
• 이후 CHANGE관리에서 CAB(변경영향평가)를 한다.
• 이후 최종 RELEASE (Build, test, Implement)
• 이후 다시 변경으로 돌아와 작업이 정상적인지 사후 검토한다.
• 사후 검토는 변경, 릴리즈가 정상적인지 + 또다른 장애를 유발하지 않는지 검토하라(PIR)
• 이후 구성관리에서 최신값을 반영해준다. 이를 보증하기 위해 추가적으로 구성감사를 한다.
• 이 모든 것이 CMDB에 제대로 들어 갈 수 있는지를 보증하는 행위다.

2. BRM (Business Releastion Manager)

• 경영진에게 가장 중요한 Business에 대한 관계에 대한 행위
• 불만처리
• 만족도 조사
• 고객들과의 관계에 대한 부분
• 여기서 애기한 불만은 공식적으로 어떻게 어떤 채널을 통해 처리것인가.!!

Session 4
Page 9
SLA
6.1 Service level management

• 합의하라 하지 않는다면 노비계약이다.
• 비용하고 연계가 되어 고객에게 제공하라. 즉 우리가 하는 일에 대한 정량적데이터가 존재하고 제공되어져야한다.
• 즉 규격화와 체계화가 필요하다.
• Service level Offering (고객이 sla맺지 않을 경우 필요)
• 제일 중요한것이 측정이 가능하고 레포팅되어야 한다.
• 카드를 너무 많이 보여주지 말라. 
• 평가지표와 내부지표를 따로 가져가고 고객이 요구할때 마다 모두 Open하지 말고 아쉬워 할때 강화된 내부지표를 보여줄 수 있다.
• 각 프로세스마다 지표를 만들고 최소한 한개 이상씩 관리되어야 한다.

 

Reporting
공식적으로 6가지를 다룬다.

 

- trend
- 만족도

 

self Assessment
재난선언 기준은?

 

기밀성 : 승인된 자만 제공
무결성 : 
가용성 : 원하는 시간에 제공

 

보안 정책에 대한 요구
- 리스크 평가
- training

 

용량 계획

 

Session 5
7.1 BRM

•  불만처리에 대한 공식 채널이 있어야한다.
• VOC라면 VOC로 처리하는 프로세스가 확립되어야한다.
• 만족도 는 기본이다.

2. 검토
3. Cutromer Satisfaction
4. Measurements of Customer Satisfaction

• 큰변경이 있은 후 해라
• 고객이 싫어하는 형태는 피하라

5. Self Assessment

 

7.3 Supplier Management

Session 6
8.2 Incident Mangement
 - 최대한 빨리 합의된 서비스를 제공하고 대응하라

•  

서비스데스크가 있으면 인원에 대한 가용성이 늘어난다.
싼 임금으로 1선해결 .

 

Priority
인시던트의 중요성을 판단하는 facter
이걸 못쓰게 되면 얼마만큼 못쓰게 되는가?
전체, 나, 일부

 

Urgency : 시간으로 몇시간 쓰지못해도 되는가?
Major로 정의되면 별도의 프로세스가 정의되어야한다.

 

8.3 Problem

• 대부분 인시던트가 발생되면 문제쪽으로 넘겨 1대1로 매핑되어 파악한다.
• 변경과 문제는 추가적 검토활동을 요구한다.
• 명확한 db화가 되어야 잘하는구나 할 수 있다.
• 향후 재발생 할 수 있는 인시던트를 막자

Session 7

 

9.1 Configuration Management 구성관리

• 변경작업시 변경되는 대상으로 정확히 기입되어야한다.
• 모든 Item은 Uniq하게 기록되고 식별되어야한다.

 구성db는 변경이력 , 장애이력,

 

9.2 Change Management

• 어디를 변경할 것인지 명확해야한다.
• RFC를 명확하게 평가하라
• 변경승인되고 , 체킹되고, 유보되고 취소되고, 교정이 되면 모두 DEMONSTRATION되어야한다.

나혼자할 경우  MINOR 이고 혼자하지 못할 경우 MAJOR (검토하고 많은 인원이 참석하고)
급할 수록 더 검토하고 돌아가라.

 

CAB Change Advisor Board


10.1 Release

• Back Out plans : 성공하지 못할 경우 어떻게 할 것인가.?
•  

용어정리

• 가용성(Availability)
  - 순간 또는 기간동안 요구되는 기능을 수행하기 위한 서비스
• 기준선(Baseline)
  - 특정순간의 서비스나 구성항목의 상태
• 구성항목
  -