관측가능성·장애대응·문제관리·변경관리

1. CPU·메모리·오류율을 보고 있으면 관측가능한 시스템일까

정해 둔 지표를 보는 모니터링은 알려진 실패를 빠르게 찾는 데 유용하지만, 처음 보는 장애에서 내부상태를 설명하기에는 부족할 수 있다. 관측가능성은 외부로 나온 신호를 조합해 왜 이런 결과가 생겼는지 내부상태에 대한 가설을 세우고 검증할 수 있는 정도에 초점을 둔다.

이번 절은 운영신호를 사건 복구, 반복원인 제거와 안전한 변경으로 연결한다.

운영피드백은 결과를 다음 변경으로 되돌리는 순환이었다

검증·확인·운영 피드백에서는 운영결과를 요구·설계·검증으로 되돌려 다음 판단을 바꾸는 운영피드백을 다뤘다. 이번 절은 로그·메트릭·트레이스와 사건기록을 그 피드백의 구체적 증거로 사용한다.

관측가능성과 장애관리

관측가능성은 로그·메트릭·트레이스 같은 외부 신호를 바탕으로 내부상태를 이해할 수 있는 정도다. 이 절에서는 알려진 임계값뿐 아니라 처음 보는 결과에 대해서도 가설을 세우고 검증할 수 있는지를 본다. 장애관리는 발생한 서비스 영향의 신속한 완화·복구에 초점을 둔다. 그 과정에서 관측 신호를 활용하고, 반복 원인 분석과 변경 검증으로 이어질 근거를 남긴다.

신호를 많이 저장하는 것보다 질문 가능한 문맥과 복구·개선 연결이 중요하다.

신호에서 개선까지의 폐루프

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

사용자 영향과 증거에서 복구 조치를 선택하고 회복 여부를 확인한다. 원인이 남으면 문제 분석과 통제된 변경으로 이어진다. 명령 성공·서비스 회복·원인 확정·재발 방지는 서로 다른 확인 대상이다.

텍스트 표현으로 다시 확인하기

서비스 회복·재발 방지 그림을 따라 사용자 영향과 로그·메트릭·트레이스·이벤트를 연결하고 가설·영향범위·우선순위를 정한다. 사건 복구 뒤 실제 회복을 확인하며, 미확정 원인은 문제 분석과 필요한 변경·검증으로 이어간다. 검증·운영피드백을 다음 신호·판단에 되돌린다.

2. 로그·메트릭·트레이스는 서로 다른 질문에 강하다

로그는 개별 이벤트와 문맥, 메트릭은 시간에 따른 집계 변화, 트레이스는 한 요청이 여러 구성요소를 지나간 경로와 시간을 설명하는 데 유용하다. 한 종류만으로 모든 원인을 증명하려 하지 않고 공통 시간·서비스·판본·요청 문맥으로 연결한다.

운영신호를 다음 판단으로 되돌리는 피드백으로 쓴다

장애에서 얻은 신호는 단순 보고로 끝내지 않고 어떤 경보가 늦었는지, 어떤 요구·설계·변경이 위험을 만들었는지, 어떤 검증이 빠졌는지를 다음 계획에 반영한다. 운영피드백이 있어야 사건복구가 같은 장애의 반복을 줄이는 학습으로 이어진다.

세 신호의 대표 질문

이 구분은 절대적 도구분류가 아니라 진단 질문을 명확히 하기 위한 실무적 틀이다.

OB-1: 평균 120 ms인데 일부 요청이 3초라면

1,000개 요청 중 990개가 약 90 ms이고 10개가 약 3초라면 평균은 약 119 ms다. 평균만으로 꼬리 지연을 설명하기 어렵다. 느린 요청 ID의 트레이스를 찾아 어느 서비스·DB·외부호출 구간이 길었는지 확인한다.

모든 필드를 로그로 남기면 관측가능성이 높아지는 것이 아니다

