Ⅴ-12. 컴퓨터 시스템 장애 복구 후 정상 상태 검증 분석

Ⅴ-14. 컴퓨터 시스템 장애 복구 후 정상 상태 검증 분석

컴퓨터 시스템에서 장애가 발생한 후 오류가 사라지고 서비스가 다시 실행되었다고 해서 장애 복구가 완전히 끝났다고 판단해서는 안 된다.

재부팅이나 서비스 재시작만으로 일시적인 증상이 사라질 수 있지만, 장애를 발생시킨 조건이 그대로 남아 있거나 시스템 내부에 불안정한 상태가 지속되고 있을 수도 있기 때문이다.

따라서 장애 대응의 마지막 단계에서는 단순히 “다시 작동하는가?”를 확인하는 것에서 끝나지 않고,

복구 작업이 실제로 정상 상태를 회복시켰는가?
복구 후에도 시스템이 안정적으로 유지되는가?
동일한 장애가 다시 발생할 가능성은 없는가?

를 단계적으로 확인해야 한다.

1. 복구 완료와 정상 상태는 같은 의미가 아니다

장애 복구 과정에서 가장 쉽게 발생하는 판단 오류는 서비스가 다시 실행되면 정상으로 판단하는 것이다.

예를 들어 서버를 재부팅한 후 애플리케이션이 정상적으로 실행되었다고 하더라도 다음과 같은 문제가 남아 있을 수 있다.

• CPU 사용률이 이전보다 높게 유지됨
• 메모리 사용량이 계속 증가함
• 저장장치 I/O 지연이 지속됨
• 네트워크 오류가 반복됨
• 특정 프로세스가 계속 오류를 발생시킴
• 시스템 로그에 동일한 경고가 반복됨
• 하드웨어 오류 카운트가 증가함

따라서 다음 세 가지를 구분해야 한다.

상태	의미
복구 작업 완료	재부팅, 서비스 재시작, 장치 교체 등의 복구 작업이 끝난 상태
서비스 정상	사용자가 요구하는 주요 기능이 다시 동작하는 상태
시스템 안정화	기능뿐 아니라 자원·로그·장치 상태 등이 정상 범위에서 지속되는 상태

즉,

복구 작업 완료 ≠ 서비스 정상 ≠ 시스템 안정화

이다.

2. 복구 후 검증의 목적은 정상 상태를 증명하는 것이다

복구 후 검증은 단순히 오류 메시지가 없어졌는지를 확인하는 과정이 아니다.

핵심은 장애 이전의 정상 상태와 비교하여 시스템이 실제로 정상 범위로 돌아왔는지 확인하는 것이다.

이를 위해 다음과 같은 질문을 순서대로 확인할 수 있다.

1. 주요 서비스가 다시 실행되었는가?
2. 사용자가 실제 기능을 정상적으로 사용할 수 있는가?
3. CPU·메모리·저장장치·네트워크 상태가 정상 범위인가?
4. 새로운 오류가 발생하고 있지 않은가?
5. 장애와 관련된 이상징후가 계속되고 있지 않은가?
6. 일정 시간 동안 안정적인 상태가 유지되는가?
7. 동일한 장애가 다시 발생하지 않는가?

이러한 확인이 이루어져야 단순한 일시적 정상화와 실제 복구를 구분할 수 있다.

3. 복구 후에는 기능과 시스템 상태를 함께 확인해야 한다

시스템 자원이 정상적으로 보인다고 해서 서비스 기능까지 정상이라고 판단할 수는 없다.

반대로 사용자가 서비스를 이용할 수 있다고 해서 내부 시스템 상태가 완전히 정상이라고 볼 수도 없다.

따라서 다음 두 영역을 함께 확인해야 한다.

구분	주요 확인 항목
서비스 기능	로그인, 조회, 저장, 검색, 주요 업무 기능
애플리케이션	오류, 응답시간, 프로세스 상태
CPU	사용률, Load, 비정상적인 상승 여부
메모리	사용량, Swap, 지속적인 증가 여부
저장장치	I/O 지연, 오류, 장치 상태
네트워크	연결 상태, 오류·Drop, 통신 안정성
OS	시스템 로그, 이벤트, 오류 반복 여부
하드웨어	온도, 장치 상태, 오류 카운터

중요한 것은 한 가지 지표만 정상이라고 전체 시스템을 정상으로 판정하지 않는 것이다.

