변경요청서와 영향도 분석 — 무엇을·왜·언제·무엇에 영향 — 실습 Lab

INCIDENT RESPONSE

0 / 5 단계 완료

📚 PREREQUISITES

Theoryitsm/change-request-impact

TRACK

ITSM

SLA

55분

LEVEL

중급

PHASES

3단계

ENV

local

INCOMING TICKET

“운영팀장: "금요일 오후에 협력사가 '별거 아니다'며 결제 모듈을 무단으로 바꿨다가, 토요일에 주문 완료 알림 문자가 안 나가 중복 결제 사고가 났어요. RFC도, 영향도 분석도, 승인도, 점검창도 없었죠. 바꾸기 전에 무엇을·왜·언제·무엇에 영향인지 한 장에 남기고, CMDB 관계로 연쇄 영향을 따지고, 영향 범위에 맞는 승인과 점검창을 잡는 규칙을 세워 주세요."”

YOUR ROLE

IT 서비스 운영·변경관리 담당

안 하면 나중에

변경 통제가 없으면 "별거 아닌" 변경이 연쇄 영향을 타고 주말 야간 긴급 복구로 번지고, 영향도 없이 승인된 변경이 계획되지 않은 서비스 중단(인시던트)이 되며, 롤백 계획이 없어 점검창 안에서 복구를 헤매다 중단이 길어진다.

📋상황 브리핑

금요일 오후, 협력사 엔지니어가 메신저로 한 줄 보냅니다. "결제 모듈 설정 좀 바꿔서 방금 반영했어요. 별거 아니라 따로 보고는 안 했습니다."

토요일 오전, 고객센터에 전화가 폭주합니다. 결제는 되는데 주문 완료 알림 문자가 안 갑니다. 고객은 결제가 안 된 줄 알고 또 결제하고, 중복 결제 환불과 사과 공지, 야간 긴급 복구가 이어집니다. 원인은 단순했습니다 — 결제 모듈이 알림 서비스를 호출하는 방식을 바꿨는데, 그 변경이 알림 서비스에 영향을 준다는 걸 아무도 따져 보지 않았습니다. "결제만 바꿨다"고 생각했지만, 결제는 주문 DB·알림 서비스와 연결돼 있었습니다.

운영팀장이 말합니다. "이런 사고를 막으려면 바꾸기 전에 '무엇을·왜·언제 바꾸고, 실패하면 어떻게 되돌리는지'를 한 장에 남기고, '이걸 건드리면 또 뭐가 흔들리나'를 CMDB 관계로 따진 뒤, 영향에 맞는 승인과 점검창을 잡아야 합니다. 그 세 가지를 규칙으로 세워 주세요."

이 Lab은 변경요청서(RFC)를 한 장으로 못 박고, 영향도 분석을 CMDB 관계로 그리며, 영향·리스크에 맞춰 승인 경로와 점검창을 연결하는 판단형 실습이다. 감이 아니라 문서와 관계로 변경을 통제한다.

⏱ 55분📊 중급🔧 3단계#change#rfc#impact-analysis#risk

MISSION

변경요청서(RFC) 한 장으로 못 박기 — 무엇·왜·언제·롤백

RFC 여덟 항목을 빠짐없이 채우되, 사유는 산출물이 아니라 결과로 적고, 롤백은 트리거·절차·시간까지 미리 못 박는다.

영향도 분석 — CMDB 관계로 "이걸 건드리면 또 뭐가 흔들리나"

직접 대상만 보지 않고 CMDB 관계를 타고 영향 서비스·사용자·연계 시스템을 도출하며, 리스크를 영향 범위 × 실패 확률로 평가한다.

변경 유형·승인·점검창 연결 — 영향에 맞는 통제를 건다

영향과 리스크로 변경 유형(정식·표준·긴급)을 정하고, 영향도를 확인한 승인 경로와 점검창·작업 공지를 연결해 영향을 예고된 범위에 가둔다.

📌 선수 지식

• [이론] itsm/change-request-impact

ℹ️ 실습 환경

환경: local

🔒

실습 실행은 Pro 플랜 전용입니다

인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.

Pro로 업그레이드 →

>_ LAB TERMINAL↔ 너비 조절

NOTES