민감정보 노출, 저장비 폭증, 너무 많은 고유값, 검색불가능한 자유문자열은 오히려 진단을 어렵게 할 수 있다. 진단에 필요한 식별자·판본·오류·시간·의존성 문맥을 설계하고 민감정보와 보존기간을 통제한다.

3. 사건대응의 첫 목표는 사용자 영향 통제와 안전한 복구다

원인을 완벽히 이해하기 전에도 트래픽 우회, 직전 변경 롤백, 문제 기능 제한처럼 영향범위를 줄일 수 있다. 복구행동 자체가 더 큰 장애를 만들지 않도록 권한·검증·롤백 조건을 정한다.

사건대응 최소 순서

1. 사용자 영향·심각도·시작시각을 확인한다.
2. 역할과 커뮤니케이션 채널을 정한다.
3. 최근 변경과 핵심 신호를 보존한다.
4. 가장 안전한 완화·복구를 수행한다.
5. 서비스 회복을 독립적으로 검증한다.
6. 미해결 위험과 후속 문제분석을 넘긴다.

IR-1: 14:00 장애, 14:07 롤백, 14:12 회복

원인이 새 배포로 확정되지 않았더라도 13:55 배포 뒤 오류가 급증했고 롤백 위험이 낮다면 14:07에 롤백해 영향을 줄일 수 있다. 14:12 회복은 복구증거이며, 근본원인 확정과 재발방지는 후속 분석에서 계속한다.

복구 완료를 원인분석 완료로 바꾸지 않는다

재시작으로 서비스가 살아나도 메모리 누수·교착·외부의존성 포화가 남아 있을 수 있다. 사건은 닫을 수 있어도 반복원인과 재발위험을 별도 문제로 추적한다.

4. 문제관리는 반복·중대한 사건의 구조적 원인을 다룬다

문제분석은 한 사람의 실수를 찾는 데 그치지 않고 어떤 조건·설계·변경·탐지누락이 사건을 가능하게 했는지 본다. 원인, 기여요인, 임시우회, 영구개선, 검증방법과 소유자를 구분한다.

사건과 문제의 완료기준은 다르다

긴 원인분석 때문에 서비스 복구가 늦어지거나, 빠른 복구 때문에 문제분석이 사라지는 두 극단을 피한다.

PM-1: 매주 같은 타임아웃이 세 번 반복된다면

각 사건은 재시도로 복구됐더라도 같은 외부호출에 타임아웃·큐 증가가 반복되면 공통 문제로 묶어 제한시간, 재시도 폭증, 용량, 공급자 지연과 회로차단 같은 개선가설을 검토한다. 특정 해법을 자동 정답으로 가정하지 않는다.

5. 변경관리는 위험을 평가하고 관측·롤백 가능한 상태로 바꾼다

변경 목적, 영향 서비스, 의존성, 실행·검증·롤백 절차, 승인과 일정, 성공·실패 기준을 남긴다. 작은 표준 변경과 고위험 변경의 통제강도를 같게 만들기보다 영향과 되돌리기 어려움에 맞춘다.

변경 위험은 크기보다 폭발반경·가역성·관측가능성으로 본다

한 줄 설정도 모든 트래픽에 즉시 적용되고 롤백이 어렵다면 위험할 수 있다. 큰 코드변경도 일부 사용자에게만 점진 배포되고 자동 검증·빠른 롤백이 가능하면 위험을 좁힐 수 있다.

CHG-1: 5% → 25% → 100% 단계확대

가상 배포에서 새 판본을 5% 트래픽에 적용하고 오류·지연·업무결과가 기준을 만족하면 25%, 다시 검증 후 100%로 확대할 수 있다. 각 단계의 중단·롤백 기준이 없다면 단계만 나눴을 뿐 통제는 약하다.

긴급변경이라는 이름으로 기록과 사후검증을 없애지 않는다

