설계한 망이 장애를 견디는지 어떻게 확인할까

어떤 장애를 만들고 무엇으로 복구를 확인할지 정한다 ↑

장애가 나도 안정적이어야 한다는 요구만으로는 시험의 시작과 끝을 정하기 어렵습니다. 어떤 고장을 대상으로 어떤 서비스가 어느 조건을 만족해야 하는지 구체화해야 합니다. “안정적이다”라는 말을 실제 시험에서 확인할 수 있는 기준으로 바꾸는 것입니다.

교육용 사례로 A1의 상향 링크 하나가 끊겨도 업무 요청이 3초 안에 다시 완료되어야 한다는 목표를 가정하겠습니다. 3초는 사례에서 정한 시험 기준이며 Cisco 장비의 보장 성능이나 모든 업무에 적합한 목표가 아닙니다. 실제 값은 서비스 담당자와 운영자가 합의해야 합니다.

업무 요청의 시작과 완료도 정의합니다. 새 연결이 성공하는지, 기존 세션이 유지되는지, 요청이 실제 처리되어 응답을 받는지는 서로 다른 시험입니다. 결제나 저장처럼 중복 처리가 문제가 되는 서비스는 재시도 결과까지 애플리케이션 담당자와 확인해야 합니다.

실패로 판정할 조건과 중단 조건은 별도로 둡니다. 목표 시간을 넘겼다는 결과는 시험 실패이고, 예상하지 못한 범위의 서비스 중단이나 관리 접근 상실은 시험을 즉시 멈추고 이전 상태로 되돌려야 할 조건이 될 수 있습니다. 이런 조건이 발생하면 원인을 더 관찰하려고 시험을 이어가기보다 추가 영향을 막는 것이 우선입니다.

목표가 충돌할 때의 우선순위도 시험 전에 정합니다. 손실을 줄이기 위한 우회가 보안상 금지된 경로라면 정상적인 대안이 아닙니다. 어떤 업무를 유지하고 어떤 통신은 계속 차단해야 하는지 동시에 적어야 통신을 복구하면서도 필요한 보안 정책을 유지할 수 있습니다.

이 요구에 연결되는 장비와 경로, 사용한 설정, 시험 환경을 고정합니다. 나중에 소프트웨어나 정책이 바뀌면 예전 결과가 그대로 유효한지 다시 판단해야 합니다. 검증된 것은 특정 조건의 설계와 동작이며, 같은 제품 이름을 사용하는 모든 구성이 아닙니다.

정상 상태의 왕복 경로와 부하를 먼저 기록한다 ↑

고장을 만들기 전에 정상 기준선이 있어야 결과가 얼마나 달라졌는지 판단할 수 있습니다. 단순히 현재 정상이라고 적는 대신, 어떤 단말에서 어떤 서비스가 어떤 경로와 응답으로 동작하는지 기록합니다. 정상의 범위가 불명확하면 장애 시험의 비교 기준도 흔들립니다.

PC-A의 주소·게이트웨이·이름 해석 결과와 목적지 서비스의 주소·포트를 고정합니다. 같은 요청을 일정한 방식으로 반복하고 정상 완료 시간과 오류 여부를 남깁니다. 이름 해석, 연결 성립, 인증, 실제 업무 응답을 분리하면 실패한 단계도 더 명확하게 볼 수 있습니다.

네트워크에서는 각 방향의 전달 경로와 경로별 사용량을 기록합니다. 경로표에 경로가 있다는 사실과 실제 패킷이 그 인터페이스로 나가는지는 구별합니다. 필요한 범위에서 카운터나 승인된 패킷 관찰을 사용하고, 민감한 내용은 수집 목적에 맞게 최소화합니다.

측정 장비의 시간 기준도 맞춥니다. 서로 다른 장비의 로그 시각을 비교하려면 시계 동기화 상태와 오차를 알아야 합니다. 동기화되지 않은 두 로그의 차이를 그대로 고장 감지 시간이나 복구 시간이라고 계산하면 실제 순서를 잘못 해석할 수 있습니다.