4. 복구 전후 데이터를 비교해야 한다

복구 결과를 판단할 때는 복구 직후의 숫자 하나만 보는 것보다 장애 이전과 이후의 상태를 비교하는 것이 효과적이다.

예를 들어 장애 이전 CPU 사용률이 평상시 일정한 범위에 있었다면 복구 후에도 그 범위로 돌아왔는지 확인한다.

저장장치 역시 단순히 I/O 오류가 사라졌는지만 보는 것이 아니라 장애 이전의 지연시간과 복구 후 지연시간을 비교할 수 있다.

기본적인 비교 흐름은 다음과 같다.

정상 상태 → 장애 발생 → 복구 작업 → 복구 직후 상태 → 일정 시간 후 상태

이렇게 시간축으로 비교하면 복구 직후에는 정상처럼 보였지만 시간이 지나면서 다시 악화되는 현상도 확인할 수 있다.

5. 장애와 관련된 지표를 우선적으로 검증해야 한다

모든 시스템 지표를 동일한 비중으로 확인할 필요는 없다.

장애 원인과 관련된 항목을 우선적으로 확인하는 것이 효율적이다.

예를 들어 저장장치 오류로 장애가 발생했다면 다음 항목을 우선 확인할 수 있다.

• 저장장치 오류 기록
• I/O 지연시간
• 장치 상태
• SMART 정보
• 파일시스템 오류
• 관련 OS 이벤트
• 동일 오류의 반복 여부

네트워크 장애였다면

• 연결 상태
• 오류 및 Drop
• 인터페이스 상태
• 통신 지연
• 관련 로그
• 특정 구간의 반복 장애 여부

등을 우선 확인할 수 있다.

즉, 복구 검증은 단순한 전체 항목 점검이 아니라 장애와 관련된 위험이 실제로 제거되었는지를 확인하는 과정이어야 한다.

6. 복구 후에도 남아 있는 이상징후를 확인해야 한다

장애가 사라졌다고 해서 장애의 원인이 제거되었다고 단정할 수는 없다.

예를 들어 저장장치 오류가 발생한 시스템을 재부팅한 후 정상적으로 부팅되었다고 하자.

이 경우 부팅이 정상이라는 사실은 운영체제가 다시 시작되었다는 것을 보여줄 뿐, 저장장치의 상태가 정상으로 회복되었다는 것을 의미하지 않는다.

따라서 다음과 같은 잔존 이상을 확인해야 한다.

• 동일 오류 로그의 반복
• 장치 오류 카운터 증가
• 비정상적인 성능 변화
• 온도 상승
• 특정 프로세스의 반복 오류
• 저장장치 또는 네트워크 상태의 불안정
• 장애 당시와 유사한 현상의 재발

이러한 이상이 계속된다면 서비스는 복구되었지만 장애 위험은 남아 있는 상태일 수 있다.

7. 복구 직후보다 일정 시간의 안정성이 중요할 수 있다

일부 장애는 복구 직후에는 정상으로 보이지만 일정 시간이 지나면서 다시 나타난다.

대표적으로 다음과 같은 경우에는 지속적인 관찰이 필요하다.

• 메모리 사용량이 시간이 지나면서 증가하는 경우
• 장시간 부하에서 문제가 발생하는 경우
• 과열에 의해 성능이 저하되는 경우
• 간헐적인 네트워크 장애
• 특정 프로세스가 반복적으로 오류를 발생시키는 경우
• 저장장치 성능이 점차 저하되는 경우

따라서 정상 판정은 특정 순간의 상태만으로 결정하기보다 정상 상태가 일정 시간 유지되는지까지 확인하는 것이 중요하다.

여기서 중요한 것은 모든 장애에 동일한 관찰 시간을 적용하는 것이 아니다.

장애의 특성과 위험도에 따라 필요한 관찰 범위를 결정해야 한다.

8. 정상 상태의 판단 기준을 미리 정해야 한다

복구 여부를 담당자의 주관적인 판단에만 맡기면 같은 시스템을 보고도 서로 다른 결론을 내릴 수 있다.

따라서 정상 상태에 대한 판단 기준을 미리 정해두는 것이 좋다.

예를 들어 다음과 같이 설정할 수 있다.