복구가 시급하면 사전절차를 축소할 수 있어도 누가 무엇을 왜 바꿨는지, 어떤 결과가 났는지, 이후 원상복구·정식반영·재발방지를 어떻게 할지는 남겨야 한다.

사후검토는 사건의 시간선과 의사결정을 재구성한다

탐지, 판단, 완화, 복구, 커뮤니케이션, 변경을 시간순으로 놓고 당시 이용 가능했던 정보와 실제 결과를 구분한다. 개선항목은 구체 소유자·검증방법·완료조건이 있어야 운영피드백이 된다.

IR-2: 롤백 성공과 근본원인 확정은 다른 증거다

가상 주문서비스에서 13:55에 새 판본 v2를 지역 A 일부에 배포했고 14:00부터 오류가 늘었다고 하자. 14:00~14:05의 요청을 판본과 지역으로 나누면 다음과 같다.

전체 1.24%만 보면 지역·판본 차이가 가려진다. 지역 A 전체는 (96+13)/(1200+1300)=109/2500=4.36%이고, 같은 지역 안에서도 v2는 8.00%, v1은 1.00%다. 이 차이는 새 판본 가설을 강하게 만들지만, 배포와 동시에 다른 지역조건이나 외부의존성이 바뀌었을 가능성까지 자동으로 제거하지는 않는다.

시간선도 결과와 구분해 적는다.

이 사건에서 탐지 지연은 2분, 증상 시작부터 롤백 시작까지는 7분, 회복 기준 충족까지의 관찰시간은 12분이다. 조직마다 MTTD·MTTR 정의가 다를 수 있으므로 이 교육용 시간차를 보편 지표명으로 바꾸지 않는다. 회복 구간의 실패율은 10/5000=0.20%다. 14:12의 회복은 롤백이 유효한 완화였다는 증거지만, 그 자체로 v2가 유일한 근본원인임을 증명하지 않는다.

같은 시간축의 계층 신호를 보면 앱 v2에서 외부결제 최대 재시도가 1회에서 3회로 바뀌고 큐가 80에서 900으로 증가했다. DB p95는 14 ms에서 15 ms, NW 손실률은 0.1%에서 0.1%, HW CPU 최고는 45%에서 52%로 큰 포화가 없었다. 외부결제 p95는 220 ms에서 480 ms로 늘어 v1과 v2 모두 영향을 받았다. 따라서 문제분석에서는 외부지연을 기여조건, v2의 재시도 증폭을 판본 고유 가설로 나눠 재현한다. 같은 지연 프로파일을 넣은 통제 시험에서 v2 설정만 요청증폭과 큐 증가를 재현하고 이전 설정에서는 재현되지 않아야 설정변경을 원인증거로 강화할 수 있다.

수정 설정은 단계적으로 다시 올리되 단계별 분모와 중단기준을 따로 본다. 이 자체 예제의 기준을 실패율 0.5% 이하, p95 250 ms 이하, 잘못된 업무결과 0건으로 정했다고 하자.

100% 단계는 오류율과 p95 두 기준을 모두 넘으므로 앞 단계가 통과했더라도 배포 완료가 아니다. 5%·25% 데이터를 100%와 합쳐 평균을 낮추거나 “잘못된 결과가 0건”이라는 한 기준만으로 통과시키지 않는다. 마지막 안전 단계로 되돌린 뒤 100%에서만 드러난 부하·의존성 조건을 새 문제분석으로 연결한다.

개인 비난보다 시스템 조건을 개선대상으로 남긴다

누가 명령을 실행했는지만 적으면 같은 인터페이스·권한·검증결함이 다른 사람에게 반복될 수 있다. 인간행동도 원인의 일부일 수 있지만 권한설계·도구경고·검증·절차·업무압력 같은 조건과 함께 분석한다.

공식 범위 심화 — 운영기획을 관측·복구 가능한 계획으로 만든다

운영기획의 서비스수준·역할·에스컬레이션에 어떤 신호를 보고 어떤 조건에서 완화·복구·변경할지 관측과 대응 조건을 구체화한다.

