개념
세 단어를 먼저 가른다
운영 조직에서 가장 자주 섞이는 세 단어가 있다.
| 용어 | 뜻 | 목표 | 끝나는 시점 |
|---|---|---|---|
| 인시던트(incident) | 서비스의 계획되지 않은 중단이나 품질 저하 | 가능한 한 빨리 정상 서비스 복구 | 서비스가 복구되면 |
| 문제(problem) | 하나 이상의 인시던트의 원인, 또는 잠재적 원인 | 원인을 찾아 재발 방지 | 원인이 제거되거나 수용 결정이 나면 |
| 알려진 오류(known error) | 원인이 분석되었지만 아직 해결되지 않은 문제 | 해결 전까지 영향 줄이기 | 영구 해결될 때까지 유지 |
그리고 하나가 더 있다. 해결 방법(workaround) 은 원인을 없애지 않고 인시던트나 문제의 영향을 줄이는 방법이다.
이 구분이 QA에게 중요한 이유는 목표가 서로 충돌하기 때문이다. 인시던트 담당자는 복구가 목표 라서 재부팅으로 서비스를 살리면 성공이다. 그런데 재부팅은 원인 분석에 필요한 메모리 상태를 지운다. 문제 담당자는 원인이 목표 라서 증거를 보존하고 싶다. 두 목표가 한 사람에게 있으면 복구가 항상 이긴다. 그래서 프랙티스를 나눈다.
모듈 6에서 배운 결함은 이 표의 어디에 있는가. 문제 분석 결과 원인이 코드 결함 이면, 문제 기록은 결함 기록으로 이어진다. 인시던트 → 문제 → 결함 → 수정 → 변경 → 배포 가 하나의 추적 사슬이다. 이 사슬이 끊기면 "이 결함이 운영에 얼마나 영향을 줬나"를 아무도 모른다.
인시던트 관리 — 우선순위를 두 축으로 매긴다
인시던트 우선순위는 담당자의 느낌이 아니라 영향(impact)과 긴급도(urgency) 의 조합으로 정하는 것이 일반적이다.
긴급도 높음 긴급도 중간 긴급도 낮음
영향 높음 P1 P2 P3
영향 중간 P2 P3 P4
영향 낮음 P3 P4 P5
영향 얼마나 많은 사용자·업무·매출이 영향을 받는가
긴급도 얼마나 빨리 악화되는가, 기다릴 수 있는가매트릭스의 칸 정의는 조직마다 다르다. 중요한 것은 영향과 긴급도 각각의 판정 기준을 문장이 아니라 조건으로 적는 것이다. "많은 사용자"가 아니라 "활성 사용자 10% 이상 또는 결제 기능 불가"처럼. 모듈 2에서 검증 가능한 요구사항을 쓰던 방식이 그대로 쓰인다. 조건으로 적어야 우선순위 판정이 사람마다 달라지지 않고, 뒤에서 볼 시험도 가능해진다.
우선순위마다 목표 시간 이 붙는다.
| 우선순위 | 응답 목표 | 복구 목표 | 알림 |
|---|---|---|---|
| P1 | 15분 | 4시간 | 주요 인시던트 절차 즉시 발동, 책임자 호출 |
| P2 | 30분 | 8시간 | 담당 그룹 리더 |
| P3 | 4시간 | 3영업일 | — |
(숫자는 예시다. 실제 값은 레슨 1의 SLA와 서비스 수준 관리에서 온다.)
주요 인시던트(major incident) 는 별도 절차를 둔다. 영향이 커서 일반 흐름으로는 조율이 안 되는 인시던트다. 전담 조율자, 정해진 간격의 상황 공유, 이해관계자 통보, 그리고 복구 후 반드시 문제 관리로 넘기는 규칙 이 핵심이다.
문제 관리 — 반응형과 선제형
문제 관리는 두 방향으로 움직인다.
반응형 — 발생한 인시던트에서 출발한다. 같은 증상이 반복되거나 주요 인시던트가 발생하면 문제 기록을 만든다.
선제형 — 아직 인시던트가 되지 않은 위험에서 출발한다. 모니터링 추세, 공급사 취약점 공지, 테스트 중 발견했지만 출시한 알려진 결함이 입력이다.
선제형 문제 관리에 QA가 기여할 수 있는 입력은 크다. 출시 시점에 알려진 결함 목록 이 바로 선제형 문제의 후보다. 모듈 6에서 "수정 연기"로 분류한 결함을 알려진 오류 기록으로 운영에 넘기면, 운영 담당자는 그 증상의 인시던트가 들어왔을 때 해결 방법을 바로 적용 할 수 있다. 첫 접촉 해결률 (레슨 1)이 올라가는 가장 싼 방법이다.
문제 관리의 흐름은 대체로 이렇다.
문제 식별 → 문제 통제(분석·원인 규명·해결 방법 문서화) → 알려진 오류 기록 → 오류 통제(영구 해결 검토·변경 요청)원인 분석 기법은 모듈 32 레슨 5에서 본 구조 층까지 내려가는 원인 분석 이 그대로 쓰인다. "담당자 실수"로 끝난 원인은 문제를 닫지 못한다. 실수가 가능했던 구조(검증 없는 수동 배포, 경고 없는 설정 화면)가 원인이다.
변경 지원 — 변경의 세 유형과 변경 권한자
ITIL 4는 변경 관련 프랙티스를 변경 지원(change enablement) 이라고 부른다(초기 ITIL 4 자료에는 change control이라는 이름으로 나온다). 목적은 변경의 성공률을 높이는 것 이다. 위험을 평가하고, 변경을 승인하고, 일정을 관리한다.
변경은 대체로 세 유형으로 나뉜다.
| 유형 | 성격 | 승인 | 예 |
|---|---|---|---|
| 표준 변경 | 위험이 낮고 반복되며 절차가 검증된 변경 | 사전 승인 — 매번 승인받지 않는다 | 계정 권한 추가, 인증서 정기 갱신 |
| 일반 변경 | 위험 평가와 승인이 필요한 변경 | 위험에 맞는 변경 권한자 가 승인 | 기능 배포, DB 스키마 변경 |
| 긴급 변경 | 인시던트 해결이나 보안 위협 대응을 위해 가능한 한 빨리 해야 하는 변경 | 긴급 권한자가 빠르게 승인, 사후 문서화 | 악용 중인 취약점 패치 |
변경 권한자(change authority) 라는 표현에 주목하자. 과거에는 모든 일반 변경을 변경 자문 위원회(CAB) 회의에서 승인하는 방식이 일반적이었다. ITIL 4는 위험에 따라 권한을 분산 하는 쪽을 강조한다. 낮은 위험의 일반 변경은 팀 리드가, 높은 위험은 위원회가 승인하는 식이다. 도구에 따라서는 여전히 CAB 승인 단계를 기본 흐름으로 두기도 한다(레슨 6).
여기서 QA가 가장 크게 기여하는 칸이 위험 평가 다. 변경 위험 평가표에 테스트 증거를 넣으면 이렇게 된다.
[변경 위험 평가표]
| 항목 | 평가 | 근거 |
|---|---|---|
| 변경 범위 | 결제 모듈 3개 파일, 설정 1건 | PR 링크 |
| 영향받는 서비스 | 결제, 주문 조회 | CMDB 의존 관계 |
| 회귀 시험 범위 | 결제 스모크 42건 + 결제 회귀 318건 | 실행 기록 링크, 스테이징 환경 버전 |
| 운영 구성과 시험 환경 차이 | PG 사 샌드박스 vs 운영 — 타임아웃 값 다름 | 차이 분석 |
| 롤백 방법과 시험 여부 | 이전 이미지 재배포, 스테이징에서 롤백 리허설 완료 | 리허설 기록 |
| 과거 유사 변경 실패 | 최근 6개월 결제 변경 14건 중 1건 실패(타임아웃) | 변경 기록 |
| 판정 | 일반 변경 — 중위험 | 권한자: 결제 서비스 리드 |"운영 구성과 시험 환경 차이" 줄이 레슨 1의 구성 관리 접점 이다. 모듈 35 레슨 2의 호스트·타깃 차이 분석과 발상이 같다. 시험한 환경과 반영할 환경이 다르면, 그 차이가 위험 평가의 한 줄이 되어야 한다.
변경이 반영된 뒤에는 변경 후 검토 가 남는다. 변경이 목표를 달성했는지, 인시던트를 만들지 않았는지 확인한다. 실패한 변경은 문제 관리로 넘어가고, 그 원인이 회귀 시험 범위의 누락 이면 다음 테스트 계획이 바뀐다.
흐름을 시험하기 — ITSM 워크플로도 소프트웨어다
ITSM 프랙티스는 결국 도구 안의 워크플로 로 구현된다. 상태 흐름, SLA 타이머, 자동 배정, 에스컬레이션 규칙이 전부 설정이고, 설정은 결함을 가진다. QA가 ITSM 도구 구축·운영 과제에서 가장 직접적으로 기여하는 곳이 여기다.
상태 전이 시험. 인시던트의 전형적인 상태는 이렇다.
신규 ──▶ 진행 중 ──▶ 해결됨 ──▶ 종료
│ ▲ │
▼ │ │ (사용자가 해결 안 됐다고 응답)
보류 ─┘ └──────▶ 진행 중 (재개)모듈 3 레슨 3의 상태 전이 기법으로 케이스를 뽑는다. 정상 전이뿐 아니라 허용되지 않아야 할 전이 가 중요하다.
| 시험 | 기대 |
|---|---|
| 신규 → 종료 직접 전이 | 불가 (해결 기록 없이 종료 금지) |
| 해결됨 → 종료: 자동 종료 기간 경계 | 기간 N일 직전 유지, 경과 후 자동 종료 |
| 종료 → 진행 중 재개 | 불가 — 새 인시던트로 연결 |
| 보류 사유 없이 보류 | 불가 |
| 해결 코드 없이 해결됨 | 불가 |
SLA 타이머 시험. 타이머는 경계값의 보고다.
| 시험 | 확인할 것 |
|---|---|
| 응답 목표 15분: 14분 59초·15분 1초에 첫 응답 | 달성/위반 판정 경계 |
| 보류 상태에서 타이머 일시 정지 | 정지·재개 시점, 보류 사유별 정지 여부 |
| 업무 시간 기준 SLA: 금요일 17:50 접수, 업무 종료 18:00 | 다음 영업일로 이월 계산 |
| 공휴일 달력 | 공휴일 이월 |
| 우선순위 변경(P3 → P1) | 타이머 재계산 방식(처음부터 / 경과 반영) |
| 위반 임박 알림(목표의 75%) | 알림 발송 시점과 수신자 |
우선순위 변경 시 타이머 재계산은 조직이 정해야 하는 정책 이고, 정책이 없는 채로 도구 기본값을 쓰는 경우가 많다. 시험이 정책 공백을 드러내는 전형적인 사례다. 레슨 6에서 도구별로 이 설정을 다시 본다.
우선순위 매트릭스 시험. 영향·긴급도 조건을 조건으로 적었다면 결정 테이블(모듈 3)로 전수 시험할 수 있다. 3×3 매트릭스라면 아홉 칸 전부와, 각 조건의 경계(활성 사용자 9.9%·10%)를 시험한다.
실무에서 왜 필요한가
세 프랙티스를 구분하지 않은 조직은 인시던트를 "해결"로 닫고 원인은 남긴다. 같은 증상이 매주 반복되지만 매번 복구에 성공했으므로 지표는 좋아 보인다. 재발 인시던트 비율을 따로 재기 시작하는 순간 이 착시가 드러난다. 문제 관리를 운영에 붙이는 일은 대개 재발 인시던트 목록을 만드는 것 에서 시작한다.
변경 위험 평가에 테스트 증거가 붙으면 두 가지가 바뀐다. 승인자가 형식적 서명 대신 근거를 보고 판단 하게 되고, 변경이 실패했을 때 "어떤 증거가 부족했는지"를 기록으로 되짚을 수 있다. 변경 실패율을 떨어뜨리는 가장 직접적인 수단이다.
ITSM 도구 구축 프로젝트에서 워크플로 시험이 빠지면 운영 첫 달에 SLA 보고서를 신뢰할 수 없게 된다. 보류 중 타이머가 계속 돌거나 공휴일이 반영되지 않으면, 계약상 SLA 위반이 실제로는 없었는데 보고된다. 반대의 경우는 더 위험하다.