확인 영역	정상 상태 판단 예시
서비스	주요 기능 정상 응답
CPU	장애 이전의 일반적인 범위로 회복
메모리	비정상적인 지속 증가 없음
저장장치	관련 오류 및 비정상 지연 없음
네트워크	통신 및 인터페이스 상태 안정
로그	장애 관련 오류의 반복 발생 없음
하드웨어	이상 온도·오류 상태 없음
안정성	일정 시간 동안 동일 현상 재발 없음

단, 이러한 기준값은 모든 시스템에 동일하게 적용되는 절대적인 수치가 아니다.

장애 이전의 정상 상태, 서비스 특성, 운영 환경을 기준으로 설정해야 한다.

9. 정상화와 원인 제거를 구분해야 한다

복구 검증에서 특히 주의해야 할 부분이 있다.

시스템 정상화가 곧 근본원인 제거를 의미하지는 않는다.

예를 들어 시스템 재부팅 후 장애가 사라졌다면 재부팅이 시스템을 정상 상태로 되돌리는 데 도움이 되었을 수 있다.

그러나 재부팅으로 인해 메모리 상태가 초기화되거나 프로세스가 다시 시작되면서 증상이 일시적으로 사라졌을 가능성도 있다.

따라서

재부팅 후 정상 → 재부팅이 근본원인 해결

이라고 바로 결론 내려서는 안 된다.

앞선 원인 분석과 복구 검증을 연결하여 장애를 발생시킨 조건이 실제로 제거되었는지를 별도로 확인해야 한다.

10. 복구 검증 결과도 기록해야 한다

복구 후 확인한 결과를 기록해 두면 동일 장애가 재발했을 때 이전 상태와 비교할 수 있다.

최소한 다음 항목은 기록하는 것이 좋다.

• 장애 발생 시간
• 장애 증상
• 복구 작업
• 복구 완료 시간
• 복구 직후 상태
• 주요 성능 지표
• 관련 로그
• 하드웨어 상태
• 기능 검증 결과
• 관찰 시간
• 동일 장애 재발 여부
• 추가 조치 필요 여부

이 기록은 단순한 작업 이력이 아니라 다음 장애의 비교 기준이 되는 데이터가 된다.

11. 복구 검증에서 흔히 발생하는 판단 오류

복구 후 다음과 같은 판단은 주의해야 한다.

① 재부팅되었으므로 정상이다

부팅 성공은 운영체제가 다시 시작되었다는 의미이지 전체 시스템의 안정성을 보장하지 않는다.

② 오류 메시지가 사라졌으므로 해결되었다

오류가 일시적으로 사라졌을 뿐 동일한 원인이 남아 있을 수 있다.

③ 서비스가 접속되므로 정상이다

서비스의 기본 접속뿐 아니라 주요 기능과 성능까지 확인해야 한다.

④ CPU와 메모리가 정상이라 시스템도 정상이다

서비스, 저장장치, 네트워크, 로그, 하드웨어 상태가 별도로 문제가 있을 수 있다.

⑤ 복구 직후 정상 상태만 확인하면 된다

시간이 지나면서 다시 나타나는 장애가 있으므로 필요한 경우 일정 기간의 안정성을 확인해야 한다.

12. 복구 검증은 장애 원인 분석과 연결되어야 한다

복구 검증은 단순히 장애 대응의 마지막 체크리스트가 아니다.

앞에서 분석한 원인 후보와 실제 복구 결과를 비교하면 원인 분석의 정확성도 다시 검증할 수 있다.

예를 들어 특정 저장장치가 원인 후보였다면 해당 장치에 대한 조치 후 관련 오류와 성능 문제가 함께 사라졌는지 확인해야 한다.

반대로 복구 후에도 동일한 이상이 지속된다면 기존의 원인 판단을 다시 검토해야 한다.

즉,

원인 후보 → 복구 조치 → 상태 변화 → 정상화 여부 → 원인 판단 재검증

이라는 연결이 필요하다.

13. 복구 검증의 실질적인 판단 순서

실제 장애 대응에서는 다음과 같은 순서로 확인하면 복구 여부를 보다 명확하게 판단할 수 있다.

① 복구 작업 완료

→ ② 주요 서비스 실행 확인

→ ③ 핵심 기능 확인

→ ④ 장애 관련 자원·장치 상태 확인

→ ⑤ 로그 및 오류 상태 확인

→ ⑥ 장애 전후 데이터 비교

→ ⑦ 일정 시간 상태 관찰

→ ⑧ 동일 장애 재발 여부 확인

→ ⑨ 정상 상태 판정

