서비스 수준과 ITSM

1. IT 서비스의 의미

IT 서비스는 고객이나 사용자가 원하는 결과를 얻도록 기술·인력·프로세스·정보를 결합해 제공하는 가치 단위이다.

사람 + 프로세스 + 기술 + 공급자
             ↓
        IT 서비스
             ↓
   업무 결과·사용자 가치

서버나 소프트웨어 한 개가 아니라 이를 이용해 제공하는 업무 기능과 품질까지 포함한다.

2. ITSM

ITSM은 IT 서비스의 기획·설계·전환·운영·개선을 체계적으로 관리하는 접근이다.

주요 관리영역:

• 서비스 포트폴리오·카탈로그
• 서비스 수준
• 인시던트·문제·요청
• 변경·릴리스·배포
• 구성·자산
• 가용성·용량·연속성
• 지식·보안·공급자
• 지속적 개선

프레임워크 이름과 버전보다 각 관리활동의 목적을 구분하는 것이 전공 필기에 중요하다.

3. 서비스데스크

서비스데스크는 사용자와 IT 조직 사이의 단일 접점 역할을 한다.

사용자 문의·장애·요청
        ↓
    서비스데스크
   ├─ 접수·분류
   ├─ 1차 해결
   ├─ 담당자 이관
   ├─ 진행상태 안내
   └─ 지식 축적

단순 전화교환이 아니라 사용자 경험, 우선순위, 해결·에스컬레이션, 지식관리를 담당한다.

4. 인시던트·문제·서비스 요청

이벤트가 반드시 인시던트는 아니다. 자동으로 복구되거나 정보성 이벤트일 수 있다.

5. SLA·OLA·공급자 계약

• SLA: 서비스 제공자와 고객 사이의 서비스 수준 합의
• OLA: 내부 지원 조직 사이의 운영 수준 합의
• 공급자 계약: 외부 업체의 서비스·책임 합의

고객 SLA: 장애 2시간 내 복구
      ▲
      │
내부 OLA
앱팀 60분 + DB팀 30분 + 네트워크팀 30분
      ▲
      │
외부 회선 공급자 계약

내부·외부 목표를 조합했을 때 고객 SLA를 충족할 수 있어야 한다.

6. 서비스 수준 지표

평균만 보면 일부 사용자의 극단적 지연을 숨길 수 있으므로 백분위, 오류율, 업무 성공률을 함께 본다.

7. 가용성 계산

가용률 = (대상시간 - 중단시간) / 대상시간 × 100

1개월 대상시간이 43,200분이고 중단이 86.4분이면:

가용률 = (43,200 - 86.4) / 43,200 × 100
       = 99.8%

계획 정지 포함 여부, 부분 장애, 기능별 측정 범위를 SLA에 정의한다.

8. MTBF·MTTR

• MTBF: 고장 사이의 평균 정상 운전시간
• MTTR: 평균 수리·복구시간

단순한 안정상태 가용성 관계:

Availability ≈ MTBF / (MTBF + MTTR)

MTBF를 늘리거나 MTTR을 줄이면 가용성이 높아진다. 실제 서비스 가용성은 아키텍처·부분 장애·운영시간을 추가로 고려한다.

9. 용량·성능 관리

업무 수요 예측
    ↓
현재 사용량·추세
    ↓
병목·포화 지점 분석
    ↓
확장·최적화 계획
    ↓
변경 후 효과 검증

자원 사용률만 보는 것이 아니라 처리량, 큐, 응답시간, 성장률, 피크 패턴을 함께 본다.

CPU 70%가 항상 문제인 것도 아니고 CPU 30%에서도 외부 API 지연이나 락 때문에 서비스가 느릴 수 있다.

10. 서비스 카탈로그와 구성정보

서비스 카탈로그에는 사용자에게 제공하는 서비스, 대상, 신청 방법, 지원시간, 서비스 수준, 담당자 등을 정리한다.

구성정보는 서버·DB·네트워크·소프트웨어·관계와 변경상태를 관리한다.

온라인결제 서비스
  ├─ Load Balancer
  ├─ API Server 3대
  ├─ Payment DB
  ├─ Message Broker
  └─ 외부 PG 연계

구성관리는 모든 데이터를 무조건 수집하는 것이 아니라 변경·장애 영향 분석에 필요한 신뢰 가능한 정보를 유지하는 것이 목적이다.

11. 지속적 개선

현재 상태 측정
   ↓
목표와 차이 확인
   ↓
개선 우선순위
   ↓
실행
   ↓
효과 측정
   └────────► 반복

지표를 수집하는 것만으로 개선이 이루어지지 않는다. 지표 소유자, 목표, 실행조치, 검증주기가 필요하다.

12. 서비스 가치 흐름과 practice 연결

사용자 문의 → Service Desk → Incident/Request
장애 반복 → Problem → Known Error·개선
변경 필요 → Change Enablement → Release/Deployment
구성 영향 → Configuration·Monitoring 정보 활용

서비스 데스크는 단순 콜센터가 아니라 사용자와 서비스 제공자의 단일 접점 역할을 한다. incident는 정상 서비스의 신속한 복구, problem은 원인·재발 가능성의 관리다.

13. SLA·OLA·공급계약 연결

고객 SLA 99.9%
   ├─ 내부 DB OLA 99.95%
   ├─ 운영팀 응답 OLA
   └─ 통신사 Underpinning Contract

하위 목표는 고객 SLA를 달성할 수 있도록 여유와 의존성을 고려해야 한다. 개별 구성요소 SLA를 단순히 모두 99.9%로 두면 직렬 의존 서비스 전체 가용성은 더 낮아질 수 있다.

14. 직렬·병렬 가용성 계산

독립 구성요소가 모두 필요하면 직렬 가용성은 곱한다.

A=0.99, B=0.98 → 전체=0.9702(97.02%)

둘 중 하나만 살아도 되는 독립 병렬 구조는 1-(1-A)(1-B)다. A=B=0.99이면 99.99%다. 공통 장애 원인이 있으면 독립 가정을 적용할 수 없다.

15. SLI와 서비스 수준 검토

• 가용성: 성공 요청/유효 요청
• 지연: p95·p99 응답시간
• 처리량: 초당 요청·업무 완료 건수
• 신선도: 데이터가 허용 지연 안에 반영된 비율

계획된 점검시간 제외 여부, 사용자 오류와 서버 오류 분류, 측정 지점을 SLA에 명시한다.

16. CMDB와 변경 영향

CMDB는 자산 목록만이 아니라 CI 간 관계와 서비스 연결을 제공해야 한다. 오래된 자동 탐색 데이터, 중복 CI, 소유자 없는 항목을 품질 지표로 관리하고 변경 실패 시 실제 구성과 기준선을 비교한다.

확인 문제

1. 직렬 가용성 0.99와 0.98의 결합은?
2. 독립 병렬 0.99 두 개의 가용성은?
3. OLA의 대상은?
4. CMDB가 단순 자산목록과 다른 점은?
5. 가용성 SLI의 분모를 명시해야 하는 이유는?