장비 하나가 고장 나면 어디까지 함께 멈출까

고장 난 장비와 함께 멈춘 업무는 같은 범위가 아니다 ↑

장애 범위는 고장 난 부품의 위치가 아니라 그 부품 때문에 영향을 받는 단말과 업무까지 포함합니다. 원인 하나가 여러 곳의 증상으로 나타날 수 있으므로 둘을 따로 기록해야 합니다.

A1이 멈추면 A1에만 연결된 PC-A는 접속을 잃습니다. A2의 PC-B는 계속 연결돼 있을 수 있습니다. 그러나 두 단말이 사용하는 인증 서버가 A1 뒤에만 있다면 PC-B도 새 업무에 로그인하지 못할 수 있습니다. PC-B의 물리 링크는 정상인데 업무에는 접속하지 못하는 상황입니다.

이때 “A1에 연결된 단말만 영향”이라고 쓰면 공통 서비스의 의존성이 빠집니다. 고장 난 장비에서 시작해 직접 끊긴 연결을 찾고, 그 연결이 필요한 업무까지 순서대로 따라갑니다. 이미 인증된 세션과 새 로그인이 다른 결과를 보일 수 있으므로 사용자의 동작도 구체적으로 기록합니다.

장애 범위를 좁히려면 같은 업무가 정상적으로 되는 단말도 비교해야 합니다. 같은 업무를 다른 구간에서 수행해 보고, 주소·이름 해석·인증·응답에서 어디까지 같은지 대조합니다. 한 번의 성공이 서비스 전체가 항상 정상이라는 증거는 아니지만, 공유하는 부분과 달라지는 부분을 찾는 실마리가 됩니다.

장애 범위는 장비 목록뿐 아니라 업무 기능으로도 적습니다. 같은 스위치에 연결된 프린터와 인증 서버가 함께 멈추면 단말 수보다 더 넓은 서비스 영향이 생길 수 있습니다. 직접 끊기는 연결과 그 기능에 의존해 뒤따라 실패하는 업무를 구별해 기록합니다.

설계자는 장애별로 예상한 중단 범위를 업무에서 허용한 범위와 비교합니다. 작은 현장은 전체 중단 뒤 교체를 받아들일 수 있고, 다른 현장은 일부 구역만 멈추도록 구성을 나눠야 할 수 있습니다. 장애 범위를 작게 만드는 것 자체보다 어떤 업무 요구를 충족하기 위해 나누는지 명확히 하는 것이 우선입니다.

전원·배선·논리 연결·서비스의 의존성을 겹쳐 본다 ↑

같은 망에는 여러 종류의 장애 경계가 겹쳐 있습니다. 물리 도면 한 장이나 VLAN 목록 하나만으로 모든 실패 범위를 판단할 수는 없습니다.

물리적으로는 장비의 전원 입력에서 PDU와 공급 회로까지 따라갑니다. 광 케이블도 포트가 다르다는 사실보다 건물 사이에 어떤 관로를 지나는지가 중요합니다. D1과 D2가 서로 다른 장비여도 같은 회로와 관로에 의존한다면 전원 중단이나 관로 손상 때 함께 끊길 수 있습니다.

논리적으로는 VLAN이 어디까지 이어지고 어떤 라우팅 경계가 있는지 봅니다. 하나의 L2 문제가 같은 VLAN을 공유하는 구간에 영향을 줄 수 있지만, 라우팅 경계가 있다고 모든 서비스 장애가 그 안에 갇히지는 않습니다. 상향 경로와 공통 제어 기능의 의존성은 여전히 따로 남습니다.

서비스 계층에서는 이름 해석·인증·주소 배정·업무 서버를 연결합니다. DNS 서버가 둘이라는 목록도 두 서버가 같은 가상화 호스트나 저장소에 있다면 같은 장애를 함께 겪을 수 있습니다. 서버 주소가 서로 달라도 같은 호스트나 저장소가 멈추면 두 서버를 모두 사용할 수 없는 것입니다.

