2008.07.24 01:45

한메일 서비스 장애에 관한 단상

7월 22일 발생한 한메일 서비스 장애에 관한 소식을 자주 방문하는 동호회 사이트를
통하여 간접적으로 듣게 되었습니다.
타인 계정의 메일 목록이 노출되어버리는 문제점이라고 하더군요.
사실 한메일을 사용하지 않는 저로서는 피해는 없었지만,
혹시나 하는 마음에 몇일이 지난 오늘에서야 다음에서 근무하시는 윤석찬님의 블로그를 방문했습니다.
솔직히 다음에서 노출되고 있는 장애에 관한 사과문보다는 좀더 기술적으로 접근이 가능하지 않을까하는
마음에 블로그를 검색하던 중  한메일 타인 계정 노출 사고 유감 이라는 글을 읽게 되었고, 이에
QA Engineer 입장에서 몇자 적어보려고 합니다.

1. 왜 작업을 평일 낮시간대에 하였는가?

   - 사실 이 부분이 가장 이해가 되지않는 부분입니다.
     사용자의 수, 사용 빈도수를 봤을때 사용량이 상당히 높은 시간일것입니다.
     보통 이런 작업들은 새벽시간 사용자들의 접속이 낮은 시간대에 해야하고,
     대부분의 기업들이 그렇게 하고 있습니다.
     특히나 로그인관련 부분이라면 각 서버별로 로그인 세션등을 고려했을때,
     모든 접속자의 세션을 끊어버리고 작업을 진행해야하는것이 정석이라 생각됩니다.
     정말 개념없는 행위입니다.
     아무리 사소한 부분의 업그레이드라도, 만약을 대비해서 배포가 실패하거나 오류가 발생하여
     RollBack(이전 상태로 되돌리기) 을 해야하는 상황까지 고려가 되어있어야합니다.
     결론적으로 전혀 고려가 되어있지않다는 결론입니다.

2. 배포 시간

"개발자 시각에서 객관적으로 봤을 때, 한메일 서버는 대략 수백 대가 넘고 특정 업그레이드를 배포하는데 시간에 따라 순차적으로 진행합니다. 따라서, 문제가 된 코드가 배포되는 중 사용자들의 어떤 서버가 어떻게 피해를 입었는지 파악하기 위해서는 물리적으로 시간이 필요 합니다. 게다가 문제를 발견했을 때 수정본을 배포하는데 걸리는 시간도 만만치 않았을 겁니다." from Channy

   -만약 이런 사실을 알고 있다면 더욱 사용자 접속을 막아놓은채 작업을 진행했어야합니다.
    개인적인 경험으로 봤을때, 각 서버로 배포하는데 그리 오랜 시간이 걸리지 않는것으로 알고 있습니다.
    물론 각 서버별로 순차적으로 반영을 하는것이겠지만, 오래 걸렸던것 같지는 않습니다.

3. 테스트는 충분히 이루어졌는가?

대개 프로그램 상에서 어떤 기능을 수행할 때 인증된 사용자 정보를 확인하고, 기능을 호출하게 되어 있는데 타인 계정의 메일 목록이 보였다는 것은 기능 향상 배포본에서 인증 기능을 실수로 빠뜨렸거나, 계정 정보를 받아오는 루틴에서 오류가 났거나 했을 것 같습니다. 타인 메일 목록만 보였다는 점에서 그런 가능성이 있습니다. (이것은 물론 회사의 입장이 아니라 개인적인 추측입니다.) from Channy

   - 차니님께서 말씀하신것처럼
      만약 배포본에서 인증 기능을 실수로 빠뜨렸다면 개발완료본과 배포본이 다르다는것입니다.
      형상관리가 제대로 이루어지지 않는다는 이야기이고, 배포본으로 테스트가 이루어지지않았다는
      이야기입니다.
      계정 정보를 받아오는 루틴에서 오류가 났다는 이야기는 프로그램 자체 오류일 수도 있고,
      테스트 서버와 실제 서버의 환경이 정확히 일치하지 않았을 수도 있다고도 생각 할 수 있겠습니다.
      그래서 항상 테스트 서버에서 테스트가 끝나면 실제 서버에서도 꼭 확인을 해야합니다.
      결론적으로 개발이 제대로 이루어지지 않았을뿐만 아니라 테스트도 제대로 이루어지지 않았다는
      이야기입니다.

본인이 특정 기업의 개발이나 QA에 관하여 뭐라고 평가하기에는 다소 무리가 있겠지만,
이전 V3 대란 이후로 다음이라는 큰 기업에서 이런 문제가 발생한것에 대해 다소 유감을 표명하는 바입니다.
이로서 품질보증을 위한 일련의 행위들이 얼마나 중요한 것인가를 다시금 생각해 볼 수 있는
좋은 기회가 아닐까 하는 생각을 해봅니다.

이전에도 중요성을 강조했지만, 이런 문제가 발생하게 되면 고객 혹은 사용자로 부터 신뢰를 잃게 됩니다.
품질은 곧 신뢰입니다.

결론적으로 충분한 테스트가 이루어지지 않았다는 생각이 들고, 문제가 발생했을 경우를 대비하는 부분이
미흡했다고 생각됩니다. 문제 발생을 예상했다면 적어도 낮시간대에 작업을 진행하지는 않았겠죠?
사용자를 배려하여 업그레이드를 진행했지만, 정작 사용자를 혼란스럽게 만들고 마는 결과를 초래했습니다.

앞으로 좀 더 철저한 품질관리가 필요할 것같습니다.

Trackback 0 Comment 2