공식 범위 심화 — 운영관리 실행증거를 연결한다

사건·문제·변경의 시간선과 신호·결과를 연결해 운영관리의 실제 실행과 잔여위험을 추적한다.

공식 범위 심화 — 응용SW 운영

배포판본·오류·큐·외부호출 신호를 사건·문제·변경과 연결해 응용SW의 복구와 재발방지를 지원한다.

공식 범위 심화 — HW 운영

자원·장애영역·장치이벤트를 서비스 영향과 시간축에 맞춰 HW 고장·포화 가설과 복구를 검증한다.

공식 범위 심화 — NW 운영

경로·DNS·지연·손실 신호를 요청·지역·변경이력과 연결해 네트워크 기여도를 검증한다.

공식 범위 심화 — DB 운영

트랜잭션·잠금·쿼리·복제·복구 신호를 요청과 연결해 DB 병목·오류와 재발위험을 검증한다.

출처와 적용 경계

관측신호·사건·문제·변경의 구체 도구명과 조직 절차는 채택한 운영관리 표준과 제품 문서를 확인한다. 관측가능성과 모니터링의 구분은 OpenTelemetry의 관측가능성 입문을 참고한다. 사건·문제·변경의 목적 차이는 앞의 운영관리 절과 연결한 자체 장애 사례이며, 특정 표준의 필수 용어목록을 그대로 재현하지 않는다. IR-2의 지역·판본별 요청 수, 시간선, 계층 신호와 단계적 재배포 기준은 학습을 위한 자체 수치이며 실제 서비스 측정·SLO·사고승인 결과가 아니다.

6. 한 장으로 정리하기

1. 관측가능성은 신호를 많이 모으는 것이 아니라 내부상태 가설을 검증하는 능력이다.
2. 사건은 영향복구, 문제는 반복원인 제거, 변경은 안전한 상태변경에 초점을 둔다.
3. 로그·메트릭·트레이스를 시간·서비스·판본·요청 문맥으로 연결한다.
4. 복구와 원인분석을 구분하고 둘 다 기록한다.
5. 운영결과를 요구·설계·검증 개선으로 되돌린다.

독립 연습 — 롤백 직후와 서비스 회복 이후의 완료를 나눈다

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

IR-1의 장애 시작 14:00·롤백 완료 14:07·사용자 회복 14:12를 유지한다. 롤백 명령은 성공했지만 14:07~14:12에는 사용자가 계속 실패했다. 별도 관찰에서 v1과 v2 모두 지역 A의 오류율 8%를 보였다고 가정한다.

• 사용자가 경험한 회복 시간을 계산하고 14:07을 종료로 둘 수 있는지 쓰라.
• 롤백이라는 완화 조치와 v2 단독 원인 가설을 구분해 판정하라.
• 인시던트 이후 문제 기록에 넘길 미확정 가설을 적어라.

풀이와 오답 교정 보기

회복 시간은 14:00부터 14:12까지 12 분이다. 명령 완료 14:07은 사용자 회복 시각이 아니다. 제한된 롤백은 영향을 줄이는 조치일 수 있지만, 같은 조건에서 두 판본이 동일하게 실패하면 v2 단독 원인 가설의 근거는 약해진다. 공통 지역 경로·외부 의존성·관측 조건을 같은 시간창에서 확인한다. 서비스 회복과 근본 원인 확정, 재발 방지의 완료는 서로 다른 종료 조건이다.

명령 완료를 회복으로 썼다면 IR-1, 복구를 근본 원인 확정으로 썼다면 IR-2와 종료 조건을 비교한다.

7. 자체 10점 문제

관측가능성과 모니터링의 차이를 설명하고, 로그·메트릭·트레이스를 이용한 사건대응·문제관리·변경관리의 연결방안을 제시하시오.

