03. 일반적인 네트워크 장애 대응 프로세스?

 

---

 

네트워크에 어떤 장애가 일어났을 때 대응 방법은 상황에 따라 다릅니다. 일어날 수 있는 상황은 장치의 하드웨어 고장, 소프트웨어 장애, 외부 요인 등 다양합니다. 또한 장애 탐지의 타이밍과 원인 분석 방법, 복구 방법도 다릅니다. 엄밀히 말해 이런 장애 대응 방법들을 패턴화하기는 어렵지만 큰 틀을 파악하고 시간순으로 대응 패턴을 정리할 수 있습니다.

여기서는 ‘장애 탐지와 접수’, ‘원인 분석’, ‘복구 작업’의 세 대응 패턴으로 나눠서 장애 대응의 흐름을 설명합니다.


장애 탐지와 접수

애당초 장애가 일어났다는 것을 어떻게 알 수 있을까요? 크게 두 종류가 있습니다.
• 운용 및 유지 보수 회사가 장애를 탐지한다.
• 고객(사용자)이 장애를 알아챈다.


운용 및 유지 보수 회사가 장애를 탐지한다

운용 및 유지 보수 회사가 장애를 탐지하면 해당 상황을 고객의 담당자에게 연락합니다.
그다음 원인 분석과 복구 작업이 진행됩니다.

그렇다면 어떻게 운용 및 유지 보수 회사가 장애를 탐지할 수 있을까요? 운용 및 유지 보수 회사에 있는 네트워크 감시 장치가 자동으로 탐지해 주기 때문입니다.

일반적인 장애 대응의 흐름

운용 및 유지 보수 회사가 장애를 탐지한다

고객(사용자)이 장애를 알아챈다

고객(사용자)이 장애를 알아채는 경우도 있습니다. 사용자는 네트워크를 실제로 사용 중이므로 어떤 문제가 발생하면 당연히 문제를 알게 됩니다. 그러나 장애를 발견한 사용자는 네트워크 전문가도 아니며 진단 도구가 있는 것도 아닙니다. 대부분의 사용자는 ‘갑자기 서울로 전화가 걸리지 않는다’, ‘인터넷이 안 된다’와 같은 정도의 내용만 정보 시스템 부서(고객 담당자)에게 연락해서 전합니다.

정보 시스템 부서는 사용자로부터 얻은 정보, 상황이나 경위를 종합합니다. 사내 시스템을 가장 잘 알고 있으므로 어떤 장애가 발생했을 때 어느 운용 및 유지 보수 회사에 연락하면 될지 잘 알고 있습니다. 곧바로 운용 및 유지 보수 회사로 장애를 신고합니다. 또한 상주 보수 요원이 있는 경우 주간 시간대에는 상주 보수 요원에게 연락합니다.

고객(사용자)이 장애를 알아챈다

 

신고를 받은 운용 및 유지 보수 회사는 장애 상황에 대해 기술적인 측면에서 고객에게 문진해 원인을 분석한 후 복구 작업을 합니다.


원인 분석

원인 분석은 현장의 상황을 파악하는 것부터 시작합니다. 우선 정보를 수집한 후 장애 진단 작업, 원인 특정의 순서로 진행합니다.

정보 수집하기

정보 수집 단계에서 대략적인 장애 부분에 대한 가설을 세웁니다. 정보 수집이라는 말은 간단하지만 상황은 천차만별입니다. 그러나 어떤 상황이더라도 고객으로부터 듣는 요점은 같습니다. 아래의 요점에 대해서 구체적으로 청취하게 됩니다.

네트워크나 시스템은…
• 누가 사용하지 못하는가 ― 전부? 한 명만?
• 누구를 대상으로 사용하지 못하는가 ― 특정한 상대방하고? 모든 상대방하고?
• 언제부터 ― 오늘? 이전부터?
• 어느 장소에서 ― 자기 자리에서? 다른 자리에서?
• 어떻게 ― 항상? 가끔씩?

그러나 현실적으로 긴급을 요하는 고객에게는 시간을 들여서 청취하기 어려운 경우가 있습니다. 그럴 때는 아래 두 가지 요점을 청취합니다.

• ‘지금은 네트워크 사용이 가능한가요?’
• ‘최근이나 방금, 네트워크나 시스템과 관련된 작업을 한 적이 있나요?’

