'quality'에 해당되는 글 3건

  1. 2008.07.24 한메일 서비스 장애에 관한 단상 (2)
  2. 2008.07.23 SW Quality Insight 정기 세미나
  3. 2008.07.11 V3 대란에 대한 단상 (1)
2008.07.24 01:45

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

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

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

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

2. 배포 시간

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

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

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

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

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

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

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

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

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

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 2
2008.07.23 10:40

SW Quality Insight 정기 세미나

사실 최근 QA관련 세미나 혹은 컨퍼런스등 많은 행사가 진행되고 있지만,
솔직히 부담이 되는 참가비때문에 회사를 다니고 있지않은 사람들에게는 부담이 되기 마련입니다.
간혹 무료로 진행하는 행사도 있어서 빠지지않고 참석하고 있습니다.
관심있으신분들은 참석해보시길...

물론 어디까지나 많은것을 바라지말고, QA에 관한 감을 잊지말자는 취지하에...

아래 신청하기 페이지로 이동하셔서, 회원가입 후에 신청하시기 바랍니다.

신청하기

SW Quality Insight 정기 세미나
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 0
2008.07.11 10:52

V3 대란에 대한 단상

문제의 요지는 V3와 Win XP SP3간의 충돌문제였습니다.
V3 엔진이 운영체제 파일을 악성코드로 오인하여 발생한 문제더군요.

일단 V3 대란이 발생하게 된 원인을 살펴보고 싶습니다.
안랩의 테스팅 혹은 QA 관한 자세한 내용을 모르고 있기때문에,
뭐라고 말하기에는 조금 부족하겠지만...
일단 소프트웨어의 테스팅에 있어서 최소한 다양한 환경에서의 확인이 필요한 것은
당연한 이치인데, 아마도 이점이 부족하지 않았나 생각됩니다.

Windows XP SP3와의 호환성 내지는 최소한의 확인작업이 이루어져야한것은 당연한
일이겠죠?

일단 안랩에서의 사후조치는 잘한것이라고 생각이 들지만,
신뢰를 잃어버린것은 당연한 결과라 생각됩니다.

사용자들의 불편이 이만저만 아닌 상태여서 사후조치를 한들 사용자들이
이미 신뢰를 저버린 상태이기때문에, 신뢰를 회복하기에는 아마 오랜 시간이 걸릴것같습니다.

아무쪼록 피해를 입으신분들은 하루빨리 복구하셔서 예전 모습을 되찾으셨으면 합니다.

안랩 사과문

복구관련

무엇보다도 소프트웨어의 품질이라 함은 결론적으로 그 회사의 신뢰와 아무 밀접한 관계가 있다고 생각합니다.
따라서 소프트웨어의 품질 = 신뢰 라는 결론이 내려지는군요.
테스팅이나 QA활동의 전반적인 부분은 어떤 문제점을 찾아서 해결하기 위한 활동들이 대부분이고
이런 활동들이 결론적으로 그 회사의 신뢰를 높이는데 기여한다는 것입니다.
특히나 요즘은 다양한 사용자 환경속에서 어느부분에서 문제가 발생할지 예측하기 힘듭니다.
좀더 다양한 환경에서 테스팅이 진행되어야함은 물론이고 사용자에 대한 배려가 필요한 시기인것같습니다.

P.S
혹자는 이번 사태가 안랩쪽 문제만은 아니라고 하는군요. 거대한 음모가 뒤에 숨어있다는...
진실은 저 너머에...여기까지~ 더 알면 다쳐요~

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Trackback 0 Comment 1


티스토리 툴바