이때 어느 단계에서라도 장애 당시와 유사한 이상이 지속된다면 정상 판정을 보류하고 원인 분석으로 다시 돌아갈 필요가 있다.

14. 우리가 복구를 판단할 때 봐야 하는 것은 ‘현재 상태’만이 아니다

복구 여부를 판단할 때 가장 중요한 관점은 현재 정상처럼 보이는가가 아니다.

다음 세 가지를 함께 봐야 한다.

① 지금 정상인가?

서비스와 시스템 기능이 현재 정상적으로 동작하는지 확인한다.

② 이전 정상 상태로 돌아왔는가?

장애 발생 전의 성능과 상태와 비교한다.

③ 일정 시간 동안 정상 상태가 유지되는가?

복구 직후뿐 아니라 시간이 지나도 동일한 이상이 나타나지 않는지 확인한다.

따라서 정상 판정은 단순한 한 시점의 확인이 아니라

현재 상태 + 정상 기준 + 시간에 따른 안정성

을 함께 판단하는 과정이라고 볼 수 있다.

15. Ⅴ-14 핵심 정리

컴퓨터 시스템 장애에서 복구 작업이 끝났다는 것과 시스템이 정상 상태로 안정화되었다는 것은 서로 다른 개념이다.

서비스가 다시 실행되었더라도 CPU, 메모리, 저장장치, 네트워크, 로그, 하드웨어 상태 등에 이상이 남아 있을 수 있다.

따라서 복구 후에는

복구 작업 완료 → 기능 정상 확인 → 시스템 상태 확인 → 장애 전후 비교 → 일정 시간 관찰 → 재발 여부 확인

의 과정을 통해 정상 상태를 판단하는 것이 중요하다.

가장 중요한 것은 “오류가 없어졌는가?”가 아니라 “정상 상태가 실제로 회복되었고, 일정 시간 동안 유지되고 있는가?”를 확인하는 것이다.

그리고 여기서 한 단계 더 나아가야 한다.

정상화되었다는 사실과 근본원인이 제거되었다는 사실은 별도로 검증해야 한다.

결국 장애 복구의 마지막 단계는 단순히 시스템을 다시 작동시키는 것이 아니라,

정상 상태를 확인하고 그 상태가 유지되는지를 증거로 검증하는 과정이다.컴퓨터 시스템에서 장애가 발생한 후 오류가 사라지고 서비스가 다시 실행되었다고 해서 장애 복구가 완전히 끝났다고 판단해서는 안 된다.

재부팅이나 서비스 재시작만으로 일시적인 증상이 사라질 수 있지만, 장애를 발생시킨 조건이 그대로 남아 있거나 시스템 내부에 불안정한 상태가 지속되고 있을 수도 있기 때문이다.

따라서 장애 대응의 마지막 단계에서는 단순히 “다시 작동하는가?”를 확인하는 것에서 끝나지 않고,

복구 작업이 실제로 정상 상태를 회복시켰는가?
복구 후에도 시스템이 안정적으로 유지되는가?
동일한 장애가 다시 발생할 가능성은 없는가?

를 단계적으로 확인해야 한다.

1. 복구 완료와 정상 상태는 같은 의미가 아니다

장애 복구 과정에서 가장 쉽게 발생하는 판단 오류는 서비스가 다시 실행되면 정상으로 판단하는 것이다.

예를 들어 서버를 재부팅한 후 애플리케이션이 정상적으로 실행되었다고 하더라도 다음과 같은 문제가 남아 있을 수 있다.

• CPU 사용률이 이전보다 높게 유지됨
• 메모리 사용량이 계속 증가함
• 저장장치 I/O 지연이 지속됨
• 네트워크 오류가 반복됨
• 특정 프로세스가 계속 오류를 발생시킴
• 시스템 로그에 동일한 경고가 반복됨
• 하드웨어 오류 카운트가 증가함

따라서 다음 세 가지를 구분해야 한다.

상태	의미
복구 작업 완료	재부팅, 서비스 재시작, 장치 교체 등의 복구 작업이 끝난 상태
서비스 정상	사용자가 요구하는 주요 기능이 다시 동작하는 상태
시스템 안정화	기능뿐 아니라 자원·로그·장치 상태 등이 정상 범위에서 지속되는 상태

즉,

복구 작업 완료 ≠ 서비스 정상 ≠ 시스템 안정화

이다.