기준선의 설정과 측정 파일은 대응 관계를 남깁니다. 시험 뒤 어떤 설정에서 나온 결과인지 알 수 없다면 같은 조건으로 재현하기 어렵습니다. 기록 시각과 환경 식별, 관련 변경을 함께 보관하고 민감한 운영 정보는 인계 대상과 보관 권한에 맞게 관리합니다.

트래픽이 거의 없는 상태에서 한 시험은 바쁜 시간대의 결과와 다를 수 있습니다. 시험할 수요와 배경 트래픽의 조건을 적고 정상·고장 비교에서 유지합니다. 실제 운영 부하를 재현하지 못했다면 그 한계를 기록하고, 어떤 부하에서 시험했는지 결과와 함께 적습니다.

정상 기준선도 배치도에 기록할 위치를 표시해 두면 비교하기 쉽습니다. PC-A에서는 실제 업무 응답을, A1·D1·D2에서는 전달 경로와 사용량을 관찰합니다. 아래에서 지정한 상향 연결을 나중에 시험하더라도 같은 위치와 조건에서 결과를 비교해야 합니다.

장애별로 멈추는 기능과 남는 경로·용량을 적는다 ↑

시험 목록은 케이블을 뽑는 순서가 아니라 설계에서 대비하기로 한 장애를 기준으로 만들어야 합니다. 상향 링크 하나, 집계 장비 한 대, 전원 한 계통처럼 별도로 검토한 장애를 나누고, 각 장애가 나면 어떤 기능과 경로를 사용할 수 없게 되는지 적습니다.

A1의 상향 링크 하나를 중단하는 시험에서는 남은 링크로 양방향 통신이 가능한지 확인합니다. D1 한 대를 제외하는 시험에서는 그 장비가 제공하던 경로와 기능이 모두 사라진 조건을 봅니다. 단일 링크 시험의 성공을 장비 전체 고장에 대한 검증으로 대신하지 않습니다.

공통 전원이나 동일 관로 같은 공유 장애는 또 다른 항목입니다. 실제로 해당 범위를 중단할 권한과 안전한 시험 환경이 없다면 도면 검토나 제한된 모의 환경에서 확인할 수 있지만, 실측하지 않은 부분은 남습니다. 도면에서 확인한 내용과 실제로 장애를 만들어 측정한 결과는 구분해서 기록합니다.

시험 표에는 영향을 받는 단말과 서비스, 남는 경로, 잔여 용량, 관리 접근 방법을 함께 적습니다. 업무 통신은 살아 있는데 관리 경로가 사라질 수도 있고, 관리 화면은 열리는데 사용자 서비스가 실패할 수도 있습니다. 두 결과를 독립된 열로 남겨야 복구 가능성까지 검토할 수 있습니다.

운영망에서 시험할 때는 사전 승인과 작업 창, 영향 고지, 담당자 연락, 되돌릴 수단이 전제입니다. 본문의 도해를 운영망 시험에 적용하려면 현장 조건에 맞춘 시험 계획과 승인이 먼저 필요합니다. 운영망과 분리한 검증 환경에서 먼저 관찰한 뒤 운영 조건으로 확장할 범위를 결정해야 합니다.

상향 링크, D1 전체, 공통 전원, 장비 복귀를 별도 시험으로 나누었습니다. 각 시험에서 양방향 통신·남는 용량·관리 접속을 무엇으로 확인할지 정리합니다.

경로 변경과 업무 복구를 서로 다른 시각으로 측정한다 ↑

고장 뒤에 라우팅 로그가 안정되었다는 사실은 중요한 관찰이지만 업무 복구의 끝은 아닙니다. 경로 선택, 전달 상태 반영, 실제 패킷 왕복, 애플리케이션 요청 완료를 구별해 기록해야 어디에서 시간이 추가로 필요했는지 설명할 수 있습니다.

시험 시작 시각은 실제로 장애가 발생한 시점을 기준으로 정합니다. 운영자가 버튼을 누른 시각과 링크가 내려간 시각이 다를 수 있으므로 사용한 관찰 지점을 적습니다. 고장 이전의 마지막 성공과 이후 첫 성공도 남겨 탐침 간격에 따른 측정 한계를 표시합니다.

