개발자 노트

roll out 이관
back out 철회
fall-back 대체
ITIL is foucs on Process
1. 품질보증
2. 비용감소
IT에 대한 의존도가 높아지고 복잡해짐에 따라 관리의 필요성이 대두되고 ITSM이 등장함
Process - Infinitive
Project - Finitive, Life Cycle(Span)
Process 구성요소
(Input, Activity[GOAL에 도달하도록], Output[=Result])
Process Control
-> Process Owner, Goal, Quality param and Key performance indicators
ITIL
Qualty 보증을 위해 Plan - Do - Action - Check 를 반복
인시던트 관리
Incident - SLA에서 명시하고 있는 서비스에 대한 약속을 지키지 못하는 모든 이벤트(사용법, 비밀번호를 모르는 것도 모두 인시던트에 포함)
(ex. 에러와 서비스요청 분류 법)
용어 - Escalation(Functional, Hierarchical), Resolution(=Work-around), Impact(User에게 미치는 영향), Urgency
입력 - Call
행동 - 기록 -> 분류(IS a Service Request?) -> 매칭(CMDB) : 서비스 데스크가 한다 / 저장 : 서비스 데스크가 한다 -> Incident Tracing(진행상황 추적: 서비스 데스크) -> Escalation(Functional, Hierachical) -> Close : User가 만족하면 User가 한다
목표 - 조직과 사용자의 비즈니스 활동에 미치는 영향을 최소화하면서 가능한 한 신속하게 서비스 수준 계약에 규정된 정상 서비스 수준으로 "복구"하는 것(cf. 원인파악 X)
출력 - 각종 정보가 CMDB에 쌓이고, Availability, Problem에서 참고함 / 
       Problem /
       RFC에 대한 요청서 -> Change Management
문제 관리
용어 - Problem -> Known Error -> RFC
입력 - Problem, Incident에 대한 정보, CMDB로 부터 CI에 대한 정보
목표 - 근본 원인을 해결하여 인시던트의 재발 방지 / Infra structure가 에러로 인한 역효과를 최소화
서브프로세스 - Reactive(Problem Control - Known Error를 만든다[기록 -> 분류 -> 자원할당 -> 에러 조사/진단], Error Control[기록 -> 평가 -> 해결책 찾아서 -> RFC / RFC를 통해서 해결이 목표다 / PIR 후 만족할만한 결과를 얻었을때 종료]), Proactive Problem Management(사전예방활동 / Trend Analysis[기록된 Incident의 경향 분석 / 변경 후 발생, 초기 결함])
출력 - RFC구성 관리
행동 - 구축{PLAN -> Identification(CI, CI Level 식별[CI의 수준을 어디까지 가져 갈 것인가?], CI의 Attribute(Level Of Detail, CI의 정보 / 속성값))} -> 관리 및 운영{Control -> Status accounting} -> Verification(Audit[하는 시점: 큰 변경 후, CMDB 처음 구축 후])
목표 - 논리적 모델의 IT 인프라스트럭처 및 IT 서비스를 유지하고 관련 정보를 다른 비즈니스 프로세스에 제공함으로써, IT 서비스의 경제적 가치(고객의 요구 기준, 품질, 비용의 합) 관리를 통해 지원함(인프라스트럭처의 CI와 CI의 관게성을 관리, 운영해서 인프라스트럭처의 로지컬 모델을 제공한다.)
출력 - CI와 CI의 관계성(Relationship)
CMDB의 접근 권한은 Configuration Management만 있다.
Asset Management < Configuration Management(각종 문서까지 저장)
변경 관리
목표 - 서비스 품질에 미치는 파급 효과를 가능한 적게 하면서 표준 방법과 절차에 따라 변경을 신속하게 처리하는 것(변경으로 인한 Incident 수 최소화)
       변경으로 인해 발생하는 Incident 수에 관심
