SOA-C03 16/16 — 종단 간 Incident 운영 흐름

정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.

1. Incident는 서비스 이름보다 고객 영향에서 시작한다

01~15에서 배운 도구를 하나의 흐름으로 묶는 목적은 더 빨리 많은 설정을 바꾸는 데 있지 않다. 어떤 고객 기능이 실패했는지 확인하고, 증거로 범위를 좁혀, 영향을 줄이는 조치를 검증 가능하게 수행하는 것이다.

영향 확인 → 증거 수집 → 원인 범위 축소
                         ↓
                 복구 선택·실행
                         ↓
                 기능·안전성 검증
                         ↓
              기록·재발 방지·절차 개선

AWS Well-Architected는 운영·보안·신뢰성·성능·비용·지속가능성의 선택과 trade-off를 검토하는 틀이다. 이 구간에서는 SOA의 다섯 도메인이 장애 대응에서 어떻게 만나는지에 집중한다. Well-Architected Framework

2. 영향과 사건의 우선순위를 정한다

처음 확보할 정보는 영향 기능, 시작 시각, 영향 사용자·Region·AZ, 오류율·지연·손실 가능성, 진행 중인 변경이다. Resource alarm 하나가 울렸다는 사실과 고객 업무가 실패했다는 사실을 연결하되 동일하게 취급하지 않는다.

예를 들어 CPU 경보가 발생했어도 고객 응답은 정상일 수 있다. 반대로 CPU가 낮아도 잘못된 인증서나 권한 때문에 전체 요청이 실패할 수 있다. 먼저 사용자 기능의 신호와 서비스 지표를 같은 시간축에 놓는다.

운영 사건의 담당자, 필요한 escalation, 고객에게 알려야 할 영향과 다음 안내 시점을 정한다. 조사·복구·소통 역할이 겹치더라도 무엇을 누가 판단하는지 남겨 중복 변경을 줄인다. 이벤트·Incident 관리

AWS Health의 서비스·계정 관련 사건도 확인한다. 해당 Region·resource의 event가 가설을 보조할 수 있지만 AWS Health에 표시가 없다는 이유로 애플리케이션이 정상이라고 단정하지 않는다. AWS Health

3. 증거를 질문에 맞게 선택한다

확인할 질문	먼저 연결할 증거	관련 구간
언제 얼마나 나빠졌나	사용자 지표·CloudWatch·alarm history	01·02
어디서 지연·오류가 생겼나	log·trace·compute/storage/DB 지표	01·04·05
무엇이 바뀌었나	CloudTrail·Config·배포·Git 이력	01·08·09
자동화는 어디까지 했나	EventBridge delivery·Lambda·Automation 결과	03·10
어떤 권한·보호가 막았나	caller·IAM·KMS·security finding	11·12
어느 경로에서 실패했나	DNS·Flow Logs·ELB·edge·container 로그	13·14·15
어떻게 복구할 수 있나	capacity·replica·backup·복원 지점	06·07

Metric은 현상의 규모와 시간, log는 개별 사건의 맥락, trace는 요청의 단계 관계를 보여 준다. CloudTrail의 변경과 오류 시작이 가깝다는 것은 상관관계이며, 그것만으로 원인이 확정되지는 않는다.

Evidence를 남길 때 account·Region·resource ID·query 시간 범위·timezone·배포 version을 포함한다. 같은 이름의 resource나 다른 기간의 화면을 비교해 잘못된 원인을 만들지 않는다. 비밀값 대신 식별자·오류 코드·권한 경계를 기록한다.

4. 가설은 반증 가능한 형태로 줄인다

“네트워크가 이상하다” 대신 “새 subnet의 NACL이 DB 응답 포트를 차단한다”처럼 예상 관찰을 포함한다. 이 가설이면 새 subnet만 실패하고 관련 흐름에서 거부가 보일 수 있다. 반대로 DB가 요청을 받고 인증 오류를 반환했다면 다른 설명을 검토해야 한다.

