보안 필수장비를 업그레이드할 때 참사를 면하려면 계획을 세워 검토하는 것이 우선이다.

이는 막대한 손실을 가져다 주는 사태를 막고 위험에 직면했을 때 좀더 원활하게 대처하기 위해서다. 추측은 금물이며, 테스트 체계를 확보하는 것이 중요하다. 확실한 기초공사와 계획을 통해 이와 유사한 참사를 겪지 않도록 노력하자.

필자는 중대한 보안 하드웨어인 방화벽을 업그레이드해야 한다고 확신했다. 업그레이드는 심장 이식만큼 중대한 사안이었다. 방화벽에 내 목숨이 달려있는 것이나 마찬가지였다. 전력을 다해 필요한 수술을 무사히 마쳤고, 이에 뿌듯해하고 있었다.

하지만 얼마 지나지 않아 그것이 착각이었음을 알게 되었다. 일상적인 보수 창이 엄청난 재난을 일으킨 것이다. 원인을 알 수 없는 장애가 주기적으로 발생하면서 우리를 완전히 궁지에 몰아 넣었다. 화면에는 분명히 방화벽 규칙이 사용되고 있다고 표시되는데 트래픽이 들어가서 나오지를 않는 것이었다. 결국, 추가 시도 끝에 문제를 해결하기는 했지만, 그것은 이미 대규모 정전이 한 번 휩쓴 후였다.

나중에, 이 재난은 벤더의 방화벽 코드 내에 침입한 알려지지 않은 한 버그가 그 원인이었음이 밝혀졌다. 업그레이드를 하기 전에 좀더 계획적으로 시스템을 검토했다면 대규모 정전이라는 초유의 사태없이 문제에 대해 좀더 원활하게 대처할 수 있었을 것이다. 이 일을 통해 우리는 몇 가지 교훈을 얻을 수 있었다.

첫째, 절대 추측하지 말라는 것이다. 필자는 업그레이드하기 전에 방화벽 시스템에 대한 개인적인 생각을 실제로 입증하고 구성 방식에 대해 정확한 기준을 가지고 있는지 검토했어야 했다. 예를 들어, 방화벽들이 클러스터링 되어 있는데, 업그레이드를 하기 전에 이 클러스터의 두 요소가 모두 실제로 동기화되고 있는지 확인하지 않았다.

두 번째 교훈은 테스트 체계를 확보해야 한다는 것. 우리는 업계 현황에 대한 정확한 정보가 없었기 때문에 이 업그레이드가 연구소에서 분석한 것과 비교해서 너무나 급작스러운 움직임이라는 사실을 깨닫지 못했다.

또한, 적절한 테스트 방식이 무엇인지에 대한 지식도 전무했기 때문에, 실제 환경에 적용되는 테스트 케이스도 없었다. 업그레이드가 잘 되었는지를 확인하는데 급급하지 말고, 시스템의 한쪽 경계에서 다른 쪽 경계에 걸쳐 특정 서비스들을 테스트했어야 했다. 재검 과정에서 우리는 테스트 결과들을 예측할 수 있었으므로, 방화벽에 산발적으로 장애가 발생해도 보다 빠르게 문제의 속성을 격리시킬 수 있었다.

마지막 교훈은 백아웃(Back-Out) 계획과 같은 든든한 유지보수 프로세스를 확립해야 한다는 사실이다. 우리의 경우, 방화벽이 성공적으로 업그레이드됨으로써 체계적인 워크플로우가 부족하다는 사실이 그냥 묻혀 넘어가게 된 것이다. 미리 성공을 가정하고 실패에 대한 계획은 세우지 않았다. 그러다가 장애가 발생하자 완전히 허를 찔린 것이다. 백아웃을 결심하기 전에 얼마 동안 지속적으로 문제를 해결할 것인지 생각해보지도 않았던 것이다.

재시도를 위해, 필자는 Microsoft의 도표작성 프로그램인 Visio를 통해 위기 상황에 대한 미리 지정된 고장 대치(Fallback) 기능이 포함된 프로세스의 논리 흐름을 생성해보았다. 비록, 예상치 못한 장애들이 발생하기도 했지만, 몇 시간에 걸친 주니퍼의 지원 담당자와의 전화 상담 끝에 안전하게 버그를 분석할 수 있었다.

우리에게 버그보다 더 심한 타격은 처음 장애가 발생하였을 때 정상적인 상태로 신속하게 돌아올 수 없었다는 점이다. 확실한 기초 공사와 계획을 통해 이와 유사한 참사를 겪지 않도록 노력하자.     

<글: 스콧 시들(Scott Sidel)>