IT 정보시스템 장애 예방 및 대응에 대한 생각

IT정보시스템 장애 예방 및 대응에 대한 기본 개념 및 생각

 

정보시스템을 개발하고 운영하는 사람들은 해당 서비스의 운영시간에 대해 보통 집착하게 된다.

그 서비스의 중요성과 성격에 따라 그 업무에 대하는 신중도와 피로도는 매우 크다.

이렇게 매우 예민하고, 세심하게 시스템을 개발하고 운영하더라도 장애는 필수불가결 발생하게 되어있다.

이는 마치 갑자기 찾아오는 질병과 같은 것이다.

 

 

시스템 장애는 언제든 발생할 수 있다.

서비스를 운영하는 조직의 상위책임자는 이러한 질병을 예방하고, 치료하는 것도 중요하게 생각하지만

이에 앞서 책임을 추궁하거나 장애의 발생 가능성 자체를 수긍하려 하지 않는다.

이러한 IT 정보시스템 장애에 대한 인식(사내문화)을 포함하여 장애에 대해 글을 작성해보고자 한다.

 

#1. "IT시스템" 완벽할 수 있는가?

 

  IT시스템은 한 순간에 뚝딱만들어 질 수 없다. 만들기전 어떠한 기능을 요구하는지 세심하게 정리하여 IT기술적으로 다양한 설계가 필요하다. 이 과정은 시스템 규모에 따라 짧게는 일주일 길게는 몇년까지 소요되는 경우가 있다. 요구사항을 통해 데이터를 모델링하고 기술셋을 정한다.

 

  사용자의 동시접속 수나 접속 수준을 파악하여 서버나 데이터베이스의 종류와 규모도 결정한다. 또한 운영을 위한 각종 써드파티 제품이나 소프트웨어 등도 결정한다. 실제 개발의 효율성을 위해 소스관리 툴도 결정하고 협업을 위한 업무 프로세스 등도 결정한다.

 

  길고 오랜 노력끝에 시스템을 개발하고 다양한 테스트를 진행을 했음에도 정보시스템 장애는 발생할 수 있다. 기술간에 연결고리와 일정 부분이 수정된 경우 다른 부분에 파급되는 영향, 당장은 문제가 없더라도 지속되었을때 등을 원인으로 장애는 발생할 수 있다. 이를 위해 시스템 모니터링이라는 용어가 존재하는 것이고 이상 징후를 모니터링하고 천천히 장애의 발생을 알려오는 데이터에 집중한다. 하지만 천천히 장애의 신호를 알려주면서 등장하는 경우는 매우 좋은 케이스이다.

 

 

  특히 하드웨어의 장애의 경우 갑작스러운 경우가 많다. 라우터 통신 장비가 갑자기 고장나거나 서버의 메인보드 또는 네트워크 카드에 장애가 발생한다. 이러한 경우는 물리적으로 기계적인 고장, 결함까지 해결할 수 없어 보통 기기자체를 이중화 하거나 하는 기술을 사용한다. 하지만 동시에 두개의 기기가 우연의 일치로 하드웨어가 고장나게 된다면? 이러한 사유로 정보시스템은 완벽할 수 없고 완벽하더라도 장애로 부터 100% 안전할 수 없다.

 

#2. 정보시스템 장애에 대한 인식을 개선해야한다.

  이러한 불가피한 정보시스템 장애임에도 불구하고 사람들의 인식은 너그럽지 못하다. 여기서 사람들이란 사용자가 아닌 조직 내부의 장애에 대한 후속조치 문화에 대한 것이다. 당연히 사용자 측면에서는 장애로 인한 서비스 이용에 대한 불편함을 느끼는 것은 당연한 것이며 운영자도 이에 대한 책임을 느끼고 장애발생 가능성을 최소화 해야한다.

 

  하지만 대부분의 IT회사를 보면 불가피한 사유로 장애가 발생하고 후속조치로 그 원인과 대응에 대해 조직책임자에게 내용이 공유 또는 보고가 되면 이를 이해하지 못하고 담당자의 책임을 추궁한다. 해당 담당자도 서비스의 안정적인 운영을 위해 지속적으로 해왔음에도 불구하고, 심지어 장애가 발생함을 인지하고 재빠르게 대처했음에도 조직 내부에서 질타를 받는다.

 

 

  외국의 경우에는 시스템 장애의 발생 그 자체에 대한 책임 추궁보다 발생 가능성을 낮추고 서비스의 정상화를 위한 다양한 대응력에 대해 초점을 맞춘다. 시스템 또는 IT 담당자의 업무에 대한 성실도와 평소 안정적인 운영을 위해 힘써준 것에 암묵적으로 인정하고 존중해주는 것이다. 이러한 장애에 대한 인식 개선이야 말로 IT담당자로 하여금 장애 예방을 위한 다양한 활동과 대응력 제고를 통해 조직에 대한 기여도를 높일 수 있는 하나의 방안일 것이다.

 