2. 복구 후 검증의 목적은 정상 상태를 증명하는 것이다

복구 후 검증은 단순히 오류 메시지가 없어졌는지를 확인하는 과정이 아니다.

핵심은 장애 이전의 정상 상태와 비교하여 시스템이 실제로 정상 범위로 돌아왔는지 확인하는 것이다.

이를 위해 다음과 같은 질문을 순서대로 확인할 수 있다.

1. 주요 서비스가 다시 실행되었는가?
2. 사용자가 실제 기능을 정상적으로 사용할 수 있는가?
3. CPU·메모리·저장장치·네트워크 상태가 정상 범위인가?
4. 새로운 오류가 발생하고 있지 않은가?
5. 장애와 관련된 이상징후가 계속되고 있지 않은가?
6. 일정 시간 동안 안정적인 상태가 유지되는가?
7. 동일한 장애가 다시 발생하지 않는가?

이러한 확인이 이루어져야 단순한 일시적 정상화와 실제 복구를 구분할 수 있다.

3. 복구 후에는 기능과 시스템 상태를 함께 확인해야 한다

시스템 자원이 정상적으로 보인다고 해서 서비스 기능까지 정상이라고 판단할 수는 없다.

반대로 사용자가 서비스를 이용할 수 있다고 해서 내부 시스템 상태가 완전히 정상이라고 볼 수도 없다.

따라서 다음 두 영역을 함께 확인해야 한다.

구분	주요 확인 항목
서비스 기능	로그인, 조회, 저장, 검색, 주요 업무 기능
애플리케이션	오류, 응답시간, 프로세스 상태
CPU	사용률, Load, 비정상적인 상승 여부
메모리	사용량, Swap, 지속적인 증가 여부
저장장치	I/O 지연, 오류, 장치 상태
네트워크	연결 상태, 오류·Drop, 통신 안정성
OS	시스템 로그, 이벤트, 오류 반복 여부
하드웨어	온도, 장치 상태, 오류 카운터

중요한 것은 한 가지 지표만 정상이라고 전체 시스템을 정상으로 판정하지 않는 것이다.

4. 복구 전후 데이터를 비교해야 한다

복구 결과를 판단할 때는 복구 직후의 숫자 하나만 보는 것보다 장애 이전과 이후의 상태를 비교하는 것이 효과적이다.

예를 들어 장애 이전 CPU 사용률이 평상시 일정한 범위에 있었다면 복구 후에도 그 범위로 돌아왔는지 확인한다.

저장장치 역시 단순히 I/O 오류가 사라졌는지만 보는 것이 아니라 장애 이전의 지연시간과 복구 후 지연시간을 비교할 수 있다.

기본적인 비교 흐름은 다음과 같다.

정상 상태 → 장애 발생 → 복구 작업 → 복구 직후 상태 → 일정 시간 후 상태

이렇게 시간축으로 비교하면 복구 직후에는 정상처럼 보였지만 시간이 지나면서 다시 악화되는 현상도 확인할 수 있다.

5. 장애와 관련된 지표를 우선적으로 검증해야 한다

모든 시스템 지표를 동일한 비중으로 확인할 필요는 없다.

장애 원인과 관련된 항목을 우선적으로 확인하는 것이 효율적이다.

예를 들어 저장장치 오류로 장애가 발생했다면 다음 항목을 우선 확인할 수 있다.

• 저장장치 오류 기록
• I/O 지연시간
• 장치 상태
• SMART 정보
• 파일시스템 오류
• 관련 OS 이벤트
• 동일 오류의 반복 여부

네트워크 장애였다면

• 연결 상태
• 오류 및 Drop
• 인터페이스 상태
• 통신 지연
• 관련 로그
• 특정 구간의 반복 장애 여부

등을 우선 확인할 수 있다.

즉, 복구 검증은 단순한 전체 항목 점검이 아니라 장애와 관련된 위험이 실제로 제거되었는지를 확인하는 과정이어야 한다.

6. 복구 후에도 남아 있는 이상징후를 확인해야 한다

장애가 사라졌다고 해서 장애의 원인이 제거되었다고 단정할 수는 없다.

예를 들어 저장장치 오류가 발생한 시스템을 재부팅한 후 정상적으로 부팅되었다고 하자.

이 경우 부팅이 정상이라는 사실은 운영체제가 다시 시작되었다는 것을 보여줄 뿐, 저장장치의 상태가 정상으로 회복되었다는 것을 의미하지 않는다.

