용량 계획과 변경 관리 — 언제 차는지 계산하고 멈출 시각을 먼저 적는다

변경 요청서를 쓰고 리허설로 검증한다

목표

세 변경 요청의 유형을 가르고, DB 재시작의 영향 범위를 의존 끝까지 따라가고, 작업 창에서 되돌리기 시간을 거꾸로 빼 중단 판단 시각을 구한 뒤, 그 숫자로 JSON 변경 요청서를 쓰고 리허설 기록으로 계획이 낙관적이었는지 판정합니다.

왜 중요한가

운영 장애의 큰 몫은 변경에서 나옵니다. 변경 요청서는 그 위험을 작업 전에 종이 위에서 확인하는 도구이고, 검토자가 반려하는 이유는 대개 같습니다 — 되돌리기 기준이 "문제가 생기면" 뿐이다, 영향 목록이 직접 의존만 있다, 되돌리기 시간을 계산하지 않아 창이 넉넉해 보인다. 이 실습은 그 세 가지를 숫자로 채우고, 리허설 기록으로 계획을 검증하는 습관을 만듭니다.

재료는 /opt/lab/capacity/change/ 에 있고, 채점기는 기대값을 원본 재료에서 계산합니다.

단계

/opt/lab/capacity/change/ 의 파일 다섯 개를 /root/chg/ 로 복사하세요.
요청 A·B·C 의 유형을 /root/chg/01-type.txt 에 A=, B=, C= 로 적으세요(standard·normal·emergency).
db01 재시작의 영향을 받는 서비스를 의존 끝까지 따라가 /root/chg/02-impact.txt 에 impacted= 로 적으세요.
/root/chg/03-window.txt 에 total_min=, rollback_min=, nogo_at=, fits= 를 적으세요.
/root/chg/cr.json 에 id, type, summary, window, impact, precheck 를 쓰세요.
cr.json 에 steps(S1…S5, 각각 verify)와 rollback(trigger·max_min·steps)을 더하세요.
리허설 기록으로 /root/chg/04-rehearsal.txt 에 slowest_step=, over_min=, finished_at=, past_nogo= 를 적으세요.

참고

의존 따라가기: 영향 집합에 더할 것이 없을 때까지 되풀이합니다.
시각 계산: datetime.strptime(s, '%H:%M'), timedelta(minutes=n).
JSON 확인: python3 -m json.tool /root/chg/cr.json.
흔한 실수 1: 되돌리기 시간을 빼지 않고 "작업 60분, 창 120분이니 넉넉하다" 로 판단하는 경우.
흔한 실수 2: rollback.trigger 를 "이상이 있으면 원복" 처럼 잴 수 없는 말로 적는 경우.

재료 복사

/opt/lab/capacity/change/ 의 파일 다섯 개(requests.txt, inventory.json, plan.csv, window.env, rehearsal.log)를 /root/chg/ 로 복사하세요.

cp 로 디렉터리 내용을 옮깁니다. requests.txt 부터 읽어 보세요.

변경 유형 가르기

requests.txt 의 세 요청 A·B·C 를 각각 standard·normal·emergency 중 하나로 분류해 /root/chg/01-type.txt 에 A=, B=, C= 세 줄로 적으세요.

승인된 절차서를 그대로 반복하는가, 새로 평가해야 하는가, 지금 하지 않으면 곧 장애가 되는가를 봅니다.

영향 범위 따라가기

inventory.json 의 depends_on 을 끝까지 따라가 db01 재시작의 영향을 받는 서비스를 모두 찾고, /root/chg/02-impact.txt 에 impacted=<이름들, 쉼표로> 한 줄로 적으세요(db01 자신은 빼고).

db01 을 직접 쓰는 서비스를 먼저 찾고, 그 서비스를 쓰는 서비스를 다시 찾는 일을 더 늘지 않을 때까지 되풀이합니다.

작업 창과 중단 판단 시각

plan.csv 와 window.env 로 /root/chg/03-window.txt 에 네 줄을 적으세요: total_min=<minutes 합>, rollback_min=<rollback_minutes 합>, nogo_at=<WINDOW_END − rollback_min − BUFFER_MIN, HH:MM>, fits=<WINDOW_START + total_min 이 nogo_at 이하면 yes, 아니면 no>.

되돌리기는 최악의 경우(모든 단계를 되돌림)로 잡습니다. 창 끝에서 거꾸로 빼면 중단 판단 시각이 나옵니다.

변경 요청서의 머리

요청 B 의 변경 요청서를 /root/chg/cr.json 으로 쓰세요. 최상위 객체에 id, type(B 의 유형), summary, window({"start": "02:00", "end": "04:00"}), impact(3단계의 서비스 이름 목록), precheck(비어 있지 않은 문장 두 개 이상, 그중 하나는 백업이나 스냅숏 확인)가 있어야 합니다.

JSON 은 python3 -m json.tool cr.json 으로 문법을 확인할 수 있습니다. 영향 목록은 손으로 옮기지 말고 02-impact.txt 에서 읽어 넣으세요.

단계별 확인과 되돌리기 기준

cr.json 에 steps 와 rollback 을 더하세요. steps 는 plan.csv 의 순서대로 id(S1…S5)와 비어 있지 않은 verify(끝났다고 판단할 확인 방법)를 가진 객체 목록입니다. rollback 은 trigger(4단계의 nogo_at 시각을 포함한 잴 수 있는 기준), max_min(4단계의 rollback_min), steps(세 단계 이상의 목록)를 가진 객체입니다.

trigger 에는 '문제가 생기면' 이 아니라 시각·비율·건수가 들어가야 합니다. 중단 판단 시각은 03-window.txt 에서 읽어 넣으세요.

리허설 기록 읽기

rehearsal.log 로 /root/chg/04-rehearsal.txt 에 네 줄을 적으세요: slowest_step=<계획보다 가장 많이 늦은 단계 id>, over_min=<그 단계가 늦은 분, 소수 첫째 자리>, finished_at=<마지막 done 의 HH:MM>, past_nogo=<리허설이 끝난 시각이 nogo_at 보다 늦으면 yes, 아니면 no>.

단계마다 done 시각에서 start 시각을 빼 실제 소요를 구하고 plan.csv 의 minutes 와 비교합니다. 초 단위까지 있으니 분으로 바꿀 때 60 으로 나눕니다.