예를 들어 200ms마다 탐침을 보냈다면 두 탐침 사이에서 상태가 바뀐 정확한 순간까지 알 수는 없습니다. 첫 성공 탐침으로 응답이 돌아온 시각은 알 수 있지만, 장비 내부에서 복구가 끝난 정확한 시각까지 알 수는 없습니다. 탐침 자체의 왕복 시간과 시간 기록 방식도 해석에 포함합니다.

ICMP 응답이 돌아와도 업무 포트가 막혀 있거나 인증·이름 해석·연결 상태 처리에 문제가 남아 있을 수 있습니다. 실제 사용할 업무 요청을 같은 조건으로 수행하고 실패 단계와 응답 내용을 분리합니다. 단, 시험 트래픽은 승인된 범위로 제한하고 업무 데이터를 임의로 변경하지 않도록 구성합니다.

시험 도구에 문제가 생긴 것인지, 실제 서비스에 장애가 난 것인지도 구별해야 합니다. 탐침을 보내는 단말이 같은 장애 구간에서 접속을 잃었다면 목적지 서비스의 상태를 그 결과만으로 판단할 수 없습니다. 시험 단말의 위치와 경로를 기록하고 필요한 경우 독립된 관찰점의 결과와 대조합니다.

목표를 만족한 경우에도 관찰 결과와 적용 조건을 함께 남깁니다. 어느 고장에서 어떤 서비스가 얼마 만에 복구되었는지 적고, 탐침 해상도와 관찰하지 못한 구간을 표시합니다. 보고서에서도 네트워크와 애플리케이션의 복구 시간을 따로 적어, 패킷 전달 뒤 어느 단계에서 더 기다렸는지 알 수 있게 합니다.

200ms마다 보낸 탐침의 결과를 시간축에 표시했습니다. 두 탐침 사이의 정확한 복구 시각은 알 수 없으므로, 측정 간격과 첫 성공 시각을 함께 기록합니다.

복귀와 롤백까지 확인하고 미검증 항목을 인계한다 ↑

대체 경로로 서비스가 복구됐다면, 다음에는 중단했던 장비나 링크를 다시 연결해 봅니다. 원래 구성으로 돌아가는 과정에도 경로 재분산, 상태 동기화, 정책 변경이 일어날 수 있습니다. 장애 때 대체 경로로 잘 바뀌었더라도 원래 구성으로 돌아오는 과정은 따로 확인해야 합니다.

복귀 장비의 소프트웨어와 설정이 시험 기준과 일치하는지 먼저 확인합니다. 이웃 연결이 생겼다는 이유로 모든 서비스가 준비된 것은 아닙니다. 새 경로로 트래픽이 이동한 뒤 기존 세션과 신규 요청, 부하와 오류를 다시 관찰해야 합니다.

복귀 중 예상하지 못한 영향이 나타나면 사전에 정한 중단 조건에 따라 되돌립니다. 어느 설정과 연결을 어느 상태로 되돌릴지, 누가 수행하고 누가 결과를 확인할지 문서에 적습니다. 관리 경로까지 사라질 가능성에 대비한 별도 접근 수단도 필요합니다.

최종 표에는 성공, 실패, 미실행, 조건부 확인을 분리해 남깁니다. 장비 한 대 고장을 시험하지 않았는데 링크 하나 시험만으로 그 칸을 성공 처리하지 않습니다. 실패한 항목은 설계 변경과 재시험으로 연결하고, 실행하지 못한 항목은 남은 위험과 함께 담당자에게 인계합니다.

미검증 항목은 사유와 다음 확인 조건을 함께 적습니다. 장비가 없어서 시험하지 못한 경우와 위험을 승인받지 못해 실행하지 않은 경우는 후속 조치가 다릅니다. 단순한 빈칸 대신 필요한 환경과 담당자를 남겨야 다음 운영자도 무엇을 더 시험해야 하는지 알 수 있습니다.

검증 결과는 실제 장애 대응의 비교 기준이 됩니다. 정상 경로와 허용된 우회, 남는 용량, 되돌릴 조건을 운영자가 바로 찾을 수 있어야 합니다. 장애 판정과 복구에서는 이 기록으로 영향 범위와 복구 순서를 정합니다. 보안 정책을 포함한 시험 결과도 함께 넘겨야, 복구한 망에서 허용되지 않은 통신까지 다시 열리는 일을 막을 수 있습니다.