관찰	지지하는 조사 방향	아직 결론낼 수 없는 것
배포 직후 새 task만 실패	image·task role·설정 차이	배포 코드 자체가 유일한 원인
모든 AZ에서 DB 연결 대기 증가	공통 DB·연결 관리·쿼리	웹 capacity 부족 여부
특정 ISP·지역만 지연	인터넷 경로·edge·resolver	전체 AWS Region 장애
API AccessDenied	실제 principal·action·정책	어떤 정책 문장이 원인인지
backup job 성공	recovery point 생성 결과	실제 복원·업무 재개 성공

상태를 크게 바꾸는 실험보다 읽기 전용 관찰과 정상·실패 집단 비교부터 진행한다. 변경이 필요하면 가설에 맞는 최소 범위로 하고, 다음 결과가 무엇이면 가설을 지지하거나 버릴지 미리 정한다.

5. 완화와 원인 제거를 구분한다

완화는 현재 영향을 줄이는 행동이다. 원인 제거는 같은 조건에서 재발하지 않도록 바꾸는 행동이다. 이전 version으로 rollback해서 오류가 줄어도 잘못된 배포가 통과한 이유와 필요한 예방 조치는 남아 있다.

Capacity가 부족하면 확장 후보를 검토하되 DB·quota·subnet·시작 시간 제약을 본다.
배포 회귀이면 rollback 가능성과 데이터·schema 호환성을 확인한다.
데이터 손상이면 정상 복구 시점을 선택하고 별도 복원·검증·전환을 설계한다.
권한 누락이면 필요한 principal·action·resource 조건을 수정한다.
악성 활동이면 증거 보존·접근 제한·credential 교체·서비스 영향의 관계를 판단한다.

RPO는 허용 가능한 데이터 손실, RTO는 허용 가능한 복구 시간의 목표다. “snapshot이 있다”는 이유만으로 목표를 만족한다고 보고하지 않는다. 복사·복원·의존성 준비·DNS 또는 endpoint 전환·사용자 기능 확인까지 걸린 시간을 본다.

Runbook은 알려진 절차를 단계·입력·성공 조건으로 표현하고, playbook은 원인이 정해지지 않은 상황의 조사 분기와 근거를 안내하는 방식으로 생각할 수 있다. 사람이 검증한 절차를 자동화하더라도 권한·대상·재시도·중복 효과·중단 조건을 유지한다.

6. 자동화의 완료 표시는 증거의 한 단계다

03·10에서 본 것처럼 EventBridge가 target에 전달했다는 사실과 Lambda·Automation이 업무 효과를 만들었다는 사실은 다르다. API가 accepted를 반환한 뒤 resource가 준비되는 비동기 구간도 있다.

요청 접수
≠ 각 target 실행 완료
≠ 실제 resource가 원하는 상태
≠ 고객 기능 회복

실행 ID, 대상별 결과, 실제 resource 상태, 사용자 관찰을 연결한다. 부분 성공이면 전체를 다시 실행하기 전에 이미 생긴 효과를 확인한다. 재시도는 idempotency와 함께 설계한다.

AI 기반 조사·복구 제안도 사용한 telemetry와 확인 가능한 근거에 연결한다. 제안의 자신감 표현은 실행 권한이나 실제 복구 증거가 아니다. 기존 runbook·변경 범위와 대조해 적용하고 같은 검증 기준을 사용한다.

7. 완성된 종합 사례 — 배포 뒤 주문 조회가 실패한다

다음은 실제 사고 기록이나 평가 문항이 아닌 설명용 사례다. 두 AZ의 ALB·ECS·RDS 서비스에서 새 배포 직후 주문 조회 오류가 증가했다고 가정한다.

영향 확인. 주문 조회의 오류율·지연·시작 시각을 고정한다. ALB health가 정상이어도 health path가 DB를 사용하지 않을 수 있다. 주문 생성·조회 등 기능별 영향을 나눠 본다.

범위 축소. ALB의 target 응답과 container log를 동일 request ID·시각으로 연결한다. 새 task에서만 DB 인증 오류가 발생하고 이전 task는 정상이라는 관찰을 얻었다고 가정한다. DNS·TCP 실패보다 새 version의 secret 참조·권한·소비자 설정을 먼저 조사할 근거다.