따라서 다음과 같은 잔존 이상을 확인해야 한다.

• 동일 오류 로그의 반복
• 장치 오류 카운터 증가
• 비정상적인 성능 변화
• 온도 상승
• 특정 프로세스의 반복 오류
• 저장장치 또는 네트워크 상태의 불안정
• 장애 당시와 유사한 현상의 재발

이러한 이상이 계속된다면 서비스는 복구되었지만 장애 위험은 남아 있는 상태일 수 있다.

7. 복구 직후보다 일정 시간의 안정성이 중요할 수 있다

일부 장애는 복구 직후에는 정상으로 보이지만 일정 시간이 지나면서 다시 나타난다.

대표적으로 다음과 같은 경우에는 지속적인 관찰이 필요하다.

• 메모리 사용량이 시간이 지나면서 증가하는 경우
• 장시간 부하에서 문제가 발생하는 경우
• 과열에 의해 성능이 저하되는 경우
• 간헐적인 네트워크 장애
• 특정 프로세스가 반복적으로 오류를 발생시키는 경우
• 저장장치 성능이 점차 저하되는 경우

따라서 정상 판정은 특정 순간의 상태만으로 결정하기보다 정상 상태가 일정 시간 유지되는지까지 확인하는 것이 중요하다.

여기서 중요한 것은 모든 장애에 동일한 관찰 시간을 적용하는 것이 아니다.

장애의 특성과 위험도에 따라 필요한 관찰 범위를 결정해야 한다.

8. 정상 상태의 판단 기준을 미리 정해야 한다

복구 여부를 담당자의 주관적인 판단에만 맡기면 같은 시스템을 보고도 서로 다른 결론을 내릴 수 있다.

따라서 정상 상태에 대한 판단 기준을 미리 정해두는 것이 좋다.

예를 들어 다음과 같이 설정할 수 있다.

확인 영역	정상 상태 판단 예시
서비스	주요 기능 정상 응답
CPU	장애 이전의 일반적인 범위로 회복
메모리	비정상적인 지속 증가 없음
저장장치	관련 오류 및 비정상 지연 없음
네트워크	통신 및 인터페이스 상태 안정
로그	장애 관련 오류의 반복 발생 없음
하드웨어	이상 온도·오류 상태 없음
안정성	일정 시간 동안 동일 현상 재발 없음

단, 이러한 기준값은 모든 시스템에 동일하게 적용되는 절대적인 수치가 아니다.

장애 이전의 정상 상태, 서비스 특성, 운영 환경을 기준으로 설정해야 한다.

9. 정상화와 원인 제거를 구분해야 한다

복구 검증에서 특히 주의해야 할 부분이 있다.

시스템 정상화가 곧 근본원인 제거를 의미하지는 않는다.

예를 들어 시스템 재부팅 후 장애가 사라졌다면 재부팅이 시스템을 정상 상태로 되돌리는 데 도움이 되었을 수 있다.

그러나 재부팅으로 인해 메모리 상태가 초기화되거나 프로세스가 다시 시작되면서 증상이 일시적으로 사라졌을 가능성도 있다.

따라서

재부팅 후 정상 → 재부팅이 근본원인 해결

이라고 바로 결론 내려서는 안 된다.

앞선 원인 분석과 복구 검증을 연결하여 장애를 발생시킨 조건이 실제로 제거되었는지를 별도로 확인해야 한다.

10. 복구 검증 결과도 기록해야 한다

복구 후 확인한 결과를 기록해 두면 동일 장애가 재발했을 때 이전 상태와 비교할 수 있다.

최소한 다음 항목은 기록하는 것이 좋다.

• 장애 발생 시간
• 장애 증상
• 복구 작업
• 복구 완료 시간
• 복구 직후 상태
• 주요 성능 지표
• 관련 로그
• 하드웨어 상태
• 기능 검증 결과
• 관찰 시간
• 동일 장애 재발 여부
• 추가 조치 필요 여부

이 기록은 단순한 작업 이력이 아니라 다음 장애의 비교 기준이 되는 데이터가 된다.

11. 복구 검증에서 흔히 발생하는 판단 오류

복구 후 다음과 같은 판단은 주의해야 한다.

① 재부팅되었으므로 정상이다

부팅 성공은 운영체제가 다시 시작되었다는 의미이지 전체 시스템의 안정성을 보장하지 않는다.