공통 DNS가 있다는 사실만으로 모든 통신이 즉시 함께 끊긴다고 단정할 수도 없습니다. 이미 주소를 알고 있는 흐름과 새 이름 해석이 필요한 요청은 영향 시점이 다를 수 있습니다. 의존 기능과 사용 시점을 함께 적어야 예상한 장애 범위와 실제 관찰을 비교할 수 있습니다.

마지막으로 관리 경로와 변경 체계를 겹칩니다. 업무 장애 때 사용할 관리 접속이 같은 경로를 쓰는지, 같은 설정 템플릿이 여러 블록에 한 번에 적용되는지 표시합니다. 사용자 패킷 경로 외에 관리 접속과 설정 배포 경로까지 그려 두면, 장비를 이중화하고도 운영 중 함께 멈출 수 있는 부분을 찾을 수 있습니다.

아래 망은 D1·D2로 길을 나누었지만, 두 장비의 전원과 두 DNS 서버의 실행 호스트는 각각 하나입니다. 패킷이 지나는 실선에 전원·서비스 의존성을 겹쳐 보면, 장비를 두 대 두고도 함께 멈출 수 있는 지점이 드러납니다.

D1과 D2에서 전원·관로·설정 변경 경로를 각각 따라가 보겠습니다. 장비가 두 대여도 한 곳의 문제로 함께 멈출 수 있는 부분이 드러납니다.

선 두 개가 하나의 사건에 함께 끊기는지 확인한다 ↑

장비와 링크가 두 개씩 있어도 같은 원인으로 함께 멈출 수 있습니다. 전원과 배선 중 무엇을 분리했고 어떤 구간은 계속 공유하는지 확인해야 합니다.

D1·D2의 전원 케이블을 다른 멀티탭에 꽂았다고 하겠습니다. 두 멀티탭이 같은 공급 회로라면 회로 장애에 대한 독립성은 없습니다. 멀티탭 하나의 고장에는 도움이 되더라도 회로 전체가 끊기면 두 장비 모두 멈출 수 있습니다. 시험표에는 멀티탭 고장과 공급 회로 중단을 별도 행으로 둡니다.

광 링크도 두 포트를 쓰지만 같은 관로 X를 지날 수 있습니다. 링크 한 가닥만 분리하는 시험에서는 대체 경로가 남아도 관로 손상에서는 둘 다 없어집니다. 독립 경로 Y를 추가했다면 배선 기록과 현장을 대조해 X와 Y가 실제로 다른 길을 지나는지 확인합니다. 도면에 다른 색으로 그려 놓아도 실제 관로가 같으면 두 링크는 함께 끊길 수 있습니다.

공통 소프트웨어와 설정 오류는 다른 종류의 공유 원인입니다. 같은 모델과 설정이 운영 일관성을 높일 수 있지만, 한 결함이나 잘못된 변경이 두 장비에 함께 영향을 줄 가능성도 평가해야 합니다. 이를 이유로 무조건 이기종 장비를 섞으면 관리·상호 운용 위험이 새로 생기므로 선택의 근거가 필요합니다.

경로가 분리돼 있는지 확인하지 못했다면 문서에도 미확인으로 남깁니다. 서로 다른 회선 사업자를 사용해도 건물 인입 관로나 중간 시설을 공유할 수 있습니다. 계약상 경로 분리와 실제 확인 가능한 물리 경로를 구분하고, 확인되지 않은 공통 구간은 남은 위험으로 기록해야 합니다.

가용성 계산에서 두 장비의 고장 확률을 단순히 곱하려면 독립성 같은 가정을 먼저 설명해야 합니다. 여기서는 확인되지 않은 확률로 가용성을 계산하기보다, 장애별로 어떤 기능이 계속 동작하는지 살펴보겠습니다. 검증하지 못한 공통 원인은 별도의 위험으로 기록합니다.

허용 영향을 넘는 지점에서 설계와 변경 단위를 나눈다 ↑

장애의 영향을 줄이려면 필요한 통신은 유지하면서, 한 구역에서 문제가 생겨도 다른 구역의 업무는 계속될 수 있도록 장비와 경로를 나누어 배치합니다. 모든 구간을 잘게 나누면 관리할 연결과 정책만 늘 수 있으므로, 업무에 필요한 만큼 분리하는 것이 중요합니다.