요구어는 설명, 제시다. 신호 자체보다 복구·원인제거·안전한 변경의 흐름을 중심으로 답한다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. 관측가능성과 모니터링의 경계
2. 로그·메트릭·트레이스 역할
3. 사건: 영향통제·복구
4. 문제: 반복원인·재발방지
5. 변경: 영향·검증·롤백
6. 운영피드백 폐루프

10점 답안 도식

서비스 회복·재발 방지 그림의 신호·가설·사건 복구와 문제 분석·통제된 변경·검증을 답안에 다시 사용한다. 검증·운영피드백은 다음 신호와 판단을 개선한다. 서비스 회복과 원인 확정의 완료를 구별한다.

10점 모범답안

관측가능성은 외부 신호로 내부상태를 이해할 수 있는 정도이며, 장애관리는 서비스 영향을 완화하고 복구하는 활동이다. 모니터링이 정해 둔 상태와 임계값을 지속 확인하는 데 강하다면 관측가능성은 처음 보는 장애에서도 로그·메트릭·트레이스와 문맥을 조합해 원인가설을 세우고 검증하는 데 초점을 둔다. 사건대응에서는 사용자 영향을 먼저 통제하고 안전한 완화·복구를 수행한다. 반복·중대한 원인은 문제로 넘겨 기여조건과 재발방지를 분석한다. 변경은 영향범위, 성공·실패 기준과 롤백을 명시하고 단계별로 검증한다. 이 결과를 요구·설계·경보·검증 개선으로 되돌려 운영피드백 폐루프를 만든다.

8. 자체 25점 문제

주문서비스에서 새 배포 5분 뒤 특정 지역의 지연과 오류가 증가했다. 로그·메트릭·트레이스, 사건복구, 문제분석, 단계적 변경·롤백, 사후검토를 포함한 장애대응 및 재발방지 체계를 설계하시오. 응용SW·HW·NW·DB 운영과의 연결도 제시하시오.

요구어는 설계, 제시다. 복구와 원인확정을 분리하고 계층별 증거를 시간축에 맞춘다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 사용자 영향·지역·판본별 분모
2. 탐지·선언·완화·회복 시간선
3. 로그·메트릭·트레이스와 최근 변경
4. 안전한 롤백과 회복 판정
5. 앱·DB·NW·HW·외부의존성 반증
6. 문제분석: 원인·기여조건·탐지누락
7. 5%·25%·100% 단계 게이트와 중단
8. 사후검토·소유자·검증 완료조건
9. 운영피드백으로 요구·설계·검증 보강

25점 도식 대조표

사건·변경의 연결	IR-2에서 확인할 근거
배포 뒤 지역 오류·지연	판본·지역별 분모와 로그·메트릭·트레이스
APP·DB·NW·HW 가설	같은 시간축의 관찰과 반대 증거
완화·롤백 → 서비스 회복	명령 완료와 사용자 결과를 별도 확인
문제 분석 → 안전한 변경 → 검증	단계별 분모·중단 기준·원인과 기여조건
운영피드백	다음 요구·설계·경보·검증을 개선

25점 모범답안

1. 영향과 시간선을 고정한다. IR-2의 14:00~14:05 자료에서 지역 A의 v2는 1200건 중 96건 실패로 8.00%, 같은 지역 v1은 1300건 중 13건으로 1.00%, 다른 지역 v1은 7500건 중 15건으로 0.20%다. 전체 1.24%만 보지 않고 지역·판본·요청 ID를 보존한다. 증상은 14:00, 경보는 14:02이므로 이 사건의 탐지 지연은 2분이며, 14:04 사건 선언 뒤 역할·커뮤니케이션·최근 변경을 같은 시간축에 둔다.

2. 복구를 원인확정과 분리한다. 새 판본과 증상의 시간·지역 상관이 강하고 롤백 위험이 낮으므로 14:07 v2 롤백을 시작해 14:09 완료한다. 14:12~14:22 지역 A 5000건 중 실패 10건인 0.20%, p95 180 ms, 잘못된 업무결과 0건을 확인해 서비스 회복을 판정한다. 이 12분 관찰시간과 롤백 후 회복은 완화의 유효성 증거지만 v2가 유일한 근본원인이라는 결론은 아니다.