② 오류 메시지가 사라졌으므로 해결되었다

오류가 일시적으로 사라졌을 뿐 동일한 원인이 남아 있을 수 있다.

③ 서비스가 접속되므로 정상이다

서비스의 기본 접속뿐 아니라 주요 기능과 성능까지 확인해야 한다.

④ CPU와 메모리가 정상이라 시스템도 정상이다

서비스, 저장장치, 네트워크, 로그, 하드웨어 상태가 별도로 문제가 있을 수 있다.

⑤ 복구 직후 정상 상태만 확인하면 된다

시간이 지나면서 다시 나타나는 장애가 있으므로 필요한 경우 일정 기간의 안정성을 확인해야 한다.

12. 복구 검증은 장애 원인 분석과 연결되어야 한다

복구 검증은 단순히 장애 대응의 마지막 체크리스트가 아니다.

앞에서 분석한 원인 후보와 실제 복구 결과를 비교하면 원인 분석의 정확성도 다시 검증할 수 있다.

예를 들어 특정 저장장치가 원인 후보였다면 해당 장치에 대한 조치 후 관련 오류와 성능 문제가 함께 사라졌는지 확인해야 한다.

반대로 복구 후에도 동일한 이상이 지속된다면 기존의 원인 판단을 다시 검토해야 한다.

즉,

원인 후보 → 복구 조치 → 상태 변화 → 정상화 여부 → 원인 판단 재검증

이라는 연결이 필요하다.

13. 복구 검증의 실질적인 판단 순서

실제 장애 대응에서는 다음과 같은 순서로 확인하면 복구 여부를 보다 명확하게 판단할 수 있다.

① 복구 작업 완료

→ ② 주요 서비스 실행 확인

→ ③ 핵심 기능 확인

→ ④ 장애 관련 자원·장치 상태 확인

→ ⑤ 로그 및 오류 상태 확인

→ ⑥ 장애 전후 데이터 비교

→ ⑦ 일정 시간 상태 관찰

→ ⑧ 동일 장애 재발 여부 확인

→ ⑨ 정상 상태 판정

이때 어느 단계에서라도 장애 당시와 유사한 이상이 지속된다면 정상 판정을 보류하고 원인 분석으로 다시 돌아갈 필요가 있다.

14. 우리가 복구를 판단할 때 봐야 하는 것은 ‘현재 상태’만이 아니다

복구 여부를 판단할 때 가장 중요한 관점은 현재 정상처럼 보이는가가 아니다.

다음 세 가지를 함께 봐야 한다.

① 지금 정상인가?

서비스와 시스템 기능이 현재 정상적으로 동작하는지 확인한다.

② 이전 정상 상태로 돌아왔는가?

장애 발생 전의 성능과 상태와 비교한다.

③ 일정 시간 동안 정상 상태가 유지되는가?

복구 직후뿐 아니라 시간이 지나도 동일한 이상이 나타나지 않는지 확인한다.

따라서 정상 판정은 단순한 한 시점의 확인이 아니라

현재 상태 + 정상 기준 + 시간에 따른 안정성

을 함께 판단하는 과정이라고 볼 수 있다.

15. Ⅴ-14 핵심 정리

컴퓨터 시스템 장애에서 복구 작업이 끝났다는 것과 시스템이 정상 상태로 안정화되었다는 것은 서로 다른 개념이다.

서비스가 다시 실행되었더라도 CPU, 메모리, 저장장치, 네트워크, 로그, 하드웨어 상태 등에 이상이 남아 있을 수 있다.

따라서 복구 후에는

복구 작업 완료 → 기능 정상 확인 → 시스템 상태 확인 → 장애 전후 비교 → 일정 시간 관찰 → 재발 여부 확인

의 과정을 통해 정상 상태를 판단하는 것이 중요하다.

가장 중요한 것은 “오류가 없어졌는가?”가 아니라 “정상 상태가 실제로 회복되었고, 일정 시간 동안 유지되고 있는가?”를 확인하는 것이다.

그리고 여기서 한 단계 더 나아가야 한다.

정상화되었다는 사실과 근본원인이 제거되었다는 사실은 별도로 검증해야 한다.

결국 장애 복구의 마지막 단계는 단순히 시스템을 다시 작동시키는 것이 아니라,

정상 상태를 확인하고 그 상태가 유지되는지를 증거로 검증하는 과정이다.