Exchange Production 환경에서의 TroubleShooting 시 주의점

 시스템을 운영하다 보면, 늘 정상적이고 평범한 상황에서 진행되는 경우는 거의 없습니다.

 개선, 도는 증설 프로젝트 중이건 아니건, 장애는 늘 발생하고 , 해당 장애를 해결하고 원인을 규명하기 위한 노력은 지속되게 되죠.

 

 능숙한 엔지니어 일수록 Trouble Shooting  에 사용하는 도구는 가장 기본적인 것 부터 시작하게 됩니다.

 이벤트 로그, 부팅 메시지 등등등…

 운이 좋으면 덤프가 남아 있을 수도 있고…

 

 하지만, 차라리 시스템에 죽어 버리거나 덤프가 발생하게 되면, 오히려 처리하기가 쉽습니다. 문제는 Hang 이 걸리면, 무한 루프가 돌건… 사용자가 영향을 받기 전에는 문제를 탐지 할 수 없는 경우가 많고, 특히 내부적으로 개발하거나 프로젝트 중에서 개발된 모듈이 Data 를 잘 못 Handling  할 경우 그 문제를 찾기가 더더욱 힘들다는 겁니다.

 

 왜냐 하면, 시스템의 입장에서는 정상 동작을 하고 있는 것일 테니까요.

 이런 경우 Exchange 에서는 기본적으로 사용하게 되는 Tool 들이 있습니다.

 

1. Exchange Diagnostic log

• 익스체인지의 각 모듈들… Store, Transport…. 들의 Activity 를 상세하게 잡는 방법입니다.

2. Exchange Trouble Shooting Assistant

• 추가적인 정보를 수집할 때 사용하는 것들인데… 어느 정도의 수준의 Data 를 수집하는 정도인지는 잘 모르겠네요…

 

두 가지 툴 다, MS 의 Premier 급 엔지니어가 아니면 해독할 수 없는 자료는 수집합니다.

 

이 글의 주제는 이 두가지 툴이 아니라, 이 두가지 툴 뿐만 아니라 다른 툴로라도 Data 수집을 설정할 경우 주의해야 할 부분이 중요한 주제 입니다.

 

모든 Data 수집 도구는 시스템의 부하를 발생시킵니다.

아무리 부하가 없는  Tool  이라도 최소한 HDD 의 IO 를 발생시키는 것은 자명한 사실이겠지요?

 

두가지 툴 뿐만 아니라 모든 툴로 모니터링을 걸 때 지원 엔지니어에게 물어야 할 사항이 있습니다.

 

1. 이 툴이 생성하는 부하가 어느 정도인지 (메모리, CPU  점유율 등), 그로 인한 사용자의 성능 체감은 얼마나 영향을 받는지…
2. 이 툴이 생성하는 로그는 어느 정도인지, 그로 인한 HDD 공간과, HDD 의 IO 발생은 얼마나 되는지
3. 이 툴을 활성화 하고 나서 자동적으로 불활성화 되는지, 이 툴을 설치할 경우 시스템의 영향은 얼마나 되는지, 또 삭제할 경우 정상적인 삭제가 가능한지 또는 리부팅을 요구하는지…
4. 이 툴이 발생시킬 수 있는 운영상의 충돌은 어떤 것인지?
5. 문제 해결 또는 Data 수집 완료 후 이 툴을 계속 활성화 시켜야 하는지…

 

향후 책임 문제와 시스템의 안정적인 운영을 위해서도 꼭 필요한 질문입니다.

이 질문을 체크리스트화 하여, 꼭 사전에 물어 보셔야 합니다

 

이 질문이 누락될 경우 향후 큰 문제가 발생할 수 있습니다.

 

사례 1.

1. 국내 대기업의 라인에 동작하는  서버 상의 Verifier 를 활성화 시킨 후 재부팅으로 인하여 라인의 생산 장애 발생
2. 국내 대기업의 익스체인지 서버 상에 지원을 위한 Tag 활성화 이후 불활성화 하지 않는 상태로 운영, 추가적인 Feature 추가시 익스체인지 주요 엔진의 지속적인 Crash 발생

 

문제 발생 후 담당 엔지니어는 해당 Tool 이 발생시킬 수도 있는 Side effect 에 대하여 공식적인 견해를 표현하기를 거부하였습니다. 애매모호한 형태의 대답만 나올 뿐이죠…

 꼭… 문제 해결을 위한 개선 작업 전에 물어 봐 두도록 합시다. 적어도 메일 정도는 받아 두는게 좋겠죠?