우선 지금도 영향이 있는지를 확인합니다. 그다음 ‘무언가 고객 네트워크 환경에 변화는 없었는가?’라는 관점에서 질문합니다. 왜냐하면 가끔씩 주변의 영향으로 네트워크에 장애가 일어나는 경우가 있기 때문입니다. 예를 들면 공조나 전원 설비 공사 등으로 인해 네트워크나 시스템이 다운되는 경우도 있습니다.

네트워크나 시스템은 도입 작업이 끝나 운용 및 유지 보수 단계에 들어간 직후의 시기를 제외하면 WAN 회선이나 기기의 소프트웨어 장애(버그)가 없는 한 기본적으로는 안정됩니다. ‘외부 요인에 의한 장애가 의외로 많다’는 점을 기억해두기 바랍니다.

중요
원인 분석 시 기억해두면 좋은 내용
■ 우선, 지금 네트워크를 사용할 수 있는지 확인한다.
■ 고객의 네트워크에 변화가 없었는지 확인한다.
■ 네트워크 장애는 도입 직후의 시기를 제외하면 외부 요인에 의한 장애가 많다.

외부 요인에 해당하는 실제 사례를 몇 가지 소개합니다.

• 계획된 정전이 있었고 네트워크 감시 장치에서 알람을 탐지했다.
• 다른 네트워크 기기의 설정 변경 작업으로 인해 라우팅 정보가 사라졌다.
• 공사업자가 배선 공사를 할 때 네트워크 기기의 LAN 배선, 전원 코드, 플러그를 뺐다.
• 빌딩에서 계획된 정전이 있었고 전기업자가 실수로 차단기를 내려서 시스템이 다운됐다.
• 전산실의 공조가 고장 나서 실내의 온도가 상승해 네트워크 기기가 자동으로 정지(기기에 따라서는 40도가 넘으면 자동적으로 정지하는 것도 있다)했다.


원인을 특정하기

운용 및 유지 보수 회사는 수집한 정보를 바탕으로 장애 부분을 좁혀 나갑니다. 그리고 콘솔 단말을 사용해 고객 장치에 원격으로 로그인해 장애 진단 작업을 합니다.



복구 작업

복구 작업은 원인을 특정하고 나서 진행하게 됩니다. 또한 복구 작업은 현장에 상주하고 있는 보수 요원이 있다면 그 사람이 대응합니다(일차 진단). 그러나 하드웨어 장애 등 제품 자체의 장애가 발생했을 때는 서비스 센터에 대기하고 있는 보수 요원이 현장에 출동해 복구 작업을 실시합니다.

보수 요원이 현장에 출동한다(복구 작업)

출동한 보수 요원은 원인이 네트워크 기기의 하드웨어 고장이라면 교환 작업을 합니다. 그런데 가장 성가신 것은 소프트웨어의 버그가 의심스러울 때입니다. 즉, 현장에 도착하니 장애가 자연스레 사라졌을 때입니다. 그럴 때는 장치의 로그나 설정 정보를 보수 요원이 콘솔 단말로 수집해 서비스 센터로 가지고 갑니다. 그리고 해당 네트워크 기기의 제조사에 분석을 의뢰하고 답변을 기다립니다. 제조사에서 답변을 받으면 그에 따른 조치를 합니다. 원인이 버그라면 소프트웨어 업데이트를 실시합니다. 이 작업을 마치면 완전 복구 상태가 됩니다.


주의 
소프트웨어 버전 업데이트는 고객의 몫
기본적으로 소프트웨어 버전 업데이트 작업은 고객의 몫입니다. 보수 요원이 진행하는 경우에는 일반적으로 비용이 청구됩니다.
운용 업무의 범위를 고객과 합의하고 운용 설계서와 같은 문서의 형태로 관리하는 것이 중요합니다.


중요
고객이 네트워크를 사용할 수 있도록 하는 것이 최우선
완전 복구까지 시간이 필요한 경우는 잠정 복구를 우선시해 고객이 네트워크를 사용할 수 있도록 하는 것을 첫 번째로 생각합시다.

예를 들면 이중화된 네트워크 구성에서 망 전환을 반복해 통신이 불안정할 때 한쪽 네트워크 기기를 의도적으로 정지시켜 단중화 상태로 운용합니다. 이렇게 하면 단중화 상태지만 망 전환을 반복하는 일이 없어져 통신 자체는 안정됩니다. 그 이후에 시간을 두고 장치 교환 등 항구적인 대책을 마련하는 것이 현장의 철칙입니다.