'hanmail'에 해당되는 글 1건

  1. 2008.07.24 한메일 서비스 장애에 관한 단상 (2)
2008.07.24 01:45

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

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

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

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

2. 배포 시간

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

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

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

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

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

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

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

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

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

Trackback 0 Comment 2
  1. Channy 2008.07.24 03:57 address edit & del reply

    QA입장에서 봤을때, 이번 사고는 모든 장애가 그렇듯이 이해하기 힘든점이 있습니다. 사고란게 원래 QA에도 불구하고 나는게 일반적이니까요. 내부적으로 확인해본 결과, 배포한 오후 시간대가 일과 시간 중 사용량이 적은때라고 하더군요. (아침과 저녁에 이메일 확인이 가장 많아서요.)

    기능 장애에 대해서는 공지에도 나와 있듯이 구현하려던 기능이 회원 정보의 로그인 기록과 연동 하는 부분이라서 충분한 테스트를 하고도 배포시 뭔가 꼬였을 가능성이 큽니다. 사내 직원들만 쓰는 한메일 서버에서 주로 실 서버 테스트 후 배포를 하게 되거든요. 사실 형상 관리나 테스트 프로세스가 명확했어도 개발자가 코드 리뷰가 부진하거나 연동 후 환경이 바뀐 상황을 인지하지 못하거나 하면 여지없이 터지는 사고 유형과 비슷합니다.

  2. Mulder™ 2008.07.24 10:32 신고 address edit & del reply

    오후시간대가 사용량이 적은때라는건 새로 알게된 사실이네요.
    사용량이 적다고 해도 우리나라 사람들이 이메일을 주로 사용하고 있는 메일중에 하나이고,
    아무리 적다하더라도 그시간대에 사용자가 분면 수만명이 되지않았을까요?
    그래도 이해가 안되는 부분이라면 사용자 세션을 고려해서 서버 접속을 차단하고
    작업을 진행했어야 하는건 아닌지?
    그리고, 배포시 뭔가 꼬였다는건 저도 서비스 런치를 많이 해봐서 잘 알고 있습니다.
    중요한건, 문제가 발생했을 경우 피해를 받게되는 정도를 파악하지 못했다는것입니다.
    뭐, 다음입장에서 사용자가 적은 시간대에 작업을하는것이기때문에 비율로 따져보면
    상당히 퍼센티지가 낮을수 있지만, 상대적인 비율 말고 그 시간대에 사용하고 있을 사람들
    즉 절대적인 비율을 생각하셨어야하는것이 맞는것이 아닌지 궁금하네요.
    그리고, 다음측에서 메일 서비스라는것이 중요한 서비스로 인지되고 있다고 생각하고있습니다.
    그렇다면 당연히 서버접속 차단후에 작업을 진행하는것이 맞습니다.
    실제 서버에 배포시 문제점이 발생하는것을 잘 알고도 이렇게 배포되었다는것 자체가
    이해가 안되는 부분입니다. 테스트는 그 이전 문제입니다.
    QA는 Product 혹은 서비스의 처음부터 끝까지 관여합니다.
    그래서 제가 언급했듯이 QA적 입장에서 말씀을 드린것이구요.
    답변은 QA적 입장이 아니라 테스트만 고려하고 쓰신것같습니다.
    그리고 이런 사고를 막기 위해 QA라는 조직이 필요한것이구요.