3. 계층별 가설을 반증한다. 앱 v2는 외부결제 최대 재시도가 1회에서 3회로 늘고 큐가 80에서 900으로 증가했다. 반면 DB p95 14→15 ms, NW 손실률 0.1→0.1%, HW CPU 최고 45→52%는 큰 포화를 지지하지 않는다. 외부결제 p95 220→480 ms는 v1·v2 공통 기여조건이므로, 문제분석에서는 외부지연과 v2 재시도 증폭을 분리한다. 같은 지연 프로파일에서 설정만 바꾼 통제 재현으로 요청증폭·큐 증가가 v2에서만 나타나는지 확인한다.

4. 수정변경은 단계별 게이트로 통제한다. 자체 기준을 실패율 0.5% 이하, p95 250 ms 이하, 잘못된 업무결과 0건으로 두고 5%·25%·100%를 각각 독립 판정한다. 5%는 500건 중 1건 실패·190 ms, 25%는 2500건 중 8건·210 ms로 통과하지만 100%는 10000건 중 60건인 0.60%와 p95 270 ms로 실패한다. 앞 단계와 합산해 평균을 낮추지 않고 확대를 중단해 마지막 안전 단계로 되돌린다.

5. 문제와 변경의 후속증거를 남긴다. 문제기록에는 직접 원인, 외부지연 같은 기여조건, 경보가 지역·판본을 늦게 분리한 탐지누락, 재시도 설정 검토와 부하검증의 공백을 구분한다. 변경기록에는 단계별 분모·성공/중단 기준·실행자·승인·롤백 결과를 남기며 100%에서만 드러난 부하조건은 새 가설로 이어간다. 긴급복구였더라도 무엇을 왜 바꿨는지와 사후검증을 삭제하지 않는다.

6. 사후검토를 운영피드백으로 닫는다. 사후검토는 13:55 배포부터 탐지·선언·롤백·회복·재배포 판단까지 당시 이용 가능했던 정보와 실제 결과를 구분해 재구성한다. 개선항목마다 소유자·검증방법·완료조건을 두고, 지역·판본별 경보, 재시도 상한 검증, 외부지연 부하시험과 변경 게이트를 요구·설계·테스트에 반영한다. 서비스 회복을 문제 종료나 장기 신뢰성 승인으로 확대하지 않는다.

9. 장애대응 답안의 흔한 점프를 고친다

조건이 바뀌면 같은 절차도 결론이 달라진다

연습 1 — 경보가 14:02가 아니라 14:05에 처음 울렸다면? 증상 시작을 14:00으로 유지할 때 탐지 지연은 2분이 아니라 5분이다. 롤백·회복 시각까지 그대로라면 회복 관찰시간 12분은 변하지 않으므로 탐지 개선과 복구 실행을 한 숫자로 합치지 않는다.

연습 2 — 같은 지역 v1도 1300건 중 104건, 즉 8.00% 실패했다면? 지역 A에서 v1과 v2의 실패율 차이가 사라지므로 판본 단독가설은 약해진다. 안전한 롤백을 완화로 선택할 수는 있어도 “v2 때문에 발생했다”는 원인결론은 지역 공통 NW·외부의존성·설정 등을 더 비교한 뒤 내려야 한다.

연습 3 — 수정판 100% 단계가 10000건 중 실패 40건, p95 240 ms, 잘못된 결과 0건이라면? 선언한 자체 기준에서는 실패율 0.40%, p95 240 ms, 오류결과 0건으로 그 단계는 통과한다. 다만 이 제한된 관찰창 통과를 장기 신뢰성·모든 원인 제거·사람의 운영 승인으로 확대하지 않는다.