변경 확인. Task definition의 image digest·role·environment·secret 참조와 배포 diff를 비교한다. 실제 로그가 secret 조회의 AccessDenied인지, DB가 반환한 인증 오류인지 구분한다. 전자면 조회·KMS 권한, 후자면 사용한 credential version·DB 상태가 중심이다.

복구 선택. 이전 version이 현재 DB schema와 호환되고 정상 처리한다면 rollback 또는 트래픽 축소를 검토한다. Secret rotation이 있었으면 이전 task의 cache 덕분에 잠시 정상인 상황도 배제하지 않는다. 단순히 기존 task가 현재 정상이라는 사실만으로 장기 복구 수단을 결정하지 않는다.

실행과 검증. 선택한 조치의 실행 ID와 대상별 상태를 기록한다. 새 요청의 주문 조회 성공, 허용된 role의 필요한 접근, 잘못된 주체의 차단, DB 연결·오류율을 확인한다. ALB healthy 표시와 deploy completed만으로 종료하지 않는다.

후속 조치. Secret 참조 변경을 검토할 배포 기준, 실제 dependency를 사용하는 검증, task version별 오류 관측을 보완한다. 임시로 늘린 capacity·허용 규칙·verbose logging이 남아 있으면 목적과 종료 조건을 확인한다.

이 과정은 02의 관측, 05의 DB 연결, 08·09의 배포, 10의 자동화, 11·12의 접근·secret, 13~15의 경로 증거가 하나의 사건에 모이는 예다.

8. 복구 종료는 미리 정한 기능과 관찰 구간으로 판단한다

복구 기준에는 정상 기능·데이터 무결성·오류율·지연·대기 작업 처리·필요 권한·남은 위험이 포함된다. 지표 하나가 정상으로 돌아왔다는 이유로 모든 기능이 복구됐다고 보고하지 않는다.

관찰 구간은 workload의 주기와 실패 특성에 맞춘다. 매시간 실행되는 job을 수정한 뒤 짧은 대기만으로 재발하지 않는다고 단정할 수 없다. 다음 실행 또는 동등한 검증 결과가 필요하다. 해결된 항목과 아직 관찰 중인 항목을 분리해 소통한다.

사후 분석은 타임라인, 기여 요인, 탐지·대응에서 잘된 점과 지연된 점, 개선 항목·담당자·검증 방법을 남긴다. 개인 비난 대신 시스템과 절차의 재현 가능한 개선에 연결한다. 개선 issue를 만든 사실과 개선이 배포·검증된 사실도 구분한다. 운영 개선

9. 16구간을 다시 읽을 때의 연결

서비스 이름이 떠오르면 정의만 복기하기보다 입력·관찰 대상·권한·결과·실패 처리·검증 경계를 이어 본다. 같은 증상에도 서로 다른 원인이 있으며, 같은 서비스도 상황에 따라 다른 판단 지점에서 사용된다.

시험에서는 주어진 요구·제약·운영 오버헤드에 맞는 수단을 선택한다. 실제 운영에서는 누락된 환경 조건을 확인하고 변경 후 결과를 검증해야 한다. 이 본문 작성은 실제 실습·평가·숙달의 증거가 아니다. 공식 평가 자료를 이용한 측정과 다음 학습 전달 시점은 별도로 정한다.

계획과 연결

ID: 16-end-to-end-incident-operations
의존: 01-operational-signals-and-evidence부터 15-network-troubleshooting-and-evidence까지
결정 축: 영향 확인, 증거 수집, 원인 범위 축소, 안전한 복구, 검증, 재발 방지 변경을 하나의 반복 가능한 운영 흐름으로 묶는다.
범위: 다섯 도메인의 서비스 관계, AWS Well-Architected 운영 관점, 권한·자동화·복구의 검증 경계.
시험 매핑: 전 도메인 종합. 공식 평가 자료 사용은 별도 승인 후 수행한다.
학습 안내
전체 계획

DanzzaN

탐색기