입력 - RFC
행동 - 기록 -> Filtering -> Acceptance(RFC를 분류) -> 우선순위 구분(Urgency - 복구를 위해 허용된 시간 / 짧을 수록 Urgency가 높다) -> Category[Impact & Resource / CAB에게 회람] -> Authorized(Change를...) -> Scheduling(스케쥴링 문서 : FSC) -> (Build[구매, 개발] -> Test -> Impementation -> Working -> 문제점 발생 -> Back Out[저장된 Base Line(특정 시점의 Snap Shot) 통해서... <- Configuration에 저장됨]) -> 문제점 발생 X -> PIR -> Problem에 보고
릴리즈 관리
목표 - 필요 서비스 수준을 확보하기 위해 IT 부서가 지원하는 개발에 사용될 소프트웨어 및 하드웨어 버전을 릴리즈를 관리
       (Live Environment[실제환경]를 보호한다)
행동 - plan(버전정책) -> build -> test -> implementation -> user와 commnuication -> install
DSL - 정품의 S/W가 있는곳. 정확하게 관리하는 것에 대한 책임
DHS
서비스 데스크
목표 - IT 조직의 접근성을 보장하고 다양한 지원 활동을 담당함으로써 합의된 수준의 서비스 제공을 지원
       (유저의 정보 관리)서비스 수준 관리
목표 - 고객이 원하는 IT 서비스를 연속적으로 유지하고 개선하는 데 목표
       (서비스 수준의 정의하고, 그것이 잘 지켜지고 있는지 모니터링)
       서비스 퀄리티에 관심 -> 고객만족
       서비스 퀄리티 보증
행동 - 고객 Needs 파악 -> SLR(Service Level Requirement) -> Service Spec Sheet(우리가 제공할 수 있는 서비스) -> Negotiation -> Service Level Agreement(OLA, UC) -> Service Catalogue(우리 조직이 제공하는 All Services) -> Service Level Achievement(실제 서비스 되고 있는 수준) -> Service Improvement Program(Review 할때)서비스 재무 관리
- IT 서비스 제공에 필요한 IT 자원을 경제적으로 관리하여 내부 IT 조직을 지원
  Cost를 효과적으로 사용
- Budgeting - 어디 어디에 돈이 들어가는지 확인 후 예산
  IT Accounting
  Charging
용량 관리
- 현재와 미래의 비즈니스 요구 기준에 맞추어 IT 자원을 적시에 적절한 비용으로, 일관성 있게 제공하는데 목표
  용량 뿐만 아니라 퍼포먼스 책임
- Business : 우리 비즈니스에 맞는...
  Service : 우리가 제공하는 서비스에 맞는...
  Resource: CI와 테크놀로지 관리  
- 퍼포먼스 관리
- Demand Management: 수요 관리
- Adhoc: 필요할 때 마다
  - Modeling: 적합한지 시뮬레이션
  - Application Sizing
IT 서비스 연속성 관리
목표- 재해가 발생하면 일정 시간 안에 서비스 데스크 및 지원을 포함해 모든 필수 IT 인프라스트럭처와 IT 서비스를 복구함으로써 전체 비즈니스 연속성 관리(BCM)를 뒷받침하는 것이다.
      비상시 상황 보장.
행동 - Plan -> Test -> Manage -> Risk Management
- Interruption, Disruption
- THREATS: 위협이 될만한 것들
- VULNERABILITY: 취약점
재해상황 -> Incident 보다 Impact가 크다
- ITSC Plan을 바꾸어 달라는 요청은 RFC
- ITSC Plan이 바뀌었다 -> Configuration Management
<ITSC Manager>
가용성 관리
목표 - 경제적으로 합의된 수준의 IT 서비스를 제공하여 비즈니스 목표를 달성하는 데 도움이 되도록 하는 것을 목표
       원하는 서비스를 항상 서비스 해줄 수 있도록 하는것.
       쓰지 못하게 했던 시간에 관심(Incident가 쌓아둔 정보에 관심)
- Service Availability = (AST - DT)/AST * 100
- Reliability, Maintainability, Resilience
- Serviceability
- Down Time(TTR), Up Time(TBF)Integrity : 정확한 데이터