서로 다른 통신실의 단말이 같은 L2 구간을 유지해야 하는지부터 확인합니다. 실제 요구가 IP 통신뿐인데 VLAN을 여러 곳으로 확장했다면 라우팅 경계를 앞당기는 대안을 비교할 수 있습니다. 주소 이동이나 L2 인접성을 요구하는 애플리케이션이 있다면 그 조건을 먼저 검토해야 합니다.

설계 단위와 변경 단위도 맞춰 봅니다. 블록 A를 정비할 때 블록 B가 계속 운영돼야 한다면 두 블록을 한 번에 바꾸는 공통 작업이 남아 있는지 확인합니다. 별도 장비로 나누었어도 동일한 자동화 변경이 동시에 들어가면 변경의 영향 범위는 더 넓을 수 있습니다.

주소 계획을 블록과 대응시키면 범위 설명과 경로 요약에 도움이 됩니다. 다만 주소 대역을 정리했다고 물리 장애나 공통 서비스 실패가 차단되는 것은 아닙니다. 주소 경계, VLAN 범위, 전원과 배선의 경계를 같은 도면에서 비교하고 서로 어긋나는 부분의 이유를 기록합니다.

여기서는 고장 하나가 어느 장비와 업무까지 영향을 주는지 먼저 정리합니다. 대체 경로로 얼마나 빨리 바뀌는지는 이중화 글에서 따로 살펴보겠습니다. 장애 범위를 나누는 설계와 실제 전환 시간을 재는 시험은 각각 필요합니다.

고장 하나가 어디에서 발생했는지에 따라 끊기는 단말과 남는 경로가 달라집니다. 네 가지 장애에서 어떤 기능이 사라지는지 비교합니다.

경계를 나눈 뒤 늘어난 운영 책임도 설계에 포함한다 ↑

장애 범위를 나누면 새로운 연결과 관리 항목이 생깁니다. 분리로 줄어든 영향과 그 대가로 늘어난 운영 복잡성을 함께 비교해야 실제로 유지할 수 있는 설계가 됩니다.

VLAN과 라우팅 경계를 늘리면 관리할 주소·경로·정책도 많아집니다. 공통 서비스를 여러 위치에 배치했다면 데이터와 설정을 일치시키고 장애 감지·복구 절차를 마련해야 합니다. 장비를 추가하는 것으로 끝나는 것이 아니라, 운영 중에도 설정과 정책을 맞추고 장애 전환을 계속 점검해야 합니다.

구간별 담당자가 정해져 있지 않으면 장애 때 임시 우회나 예외 정책에 의존하기 쉽습니다. 어느 팀이 설정을 바꾸고, 누가 업무 영향을 확인하며, 어디에 되돌림 자료를 보관하는지 적습니다. 설계도와 운영 책임표의 단위가 맞지 않으면 작은 변경에도 어느 팀이 확인하고 조치할지 혼선이 생길 수 있습니다.

현재 인력과 점검 체계로 유지하기 어려운 구성이라면 단순한 대안도 비교합니다. 단순한 구성으로도 중단 범위와 복구 시간을 지킬 수 있는지 확인하고, 충족하지 못하는 부분은 감수해야 할 위험으로 기록합니다. 구성의 우열은 장비 수나 도면의 복잡함이 아니라 필요한 가용성을 실제로 유지할 수 있는지로 판단합니다.

범위를 작게 나누면 연결과 정책의 관리 항목이 늘어날 수 있습니다. 반대로 크게 묶으면 변경 한 번의 영향이 넓어집니다. 어느 쪽이 항상 우수하다고 정하지 말고, 운영자가 감당할 복잡도와 업무가 허용할 중단 범위를 같은 비교표에 두고 판단해야 합니다.

마지막으로 장애별 영향표와 장비·서비스의 연결 관계를 보여 주는 도면을 남깁니다. 장비·관로·전원·서비스 중 하나를 잃거나 변경에 문제가 생겼을 때 어느 업무가 남는지 운영자가 읽을 수 있어야 합니다. 실제 사고가 나면 이 예상과 관찰을 대조해, 설계 때 예상하지 못한 장애가 생겼는지 조사할 수 있습니다.