#3. 정보시스템 장애를 예방하려면 어떻게?

  장애의 발생을 예방하기 위한 방법으로는 다음과 같은 것들이 있다.

 

• 다양한 팀(개발팀, 서버운영팀, DB팀 등)간 기술적인 교류 및 원활한 의사소통
• 기기 이중화 등 멀티 채널로서 서비스의 안정적인 설계를 통한 구현 
• 시스템 개발 및 적용전 테스트 서버를 활용한 다양한 케이스의 테스트 및 디버깅
• 운영시스템에 변경하고자 하는 내용을 연관 모든 팀이 공유하고 다양한 적극적인 피드백을 제공
• 테스트 서버와 운영 서버의 환경을 정확히 일치시키기 위해 지속 관리
• 시스템 모니터링 강화
• 시스템의 주요 파라미터 등의 값을 추적하고 연관팀에 공유

  위와 같은 예시들이 정보시스템 장애를 예방하기 위한 방안이라고 할 수 있다. 

 

#4. 정보시스템 장애를 처리하는 대응방안은?

그렇다면 장애가 발생한 경우 조직적인 차원에서 어떻게 효율적으로 대응해야 할까?

 

 

우선 재빠른 탐지를 위해 한눈에 시스템 상황을 확인할 수 있는 시스템 대시보드나 SMS 등을 통한 알람기능이 있을 것이다. 이러한 알람 기능은 예를 들어, 서버로 통신하는 네트워크 장비에서 ping 이 failed 된 경우나 서버가 down 된 경우 혹은 메모리가 임계치 이상 상승한 경우에 동작시킬 수 있다.

 

재빠른 탐지 그 이후에는 우선 장애 상황임을 재빠르게 인식하고, 조치해야 할 사항을 관련 담당자하고 빠르게 소통하고 대응방안을 마련해야한다. 그 이후 연관팀과 팀내 책임자등 비상대응조직 등에게 장애발생 사실을 보고해야한다. 하지만 매우 긴박한 경우 선처리 후보고가 올바른 방안이다. 다만 이는 운영하는 정보시스템의 서비스 다운타임에 대한 민감도와 조직 문화에 따라 조치와 보고의 중요성은 달라질 수 있다.

 

재빠르게 복구한 이후 연관팀을 추적하여 다른 문제가 발생한 것이 없는지 확인을 요청하고, 서비스가 정상적인지 시스템 모니터링을 강화해야한다. 그 이후 서비스가 어느정도 안정화가 된다면 장애의 원인을 회상하고 동일 문제로 인한 장애발생 가능성을 차단 또는 최소화하고 이와 유사한 장애가 발생할 우려에 대해 점검하고 대비해야 한다.

 

이러한 다양한 유형의 장애들은 정보시스템 운영에 있어서는 경험이며 동일한 장애가 발생한 경우에 대비하여 자동화 복구방안이나 대응 매뉴얼 등을 상세히 기록하고 공유해야한다.

 

#5. 장애에 대한 실제사례

장애에 대한 실제사례는 매우 많으나 세부정보는 제외하고 핵심만 간단히 몇 가지 정리해보겠다.

 

우선 이중화된 서버의 NIC 카드가 네트워크 오류가 순간적으로 발생(n초) 하여 인터페이스가 down 되었으며, 이로 인해 하나의 서버로는 접근이 불가능한 상태가 되었다. 이에 따라 n초로 설정해둔 임계치 값을 n+m (m) 만큼 증가시켰다.

 

 

운영서비스의 deadlock 이슈가 발생하여 SQL을 점검하였고 동시에 수행되는 프로그램에 대한 우선순위 설정과 locking에 대한 SQL 등의 수정을 권고하였다.

 

 

SWAP 메모리의 FULL과 각종 서비스 계정의 패스워드 문제, 담당자의 휴먼에러 또는 Fat Finger 등 이외에도 많은 사례가 있다.

 

 

정보시스템 장애의 발생과 대응에 대한 4줄 요약

• IT정보시스템 장애의 발생은 사람에게 발생하는 크고 작은 질병과 같은 존재이다.
• 장애 발생가능성을 낮추고, 대응력을 강화하기 위한 정보시스템 장애에 대한 넓은 인식 개선이 필요하다.(조직적 차원)
• 담당 시스템에 대한 루틴한 업무이외에 다양한 장애발생을 예방하기 위한 방안을 탐색하고 시스템에 적용 해야한다.
• 장애발생시 재빠른 대처가 필요하며 이후 재발방지를 위한 대책을 세우고 연관팀과 적극 공유 해야한다.